Date:	Wed, 23 Nov 94 08:40:58 -0500
From:	dj AT stealth DOT ctron DOT com (DJ Delorie)
To:	eliz AT is DOT elta DOT co DOT il
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: ansi/posix results

> > * 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.

Currently, I use __dj_ENFORCE_ANSI_HOSTED,
__dj_ENFORCE_ANSI_FREESTANDING, _POSIX_SOURCE, and
__dj_ENFORCE_FUNCTION_CALLS to control what the header files look
like.  If __STRICT_ANSI__ is defined by ANSI to mean that the headers
should become strict ansi, then I'll switch to that instead.

> > * 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

Actually, I was thinking of doing away with libpc - it seems to just
confuse people.  Also, the ANSI spec says that most libm.a functions
should be in libc.a, so I might do away with that also (but leave
empty libraries to satisfy existing makefiles).

> 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.

This is already taken care of.  Even struct FILE isn't defined in any
standard header.

> > * 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?

The libc functions themselves need them, and some programs might want
the assurance that libc needs that the functions haven't been
overridden by the application.  On the other hand, I'm pretty
ambivilant about this, and libc does have a local private include
directory I could put stuff in.

- Raw text -