469,328 Members | 1,301 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,328 developers. It's quick & easy.

Question about void pointers

Is this valid?

int a[20];
void *b;

b = (void *)a; // b points to a[0]

b += 5*sizeof(*a); // b points to a[5]

a[5] = 100;

printf( "%d\n" , *((int *)b) ); // prints 100

If so, if a had been a struct, would it still work?

Is there a possibility that the array could contain some padding, so
rather than sizeof, the assignment would be

b += 5*( (void *)(&(a[1])) - (void *)(&(a[0]));

which seems more more complex.

Would any padding be incorporated into sizeof anyway?
Sep 16 '08
160 4575
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>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;
[...]
>The footnote, however,
implies that the above must print (in some implementation-defined
manner) the address of the first character of the literal.
From which we conclude that there is a bug in the standard: it doesn't
normatively convey what the authors intended, and it should be fixed.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Oct 9 '08 #151
Keith Thompson <ks***@mib.orgwrites:
Tim Rentsch <tx*@alumnus.caltech.eduwrites:
Keith Thompson <ks***@mib.orgwrites:
CBFalconer <cb********@yahoo.comwrites:
[...]
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?

Oct 10 '08 #152
Tim Rentsch <tx*@alumnus.caltech.eduwrites:
Keith Thompson <ks***@mib.orgwrites:
>Tim Rentsch <tx*@alumnus.caltech.eduwrites:
Keith Thompson <ks***@mib.orgwrites:
CBFalconer <cb********@yahoo.comwrites:
[...]
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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 10 '08 #153
On 10 Oct 2008 04:06:07 -0700, Tim Rentsch <tx*@alumnus.caltech.edu>
wrote:
Keith Thompson <ks***@mib.orgwrites:
<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?
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
Oct 20 '08 #154
David Thompson <da************@verizon.netwrites:
On 10 Oct 2008 04:06:07 -0700, Tim Rentsch <tx*@alumnus.caltech.edu>
wrote:
Keith Thompson <ks***@mib.orgwrites:
<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?

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.
Nov 10 '08 #155
On Mon, 10 Nov 2008 01:17:12 -0800, Tim Rentsch wrote:
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.
Nov 10 '08 #156
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrites:
On Mon, 10 Nov 2008 01:17:12 -0800, Tim Rentsch wrote:
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.
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.
Nov 11 '08 #157
On Tue, 11 Nov 2008 09:33:35 -0800, Tim Rentsch wrote:
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.
Nov 11 '08 #158
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrites:
On Tue, 11 Nov 2008 09:33:35 -0800, Tim Rentsch wrote:
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.
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.
Nov 18 '08 #159
On 18 Nov, 00:02, Tim Rentsch <t...@alumnus.caltech.eduwrote:
>*(<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

--
Nick Keighley
Nov 18 '08 #160
Tim Rentsch wrote:
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrites:
>On Tue, 11 Nov 2008 09:33:35 -0800, Tim Rentsch wrote:
>>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.

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.
Nov 18 '08 #161

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by kazack | last post: by
18 posts views Thread by steve | last post: by
14 posts views Thread by streamkid | last post: by
21 posts views Thread by Bo Yang | last post: by
4 posts views Thread by Jeffrey Spoon | last post: by
10 posts views Thread by Zero | last post: by
21 posts views Thread by Chad | last post: by
18 posts views Thread by mdh | last post: by
28 posts views Thread by junky_fellow | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by Purva khokhar | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.