This is the mail archive of the
mailing list for the glibc project.
Re: Implementing "Extensions to the C Library" (ISO/IEC WG14 N1172)
On Wed, Sep 19, 2007 at 12:05:32AM +1200, Richard Viney wrote:
> > > It proposes a number of new types and methods that make writing secure
> > > C code easier. A lot of it is already implemented as an optional
> > No, they make retrofitting large amounts of existing insecure code
> > (without removing arbitrary limits in that code but avoiding undefined
> > behavior in some cases when those limits are exceeded) easier.
> Yes you're right part of it is to help with securing existing code
> without requiring significant rewriting, but it also includes
> functions that improve other things in the standard library, like
> localtime_s() and tmpfile_s(). Obviously supporting these extensions
> to the standard library in glibc would also help with porting code
> from the Windows world that use them, is this the plan? Or are the
There is no plan to implement N1225 interfaces unless we are forced to.
> extensions in N1225 not going to be supported unless they're put into
> the official standard?
Already SUSv3 has localtime_r, asctime_r, ctime_r and other
reentrant functions, it makes no sense to introduce new aliases for them.
In -D_FORTIFY_SOURCE=2 mode glibc also prevents %n in *printf format
strings, with the difference that %n is only disallowed if the string
literal is in writable memory.
And I must say I completely miss the point of introducing tmpfile_s,
it doesn't do anything beyond what tmpfile does, just returns error
number in a different way (retval vs. errno).
> Is there a reluctance to support both solutions?