Compiler bug?

[Enrico `Trippo' Porreca]

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays.

The following code:

#include <stdio.h>

int main(void)
{
int a[10];
int (*p)[10];

printf("%lu\n", (unsigned long) sizeof &a);
printf("%lu\n", (unsigned long) sizeof p);
return 0;
}

compiled with the "disable extensions" flag, produces this output:

40
4

I'm pretty sure that a conforming compiler should produce a program
which prints the same number two times, since &a and p are of the same
type. Right?

--
Enrico `Trippo' Porreca

[Joona I Palaste]

Enrico `Trippo' Porreca <ep******@people.it> scribbled the following:

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays. The following code: #include <stdio.h> int main(void)
{
int a[10];
int (*p)[10]; printf("%lu\n", (unsigned long) sizeof &a);
printf("%lu\n", (unsigned long) sizeof p);
return 0;
} compiled with the "disable extensions" flag, produces this output: 40
4 I'm pretty sure that a conforming compiler should produce a program
which prints the same number two times, since &a and p are of the same
type. Right?

Yes, I think there is something wrong here. sizeof a should be 10 *
sizeof(int), which is most likely 40 on your system, but sizeof &a
should be identical to sizeof(int(*)[10]), which is equivalent to
sizeof p.
I tried it on gcc on my Linux system and it printed 4 for both.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen

[Enrico `Trippo' Porreca]

Joona I Palaste wrote:

Enrico `Trippo' Porreca <ep******@people.it> scribbled the following:

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays.

The following code:

#include <stdio.h>

int main(void)
{
int a[10];
int (*p)[10];

printf("%lu\n", (unsigned long) sizeof &a);
printf("%lu\n", (unsigned long) sizeof p);
return 0;
}

compiled with the "disable extensions" flag, produces this output:

40
4

I'm pretty sure that a conforming compiler should produce a program
which prints the same number two times, since &a and p are of the same
type. Right?

Yes, I think there is something wrong here. sizeof a should be 10 *
sizeof(int), which is most likely 40 on your system, but sizeof &a
should be identical to sizeof(int(*)[10]), which is equivalent to
sizeof p.
I tried it on gcc on my Linux system and it printed 4 for both.

Yes, gcc prints it "right". We had a discussion on it.comp.lang.c about
the results of that code when compiled with Visual Studio, and I'm
wondering about an incapacity of cl to distinguish array_name from
&array_name (at least when one applies sizeof to them).

--
Enrico `Trippo' Porreca

[Jeremy Yallop]

Enrico `Trippo' Porreca wrote:

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays.

It's been reported here before as a bug in both Visual C and Borland
compilers. See, e.g.:

http://groups.google.com/groups?selm...ing.google.com
http://groups.google.com/groups?selm...mindspring.com

Jeremy.

[Enrico `Trippo' Porreca]

Jeremy Yallop wrote:

Enrico `Trippo' Porreca wrote:

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays.

It's been reported here before as a bug in both Visual C and Borland
compilers. See, e.g.:

http://groups.google.com/groups?selm...ing.google.com
http://groups.google.com/groups?selm...mindspring.com

Thanks.

--
Enrico `Trippo' Porreca

[Dan Pop]

In <40**************@people.it> Enrico `Trippo' Porreca <ep******@people.it> writes:

It seems to me that the Visual Studio C compiler (both 6.0 and 2003),
which claims ANSI/ISO conformance, has a nasty bug involving sizes of
pointers to arrays.

The following code:

#include <stdio.h>

int main(void)
{
int a[10];
int (*p)[10];

printf("%lu\n", (unsigned long) sizeof &a);
printf("%lu\n", (unsigned long) sizeof p);
return 0;
}

compiled with the "disable extensions" flag, produces this output:

40
4

I'm pretty sure that a conforming compiler should produce a program
which prints the same number two times, since &a and p are of the same
type. Right?

Right. The Microsoft compiler can't tell the difference between a and &a
in this context.

OTOH, I can't see this bug as having any relevance in real life code:
if you *really* need to know the size of a pointer to array, sizeof p is
the most natural way of obtaining it: i.e. you use an object of the right
type as the operand of sizeof, rather than an expression of the right
type. The usual counterexample is malloc calls, but they involve
expressions using the unary * operator:

int *p = malloc(10 * sizeof *p);

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de