delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/06/21:44:40

Message-Id: <200003070231.VAA02693@qnx.com>
Subject: Re: iso646.h and some questions
To: djgpp-workers AT delorie DOT com
Date: Mon, 6 Mar 2000 21:31:10 -0500 (EST)
From: "Alain Magloire" <alain AT qnx DOT com>
In-Reply-To: <Pine.LNX.4.10.10003061537270.14313-100000@acp3bf> from "Hans-Bernhard Broeker" at Mar 06, 2000 03:42:31 PM
X-Mailer: ELM [version 2.5 PL0b1]
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> 
> On Sun, 5 Mar 2000, Eli Zaretskii wrote:
> 
> > > Shall I send header files containing new functions, so other people
> > > can start implementing them?
> > 
> > IMHO, the prototypes should be added to the headers only *after* the
> > functions are already available.  Otherwise, we might get conflicts (when
> > building a package that provides its private versions of the missing
> > functions), and some people think that the existence of a prototype is an
> > evidence that the function is provided by the library. 
> 
> I oppose to this point. As long as there are, indeed, plans to implement
> these functions in the near future, I think it's best to put in the
> prototypes right now, as a method of staking a claim. Among others, it may
> help catching unwary program authors that use names now reserved by the
> new standard library, for their own purposes. They'll get compiler error
> messages about conflicting prototypes, early, instead of having to rewrite
> their programs, later on. 

My experience speaks otherwise, but you surely have a valid point.
Many configuration scripts will not be smart enough and take the existence
of a MACRO or prototype as existence of a feature.  And as Eli mentionned
some packages come with a compatibility lib to provides the necessary bits.
for example, say strdup() was not yet implemented or malloc():
Some packages may provide a stub in the form of
#ifdef __COMPAT__
char *strdup (char *);
void *malloc (int); 
#endif
and this will conflict with.
char *strdup (const char *);

In the end, one may consider this to be a good thing, 
 
> Given that these are standardized functions, there's no risk we'll break
> any compatibility unwillingly by getting those prototypes wrong, either,
> so let's just put them in.

But one thing that would be really bad, IMHO. Would be to provide
"fake" functions 'till the proper ones are written.  This would confuse
any autoconfiguration and make the programs behave incorrectly.
I remember spending an afternoon debugging 'till I realize
char *getlogin () was a stub return NULL in the C lib, unfortunately
this was deep .. deep in hugue global constructors.


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019