469,343 Members | 5,380 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,343 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 4578
Keith Thompson said:
Antoninus Twink <no****@nospam.invalidwrites:
[...]
> void* and char* can be losslessly
converted back and forth. Nonetheless, /in theory/ they can have
different representations.
[...]

Wrong.
Well, obviously. Look at the source.

Nevertheless, incredible as it may seem, some people might not realise even
now that the source is unreliable, so here's C&V from both Standards (the
wording is identical in each):

C89, 3.1.2.5, and C99, 6.2.5(26): "A pointer to void shall have the same
representation and alignment requirements as a pointer to a character
type."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 16 '08 #51
Peter Nilsson said:
Keith Thompson <ks...@mib.orgwrote:
>... why does printf have a "%p" format?

That's actually a very good question! If you ever hear
a good answer, please share it.
Implementations have considerable licence over the textual representation
of pointer values. One MS-DOS compiler I have used (dim and distant past,
admittedly) would print pointer values like this: DS:FADE

I mean *obviously* that's a number, right? It's just not immediately
obvious /which/ number it is.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Sep 16 '08 #52
Peter Nilsson wrote:
Keith Thompson <ks...@mib.orgwrote:
>... why does printf have a "%p" format?

That's actually a very good question! If you ever hear
a good answer, please share it.
Well, how about "to allow printf to output a printable char
representation of a void* pointer, readable by scanf to
reconstitute that pointer".

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 16 '08 #53
On 16 Sep 2008 at 23:27, Richard Heathfield wrote:
C89, 3.1.2.5, and C99, 6.2.5(26): "A pointer to void shall have the same
representation and alignment requirements as a pointer to a character
type."
Well, great.

CBF says something is a problem in practise. I point out that it's at
worst a problem in theory. And actually it isn't even that.

It seems that the ISO C committee have a bit more common sense than the
average clc regular in these matters.

Sep 16 '08 #54
Peter Nilsson <ai***@acay.com.auwrites:
Keith Thompson <ks...@mib.orgwrote:
>... why does printf have a "%p" format?

That's actually a very good question! If you ever hear
a good answer, please share it.
I'm not sure of the basis for your question. Do you mean to imply
that "%p" isn't useful? If so, are you suggesting the use of other
existing formats, or questioning the need to print pointer values in
the first place?

Another interesting question is why there's no format for printing
function pointers; I suspect the answer is that it wasn't thought to
be sufficiently useful. On many systems, casting to void* and using
"%p" works; more generally, you can always get at the representation
as an array of unsigned char and print it in, say, hexadecimal.

--
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"
Sep 16 '08 #55
Richard<rg****@gmail.comwrites:
vi******@gmail.com writes:
>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>when you do
--char *c; c++; ==c is incremented by 1
--long int *x; x++ ==x is incremented by 4.

Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.
This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

We are currently living though an particularly stable few decades in
terms of machine architecture, but it was not always so and may not
always be so in the future. A large body of C code that plays fast
and loose with indeterminate pointers, treating pointers as if they
were numbers into a flat value space, or assumes that casts (on
pointers) don't change values will condemn future generations to one
of two fates:

(a) All CPU's look more and more alike and none do anything clever
with the address space because that valuable body of code won't work
without massive porting effort; or

(b) A future generation of rookies (they may be your kids!) has to
wade through all that 25 year old code looking for these bugs.

The serious point is that is does not matter if there are no machines
*now* that trap on the above code or code like

int a[1], *ap = a; a--;

there were such machine once and I, for one, would like to think there
might be again. At the very least, are you /sure/ you know exactly
which undefined behaviours will still work in 25 years time?

[Aside: Do your own thought experiment -- mine goes like this: 25
years ago I worked for a large computer company in a office with no
network. They wanted me to implement a protocol whose name I now
forget because they did not think this TCP/IP stuff would take off. I
was sent off to see a competitor that had just stared to export to the
UK to see if their 68000-based systems were any good (the then tiny
Sun Microsystems). I did not see an Ethernet until the next year --
it was a fat yellow cable that could not take tight bends but it did
run at 1M bit and you could get an interface card for only £500.
There were no laptops and PCs were a joke. Graphical interfaces were
just breaking out the research lab.]

--
Ben.
Sep 17 '08 #56
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>vi******@gmail.com writes:
>>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
when you do
--char *c; c++; ==c is incremented by 1
--long int *x; x++ ==x is incremented by 4.

Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!
Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.
Sep 17 '08 #57
CBFalconer <cbfalco...@yahoo.comwrote:
Peter Nilsson wrote:
Keith Thompson <ks...@mib.orgwrote:
... why does printf have a "%p" format?
That's actually a very good question! If you ever hear
a good answer, please share it.

Well, how about "to allow printf to output a printable char
representation of a void* pointer,
How often is this useful? When it is, how useful is %p?
readable by scanf to reconstitute that pointer".
Having printed a pointer with %p, how does a program guarantee
that subsequent printed characters will not undermine scanf's
ability to reconstitute a comprable pointer value?

If I do something like...

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

....what is the guarantee that the output won't exceed an
implementation's limit on text line width?

When I do print pointers, I hex dump the representation.
It's the only way to gain full control over the output.

#include <stdio.h>
#include <limits.h>

#define CHAR_NIBBLE ((CHAR_BIT + 3) / 4)

void dump_ptr(FILE *fp, const void *ptr)
{
const unsigned char *p = (const unsigned char *) &ptr;
size_t i;
for (i = 0; i < sizeof ptr; i++)
fprintf(fp, "%0*X", CHAR_NIBBLE, (unsigned) *p++);
}

--
Peter
Sep 17 '08 #58
Richard Heathfield <r...@see.sig.invalidwrote:
Peter Nilsson said:
Keith Thompson <ks...@mib.orgwrote:
... why does printf have a "%p" format?
That's actually a very good question! If you ever hear
a good answer, please share it.

Implementations have considerable licence over the textual
representation of pointer values.
That's the problem.
One MS-DOS compiler I have used (dim and distant past,
admittedly) would print pointer values like this: DS:FADE
I mean *obviously* that's a number, right? It's just not
immediately obvious /which/ number it is.
In the rare cases where I print pointers, I'm less concerned
about the pointer value itself than I am about how the value
is displayed.

Realising this, I've often asked myself why I bothered
printing the pointer in the first place! Which brings us
back to the question of why %p exists. [And why, if it is
to exist, is there no corresponding specifier for function
pointers.]

--
Peter
Sep 17 '08 #59
s0****@gmail.com wrote:
On Sep 16, 2:52 pm, Eric Sosman <Er*********@sun.comwrote:
>[...]
Perhaps you should be more specific about what you mean by "this
kind of task," because I (mis?)understood you to be referring to the
code in the original post.

I was referring to the task of performing pointer arithmetic on a void
pointer rather than on an unsigned char pointer, in a case where the
pointer points to some arbitrary object (an array of int, in the OP's
case).
Okay, terminology: That's not a task, it's a tactic.
A task is, for example, to make an interest calculation and
round the (probably irrational) result to hundredths of a
dollar. Various tactics might be employed to accomplish such
a task: Absalom might use log() and exp(), Bertram might use
pow(), Cecil might round by adding 0.005, scaling, truncating,
and re-scaling, Dudley might round by means of a precalculated
logarithmic table. Getting a pointer to the umpteenth element
of an array might be a task, accomplishing it via arithmetic
on a void* (forbidden in C) or a char* (signedness your option)
or a type-of-array-element* would be a means to that end, but
not an end in itself.
>>> Personally, I'm not as ready as vippstar is to give you the
award; we're only halfway through the month. But I'd be surprised
if you weren't on the ballot a couple weeks from now. Have you
chosen your running mate yet?
I did not understand a word of that paragraph.
So you understand English as well as you understand C?

