Question about void pointers

[Tim Rentsch]

[...]
In addition, as far as I can tell, there is no prohibition against
returning void* and char* pointers in different registers (or other
entities). If this is correct, using the interchangeably can
create an ugly code block.

There is no such prohibition in the normative text of the standard,
but it's suggested in a footnote.

C99 6.2.5p27:

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.

And a footnote:

The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.

This is an unfortunate flaw in the standard.

I think you're misunderstanding the idea behind the footnote.
The "interchangeability" of char*/void* is meant to talk about
values of those types used in particular contexts, not about
derived types with those types in them.

[snip]

Consider this:

printf("%p\n", "string literal");

I see nothing in the normative text of the standard that requires
char* and void* to be passed as function arguments in the same manner;
for example, void* arguments might be passed in one set of registers
and char* arguments in another. I can think of no good reason to do
so, but the standard doesn't forbid it. The footnote, however,
implies that the above must print (in some implementation-defined
manner) the address of the first character of the literal.

Doesn't 7.15.1.1 p 2 count, or 6.5.2.2 p 6?

 

[Keith Thompson]

[...]
In addition, as far as I can tell, there is no prohibition against
returning void* and char* pointers in different registers (or other
entities). If this is correct, using the interchangeably can
create an ugly code block.

There is no such prohibition in the normative text of the standard,
but it's suggested in a footnote.

C99 6.2.5p27:

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.

And a footnote:

The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values
from functions, and members of unions.

This is an unfortunate flaw in the standard.

I think you're misunderstanding the idea behind the footnote.
The "interchangeability" of char*/void* is meant to talk about
values of those types used in particular contexts, not about
derived types with those types in them.

[snip]

Consider this:

printf("%p\n", "string literal");

I see nothing in the normative text of the standard that requires
char* and void* to be passed as function arguments in the same manner;
for example, void* arguments might be passed in one set of registers
and char* arguments in another. I can think of no good reason to do
so, but the standard doesn't forbid it. The footnote, however,
implies that the above must print (in some implementation-defined
manner) the address of the first character of the literal.

Doesn't 7.15.1.1 p 2 count, or 6.5.2.2 p 6?

Yes, I think so; I hadn't seen those before. (I could probably think
of ways to work around that wording, but the intent is clear enough.)

 

[David Thompson]

Keith Thompson <[email protected]> writes:

Doesn't 7.15.1.1 p 2 count, or 6.5.2.2 p 6?

Not quite. The standard-library routines aren't required to be
implemented in standard C; some of them can't be (usefully).

If the implementation of printf is e.g. assembler, it doesn't use
va_arg, so rules for that doesn't apply. If it's in impl-dependent
extended C, it could use say __our_special_printf_vrbl_argt instead,
and again the va_arg rules don't apply -- even if that actually does
the same things va_arg does.

In reality any implementor who broke this would be figuratively ridden
out of town on a rail, because everyone expects it to work the same
way ordinary user vararg functions work, and the nonnormative
footnotes to be true. But it isn't formally required.

The function-call provision applies to the _fixed_ arguments of an
unprototyped function, not to varargs at all. Unless as above the
unprototyped function isn't C at all, in which case the C standard
can't distinguish them (and something else might or might not).

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Tim Rentsch]

Not quite. The standard-library routines aren't required to be
implemented in standard C; some of them can't be (usefully).

If the implementation of printf is e.g. assembler, it doesn't use
va_arg, so rules for that doesn't apply. If it's in impl-dependent
extended C, it could use say __our_special_printf_vrbl_argt instead,
and again the va_arg rules don't apply -- even if that actually does
the same things va_arg does.

In reality any implementor who broke this would be figuratively ridden
out of town on a rail, because everyone expects it to work the same
way ordinary user vararg functions work, and the nonnormative
footnotes to be true. But it isn't formally required.

This topic has come up before. Although there were views expressed
on both sides, those who are on the committee (either as members,
or distinguished attendees such as Larry Jones) were unanimous in
reporting that the language used in the Standard was intended to
express that printf behaves the same way that the stdarg.h
functions/macros do. So the statement "it isn't formally required"
might be reasonable as a statement of opinion, but it is not a
statement of fact.

