On Wed, Dec 3, 2014 at 2:17 AM, Clemens Ladisch <clem...@ladisch.de> wrote:
> Scott Robison wrote:
> > On Dec 3, 2014 12:57 AM, "Clemens Ladisch" <clem...@ladisch.de> wrote:
> >> Do you have a standard that allows NULL? The one I quoted does not.
> >
> > Note: I'll have to double check my copy of the C90 standard document, but
> > my re-reading of the C99 quote leads me to the conclusion that NULL is a
> > valid pointer by definition.
>
> Then we have to go reference chasing:
>
> C99, 7.21.1:
> | Unless explicitly stated otherwise in the description of a particular
> | function in this subclause, pointer arguments on such a call shall
> | still have valid values, as described in 7.1.4.
>
> 7.1.4:
> | Each of the following statements applies unless explicitly stated
> | otherwise in the detailed descriptions that follow: If an argument to
> | a function has an invalid value (such as ... a null pointer ...) ...,
> | the behavior is undefined.
>
Okay, fair enough. I'm comparing the C90 & C90 (2005) standards at the
moment. The equivalent clause in C90 7.11, but in C90, it omits the second
paragraph (from which the quote was extracted). So C90 did not prohibit
NULL values beyond their implicit undefined behavior on dereference as per
6.3.3.2 (Address and indirection operators: "... If an invalid value has
been assigned to the pointer, the behavior of the unary * operator is
undefined.[42]" and ("[42] ... Among the invalid values for dereferencing a
pointer by the unary * operator are a null pointer ...").
I can certainly appreciate why the committee opted to make the change in
C99, though in this case it seems that (at least) memcpy & memset *should*
(but don't) have exceptions for those functions, since there is never a
need to dereference a pointer if the size of the block is zero. Other
"real" string functions (like strncpy) have the extra requirement of
finding a null terminator, so I can understand why a NULL source pointer
would be undefined behavior there, but not memcpy.
In any case, "SQLite is ANSI-C source code" (as per
http://www.sqlite.org/howtocompile.html). The only C standard that was
developed by ANSI was C89. C90 (almost identical to C89) and subsequent
standards have all been ISO standards. Pedantic? Yes. Obviously DRH is
willing to make the code more portable as long as it doesn't violate
ANSI-C, hence his patch early in the thread (see
https://www.sqlite.org/src/info/0d04f380e1bd17104b3cf76b64d0cfc79a726606).
Perhaps the R language project just needs to pick the "correct" dialect for
GCC (-std=C89 seems appropriate) when compiling the amalgamation? Might not
help if the UBSan markup in the header doesn't change based on the dialect
in use, but it might permit SQLite to compile cleanly. Unless it's already
being done, in which case I guess not. And it's moot, since it has been
accommodated in the source.
--
Scott Robison
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