...says someone who made a remark about something without being aware
of what he was talking about. Seriously, though, I don't know what you
mean by me "being on the ballot a couple of weeks from now" or me
"choosing my running mate yet."
It means: (1) vippstar awarded you the "worst advice of the
month" award, (2) I said the award would be premature because
the month is only half over and worse advice might conceivably
yet appear, but (3) I thought your advice would certainly be
among the contenders for worst. I also (4) made a reference to
current events in USA politics, the suggestion being that your
maundering about "perhaps the OP doesn't need portability" reminds
one of a politician desperately backtracking. Your "Besides, void*
seems more natural" has all the sincerity of Pooh-Bah's "I wasn't
there."

--
Eric Sosman
es*****@ieee-dot-org.invalid
Sep 17 '08 #60
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>vi******@gmail.com writes:

On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
when you do
--char *c; c++; ==c is incremented by 1
--long int *x; x++ ==x is incremented by 4.

Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.
Why? I honestly can't see why you think it must do anything at all.

The whole point of my post was to say "beware" to people who
mock undefined behaviour because you don't know the future. On the
Cambridge CAP machine, that code would terminate the program before
the increment. In fact, 'int *x; x;' could terminate the program if the
compiler did not optimise the reference to x away. Do you know that
the code will increment on every future machine, now that this awkward
old one is so much scrap?

--
Ben.
Sep 17 '08 #61
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
[...]
>Wrong.

Well, obviously. Look at the source.

Nevertheless, incredible as it may seem, some people might not realise even
now that the source is unreliable, so here's C&V from both Standards (the
wording is identical in each):

C89, 3.1.2.5, and C99, 6.2.5(26): "A pointer to void shall have the same
representation and alignment requirements as a pointer to a character
type."
This originated with an attempt by one of the trolls to refute a
statement that CBFalconer never actually made, in contrast to the
perfectly correct statement that he did make.

The language requires void* and char* to have the same
representation, but it does not allow pointer arithmetic on void*
(Chuck made the latter statement). More precisely, any attempt
to perform such arithmetic is a constraint violation, requiring
a diagnostic.

The whole point of having void* in the language is that it
doesn't point to any specific type. Allowing arithmetic on
void* as an extension, as if it pointed to a one-byte object,
weakens that distinction for the sake of some minor convenience.
(A side effect of the way this extension is implemented is that,
absurdly, sizeof(void)==1.)

--
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"
Sep 17 '08 #62
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>Richard<rg****@gmail.comwrites:

vi******@gmail.com writes:

On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>when you do
>--char *c; c++; ==c is incremented by 1
>--long int *x; x++ ==x is incremented by 4.
>
Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

Why? I honestly can't see why you think it must do anything at all.
I dont think it *must* do anything at all. But I am yet to see a machine
where it is not incremented if it is not initialised. Its
"uninitialised" value is incremented in each and every case. Sure its
"undefined behaviour in terms of the value, but its still UDV+1 ...
>
The whole point of my post was to say "beware" to people who
mock undefined behaviour because you don't know the future. On the
Let me make something very clear - I am not mocking UDB. I am just
pointing out that in most cases it is WRONG to say the unitialised
variable is NOT incremented. It is. In nearly all cases and certainly in
EVERY case I have worked on on various common machines.
Cambridge CAP machine, that code would terminate the program before
the increment. In fact, 'int *x; x;' could terminate the program if the
compiler did not optimise the reference to x away. Do you know that
the code will increment on every future machine, now that this awkward
old one is so much scrap?

--
Sep 17 '08 #63
s0****@gmail.com wrote:
On Sep 16, 11:51 am, ra*****@gmail.com wrote:
>On Sep 16, 4:20 pm, vipps...@gmail.com wrote:
>>b = ((unsigned char *)b) + 5 * sizeof *a;
I see, got to switch to char * so that it can be incremented properly.

No, to unsigned char *. But if your compiler can do it with the void
*, then do it with the void *. It's probably specialized for that kind
of stuff anyway.
There's two things wrong with what you said:
1 It doesn't matter whether the cast is to
(char *) or (unsigned char *),
because the pointer arithmetic is the same.
2 (void *) is wrong. You shouldn't write code that only works
on your compiler, without a special reason.
There is no special reason here.

--
pete
Sep 17 '08 #64
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>vi******@gmail.com writes:
On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
when you do
--char *c; c++; ==c is incremented by 1
--long int *x; x++ ==x is incremented by 4.

Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.
And who exactly said "it will not increment"?

vippstar's actual statement, which you quoted, was:

"... assuming x was initialized, it would be incremented by 1".

He quite reasonably chose not to make any claim about what would
happen if x was not initialized.

--
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"
Sep 17 '08 #65
Keith Thompson <ks***@mib.orgwrites:
Richard<rg****@gmail.comwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>Richard<rg****@gmail.comwrites:
vi******@gmail.com writes:
On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>when you do
>--char *c; c++; ==c is incremented by 1
>--long int *x; x++ ==x is incremented by 4.
>
Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

And who exactly said "it will not increment"?

vippstar's actual statement, which you quoted, was:

"... assuming x was initialized, it would be incremented by 1".

He quite reasonably chose not to make any claim about what would
happen if x was not initialized.
Can you be more obstinate and childish? There is nothing "reasonable"
about it all in the context of which I am talking. In the greater
majority of cases x will incremented REGARDLESS of whether it was
initialised or not. Why this is so tricky for you to understand I am not
sure. You seem unable to think outside of the standard. Do try.

Yes, yes demons out of noses etc etc. But meanwhile in the real world.
And ONCE AGAIN : yes I DO understand that incrementing an uninitialised
variable is a silly thing to do.
Sep 17 '08 #66
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>Ben Bacarisse <be********@bsb.me.ukwrites:

Richard<rg****@gmail.comwrites:

vi******@gmail.com writes:
>
>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>when you do
>>--char *c; c++; ==c is incremented by 1
>>--long int *x; x++ ==x is incremented by 4.
>>
>Wrong, assuming x was initialized, it would be incremented by 1.
>
Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

Why? I honestly can't see why you think it must do anything at all.

I dont think it *must* do anything at all.
Good. We are agreed. I can't see how your "even if it wasn't
initialised it would be incremented by something" is consistent with
that because it suggests at least one thing must happen -- some form
of increment -- but it seems you don't hold that view any more.
But I am yet to see a machine
where it is not incremented if it is not initialised. Its
"uninitialised" value is incremented in each and every case. Sure its
"undefined behaviour in terms of the value, but its still UDV+1 ...
Ah, you do it seems. That is not what the standard says. It says
that the value may be a trap representation and that accessing such a
thing in the normal way is undefined. At that point (which can be
before the increment) the program may terminate or do whatever your
favourite example of UB is. I think termination is undefined enough
and is what the machine I described would do.
>The whole point of my post was to say "beware" to people who
mock undefined behaviour because you don't know the future. On the

