Hello, I'm trying to help someone on a linux-oriented forum. I've taken
his original code and cleaned it up, but I am still wondering about
something. Here's the code:
#include <stdio.h>
int
main(void)
{
int a[][3]={ {1,2,3},{4,5,6,},{7,8,9} };
int *b = (int *)a;
int **c = (int **)a;
int i = 0;
int num_elements = sizeof(a) / sizeof(int);
for(i = 0; i< num_elements; ++i)
printf("*b = %d *c = %d\n", *b++, *c++);
return 0;
}
When compiled I get:
gcc -Wall -W -ansi -pedantic -g -c -o pointer_wonder.o
pointer_wonder.c
pointer_wonder.c: In function `main':
pointer_wonder.c:13: warning: int format, pointer arg (arg 3)
gcc pointer_wonder.o -o pointer_wonder.exe
The output is:
*b = 1 *c = 1
*b = 2 *c = 2
*b = 3 *c = 3
*b = 4 *c = 4
*b = 5 *c = 5
*b = 6 *c = 6
*b = 7 *c = 7
*b = 8 *c = 8
*b = 9 *c = 9
Why is it same for *b and *c?
/ Eric

"Eric Lilja" <mindcooler@gmail.comwrote in message
news:1133969869.613104.235330@
Hello, I'm trying to help someone on a linux-oriented forum. I've taken
his original code and cleaned it up, but I am still wondering about
something. Here's the code:

#include <stdio.h>

int
main(void)
{
int a[][3]={ {1,2,3},{4,5,6,},{7,8,9} };
int *b = (int *)a;
int **c = (int **)a;
int i = 0;
int num_elements = sizeof(a) / sizeof(int);

for(i = 0; i< num_elements; ++i)
printf("*b = %d *c = %d\n", *b++, *c++);

return 0;
}

When compiled I get:
gcc -Wall -W -ansi -pedantic -g -c -o pointer_wonder.o
pointer_wonder.c
pointer_wonder.c: In function `main':
pointer_wonder.c:13: warning: int format, pointer arg (arg 3)
gcc pointer_wonder.o -o pointer_wonder.exe

The output is:
*b = 1 *c = 1
*b = 2 *c = 2
*b = 3 *c = 3
*b = 4 *c = 4
*b = 5 *c = 5
*b = 6 *c = 6
*b = 7 *c = 7
*b = 8 *c = 8
*b = 9 *c = 9

Why is it same for *b and *c?

*b gives you back an int

whereas

*c gives you back an int *

However, the 'values' of each are taken from a.

So, printf would really like a %p (at least) for the third arg.

"pemo" <usenetmeister@gmail.comwrote in message
news:dn705d$4r6$1@news.ox.ac.uk

