To:	dj AT stealth DOT ctron DOT com (DJ Delorie)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: ansi/posix results
Date:	Wed, 23 Nov 94 08:22:50 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

> * When you say you're an ansi program, or a posix program
> (_POSIX_SOURCE), you will only get the prototypes and defines that
> ansi/posix say you are required to have available to you.

I would suggest that ``ansi program'' be checked with the __STRICT_ANSI__
(sp?) symbol which, if memory serves, GCC defines *only* if you
specify -ansi switch to the compiler.  This is as opposed to the __STDC__
symbol which is always defined by GCC unless you say -traditional.  I
don't think that whoever uses non-ansi functions should be punished
by forcing him to write traditional-style (i.e., no prototypes) code.

> * Internally, libc will use the __ff functions when an ansi function
> calls a posix function, or when either call a non-posix function, so
> that the application may redefine those without messing up libc.a.

That would bring maximum independence to the library functions, which
is good.  But I would also suggest to pull non-POSIX PC-oriented
functions (like findfirst) from libc and put them into libpc.  For those
of them which must have their __ff counterparts in libc (because libc
functions need to call them internally), you might just call that
__ff peer.  Others should only be defined in libpc and declared in
PC-specific headers, to keep namespace pollution to the minimum.  One
other thing is to watch that non-POSIX PC-specific headers don't get
included by POSIX headers, so that whoever uses opendir()/readdir()
doesn't get struct ffblk and findfirst as a side effect.

> * The headers will prototype the __ff functions in the "I want
> everything" section.

While this doesn't violate the standards, why declare the __ff functions
at all?  A library doesn't have to advertise its internal functions,
does it?

- Raw text -