Let me make something very clear - I am not mocking UDB. I am just
pointing out that in most cases it is WRONG to say the unitialised
variable is NOT incremented.
I did not say it is *not* incremented -- you said it *will* be and at
the time you gave no exceptions.

The standard says it may not be and think you have missed that
possibility. Pointers can be invalid in such a way that merely
"touching" them cause a fault. This is an excellent bit of standards
writing and allows C to be implemented on machines with very strict
address checking in hardware (such as the CAP).
It is. In nearly all cases and certainly in
EVERY case I have worked on on various common machines.
I would never have posted if you had said "even uninitialised, it will
usually be incremented". You agree the undefined behaviour is
important but rather than point out that the example has undefined
behaviour you just chose to say what usually happens on current
machines. That does not add to the general readers stock of
understanding.

--
Ben.
Sep 17 '08 #67
Peter Nilsson <ai***@acay.com.auwrites:
CBFalconer <cbfalco...@yahoo.comwrote:
>Peter Nilsson wrote:
Keith Thompson <ks...@mib.orgwrote:
... why does printf have a "%p" format?

That's actually a very good question! If you ever hear
a good answer, please share it.

Well, how about "to allow printf to output a printable char
representation of a void* pointer,

How often is this useful? When it is, how useful is %p?
Printing pointer values probably useful very often, but I like having
"%p" for those cases where it is useful.
>readable by scanf to reconstitute that pointer".

Having printed a pointer with %p, how does a program guarantee
that subsequent printed characters will not undermine scanf's
ability to reconstitute a comprable pointer value?
I must admit I've used *printf and *scanf to print and reconstitute a
pointer value. But with reasonable precautions, such as printing the
value at the end of a line with something recognizable in front of it,
I wouldn't have any qualms about assuming that the output format will
be reasonable. A new-line character in the middle of the result would
mess this up, but I'm content to count on vendors not to do something
that silly.
If I do something like...

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

...what is the guarantee that the output won't exceed an
implementation's limit on text line width?
There's no actual guarantee of this, but again, I'm willing to assume
reasonable behavior. Having the output of "%p" exceed the maximum
text line length is hardly the only silly but legal thing a perverse
implementation could do.
When I do print pointers, I hex dump the representation.
It's the only way to gain full control over the output.

#include <stdio.h>
#include <limits.h>

#define CHAR_NIBBLE ((CHAR_BIT + 3) / 4)

void dump_ptr(FILE *fp, const void *ptr)
{
const unsigned char *p = (const unsigned char *) &ptr;
size_t i;
for (i = 0; i < sizeof ptr; i++)
fprintf(fp, "%0*X", CHAR_NIBBLE, (unsigned) *p++);
}
Sure, that works too. On the other hand, on some systems it's
traditional to show addresses in octal rather than in hexadecimal; on
others, address might be segmented, and your method loses the
distinction between the discrete pieces of the address, something that
"%p" would probably capture.

And it prints the bytes backwards on a little-endian system.

Also, if two different representations represent the same address
(possible in a segmented addressing system), "%p" could at least
potentially normalize them.

--
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"
Sep 17 '08 #68
Richard<rg****@gmail.comwrites:
Keith Thompson <ks***@mib.orgwrites:
>Richard<rg****@gmail.comwrites:
>>Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
vi******@gmail.com writes:
>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>when you do
>>--char *c; c++; ==c is incremented by 1
>>--long int *x; x++ ==x is incremented by 4.
>>
>Wrong, assuming x was initialized, it would be incremented by 1.
>
Even if it wasnt initialised it would be incremented by something.

This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

And who exactly said "it will not increment"?

vippstar's actual statement, which you quoted, was:

"... assuming x was initialized, it would be incremented by 1".

He quite reasonably chose not to make any claim about what would
happen if x was not initialized.

Can you be more obstinate and childish? There is nothing "reasonable"
about it all in the context of which I am talking. In the greater
majority of cases x will incremented REGARDLESS of whether it was
initialised or not. Why this is so tricky for you to understand I am not
sure. You seem unable to think outside of the standard. Do try.
You know what? This most recent statement of yours:

In the greater majority of cases x will incremented REGARDLESS of
whether it was initialised or not.

is one that I agree with.

So what's your problem?

Read the quoted material above. vippstar made a perfectly correct
statement, that x will be incremented if it's been initialized
(leaving aside for the moment the question of whether it's incremented
by 1 or by 4). Expanding that statement to cover the case where x has
not been initialized would have required, for accuracy, a discussion
of undefined behavior, trap representations, and all that stuff. He
quite reasonably chose not to open that can of worms.

You responded by claiming, without qualification, that x will be
incremented even it hasn't been initialized. You've now backed off
from that statement with your "greater majority of cases"
qualification, but you refuse to acknowledge that your more recent
statement differs from your earlier one.
Yes, yes demons out of noses etc etc. But meanwhile in the real world.
And ONCE AGAIN : yes I DO understand that incrementing an uninitialised
variable is a silly thing to do.
I'm glad to hear it -- and a bit surprised, given that many of your
earlier statements in this thread did not demonstrate such knowledge.

Please try to understand that your earlier claim that:

Even if it wasnt initialised it would be incremented by something.

could easily mislead an unwary newbie into thinking that it's safe to
increment an uninitialized pointer.

In addition, your later statement:

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

is correct, but it could lead someone to the incorrect conclusion that
someone had actually written "it will not increment".

You might think that putting words into other people's mouths makes it
easy to win arguments, but that trick doesn't work so well when
people's actual words are recorded.

--
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"
Sep 17 '08 #69
On Tue, 16 Sep 2008 09:51:22 -0700 (PDT), ra*****@gmail.com wrote:
>On Sep 16, 4:20 pm, vipps...@gmail.com wrote:
>b = ((unsigned char *)b) + 5 * sizeof *a;

I see, got to switch to char * so that it can be incremented properly.
If you cast b to int* then the expression could be simpler:
b = ((int *)b) + 5;

Any pointer to a complete type can be used for pointer arithmetic.
>
>Yes, but by using the offsetof() macro in <stddef.h>

I meant to point to the structure.

struct st { int val; } a[100];

void *b;

a[5].val = 100;

b = a;
b = ((unsigned char *)b) + 5 * sizeof *a;

printf( "%d\n" , b->val );
Why don't you just run it through your compiler and note the mandatory
diagnostic? The left operand of -must be a pointer to struct. While
b has the correct value, does it have the correct type?

--
Remove del for email
Sep 17 '08 #70
vi******@gmail.com writes:
On Sep 16, 11:07 pm, Jean-Marc Bourguet <j...@bourguet.orgwrote:
<snip>
@type pvoid.c
#include <stdio.h>

int main()
{
int x;
char y;
char t[10];
int i;
printf("&x = %p\n&x = %o\n&y = %p\n", (void*)&x, (unsigned)&x, (void*)&y);
for (i=0; i<10; ++i) {
printf("&t[%d] = %p\n", i, &t[i]);
}
return 0;}

