sizeof stuff and declarations

[Kevin]

I have two questions. I hope they are about C. I chose to post
here instead of comp.unix.progr ammer (or some other) because I do
think this is a C question.

Question 1:

%cat float.c
main() {
float **m = malloc(5 * sizeof(float*)) ;
m[0] = malloc( sizeof(float) );
m[0][0] = 1.2;
printf("%f\n",m[0][0]);
}

Is this legal? I never really declare and assign so fast, but I
was wondering if it works because I'm lucky or if it really is
legal. Gcc doesn't like it much.

%gcc -c float.c
float.c: In function `main':
float.c:2: warning: initialization makes pointer from integer
without a cast float.c:3: warning: assignment makes pointer from
integer without a cast

Question 2:

(gdb) p sizeof(int)
$1 = 4
(gdb) p sizeof(long)
$2 = 4

I was expecting to see long a little bigger.
Why are they the same size?

Thank you.

[Andrey Tarasevich]

Kevin wrote:

I have two questions. I hope they are about C. I chose to post
here instead of comp.unix.progr ammer (or some other) because I do
think this is a C question.

Question 1:

%cat float.c
main() {
float **m = malloc(5 * sizeof(float*)) ;
m[0] = malloc( sizeof(float) );
m[0][0] = 1.2;
printf("%f\n",m[0][0]);
}

Is this legal? I never really declare and assign so fast, but I
was wondering if it works because I'm lucky or if it really is
legal. Gcc doesn't like it much.

%gcc -c float.c
float.c: In function `main':
float.c:2: warning: initialization makes pointer from integer
without a cast float.c:3: warning: assignment makes pointer from
integer without a cast
You forgot do declare 'malloc' functions. That's what causes the
warning, since the compiler assumes that 'malloc' returns an 'int'.
Place '#include <stdlib.h>' at the beginning of your source file and the
warning will go away.

You also forgot to declare 'printf' function. 'printf' is a variadic
function. It mast be declared before use, or the behavior is undefined.
Add '#include <stdio.h>' at the beginning of your source file.

Otherwise, the code is legal.
Question 2:

(gdb) p sizeof(int)
$1 = 4
(gdb) p sizeof(long)
$2 = 4

I was expecting to see long a little bigger.
Why are they the same size?

Why not? This is perfectly legal in C. 'long' is not required to be
bigger than 'int'.

--
Best regards,
Andrey Tarasevich

[Kevin]

On Thu, 17 Mar 2005 15:03:23 -0800,
Andrey Tarasevich <an************ **@hotmail.com> wrote:

Kevin wrote:

[...]

Question 2:

(gdb) p sizeof(int)
$1 = 4
(gdb) p sizeof(long)
$2 = 4

I was expecting to see long a little bigger.
Why are they the same size?

Why not? This is perfectly legal in C. 'long' is not required
to be bigger than 'int'.

But if they take the same amount of bytes, then how is it
possible that long can take bigger numbers?

Thanks, Andrey.

[Andrey Tarasevich]

Kevin wrote:

...

> Question 2:
>
> (gdb) p sizeof(int)
> $1 = 4
> (gdb) p sizeof(long)
> $2 = 4
>
> I was expecting to see long a little bigger.
> Why are they the same size?

Why not? This is perfectly legal in C. 'long' is not required
to be bigger than 'int'.

But if they take the same amount of bytes, then how is it
possible that long can take bigger numbers?
...

Well, the _guaranteed_ range of type 'long' is indeed wider than that of
type 'int' (per C99 standard). But in actual implementation it is not
required to be strictly wider. Internally 'int' and 'long' can be
implemented in exactly the same way, which is the case on your platform,
I'm sure.

