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