I'm curious, why don't you cast &t[i] to (void *)?
I just forgot it as I normally don't make a difference between char* and
other pointers and always cast when passing them to variadic functions (see
for y above). But, while I haven't the time to back up my opinion with
citations, I also think that it shouldn't make a difference for that
reason:
My thoughts: &t[i] is a char *. void * and char * are guaranteed to
have the same representation and size.
However, does that let you pass char * to a variadic function
expecting void *? (there's probably not a singlest implementation
where it'd matter, but I'm curious)
I think so.

Yours,

--
Jean-Marc
Sep 17 '08 #71
On Sep 16, 4:49*pm, Keith Thompson <ks...@mib.orgwrote:
Another interesting question is why there's no format for printing
function pointers
I would assume that, due to the existence of dynamic loading and
relocatable libraries, you can't realistically enforce that the
printable representation of a function pointer, when fed to scanf,
reconstitutes that function pointer.

Sure, it can be *done*, but making every implementation do it is
pretty far out of line.

-o
Sep 17 '08 #72
Owen Jacobson <an**********@gmail.comwrites:
On Sep 16, 4:49*pm, Keith Thompson <ks...@mib.orgwrote:
>Another interesting question is why there's no format for printing
function pointers

I would assume that, due to the existence of dynamic loading and
relocatable libraries, you can't realistically enforce that the
printable representation of a function pointer, when fed to scanf,
reconstitutes that function pointer.

Sure, it can be *done*, but making every implementation do it is
pretty far out of line.
I don't think that's the issue. Pointer values are only expected to
be valid within the current execution of the current program. Within
that context, you can already save the representation of a function
pointer (say, by treating it as an array of unsigned char and getting
a hexadecimal representation) and then later reconstitute the pointer
value, and it will work. A printf format for function pointers
wouldn't create any new problems.

I think it's just a matter of insufficient demand.

--
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"
Sep 17 '08 #73
On 16 Sep, 21:14, s0s...@gmail.com wrote:
On Sep 16, 2:52 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
s0s...@gmail.com wrote:
On Sep 16, 12:51 pm, Eric Sosman <Eric.Sos...@sun.comwrote:
s0s...@gmail.com wrote:
On Sep 16, 12:06 pm, vipps...@gmail.com wrote:
On Sep 16, 7:59 pm, s0s...@gmail.com wrote:
On Sep 16, 11:51 am, raph...@gmail.com wrote:
>On Sep 16, 4:20 pm, vipps...@gmail.com wrote:
>>>>>>b = ((unsigned char *)b) + 5 * sizeof *a;
>I see, got to switch to char * so that it can be incremented properly.
No, to unsigned char *. But if your compiler can do it with the void
*, then do it with the void *. It's probably specialized for that kind
of stuff anyway.
nonsense
>>>You can have the "worst advice of the month" clc award.
note this
>>>You have two options, do it portably, or do it with an extension, with
absolutely no loss in efficiency or size, and you advice to choose the
extension.
Well, perhaps the OP doesn't need portability (or at least not this
kind of portability).
there is a *well defined* and *portable* way to do this. So why choose
a non-portable way? I'm sorry I've had this sort of argument before
(in my work place) we really are on different planets. Why NOT
use a portable means, if it exists?

>>Besides, void * seems more natural for this kind
of task.
rubbish
> "This kind of task" was an artificial bit of code specifically
written to experiment with manipulating pointers. An investigative
doodle, nothing more.
No. This "investigate doodle" demonstrated this kind of task. But this
kind of task is also common in real-world programs, and it's
important. I, for one, have actually done this, without realizing I
was using an extension.
so now you know- so don't do it again

Perhaps you should be more specific about what you mean by "this
kind of task," because I (mis?)understood you to be referring to the
code in the original post.

I was referring to the task of performing pointer arithmetic on a void
pointer rather than on an unsigned char pointer, in a case where the
pointer points to some arbitrary object (an array of int, in the OP's
case).
> Personally, I'm not as ready as vippstar is to give you the
award; we're only halfway through the month.
thats the ""worst advice of the month" clc award" referredf to
earlier. He probably thinks somone will come up with something
even more stupid before the end of the month

> But I'd be surprised
if you weren't on the ballot a couple weeks from now.
but he still thinks it's pretty stupid
> Have you
chosen your running mate yet?
the americans are having an election. It involves a process
called "choosing a running mate". He was making a half-humerous
reference to this.

Note: comp.lang .c doesn't have a "worst advice of the month award"
(perhaps it should)

I did not understand a word of that paragraph.
I hope I helped you there
So you understand English as well as you understand C?

...says someone who made a remark about something without being aware
of what he was talking about.
que?
Seriously, though, I don't know what you
mean by me "being on the ballot a couple of weeks from now" or me
"choosing my running mate yet."

--
Nick Keighley

"an easy to use computer should do what I mean, not what I say,
and by no means send me a dancing paper clip to ask"
Nicholas Negroponte (MIT Professor)
Sep 17 '08 #74
On 16 Sep, 22:25, Richard<rgr...@gmail.comwrote:
Keith Thompson <ks...@mib.orgwrites:
s0s...@gmail.com writes:
On Sep 16, 1:47*pm, Keith Thompson <ks...@mib.orgwrote:
Richard<rgr...@gmail.comwrites:
Keith Thompson <ks...@mib.orgwrites:
>You're using "%u" to print pointer values. *Surely you know that
invokes undefined behavior, and I know of common real-world systems
Garbage. On my machine it prints a 32 bit value. Pointers are values
which I can printf and see and they correspond to physical memory
locations. Its a number get over it.
>Then why does printf have a "%p" format?
Pointers are not numbers.
Then how come C99 introduces the intptr_t typedef and the PRIdPTR
conversion specifier to print it as decimal?
Because pointers can be *converted* to numbers. *Note that intptr_t

My pointers were numbers. I could see them in the debugger....- Hide quoted text -
but in general they aren't. Think DOS. Think IBM mainframe.
Are you trying to be dense?

--
Nick Keighley
Sep 17 '08 #75
On 17 Sep, 01:27, Peter Nilsson <ai...@acay.com.auwrote:
Richard Heathfield <r...@see.sig.invalidwrote:
Peter Nilsson said:
Keith Thompson <ks...@mib.orgwrote:
... why does printf have a "%p" format?
That's actually a very good question! If you ever hear
a good answer, please share it.
to print pointer representations...

Implementations have considerable licence over the textual
representation of pointer values.

That's the problem.
One MS-DOS compiler I have used (dim and distant past,
admittedly) would print pointer values like this: DS:FADE
I mean *obviously* that's a number, right? It's just not
immediately obvious /which/ number it is.

In the rare cases where I print pointers, I'm less concerned
about the pointer value itself than I am about how the value
is displayed.

Realising this, I've often asked myself why I bothered
printing the pointer in the first place! Which brings us
back to the question of why %p exists. [And why, if it is
to exist, is there no corresponding specifier for function
pointers.]
I've used it to identify objects. The one thing that is unique
is the address!! For instance to track memory leaks. A log
kept track of when things were allocated and freed (and some
other history). You then had a fighting chance of working
out why things were not freed. Note this would work whatever
representation %p used.

--
Nick Keighley

"Morality is a spandrel of the game theoretic implications of the
society of symbol users.
We impute moral worth to the non-social world on that basis."
(John Wilkins talk.origins)
Sep 17 '08 #76
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>Richard<rg****@gmail.comwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

