This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implement C11 annex K?
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Sun, 17 Aug 2014 19:25:20 -0400
- Subject: Re: Implement C11 annex K?
- Authentication-results: sourceware.org; auth=none
- References: <20140817190550 dot GK12888 at brightrain dot aerifal dot cx> <E1XJ793-000429-GI at rmm6prod02 dot runbox dot com>
On Sun, Aug 17, 2014 at 04:33:41PM -0400, David A. Wheeler wrote:
> On Sun, 17 Aug 2014 15:05:50 -0400, dalias <dalias@libc.org> wrote:
> > You missed the next sentence:
> >
> > "If the precision is not specified or is greater than the size of the
> > array, the array shall contain a null character."
>
> That does NOT say that the reader must not read
> beyond the precision; it merely specifies data constructs *within* it.
> Granted, you'd *hope* the implementer would stop at the precision value,
> but that is simply a hope.
>
> > Formally there is no such thing as reading past the end of the array
> > (or even indexing past the end of the array).
>
> The spec could promise that it will not read more chars than those
> given the precision when one is given. No such promise is given.
Since the interface contract only requires an array of precision
bytes (or even fewer if a null terminator appears sooner), there is no
way to an implementation to "read more chars" unless it has some
hidden mechanism to determine the size of the pointed-to object, which
in reality is not going to exist. However I agree that it would be
nice to formally specify that no other part of the array (if the array
actually is larger) shall be accessed. This is not for timing purposes
(ISO C does not specify timing) but rather data races: if another
thread is modifying part of the array past precision, this should not
result in UB when snprintf accesses the part of the array bounded
between offsets 0 and precision-1.
Rich