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: Implement C11 annex K?


On Tue, 12 Aug 2014 18:08:11 -0400, Rich Felker <dalias@libc.org> wrote:
> 1. Since the default constraint handler is implementation-defined,
>    portable code cannot rely on the default handler to catch dangerous
>    conditions, nor can it rely on the default handler to return an
>    error status to the caller in a way that the caller can handle.

Portable application code can just set the handler, once.
Portable *library* code just needs to check for error returns; if they don't return,
then the application author decided to do something else.  There's no state-saving necessary.

I think any libc implementation should by default just cause errors to be
returned, since it has no way of knowing exactly what to do with the application instead.
That also means that early library calls don't get caught in a bogus handler.
I agree that the committee should have specified the default, but at least it gives
implementers the chance to choose a reasonable default.

My guess is that most people will use error returns, and that the constraint handler's
primary use will be to support quick-and-dirty code.


> As for your specific example, which I assume is strncpy_s,

Yes.

> the standard function which already solves this problem without the
> additonal confusing and error-prone size arguments is snprintf:
> snprintf(dest, destsize, "%s", source).

snprintf is botched, too.  If the source is as least destsize in length,
then dest is not \0-terminated.  This is possible to detect, but off-by-one errors
leading to vulnerabilities are extremely easy to do.

There are also a lot of annoyances with using snprintf this way.
Why do I have to interpret a format string just to copy source to dest?
Complete botch, complete fail.  String copying is an EXTREMELY common
operation, it should be easy to do.

> And the nonstandard but widely
> available function that's even more convenient is strlcpy.

True.   strlcpy should be in glibc, too.  Lots of people use them.

My theory is that annex K is at least a formal spec, so it has an even *stronger*
argument for inclusion.  But if people would rather start with strlcpy/strlcat, that's fine.

--- David A. Wheeler



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