Re: ISO C11 issues for glibc

[Roland McGrath <roland at hack dot frob dot com>]

> Which reminds me, what is your opinion on those *_s bounds-checking
> functions, e.g, vsnprintf_s etc, as specified in Annex K?
> I'd say we don't really need them since we have _FORTIFY_SOURCE
> and thus *_chk functions...

I've only skimmed the spec.  Half those interfaces seem to actually be
*_r style stuff, i.e. interfaces that use return values and result
parameters instead of global/per-thread state.  Those seem useful, but
only if people actually start using them.  In practice, we already have
*_r variants and people are using those where they care.  But we can
probably expect that one day more systems will implement the Annex K
features to spec and so it would become useful for application
portability if we support them.

The other main thing is the "runtime constraints" stuff.  I haven't
really formed an opinion about that yet.  It's intended to give
applications a reliable graceful error return behavior for various
situations that in the vanilla interfaces are just undefined behavior
that an application must avoid provoking.  On the one hand, applications
can recover better.  On the other hand, most undefined behavior
situations are things that only a sloppy application would ever get
into.  For the most part, our theory on such things in glibc has been
that a sloppy application is better served by getting hard crashes that
force the programmer to clean up their code.  These new interfaces that
give graceful error returns that a sloppy application can just ignore
seem like they might actually encourage more sloppiness with far more
subtle failure modes, which could be worse than the status quo.  (See
the archives for why we don't have strlcpy et al, which seems like a
similar issue.)

As for the ones that are actually about bounds-checking, I can't quite
tell what to think.  Many of them have additional length parameters,
which is just another thing for the application to calculate wrong.  But
perhaps they can help, I don't know.  The _FORTIFY_SOURCE stuff we have
is mostly based on __builtin_object_size, which has the benefit that it
catches programmer errors--whereas an explicit length parameter is prone
to yet another class of programmer error.  OTOH, those don't help at all
when the compiler doesn't know statically how to figure the size,
i.e. when a pointer parameter is not directly computed from an array.


Thanks,
Roland