A more pedantic answer (which you probably don't care about, so you can
stop reading now :) is that by applying 'sizeof' to a type you get the
number of bytes in the so called 'object representation' of that type.
If you multiply that value by CHAR_BIT, you'll get the number of bits in
the object representation of the type. But not all of those bits are
actually required to participate in the value representation. Some of
those object representation bits can remain "unused" (they are called
"padding" bits). For example, let's assume that on your platform
CHAR_BIT is 8. In this case on your platform the object representation
of both 'int' and 'long' contains 32 bits. But theoretically it is
possible that 'int' uses only 16 of those bits (and other 16 are just
padding) and 'long' uses all 32. In this case 'long' would be able to
take bigger numbers than 'int' and at the same time 'sizeof' of those
types would still be the same.

--
Best regards,
Andrey Tarasevich

[Peter Nilsson]

> Kevin wrote:

%cat float.c
main() {
float **m = malloc(5 * sizeof(float*)) ;
m[0] = malloc( sizeof(float) );
m[0][0] = 1.2;
printf("%f\n",m[0][0]);
}

Is this legal? I never really declare and assign so fast,
but I was wondering if it works because I'm lucky or if it
really is legal. Gcc doesn't like it much.

%gcc -c float.c
float.c: In function `main':
float.c:2: warning: initialization makes pointer from
integer without a cast float.c:3: warning: assignment
makes pointer from integer without a cast

Andrey Tarasevich wrote: You forgot do declare 'malloc' functions. That's what causes
the warning, since the compiler assumes that 'malloc' returns
an 'int'. Place '#include <stdlib.h>' at the beginning of your
source file and the warning will go away.

You also forgot to declare 'printf' function. 'printf' is a
variadic function. It mast be declared before use, or the
behavior is undefined.
Add '#include <stdio.h>' at the beginning of your source file.

Otherwise, the code is legal.

Depends what you mean by 'legal'? ;)

The implicit int declaration requires a diagnostic in C99. The
lack of return value from main means the status returned to the
host is undefined in C90. There is also the small matter of not
checking the return value from malloc.

--
Peter

[Kevin]

On Thu, 17 Mar 2005 15:28:46 -0800,
Andrey Tarasevich <an************ **@hotmail.com> wrote:

Kevin wrote:

...

> Question 2:
>
> (gdb) p sizeof(int)
> $1 = 4
> (gdb) p sizeof(long)
> $2 = 4
>
> I was expecting to see long a little bigger.
> Why are they the same size?

Why not? This is perfectly legal in C. 'long' is notrequired> to be bigger than 'int'.

But if they take the same amount of bytes, then how is it
possible that long can take bigger numbers?
...

Well, the _guaranteed_ range of type 'long' is indeed wider
than that of type 'int' (per C99 standard). But in actual
implementation it is not required to be strictly wider.
Internally 'int' and 'long' can be implemented in exactly the
same way, which is the case on your platform, I'm sure.

Yes, you're right about my platform.
A more pedantic answer (which you probably don't care about, so
you can stop reading now :) is that by applying 'sizeof' to a
That's the answer I was looking for :-) Thank you.
type you get the number of bytes in the so called 'object
representation' of that type. If you multiply that value by
CHAR_BIT, you'll get the number of bits in the object
representation of the type. But not all of those bits are
actually required to participate in the value representation.
Some of those object representation bits can remain "unused"
(they are called"padding" bits). For example, let's assume that
on your platform CHAR_BIT is 8. In this case on your platform
the object representation of both 'int' and 'long' contains 32
bits. But theoretically it is possible that 'int' uses only 16
of those bits (and other 16 are just padding) and 'long' uses
all 32. In this case 'long' would be able to take bigger
numbers than 'int' and at the same time 'sizeof' of those types
would still be the same.

I see. That's what happens here then. I get 4 bytes in int, but I
can't use them all. That explains. The reason why an int takes 4
bytes is probably for compilers/whatever have an easy time
dealing with it. Is that right?

So anyway, if on my platform they both take the same amount of
bytes, I would conclude that I should never use an int (unless to
conform with a function prototype or something) because I will
consume the same amount of bytes when using a long. And by using
a long, at least I will have the freedom to use all the bits I
allocated.

Am I right, here? Or did I misunderstand everything? Thank you.

[Andrey Tarasevich]

Kevin wrote:

...

A more pedantic answer (which you probably don't care about, so
you can stop reading now :) is that by applying 'sizeof' to a

That's the answer I was looking for :-) Thank you.

type you get the number of bytes in the so called 'object
representation' of that type. If you multiply that value by
CHAR_BIT, you'll get the number of bits in the object
representation of the type. But not all of those bits are
actually required to participate in the value representation.
Some of those object representation bits can remain "unused"
(they are called"padding" bits). For example, let's assume that
on your platform CHAR_BIT is 8. In this case on your platform
the object representation of both 'int' and 'long' contains 32
bits. But theoretically it is possible that 'int' uses only 16
of those bits (and other 16 are just padding) and 'long' uses
all 32. In this case 'long' would be able to take bigger
numbers than 'int' and at the same time 'sizeof' of those types
would still be the same.

I see. That's what happens here then. I get 4 bytes in int, but I
can't use them all. That explains. The reason why an int takes 4
bytes is probably for compilers/whatever have an easy time
dealing with it. Is that right?

So anyway, if on my platform they both take the same amount of
bytes, I would conclude that I should never use an int (unless to
conform with a function prototype or something) because I will
consume the same amount of bytes when using a long. And by using
a long, at least I will have the freedom to use all the bits I
allocated.

Am I right, here? Or did I misunderstand everything? Thank you.

I don't think this is the case. You must've misunderstood me. The reason
I called the above answer "pedantic" (and the reason I assumed that you
don't care about it) is that normally in practice objects of integral
types don't contain any padding bits (unless you are working on some
very exotic platform).

In your case, I'm [almost] sure, all bits of an 'int' object are used in
the value representation of that type. The C standard requires that
objects of type 'int' can hold _at_ _least_ values in -32767 - +32767
range. Note: _at_ _least_. Which means that if on some platform objects
of type 'int' can hold values in -2147483647 - [phone] range (which
also happens to be the guaranteed range of 'long' type), the
requirements of the standard are still formally satisfied. You simply
got a "free extension" of the range of your 'int' type. You can use this
"free extension" as you see fit. Bot keep in mind that if you want your
code to be absolutely portable, you shouldn't rely on the 'int's range
being that wide. On some other platform it could happen to be only
-32767 - +32767.

Once again, the specification of the C language doesn't require type
'int' to be neither narrower (in terms of value range) nor smaller (in
therms of 'sizeof') than type 'long'.

--
Best regards,
Andrey Tarasevich

[Kevin]

On Thu, 17 Mar 2005 16:32:46 -0800,
Andrey Tarasevich <an************ **@hotmail.com> wrote:

Kevin wrote:

...

A more pedantic answer (which you probably don't care about,so> you can stop reading now :) is that by applying 'sizeof'
to a

That's the answer I was looking for :-) Thank you.

type you get the number of bytes in the so called 'object
representation' of that type. If you multiply that value by
CHAR_BIT, you'll get the number of bits in the object
representation of the type. But not all of those bits are
actually required to participate in the value

representation .> Some of those object representation bits can
remain "unused"> (they are called"padding" bits). For example,
let's assume that> on your platform CHAR_BIT is 8. In this
case on your platform> the object representation of both 'int'
and 'long' contains 32> bits. But theoretically it is possible
that 'int' uses only 16> of those bits (and other 16 are just
padding) and 'long' uses> all 32. In this case 'long' would be
able to take bigger> numbers than 'int' and at the same time
'sizeof' of those types> would still be the same.

I see. That's what happens here then. I get 4 bytes in int,
but I can't use them all. That explains. The reason why an
int takes 4 bytes is probably for compilers/whatever have an
easy time dealing with it. Is that right?

So anyway, if on my platform they both take the same amount
of bytes, I would conclude that I should never use an int
(unless to conform with a function prototype or something)
because I will consume the same amount of bytes when using a
long. And by using a long, at least I will have the freedom
to use all the bits I allocated.

Am I right, here? Or did I misunderstand everything? Thank
you.

I don't think this is the case. You must've misunderstood me.
The reason I called the above answer "pedantic" (and the reason
I assumed that you don't care about it) is that normally in
practice objects of integral types don't contain any padding
bits (unless you are working on some very exotic platform).

Okay, sorry then. Let's see if I understood you now.

In your case, I'm [almost] sure, all bits of an 'int' object
are used in the value representation of that type. The C
standard requires that objects of type 'int' can hold _at_
_least_ values in -32767 - +32767 range. Note: _at_ _least_.
Which means that if on some platform objects of type 'int' can
hold values in -2147483647 - [phone] range (which also
happens to be the guaranteed range of 'long' type), the
requirements of the standard are still formally satisfied. You
simply got a "free extension" of the range of your 'int' type.
You can use this"free extension" as you see fit. Bot keep in
mind that if you want your code to be absolutely portable, you
shouldn't rely on the 'int's range being that wide. On some
other platform it could happen to be only-32767 - +32767.

So, in my case (freebsd/intel) I have the benefit of having int
just as big as a long? But as I think you explained, I should not
rely on this, because my code may not be portable then.

Did I get it now?

I wrote:
(gdb) list 0
1 main() {
2
3 unsigned int i;
4 unsigned long j;
5
6 i = 4294967295U;
7 j = 4294967295U;
8
9
10 }
(gdb) p i
$4 = 4294967295
(gdb) p j
$5 = 4294967295

Thank you.

[Chris Torek]

[on machine X, "sizeof(int )" and "sizeof(lon g)" are the same]

On Thu, 17 Mar 2005 15:03:23 -0800,
Andrey Tarasevich <an************ **@hotmail.com> wrote:

Why not? This is perfectly legal in C. 'long' is not required
to be bigger than 'int'.

In article <20************ *************** @hotmail.com>
Kevin <ke***@hotmail. com> wrote:But if they take the same amount of bytes, then how is it
possible that long can take bigger numbers?

Maybe it can't -- on machine X anyway.

An analogy might help. Suppose the motor-vehicle administration
(DMV or MVA or whatever it is called where you are) says that you
need a different kind of license to drive a motorcycle vs a car vs
a tractor-trailer. You only have a "regular car" license. Suppose
also that they say "a car must hold two or more people side by
side". If your vehicle holds eight people, two in front seats and
three in second and third row seats, is it a car? (What if it
holds two or so people but can pull a triple trailer? :-) )

The C standard says that an "int" variable must hold, at the least,
values in the range -32767 to +32767, and "long" has to cover at
least -2147483647 to [phone]. If your "int" and "long" both
happen to hold values in the range -2147483648 to [phone], is
that sufficient?

It is not unusual for a standard (or a law) to set some sort of
"least quality required" limit, and for people to exceed that, for
whatever reason.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Andrey Tarasevich]

Kevin wrote:

...
In your case, I'm [almost] sure, all bits of an 'int' object
are used in the value representation of that type. The C
standard requires that objects of type 'int' can hold _at_
_least_ values in -32767 - +32767 range. Note: _at_ _least_.
Which means that if on some platform objects of type 'int' can
hold values in -2147483647 - [phone] range (which also
happens to be the guaranteed range of 'long' type), the
requirements of the standard are still formally satisfied. You
simply got a "free extension" of the range of your 'int' type.
You can use this"free extension" as you see fit. Bot keep in
mind that if you want your code to be absolutely portable, you
shouldn't rely on the 'int's range being that wide. On some
other platform it could happen to be only-32767 - +32767.
So, in my case (freebsd/intel) I have the benefit of having int
just as big as a long?

Exactly!
But as I think you explained, I should not
rely on this, because my code may not be portable then.

Did I get it now?

Yes. Whether you should rely on this or not is up to you. You shouldn't
rely on this if you want you code to be absolutely-pedantically-formally
portable. In practice this level of formal portability is rarely
required. I, for example, work with several platforms, all of which use
plain 'int's with 32-bit value range. I have no problem relying on this
fact in my code, because I'm pretty sure that I'll never encounter a
16-bit-'int' platform in my field.

--
Best regards,
Andrey Tarasevich