[tz] [PROPOSED 1/7] Avoid undefined behavior if no Link lines
Clive D.W. Feather
clive at davros.org
Wed Oct 26 16:20:09 UTC 2022
Tom Lane via tz said:
> 7.1.4 Use of library functions
>
> [#1] 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 value outside the domain of the function,
> or a pointer outside the address space of the program, or a
> null pointer) or a type (after promotion) not expected by a
> ^^^^^^^^^^^^
> function with variable number of arguments, the behavior is
> undefined. If a function argument is described as being an
> array, the pointer actually passed to the function shall
> have a value such that all address computations and accesses
> to objects (that would be valid if the pointer did point to
> the first element of such an array) are in fact valid.
>
> There's a faction that thinks that the underlined comment entitles
> every libc function to halt-and-catch-fire when passed a null
> pointer.
They're right.
> Never mind whether a nearby zero count argument clearly
> forbids it from making any memory accesses associated with that
> pointer, as expressed by the immediately following sentence.
No, because the implementation might do something like:
endptr = (unsigned char *) base + nmemb * size;
before (or after) checking the value of nmemb.
> I side with Winston Churchill in saying "this is nonsense up
> with which I shall not put".
Actually, he didn't say it.
> There are no useful grounds for
> claiming that qsort, memset, memcpy, etc, with a null pointer
> and a zero count argument should be undefined.
There are, or were, implementers who disagree with you.
--
Clive D.W. Feather | If you lie to the compiler,
Email: clive at davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
More information about the tz
mailing list