Richard<rg****@gmail.comwrites:
>
>vi******@gmail.com writes:
>>
>>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>>when you do
>>>--char *c; c++; ==c is incremented by 1
>>>--long int *x; x++ ==x is incremented by 4.
>>>
>>Wrong, assuming x was initialized, it would be incremented by 1.
>>
>Even if it wasnt initialised it would be incremented by something.
>
This thread has gone off in another direction, but I want to come back
to this. Please, coders of the world, don't take this remark from
Richard to heart -- think of your children!

Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

Why? I honestly can't see why you think it must do anything at all.

I dont think it *must* do anything at all.

Good. We are agreed. I can't see how your "even if it wasn't
initialised it would be incremented by something" is consistent with
that because it suggests at least one thing must happen -- some form
of increment -- but it seems you don't hold that view any more.
Hold on here. You're trying to be smart. Once again

1) I do not think that incrementing a non initialised var is a good
idea.
2) Yes I know the standard says "UDB".
3) In ALL cases I have ever known it IS incremented.

So to say "it is not incremented" is not true.

We can play all the word games you like. But the above are true.
>
>But I am yet to see a machine
where it is not incremented if it is not initialised. Its
"uninitialised" value is incremented in each and every case. Sure its
"undefined behaviour in terms of the value, but its still UDV+1 ...

Ah, you do it seems. That is not what the standard says. It says
Do you have a comprehension issue today? I am not supporting that
increment. I am not saying one should do it. I am not arguing about what
the standard says, I am merely saying that in the real world in the
great majority of cases it is indeed incremented.

Which part of the above confuses you or you trying to manipulate this
into making me look like some clueless nOOb who is not aware of the
dangers of toying with UDB?
Sep 17 '08 #77
Nick Keighley <ni******************@hotmail.comwrites:
On 16 Sep, 22:25, Richard<rgr...@gmail.comwrote:
>Keith Thompson <ks...@mib.orgwrites:
s0s...@gmail.com writes:
On Sep 16, 1:47*pm, Keith Thompson <ks...@mib.orgwrote:
Richard<rgr...@gmail.comwrites:
Keith Thompson <ks...@mib.orgwrites:
>>You're using "%u" to print pointer values. *Surely you know that
invokes undefined behavior, and I know of common real-world systems
>Garbage. On my machine it prints a 32 bit value. Pointers are values
which I can printf and see and they correspond to physical memory
locations. Its a number get over it.
>>Then why does printf have a "%p" format?
Pointers are not numbers.
>Then how come C99 introduces the intptr_t typedef and the PRIdPTR
conversion specifier to print it as decimal?
Because pointers can be *converted* to numbers. *Note that intptr_t

My pointers were numbers. I could see them in the debugger....- Hide quoted text -

but in general they aren't. Think DOS. Think IBM mainframe.
Are you trying to be dense?
Are you?

What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address. And lets
face it that address IS a number whether you like to be too clever about
it or not.

--
Sep 17 '08 #78
On Sep 17, 3:05 pm, Richard <rgr...@gmail.comwrote:

<snip>
What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address. And lets
face it that address IS a number whether you like to be too clever about
it or not.
You are wrong. Pointers are objects. Objects have a representation,
which is a bit string.
Bit strings can interpreted in arbitrary ways. One of them is treating
the bit string as a base 2 integer.

I'm sure you'll come up again with something stupid to say. Don't let
me down.
Sep 17 '08 #79
On Sep 16, 7:00*pm, Antoninus Twink <nos...@nospam.invalidwrote:
On 16 Sep 2008 at 21:48, Richard wrote:
In gcc you can perform arithmetic on void pointers as it assumes
unsigned char *. Which is common sense IMO in 99.9999% of platforms
since real memory is address at real memory addresses which are real
numbers.

It's another clc obsession, though. void* and char* can be losslessly
converted back and forth. Nonetheless, /in theory/ they can have
different representations. The fact that they don't on any system in
existence or any system that will ever be built doesn't stop the "regs"
waking up in a cold sweat worrying about it.
You're missing the point, void * and char * are guaranteed to have the
same representation, I haven't seen anyone else say otherwise, and the
accepted solution involves converting back and forth through
(unsigned) char *. The problem is that since the Standard expressly
forbids pointer arithmetic on void * pointers (despite similarities
with char pointers, they are a different type), many compilers do not
support it and those that do cannot support it in full compliance
mode. The objection stems from the issue of portability, especially
given that there is a simple, portable alternative.

--
Robert Gamble
Sep 17 '08 #80
On Sep 17, 3:37 pm, Robert Gamble <rgambl...@gmail.comwrote:
On Sep 16, 7:00 pm, Antoninus Twink <nos...@nospam.invalidwrote:
[snip incrementing void pointers]
It's another clc obsession, though. void* and char* can be losslessly
converted back and forth. Nonetheless, /in theory/ they can have
different representations. The fact that they don't on any system in
existence or any system that will ever be built doesn't stop the "regs"
waking up in a cold sweat worrying about it.

You're missing the point, void * and char * are guaranteed to have the
same representation, I haven't seen anyone else say otherwise, and the
accepted solution involves converting back and forth through
(unsigned) char *. The problem is that since the Standard expressly
forbids pointer arithmetic on void * pointers (despite similarities
with char pointers, they are a different type), many compilers do not
support it and those that do cannot support it in full compliance
mode. The objection stems from the issue of portability, especially
given that there is a simple, portable alternative.
Well, that is not entirely true. It's possible for a compiler to
support[*] incrementing void * pointers in strict conformance mode.
Incrementing a void pointer is a constraint violation which, as far as
the standard is concerned, requires a diagnostic.
The compiler may, along with emitting that diagnostic, choose to
increment the pointer as if it were a char * pointer.
[*] support as in, choose a particular behavior when undefined
behavior is invoked.
Sep 17 '08 #81
Richard wrote:
What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address.
Clearly a pointer has to "correspond" with a "memory address" in some
way, otherwise you couldn't use it to access memory.
And lets face it that address IS a number whether you like to be
too clever about it or not.
/Part of/ an address has to respect arithmetic, at least + - = < >.
That doesn't mean the address /is/ a number. One only has to remember
segmented addresses to realise that.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Sep 17 '08 #82
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Richard<rg****@gmail.comwrites:
>>Ben Bacarisse <be********@bsb.me.ukwrites:

Richard<rg****@gmail.comwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:
>
>Richard<rg****@gmail.comwrites:
>>
>>vi******@gmail.com writes:
>>>
>>>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>>>when you do
>>>>--char *c; c++; ==c is incremented by 1
>>>>--long int *x; x++ ==x is incremented by 4.
>>>>
>>>Wrong, assuming x was initialized, it would be incremented by 1.
>>>
>>Even if it wasnt initialised it would be incremented by something.
>>
>This thread has gone off in another direction, but I want to come back
>to this. Please, coders of the world, don't take this remark from
>Richard to heart -- think of your children!
>
Oh for goodness sake Ben, I was not condoning it! But to say "it will
not increment" is clearly false.

Why? I honestly can't see why you think it must do anything at all.

I dont think it *must* do anything at all.

Good. We are agreed. I can't see how your "even if it wasn't
initialised it would be incremented by something" is consistent with
that because it suggests at least one thing must happen -- some form
of increment -- but it seems you don't hold that view any more.

