This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

Yes.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]