Incidentally, the comments about assembler etc are beside the
point. Whether a library function is or is not, or can be or
cannot be, implemented in standard C is irrelevant; all that
matters is that it must conform to the specifications in the
Standard. The library function printf() must conform to the
declaration given in 7.19.6.3 p 1, and (indirectly) must conform
to the specification of 7.19.6.1 (describing fprintf). Since
7.19.6.1 doesn't explicitly state otherwise, the provisions
of 7.1.4 hold; these provisions allow the reasonable inference
that the conventions of stdarg.h apply.

Furthermore, my comment/question was a response to the general
statement in Keith's posting (the sentence starting "I see
nothing ..."), which was not about printf specifically, but
about function arguments in general. Mentioning 6.5.2.2 p 6
should have made that clear, since it doesn't apply to printf.

The function-call provision applies to the _fixed_ arguments of an
unprototyped function, not to varargs at all. Unless as above the
unprototyped function isn't C at all, in which case the C standard
can't distinguish them (and something else might or might not).

Yes, the function-call section doesn't apply to printf or any other
function that takes a variable number of arguments. That's because
my response was to the general question, and not specifically about
printf.

 

[Harald van Dijk]

This topic has come up before. Although there were views expressed on
both sides, those who are on the committee (either as members, or
distinguished attendees such as Larry Jones) were unanimous in reporting
that the language used in the Standard was intended to express that
printf behaves the same way that the stdarg.h functions/macros do. So
the statement "it isn't formally required" might be reasonable as a
statement of opinion, but it is not a statement of fact.

It's intended to be formally required doesn't mean it is formally
required. The wording in the standard doesn't guarantee that printf e.a.
use an equivalent of va_arg, no matter what the intent may be.

 

[Tim Rentsch]

It's intended to be formally required doesn't mean it is formally
required. The wording in the standard doesn't guarantee that printf e.a.
use an equivalent of va_arg, no matter what the intent may be.

The point is there isn't agreement on what the formal requirements
are. Although the C standard is a formal document, it is not formal
in the sense of using mathematical language (at least, not generally).

I realize some people think the formal language of the standard allows
printf() to use different rules than va_arg. Other people, however,
think the formal language of the standard requires printf() to use the
same rules as va_arg.

Since the actual language is not unambiguous, and based on my own
judgment of which reading is more consistent with all that the
standard says about library functions and function arguments, I find
the second reading more compelling. And I believe other people that
adopt this metric for evaluating how the standard should be read
will also.

 

[Harald van Dijk]

I realize some people think the formal language of the standard allows
printf() to use different rules than va_arg. Other people, however,
think the formal language of the standard requires printf() to use the
same rules as va_arg.

Could you give a few messages where people try to explain where that is?
I've seen it discussed often enough, but have always thought there was
agreement that the standard is missing the text to require this.

 

[Tim Rentsch]

Could you give a few messages where people try to explain where that is?
I've seen it discussed often enough, but have always thought there was
agreement that the standard is missing the text to require this.

Unfortunately I've lost the references since reading them. (<aside>Is
it my imagination or is searching Google groups harder than it used to
be?</aside>) But I remember that both Doug Gwyn and Larry Jones
contributed to the thread discussing printf() vis-a-vis other variadic
functions.

 

[Nick Keighley]

 (<aside>Is it my imagination or is searching Google groups harder than it used to
be?</aside>)

no. It's been "upgraded". I used to search for "C++" and get
comp.lang.c++
Now not even searching for comp.lang.c++ actually yeilds comp.lang.c++

duh

 

[James Kuyper]

Unfortunately I've lost the references since reading them. (<aside>Is
it my imagination or is searching Google groups harder than it used to
be?</aside>) But I remember that both Doug Gwyn and Larry Jones
contributed to the thread discussing printf() vis-a-vis other variadic
functions.

It's not your imagination. Among other problems, when searching for a
message meeting certain criteria, Google no longer provides you with a
link to that particular message, only a link to the thread in which that
message appears. If that thread contains a few thousand messages (as has
been the case for a couple of my searches), this is pretty much useless.
Even for threads with only a dozen messages, it's pretty annoying.

The most recent relevant thread that I could find was

<http://groups.google.com/g/6137feeb/t/a656169cb5941cbf/d/5091258077e0a3b8>

The second message of that thread gives my take on the issue. Both Doug
Gwyn and Larry Jones did participate in the discussion, but only to a
limited extent. Larry Jones' response disagrees with mine.