Hold on here. You're trying to be smart. Once again

1) I do not think that incrementing a non initialised var is a good
idea.
2) Yes I know the standard says "UDB".
3) In ALL cases I have ever known it IS incremented.

So to say "it is not incremented" is not true.

We can play all the word games you like. But the above are true.
>>
>>But I am yet to see a machine
where it is not incremented if it is not initialised. Its
"uninitialised" value is incremented in each and every case. Sure its
"undefined behaviour in terms of the value, but its still UDV+1 ...

Ah, you do it seems. That is not what the standard says. It says

Do you have a comprehension issue today?
No, but I can see there no point in continuing. We have both made our
positions clear.

--
Ben.
Sep 17 '08 #83
Richard wrote:
....
3) In ALL cases I have ever known it IS incremented.
How is that relevant? You clearly do not know ALL cases, since there are
real machines (one has already been cited) where it is NOT incremented.
The existence of that machine (and many others with similar properties)
is far more relevant than your lack of experience with such machines.
So to say "it is not incremented" is not true.
No one but you has said anything like that, and you have said it only to
refute the claim (which no one made). What has been said is that your
claim that it is incremented is not always true.

....
the standard says, I am merely saying that in the real world in the
great majority of cases it is indeed incremented.
And if you had qualified your original statement with "in the great
majority of cases", it would have been unobjectionable. It was your flat
out, unqualified assertion that it is incremented that people have been
objecting to.
Which part of the above confuses you or you trying to manipulate this
into making me look like some clueless nOOb who is not aware of the
dangers of toying with UDB?
You don't look like a clueless nOOb. A nOOb has too little experience,
and is generally very aware of that fact. You look like someone who has
too much experience with a limited class of machines, and as a result
tends to assume that all machines are like the ones you have experience
with, or at least all machines worth bothering to think about.
Sep 17 '08 #84
Ben Bacarisse <be********@bsb.me.ukwrites:
Richard<rg****@gmail.comwrites:
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>Richard<rg****@gmail.comwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

Richard<rg****@gmail.comwrites:
>
>Ben Bacarisse <be********@bsb.me.ukwrites:
>>
>>Richard<rg****@gmail.comwrites:
>>>
>>>vi******@gmail.com writes:
>>>>
>>>>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
>>>>>when you do
>>>>>--char *c; c++; ==c is incremented by 1
>>>>>--long int *x; x++ ==x is incremented by 4.
>>>>>
>>>>Wrong, assuming x was initialized, it would be incremented by 1.
>>>>
>>>Even if it wasnt initialised it would be incremented by something.
>>>
>>This thread has gone off in another direction, but I want to come back
>>to this. Please, coders of the world, don't take this remark from
>>Richard to heart -- think of your children!
>>
>Oh for goodness sake Ben, I was not condoning it! But to say "it will
>not increment" is clearly false.
>
Why? I honestly can't see why you think it must do anything at all.

I dont think it *must* do anything at all.

Good. We are agreed. I can't see how your "even if it wasn't
initialised it would be incremented by something" is consistent with
that because it suggests at least one thing must happen -- some form
of increment -- but it seems you don't hold that view any more.

Hold on here. You're trying to be smart. Once again

1) I do not think that incrementing a non initialised var is a good
idea.
2) Yes I know the standard says "UDB".
3) In ALL cases I have ever known it IS incremented.

So to say "it is not incremented" is not true.

We can play all the word games you like. But the above are true.
>>>
But I am yet to see a machine
where it is not incremented if it is not initialised. Its
"uninitialised" value is incremented in each and every case. Sure its
"undefined behaviour in terms of the value, but its still UDV+1 ...

Ah, you do it seems. That is not what the standard says. It says

Do you have a comprehension issue today?

No, but I can see there no point in continuing. We have both made our
positions clear.
Actually,no, you haven't. You keep trying to put words in my mouth. I am
surprised. My comments are clear enough.
Sep 17 '08 #85
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address.

Clearly a pointer has to "correspond" with a "memory address" in some
way, otherwise you couldn't use it to access memory.
>And lets face it that address IS a number whether you like to be
too clever about it or not.

/Part of/ an address has to respect arithmetic, at least + - = < >.
That doesn't mean the address /is/ a number. One only has to remember
segmented addresses to realise that.
So, you are saying that in segmented architectures (which I wrote
assembler VGA libraries for) your debugger does not store the pointer
parts in binary registers which in turn render as numbers on the
debugger display?

Now this is getting silly.

My only comment was that in most cases an uninitialised pointer will
indeed increment in the real world.

nothing more. Nothing less.

Quite why this has turned into a crusade for clc standard correctness is
any ones guess.
Sep 17 '08 #86
James Kuyper <ja*********@verizon.netwrites:
Richard wrote:
...
>3) In ALL cases I have ever known it IS incremented.

How is that relevant? You clearly do not know ALL cases, since there
Where did I say ALL cases? Please post a link. And it is relevant
because I am telling MY experience.
are real machines (one has already been cited) where it is NOT
incremented. The existence of that machine (and many others with
similar properties) is far more relevant than your lack of experience
with such machines.
What are you taking about? I never said there were no machines where the
increment DID NOT take place. I countered the argument that was "the
increment will not happen" or words to that affect.
>
>So to say "it is not incremented" is not true.

No one but you has said anything like that, and you have said it only
to refute the claim (which no one made). What has been said is that
your claim that it is incremented is not always true.
Err, I said that. I made it clear maybe 5 times now. I also said I do
not condone sloppy programming which ASSUMES it be so incremented.
>
...
>the standard says, I am merely saying that in the real world in the
great majority of cases it is indeed incremented.

And if you had qualified your original statement with "in the great
majority of cases", it would have been unobjectionable. It was your
flat out, unqualified assertion that it is incremented that people
have been objecting to.
I dont recall ever saying that. I said it is incremented on my
machines. I countered that argument which said "it is NOT incremented".
>
>Which part of the above confuses you or you trying to manipulate this
into making me look like some clueless nOOb who is not aware of the
dangers of toying with UDB?

You don't look like a clueless nOOb. A nOOb has too little experience,
and is generally very aware of that fact. You look like someone who
has too much experience with a limited class of machines, and as a
result tends to assume that all machines are like the ones you have
experience with, or at least all machines worth bothering to think
about.
Unbelievable. Really. Even for c.l.c
Sep 17 '08 #87
Richard<rg****@gmail.comwrites:
Ben Bacarisse <be********@bsb.me.ukwrites:
<snip>
>No, but I can see there no point in continuing. We have both made our
positions clear.

Actually,no, you haven't. You keep trying to put words in my mouth. I am
surprised.
It is obvious that I have not been able to clear to you and that you
believe you have not been able to be understood by me. The point is
that I sure that I have been as clear as I want to be and that I have
understood you as well as I can.
My comments are clear enough.
Then you have nothing to worry about. Everyone will be able to read
what you have said and come to the right conclusion.

--
Ben.
Sep 17 '08 #88
On Sep 16, 8:14*pm, pete <pf*****@mindspring.comwrote:
s0****@gmail.com wrote:
On Sep 16, 11:51 am, ra*****@gmail.com wrote:
On Sep 16, 4:20 pm, vipps...@gmail.com wrote:
>b = ((unsigned char *)b) + 5 * sizeof *a;
I see, got to switch to char * so that it can be incremented properly.
No, to unsigned char *. But if your compiler can do it with the void
*, then do it with the void *. It's probably specialized for that kind
of stuff anyway.

