printf("%p\n", (void *)0);

[infobahn]

printf("%p\n", (void *)0); /* UB, or not? Please explain your answer. */

[Douglas A. Gwyn]

infobahn wrote:

But Keith Thompson has already agreed that, in cases where a
null pointer value has *explicit* semantics (fflush, strtok,
etc), it's clearly valid and there's no problem.

That counter-argument relies on "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 ..., the behavior is
undefined." Certainly if you examine the fprintf spec,
a null pointer value is not inherently invalid in that
context; that pointer argument is not required to point
at an object (unlike e.g. the arguments for strcpy).
You don't even need to refer to the parenthetical clause
("..." above), which gave examples of classes of values
that might be considered invalid, generally depending on
context. Not every use of a null pointer is invalid.

[Douglas A. Gwyn]

Stephen Sprunk wrote:

free(a);
printf("%p\n", a);

Don't do that. Thanks.

[Douglas A. Gwyn]

Keith Thompson wrote:

I've been wondering why the standard says that the value of a free()d
pointer becomes indeterminate and not that it becomes a trap
representation; ...

"Trap representation" was a C99 invention (mainly by Clive
Feather, during revision of the specs for integer reps),
and was meant to cover bit patterns that were not valid
values. Since in the case of a freed pointer it is not
the bit pattern but rather its *meaning* that may have
become indeterminate, "trap rep" didn't seem appropriate.

[Douglas A. Gwyn]

"Trevor L. Jackson, III" wrote:

I.e., if there were no intervening heap oprtations the most recently
free()'d block was still available *and it's contents unchanged*.
Clearly that is no longer true.

That hasn't been true since C was standardized, and wasn't a
property to rely on even before that.

[Douglas A. Gwyn]

"Trevor L. Jackson, III" wrote:

So realloc() is explicitly defined to not handle stale pointers?

How would you pass the pointer value as an argument without
evaluating it?

[Keith Thompson]

pete <pf*****@mindsp ring.com> writes:

Richard Bos wrote:

dj******@csclub .uwaterloo.ca (Dave Vandervies) wrote:

> I do disagree with the claim that similar reasoning doesn't apply to
> fprintf's %p format specifier, which was the context of my statement
> above.

The definition of assert() explicitly mentions 0 values.
The definition
of printf("%p...) does not, and is AFAICT unique in this.

In all of the rest of the standard functions
where NULL is an invalid argument, the standard's description
of the function will define arguments in such a way
so as to exclude NULL, unlike the way printf is described.

When the standard says "the object pointed to by s1" or
"the initial element of which is pointed to by base"
then those words exclude NULL as a valid value for both s1 and base.

All of the library descriptions are like that.

If the behavior of printf("%p\n", (void*)0) depends on the way all the
other standard functions are described, I think it would be better to
describe the behavior of the "%p" format specifier.

I think I'd even be happy with a footnote.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[James Kuyper]

James Kuyper wrote:

Keith Thompson wrote:

pete <pf*****@mindsp ring.com> writes:

.... That's not how I understood Keith's argument. He's arguing that a single

pete's

Sorry! I was paying more attention to arguments than to attributions.

[James Kuyper]

Keith Thompson wrote:

pete <pf*****@mindsp ring.com> writes:

....

When the standard says "the object pointed to by s1" or
"the initial element of which is pointed to by base"
then those words exclude NULL as a valid value for both s1 and base.

All of the library descriptions are like that.

If the behavior of printf("%p\n", (void*)0) depends on the way all the
other standard functions are described, I think it would be better to
describe the behavior of the "%p" format specifier.

That's not how I understood Keith's argument. He's arguing that a single
consistent approach is used: a null pointer argument is invalid whenever
the corresponding description of the behavior implies that the argument
is dereferenced. He's referring to the other descriptions only as
confirmation of this convention, not as something that must be read in
order to understand the description of printf().

[pete]

James Kuyper wrote:

Keith Thompson wrote:

pete <pf*****@mindsp ring.com> writes: ...

When the standard says "the object pointed to by s1" or
"the initial element of which is pointed to by base"
then those words exclude NULL as a valid value for both s1 and base.

All of the library descriptions are like that.

a single consistent approach is used:
a null pointer argument is invalid whenever
the corresponding description of the behavior
implies that the argument is dereferenced.

In cases when it boils down to that the totality of the issue
is just that it confuses a couple of guys on c.l.c,
then the committee doesn't do anything.

--
pete

[pete]

pete wrote:

James Kuyper wrote:

Keith Thompson wrote:

pete <pf*****@mindsp ring.com> writes:

...

>When the standard says "the object pointed to by s1" or
>"the initial element of which is pointed to by base"
>then those words exclude
> NULL as a valid value for both s1 and base.
>
>All of the library descriptions are like that.

a single consistent approach is used:
a null pointer argument is invalid whenever
the corresponding description of the behavior
implies that the argument is dereferenced.

Actually dereferencing isn't required to disqualify NULL
as a valid argument value.
In C99, a call to qsort is valid when nmemb equals zero.
While qsort is neither allowed to call the comparison function
nor perform any rearrangement when nemb is zero,it may still
do things like calculate the address of the last element
or the one after that, unconditionally ,
and (NULL + 0) and (NULL + 1) are undefined.
And so, NULL is an undefined value for base in a call to qsort,
even in C99, and even when nmemb equals zero.

void qsort(void *base, size_t nmemb, size_t size,
int (*compar)(const void *, const void *))
{
unsigned char *array, *after, *i, *j, *k, *p1, *p2, *end, swap;
size_t bytes;

array = base;
after = nmemb * size + array;
if (nmemb > (size_t)-1 / 3 - 1) {
nmemb = nmemb / 3 - 1;
} else {
nmemb = (nmemb * 3 + 1) / 7;
}
while (nmemb != 0) {
bytes = nmemb * size;
i = bytes + array;
do {
j = i - bytes;
if (compar(j, i) > 0) {
k = i;
do {
p1 = j;
p2 = k;
end = p2 + size;
do {
swap = *p1;
*p1++ = *p2;
*p2++ = swap;
} while (p2 != end);
if (bytes + array > j) {
break;
}
k = j;
j -= bytes;
} while (compar(j, k) > 0);
}
i += size;
} while (i != after);
nmemb = (nmemb * 3 + 1) / 7;
}
}

--
pete