"Eric Lilja" <mindcooler@gmail.comwrote in message
news:1133969869.613104.235330@
>Hello, I'm trying to help someone on a linux-oriented forum. I've taken
>his original code and cleaned it up, but I am still wondering about
>something. Here's the code:
>>
>#include <stdio.h>
>>
>int
>main(void)
>{
>int a[][3]={ {1,2,3},{4,5,6,},{7,8,9} };
>int *b = (int *)a;
>int **c = (int **)a;
>int i = 0;
>int num_elements = sizeof(a) / sizeof(int);
>>
>for(i = 0; i< num_elements; ++i)
>printf("*b = %d *c = %d\n", *b++, *c++);
>>
>return 0;
>}
>>
>When compiled I get:
>gcc -Wall -W -ansi -pedantic -g -c -o pointer_wonder.o
>pointer_wonder.c
>pointer_wonder.c: In function `main':
>pointer_wonder.c:13: warning: int format, pointer arg (arg 3)
>gcc pointer_wonder.o -o pointer_wonder.exe
>>
>The output is:
>*b = 1 *c = 1
>*b = 2 *c = 2
>*b = 3 *c = 3
>*b = 4 *c = 4
>*b = 5 *c = 5
>*b = 6 *c = 6
>*b = 7 *c = 7
>*b = 8 *c = 8
>*b = 9 *c = 9
>>
>Why is it same for *b and *c?
>
*b gives you back an int

whereas

*c gives you back an int *

However, the 'values' of each are taken from a.

So, printf would really like a %p (at least) for the third arg.

So, [I should have added] *c's value is 1, 2, 3, where c is an int *
(obviously, you wouldn't want to deref that!

"Kenneth Brody" <kenbrody@spamcop.netwrote in message
news:43971F85.8FD77233@spamcop.net
pemo wrote:
>>
>"Eric Lilja" <mindcooler@gmail.comwrote in message
>news:1133969869.613104.235330@
>Hello, I'm trying to help someone on a linux-oriented forum. I've taken
>his original code and cleaned it up, but I am still wondering about
>something. Here's the code:
>>
>#include <stdio.h>
>>
>int
>main(void)
>{
>int a[][3]={ {1,2,3},{4,5,6,},{7,8,9} };
>int *b = (int *)a;
>int **c = (int **)a;
>int i = 0;
>int num_elements = sizeof(a) / sizeof(int);
>>
>for(i = 0; i< num_elements; ++i)
>printf("*b = %d *c = %d\n", *b++, *c++);
>>
>return 0;
>}
>>
>When compiled I get:
>gcc -Wall -W -ansi -pedantic -g -c -o pointer_wonder.o
>pointer_wonder.c
>pointer_wonder.c: In function `main':
>pointer_wonder.c:13: warning: int format, pointer arg (arg 3)
>
Note the warning here. ("*c++" is an "int*" type.)
>
>gcc pointer_wonder.o -o pointer_wonder.exe
>>
>The output is:
>*b = 1 *c = 1
[]
>*b = 9 *c = 9
>>
>Why is it same for *b and *c?
>>
>*b gives you back an int
>>
>whereas
>>
>*c gives you back an int *
>>
>However, the 'values' of each are taken from a.
>
And it happens to be that sizeof(int)==sizeof(int*). Try it on a
system where this is not true, such as an old 16-bit DS compiler
in large model mode. (sizeof int == 2, and sizeof int* is 4.)

In a test here, I get:

*b = 1 *c = 1
*b = 2 *c = 3
*b = 3 *c = 5
*b = 4 *c = 7
*b = 5 *c = 9
*b = 6 *c = 2013
*b = 7 *c = 2013
*b = 8 *c = 9
*b = 9 *c = 2680
>
>So, printf would really like a %p (at least) for the third arg.
>
Though it would still print (basically) the same thing, as *c is
still really an int being treated as int*.
--
In any case, this probably falls under the "UB" heading, as you are
taking int's and treating them as int*'s.

(Yes, I know the apostrophes don't really belong in the last sentence,
but it makes it more legible, IMH)

That's so cool!

I really should *invest* in an 'old' compiler! And, it'd be so great to
have a 'Take me Back' experience of my own [in an archive.org kinda sense].
Like, if only I'd saved some of programs I 'cut' into 7-hole punched tape (I
never had access to the punched cards!: they were [for eyes only] in the
domain of the machine room ops!)

I used to have my first Ph.D. thesis on one of those removable hard drives -
big clunky things, with equaly big handles!

, I'm 48 - anyone care to beat that?

Fart

Dik T. Winter wrote:

"Eric Lilja" <mindcooler@gmail.comwrites:
>
>#include <stdio.h>
>>
>int main(void) {
>int a[][3]={ {1,2,3},{4,5,6,},{7,8,9} };
>
>int *b = (int *)a;
>
As 'a' in this context is a pointer to an array of three ints, you are
lying to the compiler. The result is (I think) undefined behaviour.

I don't think there is any lying here; you are allowed to cast
one object pointer type to another as long as there are no
alignment issues. The troubles only (potentially) start when
you dereference the pointer.

&a[0] must be correctly aligned for int, because the members
of a[0] are ints, and there cannot be any padding before the
first member of an array.

int **c = (int **)a;
And more so. Here the result is certain to be undefined behaviour.

Here there could be alignment issues. But if there are not,
then no UB if c is not dereferenced.

(Note: I don't think I worded that exactly right -- the code always
has UB, but on implementations where there were no alignment
problems, the code would behave in a well-defined manner).

>int i = 0;
>int num_elements = sizeof(a) / sizeof(int);
>>
>for(i = 0; i< num_elements; ++i)
>printf("*b = %d *c = %d\n", *b++, *c++);
>
And this is the third time you are lying. You are lucky that
sizeof(int) == sizeof(*int) on your system.

Agree (int* you mean, not *int).

IMH, *b causes undefined behaviour iff i >= 3,
because "a" (ie. &a[0]) points to an array of 3 ints,
and a bounds checking implementation could flag this.

But if b were initialized as: int *b = &a;
then there would be no UB because &a points to
an object that is the size of nine ints.

But some people think that even as written there is
no UB because a[0] is part of the entire object "a",
I don't recall seeing any consensus when this point
has been debated in the past.

*c would cause undefined behaviour in most cases,
because either the bytes pointed to by c form a
trap representation for an int*, or if they form an address
that isn't the address of a valid object.

pemo wrote:
"Kenneth Brody" <kenbrody@spamcop.netwrote in message
And it happens to be that sizeof(int)==sizeof(int*). Try it on a
system where this is not true, such as an old 16-bit DS compiler
in large model mode. (sizeof int == 2, and sizeof int* is 4.)

I really should *invest* in an 'old' compiler! And, it'd be so great to
have a 'Take me Back' experience of my own [in an archive.org kinda sense].

you could buy a new amd64 machine and experience the same pain today,
only faster. :)

"Kenneth Brody" <kenbrody@spamcop.netwrote in message
news:43984DA7.3D4A7FFE@spamcop.net

<snip>

>
>I used to have my first Ph.D. thesis on one of those removable hard
>drives -
>big clunky things, with equaly big handles!
>
You mean one of those washing machines that stored data?

That reminds me My friend never returned my DEC-Tape with the copy
of Star Trek on it that he borrowed (mumble, mumble) years ago.
>
>, I'm 48 - anyone care to beat that?
>
Well, I'm "only" 44, but I do have 34+ years of programming experience.

"And you tell that to young. people today and. they won't believe you!"

Yup, it was a bit 'top-loader like' if memory still serves.

You've been programming longer then. I started as an undergrad - back then,
there was no university in the UK that offered *just* a degree in computing,
so I did a mixed degree, Computing and Pure Maths. Note the lack of the
term 'Computer Science' - wasn't really invented yet.

All my programming assignments had to be written out on coding sheets, and
handed into the machine room - where someone entered them, and probably
produced punched cards etc If you were unlucky, you'd turn up the next
day to get your printout, and find it said syntax error. Sometimes, it even
told you where! The *big* machine on which this stuff ran used to go on to
'MP' at 6.00pm everyday. I don't believe I ever knew what MP stood for,
but I know what it meant - the machine was hired out from 6.00 until
midnight every evening.

We did have one machine that we could program directly. A PDP ? In order to
use that, you had to enter the boot strap routine by flicking switches, and
then load the S from seven hole punched tape.

Ah, those were the days!

"tedu" <tu@zeitbombe.orgwrote in message
news:1134068786.943261.172050@
pemo wrote:
>"Kenneth Brody" <kenbrody@spamcop.netwrote in message
>And it happens to be that sizeof(int)==sizeof(int*). Try it on a
>system where this is not true, such as an old 16-bit DS compiler
>in large model mode. (sizeof int == 2, and sizeof int* is 4.)
>>
>I really should *invest* in an 'old' compiler! And, it'd be so great to
>have a 'Take me Back' experience of my own [in an archive.org kinda
>sense].
>
you could buy a new amd64 machine and experience the same pain today,
only faster. :)

:-)