RE: add mkstemps

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

 -----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Jeff Johnston
Sent: Tuesday, June 30, 2009 5:00 PM
To: Eric Blake
Cc: newlib@sources.redhat.com
Subject: Re: add mkstemps

>>> Secondly, the addition probably should be in unistd.h.  stdlib.h is
>>> properly fully standardized from ISO and POSIX.
>>>
>>
>> stdlib.h can still be fully compliant, with proper #ifdef guards to
>> hide non-standard functions when the user is requesting strict 
>> compliance.  I disagree about <unistd.h> for two reasons: 
>> 1) <unistd.h> implies standardized functions, but mkstemps is not
>> (yet) standardized; 2) existing practice - Solaris chose <stdlib.h>.
1) stdlib.h is standardized functions--and is supposed to be only
standardized functions.
2) My suggestion of unistd.h is based on existing practice that was
pointed
out in the initial email--it said that it comes in either stdlib.h or
unistd.h.  I'm simply advocating the second choice that was given.  My
feeling is that unistd.h is less standard (due to BSD vs. SysV vs. etc.)
than stdlib.h.  But you're right, strictly it really breaks either.  The
stdlib.h choice has the benefit of it being with mkstemp and the other
POSIX standard ones.  So either works, and either is not all that good.
Your creation, your preference prevails.
>
>>>  We should avoid
>>> "polluting" it with non-standard items (not that it isn't already).
>>>
>>
>> Again, the pollution should be something that can be controlled by
#ifdef
>> switches (similar to glibc's _GNU_SOURCE, or AIX' _ALL_SOURCE, or
Solaris'
>> __EXTENSIONS__, etc).  True, newlib is not yet at the point where all
>> extensions are properly guarded by a single macro, ....
On a side note:
The present Newlib method of gating function prototypes is a VERY bad
one.  It leaves the functions in the library and lets the user nuke
prototypes based on compiler settings which may or may not match how the
library itself was built, which means default argument passing without
checks.  This approach needs to be abandoned.  (Now if the practice was
done at configure time and actually put the routines in and out of
the libraries, then it could be OK.)  But this is a different issue that
is a step above the specific placement of mkstemps.
>>
>>
>>> If it needed to be moved later if it ever became standard, then move
it
>>> later.  (Or perhaps now is a good time to introduce a stdlibext.h
>>> file, which is one of the things that I've been thinking about as a
>>> possible mechanism for cleaning up the system header files.)
>>>
>>
>> But that's the whole point of this thread - there is existing
practice that
>> puts it in <stdlib.h>, so putting it in a non-standard header like
>> <stdlibext.h> is only doing a disservice to code trying to be
portable 
>> across all the systems that already provide this function as an
extension.
>>
>If stdlibext.h is included from stdlib.h, then stdlib.h becomes less
>cluttered.  I assume that is what
>Craig is suggesting.  This does not need to be done as part of this
patch.
Correct on both counts.  (At configure time the user would choose strict
compliance or not--where the functions are truly excluded both from the
headers and the standard libraries.  The extension functions could still
be available by using the *ext.h includes directly and linking with
-lcext,
-lmext, etc., or something of the sort.)