Re: Implementing "Extensions to the C Library" (ISO/IEC WG14 N1172)

["Richard Viney" <richard dot viney at gmail dot com>]

On 19/09/2007, Jakub Jelinek <jakub@redhat.com> wrote:
> 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.

Fair enough. Are there correct procedures for writing non-platform
specific code that utilizes these sorts of improved functions? Or will
that not be the case until either N1125 is approved (if that happens),
or every platform implements SUSv3 (which seems unlikely), or some
other solution is proposed? At the moment it seems that a set of
intermediate functions/macros would be needed to enable this, and they
would have to adapt correctly to what's provided natively by each
platform, is that right?

>
>         Jakub
>