There's two things wrong with what you said:
1 * *It doesn't matter whether the cast is to
* * * (char *) or (unsigned char *),
* * * because the pointer arithmetic is the same.
Yes, but I and vippstar suggested using unsigned char because the
pointer pointed to an array of int, so it's safer to use unsigned char
in this cases (I actually asked a question here about this some time
ago).
2 * *(void *) is wrong. You shouldn't write code that only works
* * * on your compiler, without a special reason.
* * * There is no special reason here.
Surely you meant that performing arithmetic on a (void *) is wrong.
Well, there's at least a small reason here: preference. :-) (Not to
mention the minor annoyance of having to do the conversion.)

Sebastian

Sep 17 '08 #89
On Sep 17, 3:02*am, Nick Keighley <ni******************@hotmail.com>
wrote:
On 16 Sep, 21:14, s0s...@gmail.com wrote:
<snip>
>>>>You have two options, do it portably, or do it with an extension,with
>>>>absolutely no loss in efficiency or size, and you advice to choose the
>>>>extension.
>>>Well, perhaps the OP doesn't need portability (or at least not this
>>>kind of portability).

there is a *well defined* and *portable* way to do this. So why choose
a non-portable way? I'm sorry I've had this sort of argument before
(in my work place) we really are on different planets. Why NOT
use a portable means, if it exists?
Because sometimes you don't need portability and because sometimes
there's a better way?
>>>Besides, void * seems more natural for this kind
>>>of task.

rubbish
Why is it rubbish? If you have a void pointer, it will typically point
to any kind of object: int, double, long long, structures, anything.
Does it seem natural to you to treat such an object as if it were a
*character*?
>>* * *"This kind of task" was an artificial bit of code specifically
>>written to experiment with manipulating pointers. *An investigative
>>doodle, nothing more.
>No. This "investigate doodle" demonstrated this kind of task. But this
>kind of task is also common in real-world programs, and it's
>important. I, for one, have actually done this, without realizing I
>was using an extension.

so now you know- so don't do it again
Why not? I'll simply keep in mind that it works only under a certain
compiler.

Sebastian

Sep 17 '08 #90
Peter Nilsson wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
>Peter Nilsson wrote:
>>Keith Thompson <ks...@mib.orgwrote:
... why does printf have a "%p" format?
That's actually a very good question! If you ever hear
a good answer, please share it.
Well, how about "to allow printf to output a printable char
representation of a void* pointer,

How often is this useful? When it is, how useful is %p?
It's helpful in debugging, sometimes. I've never found a
use for it in "deployed" code.
>readable by scanf to reconstitute that pointer".

Having printed a pointer with %p, how does a program guarantee
that subsequent printed characters will not undermine scanf's
ability to reconstitute a comprable pointer value?
That's the same problem one always has: The fact that you've
used printf() and made no mistakes doesn't guarantee that you
can read the same data back again with scanf(). For example,

int i = 42, j = 9;
printf ("%d%d\n", i, j);

Also, FWIW, although I've used "%p" with printf() I have
never found a reason to use it with scanf(). Pleasant symmetry,
I suppose (although printf() and scanf() are by no means mirror
images), but I've never found a use for it.
If I do something like...

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

...what is the guarantee that the output won't exceed an
implementation's limit on text line width?
None that I can see. But again, the same problem arises
in other situations:

printf("DBL_MAX is %f\n", DBL_MAX);

.... might try to print a very long string.
When I do print pointers, I hex dump the representation.
It's the only way to gain full control over the output.
[...]
Well, you can do as you like. It doesn't strike me that
this "full control" you're fond of does you a lot of good, but
if it floats your boat ...

--
Er*********@sun.com
Sep 17 '08 #91
On Sep 17, 5:55 pm, s0s...@gmail.com wrote:

[about incrementing void pointers as opposed to (char *) cast]
Because sometimes you don't need portability and because sometimes
there's a better way?
Yes, that better way being the portable way, in this case.

....
Why is it rubbish? If you have a void pointer, it will typically point
to any kind of object: int, double, long long, structures, anything.
Does it seem natural to you to treat such an object as if it were a
*character*?
No it doesn't. How the heck does void * feel more natural to treat as
a pointer to character than char *?

....
Why not? I'll simply keep in mind that it works only under a certain
compiler.
No, what you keep in mind is to never suggest this crap again.

P.S. Just a troll or too stubborn?
Sep 17 '08 #92
Richard<rg****@gmail.comwrites:
[...]
My only comment was that in most cases an uninitialised pointer will
indeed increment in the real world.

nothing more. Nothing less.
[...]

No, your original comment did not include the "in most cases"
qualification. You claimed that an uninitialized pointer can be
incremented. Now you've backtracked and qualified your earlier
statement, but you still refuse to admit that your earlier statement
was incorrect. You're even denying ("nothing more. Nothing less.")
that you've changed your statement.

--
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"
Sep 17 '08 #93
Richard wrote:
Chris Dollin <ch**********@hp.comwrites:
>Richard wrote:
>>What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address.

Clearly a pointer has to "correspond" with a "memory address" in some
way, otherwise you couldn't use it to access memory.
>>And lets face it that address IS a number whether you like to be
too clever about it or not.

/Part of/ an address has to respect arithmetic, at least + - = < >.
That doesn't mean the address /is/ a number. One only has to remember
segmented addresses to realise that.

So, you are saying that in segmented architectures (which I wrote
assembler VGA libraries for) your debugger does not store the pointer
parts in binary registers which in turn render as numbers on the
debugger display?
No, I am not saying that. I'm perfectly happy to believe that your
debugger renders bits of pointer as numbers.
Now this is getting silly.
Correct.
My only comment was that in most cases an uninitialised pointer will
indeed increment in the real world.
That's cool, so long as you acknowledge that "most" and don't
confuse it with an "all".

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Sep 17 '08 #94
Keith Thompson <ks***@mib.orgwrites:
Richard<rg****@gmail.comwrites:
[...]
>My only comment was that in most cases an uninitialised pointer will
indeed increment in the real world.

nothing more. Nothing less.
[...]

No, your original comment did not include the "in most cases"
I made it very clear in the thread.
qualification. You claimed that an uninitialized pointer can be
incremented. Now you've backtracked and qualified your earlier
I know I did. And I still do. It can be incremented. And in most cases
it will. Is this right to do? No. Seriously, do you not understand what
I am saying here?
statement, but you still refuse to admit that your earlier statement
was incorrect. You're even denying ("nothing more. Nothing less.")
that you've changed your statement.
I have nothing to admit.

I stand by each and every one of my comments.

I can see your agenda here, but sorry it wont wash.
Sep 17 '08 #95
Chris Dollin <ch**********@hp.comwrites:
Richard wrote:
>Chris Dollin <ch**********@hp.comwrites:
>>Richard wrote:

What pointer do you know that doesnt render as a number? MSDOS,
anything. I have built various SW systems on various machines and am yet
to see a pointer which did not correspond to a memory address.

Clearly a pointer has to "correspond" with a "memory address" in some
way, otherwise you couldn't use it to access memory.

