Question about void pointers

[Richard]

Richard wrote:
...

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.

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.

...

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".

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

 

[Ben Bacarisse]

Ben Bacarisse <[email protected]> writes:

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.

 

[s0suk3]

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

 

[s0suk3]

On 16 Sep, 21:14, (e-mail address removed) wrote:

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?

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*?

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

 

[vippstar]

On Sep 17, 5:55 pm, (e-mail address removed) 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?

 

[Keith Thompson]

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.

 

[Chris Dollin]

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".

 

[Richard]

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.

 

[Richard]

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.....

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".

 

[s0suk3]

On Sep 17, 5:55 pm, (e-mail address removed) 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 *.

...


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"?

...


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

 

[Richard]

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.)

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.

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".

 

[Richard]

On Sep 17, 5:55 pm, (e-mail address removed) 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 *.

...


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"?

...


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".

 

[Keith Thompson]

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]

Yes, the above are true.

But nobody said "it is not incremented", or even words to that effect.
You are refuting a claim that nobody ever made.

[...]

Actually,no, you haven't. You keep trying to put words in my mouth. I am
surprised. My comments are clear enough.

Putting words in *your* mouth? Typical trollish hypocricy. I'm
tempted to assume that you're doing it deliberately, but I really
don't care one way or the other.

 

[vippstar]

[...]> 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.

They should however, use the same implementation.
Else program X's %p is/might be different than Y's.

I remember someone, some months ago, saying he once had to write
pointers to files, or perhaps he was just describing a scenario where
this might happend.

 

[vippstar]

On Sep 17, 5:55 pm, (e-mail address removed) 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 *.

No you idiot, it's a matter of whether you prefer portability over non-
portability without any other gains or loses.

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"?

Read again.

Give me a good argument not to.

Because it's crap. See previous posts to learn why.

You have demonstrated several things in this post:

- You have reading comprehension problems

You certainly do.

- You are aggressive about purely stylistic issues

OH MY GOD what an idiot. I'm ignoring you.

- You are incapable of using decent language

It's clear who is the troll here.

True. Bye.

 

[Richard Tobin]

Programs X and Y communicate with each other somehow. They could be
running on the same machine, on different machines, whatever.

[/QUOTE]

They should however, use the same implementation.
Else program X's %p is/might be different than Y's.

The second program doesn't have to use %p to read the value, since it
doesn't try to interpret it. Since the %p format only produces
printing characters, a linefeed is sufficient to bound it.

-- Richard

 

[CBFalconer]

.... snip ...

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.

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.

 

[vippstar]

The second program doesn't have to use %p to read the value, since it
doesn't try to interpret it. Since the %p format only produces
printing characters, a linefeed is sufficient to bound it.

Ah yes, you are right. thanks.

 

[James Kuyper]

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*?

Tracing back, "this kind of task" refers to:

int a[20];
void *b;
b = (void *)a; // b points to a[0]
b += 5*sizeof(*a); // b points to a[5]

In this case, 'b' is being used as a pointer to char, because the amount
that is being added to is a number of bytes, not a number of ints. That
being the case, it should be declared as char*, not void*.

If you want use it as a pointer to int, declare it as such:

b = (int*)b + 5;

That has the advantage of being not only more portable than the
original, but simpler, too.