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  5458 
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.
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?
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"
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
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.
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.
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.
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.
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.
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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kazack |
last post by:
I am under the the impression that a variable is what is stored in a memory
address and a pointer is the memory address of the variable?
I was looking to use a function that does not return a...
|
by: steve |
last post by:
I'm trying to create a structure of three pointers to doubles. For
which I have:
typedef struct {
double *lst_t, *lst_vc, *lst_ic;
} last_values;
I then need to allocate space for...
|
by: streamkid |
last post by:
i'm a learning newbie at c++... and i have the following question...
reading some source code, i saw this:
int function(const void * one, const void * two)
{
int var1, var2;
var1 =...
|
by: Bo Yang |
last post by:
As long as I write c++ code, I am worry about the
pointer. The more the system is, the dangerous the pointer
is I think.
I must pass pointers erverywhere, and is there a way to
ensure that every...
|
by: Jeffrey Spoon |
last post by:
Hello, I am trying to make a simple function that returns a pointer to
another function. In my header file I've declared my function pointer:
void (*pStateFunction) (void); //assume the function...
|
by: Zero |
last post by:
Hello all,
I wonder about void?
To which category in the C programming language does it belong?
Of how many bits consits void?
Is it possible to define a varibale called
void a;
|
by: Chad |
last post by:
At the following url http://c-faq.com/lib/qsort2.html, they have the
following
Q: Now I'm trying to sort an array of structures with qsort. My
comparison function takes pointers to structures,...
|
by: Ben Bacarisse |
last post by:
candide <toto@free.frwrites:
These two statements are very different. The first one is just wrong
and I am pretty sure you did not mean to suggest that. There is no
object in C that is the...
|
by: mdh |
last post by:
May I ask the following.
By K&R's own admission, the example used to describe function pointers
is complex ( on P119). In addition, the use of casts has been stated
by some on this group as...
|
by: junky_fellow |
last post by:
Guys,
Consider a function
func(void **var)
{
/* In function I need to typecast the variable var as (int **)
I mean to say, I need to access var as (int **)
}
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