And lets face it that address IS a number whether you like to be
too clever about it or not.

/Part of/ an address has to respect arithmetic, at least + - = < >.
That doesn't mean the address /is/ a number. One only has to remember
segmented addresses to realise that.

So, you are saying that in segmented architectures (which I wrote
assembler VGA libraries for) your debugger does not store the pointer
parts in binary registers which in turn render as numbers on the
debugger display?

No, I am not saying that. I'm perfectly happy to believe that your
debugger renders bits of pointer as numbers.
Thats nice. How does your debugger do it? When you look into memory and
you see your pointer stored in an arry how does it look? Hex number by
any chance? What a surprise. If you cast it to a char * and subtract p
from ++p do you get 4 on a 32 bit machine? I did.....
>
>Now this is getting silly.

Correct.
>My only comment was that in most cases an uninitialised pointer will
indeed increment in the real world.

That's cool, so long as you acknowledge that "most" and don't
confuse it with an "all".
Huh?!?!?!?!

Please quote where I said all. Where I did not qualify with "in my
experience" or "my platforms".
Sep 17 '08 #96
On Sep 17, 10:22*am, vi******@gmail.com wrote:
On Sep 17, 5:55 pm, s0s...@gmail.com wrote:

[about incrementing void pointers as opposed to (char *) cast]
Because sometimes you don't need portability and because sometimes
there's a better way?

Yes, that better way being the portable way, in this case.
Well, it's a matter of whether you prefer void * or char *.
...
Why is it rubbish? If you have a void pointer, it will typically point
to any kind of object: int, double, long long, structures, anything.
Does it seem natural to you to treat such an object as if it were a
*character*?

No it doesn't. How the heck does void * feel more natural to treat as
a pointer to character than char *?
Read again: I was talking about pointers to int, double, long long,
structures, or any arbitrary object. How do you come up with "pointer
to character"?
...
Why not? I'll simply keep in mind that it works only under a certain
compiler.

No, what you keep in mind is to never suggest this crap again.
Give me a good argument not to.
P.S. Just a troll or too stubborn?
You have demonstrated several things in this post:

- You have reading comprehension problems
- You are aggressive about purely stylistic issues
- You are incapable of using decent language

It's clear who is the troll here.

Sebastian

Sep 17 '08 #97
Keith Thompson <ks***@mib.orgwrites:
Richard<rg****@gmail.comwrites:
>vi******@gmail.com writes:
>>On Sep 16, 7:13 pm, sh.vi...@gmail.com wrote:
when you do
--char *c; c++; ==c is incremented by 1
--long int *x; x++ ==x is incremented by 4.

Wrong, assuming x was initialized, it would be incremented by 1.

Even if it wasnt initialised it would be incremented by something.

If x isn't initialized, referring to its value invokes undefined
behavior. It's likely, but by no means certain, that the behavior
would be *as if* it were incremented. It's also possible, on some
systems, that x could have a value such that attempting to read it
causes a program crash. (Before you ask, no, I don't have an
example.)
>>Here's proof:

Proof of nothing. You are, again, being purposely difficult.

The ++ operator increments its operand by 1, by definition. The
question is, 1 what? In the case of:

long int *x = some_value;
x ++;

it advances it by 1 long int object, i.e., causes it to point to the
next adjacent long int object in memory, assuming that such an object
exists; it can also legally point just past the end of an array.
>>long int i[1], *p = i, *q = &i[1];

Note that evaluating &i[1] is ok, and equivalent to i+1, but only
because of a special-case rule; see C99 6.5.3.2p3.
>>printf("%d\n", (int)(q - p));

Will always print 1.

Yes, because of the way pointer subtraction is defined.
>And the following:

int main() {
long int i[1], *p = i, *q = &i[1];
printf("%u\n",p++);
printf("%u\n",p++);
printf("%u\n", (int)(p - q));

}

The first printf gives me:

3214862936

And the second:

3214862940

Now, that is 4. On my machine.
I will reply to this to highlight the above statement.

Enough of the stupid games trying to back me into a corner.

Even if that was NOT clear enough, and I can understand that for this NG
it wasnt, I made it perfectly clear later.

It is just as wrong to say "It will NOT increment".

Personally I have never used a machine where it will not increment. Some
of you assure us there are such. I am willing to believe that with no
proof. I have, however, proven that x can increment. With numbers. And
code.

Now, try growing up a little bit and open your mind to the real
world. Its not good pretending it does not exist. It confuses nOObs for
a start. You say "it will not increment" they then see with their own
eyes in the debugger that it does. What do they then think?

The correct statement is

"It is incorrect to increment a non initialised variable since the
behaviour is undefined - however the value may well increment as
expected".
Sep 17 '08 #98
s0****@gmail.com writes:
On Sep 17, 10:22*am, vi******@gmail.com wrote:
>On Sep 17, 5:55 pm, s0s...@gmail.com wrote:

[about incrementing void pointers as opposed to (char *) cast]
Because sometimes you don't need portability and because sometimes
there's a better way?

Yes, that better way being the portable way, in this case.

Well, it's a matter of whether you prefer void * or char *.
>...
Why is it rubbish? If you have a void pointer, it will typically point
to any kind of object: int, double, long long, structures, anything.
Does it seem natural to you to treat such an object as if it were a
*character*?

No it doesn't. How the heck does void * feel more natural to treat as
a pointer to character than char *?

Read again: I was talking about pointers to int, double, long long,
structures, or any arbitrary object. How do you come up with "pointer
to character"?
>...
Why not? I'll simply keep in mind that it works only under a certain
compiler.

No, what you keep in mind is to never suggest this crap again.

Give me a good argument not to.
>P.S. Just a troll or too stubborn?

You have demonstrated several things in this post:

- You have reading comprehension problems
- You are aggressive about purely stylistic issues
- You are incapable of using decent language

It's clear who is the troll here.

Sebastian
Yes it is. Vippstar is currying favour with the regs. He is obstreperous
to the extreme in his desire to "live and breath the standard".
Sep 17 '08 #99
Eric Sosman <Er*********@sun.comwrites:
[...]
Also, FWIW, although I've used "%p" with printf() I have
never found a reason to use it with scanf(). Pleasant symmetry,
I suppose (although printf() and scanf() are by no means mirror
images), but I've never found a use for it.
[...]

I've never used it either, but I can think of a plausible use for it.

Programs X and Y communicate with each other somehow. They could be
running on the same machine, on different machines, whatever. (The
fact that they're running simultaneously and communicating with each
other necessarily involves mechanisms outside the scope of the C
standard.)

Program X maintains a collection of objects in memory. Program Y
needs to manipulate those objects, or rather, needs to ask X to do so
on its behalf. X uses sprintf(buf, "%p", (void*)&obj) to generate a
textual representation of the address of an object, and transmits that
to Y. Later Y asks X for information about that object, sending back
the textual representation. X uses sscanf with "%p" to reconstruct
the address and access the object. As far as Y is concerned, the
string is just an opaque unique tag that it can use to request
information from X.

As long as Y doesn't try to use these strings beyond the current
execution of X, this should work. (Note that by storing the result by
itself in a single string, we avoid any problems with funny formats.
An extremely long format could cause problems, but we can assume
reasonableness on the part of the author of the *printf routines.)

--
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"
Sep 17 '08 #100

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
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.