Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

sizeof() in 64-bit environment survey

3 views
Skip to first unread message

Mark Hanson

unread,
Aug 12, 1998, 3:00:00 AM8/12/98
to
I'm taking a survey to find out how different C compilers handle long
data types in 64-bit environments.

If you could take a minute to compile and run the following program on
whatever 64-bit machines you have available, and mail me the results along
with an English description of your environment I would appreciate it.

I will post a summary if there is interest.

Thanks,
Mark


#include <stdio.h>

int
main()
{
system("uname -a");

/* conventional C types */
printf("sizeof(char) = %ld\n", sizeof(char));
printf("sizeof(short) = %ld\n", sizeof(short));
printf("sizeof(int) = %ld\n", sizeof(int));
printf("sizeof(long) = %ld\n", sizeof(long));
printf("sizeof(char *) = %ld\n", sizeof(char *));

/* you will likely have to delete one or more of these to compile */
printf("sizeof(_int32) = %ld\n", sizeof(_int32));
printf("sizeof(_int64) = %ld\n", sizeof(_int64));
printf("sizeof(long long) = %ld\n", sizeof(long long));
printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));

/* if your 64-bit environment has some other
oddball-yet-vital 64-bit data types, please add them */

exit(0);
} /* main */

Ian_Ameline

unread,
Aug 12, 1998, 3:00:00 AM8/12/98
to
Mark Hanson wrote:
>
> I'm taking a survey to find out how different C compilers handle long
> data types in 64-bit environments.


On an SGI machine, it gives;
"t.c", line 17: error(1020): identifier "_int32" is undefined


printf("sizeof(_int32) = %ld\n", sizeof(_int32));

^

"t.c", line 18: error(1020): identifier "_int64" is undefined


printf("sizeof(_int64) = %ld\n", sizeof(_int64));

^

"t.c", line 20: error(1020): identifier "__longlong" is undefined


printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));

--
Regards, | I don't believe in the carrot anymore;
Ian Ameline, | I think it's just another stick that's
Senior Software Engineer, | been painted orange.
Alias/Wavefront |

Jack Klein

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
On 12 Aug 1998 15:51:08 -0700, k...@cafe.net (Kaz Kylheku) wrote:

> In article <mbhExL...@netcom.com>, Mark Hanson <m...@netcom.com> wrote:
> >I'm taking a survey to find out how different C compilers handle long
> >data types in 64-bit environments.
> >

> >If you could take a minute to compile and run the following program on
> >whatever 64-bit machines you have available, and mail me the results along
> >with an English description of your environment I would appreciate it.
>

> [ snip ]


>
> > printf("sizeof(char) = %ld\n", sizeof(char));
>

> * Cough *
>
> I ran it on my DeathStation 9000 and demons flew out of my nose.
>
> Don't you know that %ld requires an argument of type unsigned long, and that
signed long
> sizeof yields a value of type size_t, which is not necessarily compatible with
> unsigned long?

<Jack>

But it's good to have you back again, Kaz. :)

</Jack>


Martin Ambuhl

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to

Kaz Kylheku wrote in message <6qt68s$v...@espresso.cafe.net>...

|Don't you know that %ld requires an argument of type unsigned long, and
that
|sizeof yields a value of type size_t, which is not necessarily
compatible with
|unsigned long?

Kaz has not been getting enough coffee. He meant, of course, that
%ld is the type specifier for a signed long.
The way to use printf with size_t is (until C9x)
printf("%lu", (unsigned long) sizeof(int));


tst...@my-dejanews.com

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
In article <mbhExL...@netcom.com>,

m...@netcom.com (Mark Hanson) wrote:
> I'm taking a survey to find out how different C compilers handle long
> data types in 64-bit environments.
>
> If you could take a minute to compile and run the following program on
> whatever 64-bit machines you have available, and mail me the results along
> with an English description of your environment I would appreciate it.
>
> I will post a summary if there is interest.
>
> Thanks,
> Mark
>
> #include <stdio.h>
>
> int
> main()
> {
> system("uname -a");
>
> /* conventional C types */
> printf("sizeof(char) = %ld\n", sizeof(char));
> printf("sizeof(short) = %ld\n", sizeof(short));
> printf("sizeof(int) = %ld\n", sizeof(int));
> printf("sizeof(long) = %ld\n", sizeof(long));
> printf("sizeof(char *) = %ld\n", sizeof(char *));
>
> /* you will likely have to delete one or more of these to compile */
> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
> printf("sizeof(long long) = %ld\n", sizeof(long long));
> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>
> /* if your 64-bit environment has some other
> oddball-yet-vital 64-bit data types, please add them */
>
> exit(0);
> } /* main */
>

I'd say that this is guaranteed to NOT compile on any sysyrem you can think
of. Mayb yo should've just asked people to send what their documentation says
about 64 bit ints (if anything)

--
Tristan Styles

Failure is not an option
It is Standard Operating Procedure

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Lawrence Kirby

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
In article <6quan8$a46$1...@nnrp1.dejanews.com> tst...@my-dejanews.com writes:

>> #include <stdio.h>

You need #include <stdlib.h> for system() and exit().

>> int
>> main()
>> {
>> system("uname -a");

Many platforms wont understand "uname -a".

>> /* conventional C types */
>> printf("sizeof(char) = %ld\n", sizeof(char));

%ld is for converting arguments of type long. sizeof produces a result of
type size_t which can be any unsigned integer type. SO one type you know for
sure that it isn't is long. Since the actual type is unknown you
need a cast. Assuming that the result can be represented in an int (which
is a reasonable assumption here) you can write:

printf("sizeof(char) = %d\n", (int)sizeof(char));

and so on.

>> printf("sizeof(short) = %ld\n", sizeof(short));
>> printf("sizeof(int) = %ld\n", sizeof(int));
>> printf("sizeof(long) = %ld\n", sizeof(long));
>> printf("sizeof(char *) = %ld\n", sizeof(char *));
>>
>> /* you will likely have to delete one or more of these to compile */
>> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
>> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
>> printf("sizeof(long long) = %ld\n", sizeof(long long));
>> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>>
>> /* if your 64-bit environment has some other
>> oddball-yet-vital 64-bit data types, please add them */
>>
>> exit(0);
>> } /* main */
>>
>
>I'd say that this is guaranteed to NOT compile on any sysyrem you can think
>of. Mayb yo should've just asked people to send what their documentation says
>about 64 bit ints (if anything)

Ignoring the <stdlib.h> issue the only problem is the stuff after the

/* you will likely have to delete one or more of these to compile */

comment. But clearly that comment acknowledges what you are saying and
even suggests a remedy.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


John Hascall

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
Kaz Kylheku <k...@cafe.net> wrote:

}Mark Hanson <m...@netcom.com> wrote:
}>I'm taking a survey to find out how different C compilers handle long
}>data types in 64-bit environments.

}[ snip ]


}> printf("sizeof(char) = %ld\n", sizeof(char));

}* Cough *
}I ran it on my DeathStation 9000 and demons flew out of my nose.

}Don't you know that %ld requires an argument of type unsigned long, and that


}sizeof yields a value of type size_t, which is not necessarily compatible with
}unsigned long?

Well, I'm sure we can look forward to:

printf("sizeof(char) = %<size_t>\n", sizeof(char));

RSN.

John
--
John Hascall, Software Engr. | "One World, One Web, One Program" - Microsoft Ad
ISU Computation Center | "Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
mailto:jo...@iastate.edu |
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud

Chris Engebretson

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
In article <6qv4fj$cs4$1...@news.iastate.edu>,
jo...@iastate.edu (John Hascall) writes:

[ regarding printing the value of a size_t object ]

|> Well, I'm sure we can look forward to:
|>
|> printf("sizeof(char) = %<size_t>\n", sizeof(char));
|>
|> RSN.

Ahh, wishful thinking. :-) A bit closer to the mark might be

printf("sizeof(char) = %" PRIuMAX "\n", (uintmax_t) sizeof(char));

But fortunately, this can be shortened:

printf("sizeof(char) = 1\n");

Regards,

--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions are not those of Raytheon Systems Company or the USGS.

Martin Ambuhl

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to

Bob Cousins wrote in message <35de92c9...@news.demon.co.uk>...

|In comp.arch, Chris Engebretson wrote:
|
|>But fortunately, this can be shortened:
|>
|> printf("sizeof(char) = 1\n");
|
|1 what though?
|
=======
1 char, of course, you silly. The description of sizeof in the
standard says "bytes", but a byte is defined in C to mean only the
space a char takes. And the definition of sizeof says explicitly that
"When applied to an operand that has type char, unsigned char, or signed
char (or a qualified version thereof) the result is 1."
[Note the misplaced ','].


John Kugelman

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
Bob Cousins wrote:
>
> Chris Engebretson wrote:
> >
> > But fortunately, this can be shortened:
> >
> > printf("sizeof(char) = 1\n");
>
> 1 what though?

1 char, obviously.

--
John Kugelman. kuge...@mnsinc.com

I believe we can change anything.
I believe in my dream.
- Joe Satriani

Bob Cousins

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In comp.arch, Chris Engebretson wrote:

>But fortunately, this can be shortened:
>
> printf("sizeof(char) = 1\n");

1 what though?

--
Bob Cousins, Software Engineer.
Home page at http://www.lintilla.demon.co.uk/

Chris Engebretson

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <35de92c9...@news.demon.co.uk>,
b...@lintilla.demon.co.uk (Bob Cousins) writes:

|> In comp.arch, Chris Engebretson wrote:
|>
|> >But fortunately, this can be shortened:
|> >
|> > printf("sizeof(char) = 1\n");
|>
|> 1 what though?

sizeof(char) is 1 by definition.

Lawrence Kirby

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <35de92c9...@news.demon.co.uk>
b...@lintilla.demon.co.uk "Bob Cousins" writes:

>In comp.arch, Chris Engebretson wrote:
>
>>But fortunately, this can be shortened:
>>
>> printf("sizeof(char) = 1\n");
>
>1 what though?

1 char (clearly), 1 byte (equivalently in C), 1 lump of CHAR_BIT bits (where
CHAR_BIT is defined in <limits.h> and can be 8 or more).

Bob Cousins

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In comp.arch, Martin Ambuhl wrote:

>
>Bob Cousins wrote in message <35de92c9...@news.demon.co.uk>...

>|In comp.arch, Chris Engebretson wrote:
>|
>|>But fortunately, this can be shortened:
>|>
>|> printf("sizeof(char) = 1\n");
>|
>|1 what though?
>|

>=======
>1 char, of course, you silly. The description of sizeof in the
>standard says "bytes", but a byte is defined in C to mean only the
>space a char takes. And the definition of sizeof says explicitly that
>"When applied to an operand that has type char, unsigned char, or signed
>char (or a qualified version thereof) the result is 1."
>[Note the misplaced ','].

I assumed the original poster would want to find the size of long types in terms
of bits. I guess I missed the point of the survey.

Ian_Ameline

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
Martin Ambuhl wrote:
>
> |>But fortunately, this can be shortened:
> |>
> |> printf("sizeof(char) = 1\n");
> |
> |1 what though?
> |
> 1 char, of course, you silly. The description of sizeof in the
> standard says "bytes", but a byte is defined in C to mean only the
> space a char takes. And the definition of sizeof says explicitly that
> "When applied to an operand that has type char, unsigned char, or signed
> char (or a qualified version thereof) the result is 1."

Yep -- straight out of ANSI X3.159-1989 Section 3.3.3.4, lines 32 and 33.

P Dickerson

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to

Kaz Kylheku wrote in message <6qt68s$v...@espresso.cafe.net>...
>In article <mbhExL...@netcom.com>, Mark Hanson <m...@netcom.com> wrote:
>>I'm taking a survey to find out how different C compilers handle long
>>data types in 64-bit environments.
>>
>>If you could take a minute to compile and run the following program on
>>whatever 64-bit machines you have available, and mail me the results along
>>with an English description of your environment I would appreciate it.
>
>[ snip ]
>
>> printf("sizeof(char) = %ld\n", sizeof(char));
>
>* Cough *
>
>I ran it on my DeathStation 9000 and demons flew out of my nose.
>
>Don't you know that %ld requires an argument of type unsigned long, and
that
>sizeof yields a value of type size_t, which is not necessarily compatible
with
>unsigned long?
No, not unsigned long. Signed. %lu for unsigned long.
--
P.M.Dickerson.
email: peter (at) izabella (dot) demon (dot) co (dot) uk


P Dickerson

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to

Mark Hanson wrote in message ...

>I'm taking a survey to find out how different C compilers handle long
>data types in 64-bit environments.
>
>If you could take a minute to compile and run the following program on
>whatever 64-bit machines you have available, and mail me the results along
>with an English description of your environment I would appreciate it.
>
>I will post a summary if there is interest.
>
>Thanks,
>Mark
>
>
>#include <stdio.h>
>
>int
>main()
>{
> system("uname -a");
>
> /* conventional C types */
> printf("sizeof(char) = %ld\n", sizeof(char));
> printf("sizeof(short) = %ld\n", sizeof(short));
> printf("sizeof(int) = %ld\n", sizeof(int));
> printf("sizeof(long) = %ld\n", sizeof(long));
> printf("sizeof(char *) = %ld\n", sizeof(char *));
>
> /* you will likely have to delete one or more of these to compile */
> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
> printf("sizeof(long long) = %ld\n", sizeof(long long));
> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>
> /* if your 64-bit environment has some other
> oddball-yet-vital 64-bit data types, please add them */
>
> exit(0);
>} /* main */

int main() requires a return value.

Michael Rubenstein

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
On Fri, 14 Aug 1998 16:51:42 +0100, "P Dickerson" <peter@localhost>
wrote:

>
>Mark Hanson wrote in message ...

>>#include <stdio.h>
>>
>>int
>>main()
>>{
>> system("uname -a");
>>
>> /* conventional C types */
>> printf("sizeof(char) = %ld\n", sizeof(char));
>> printf("sizeof(short) = %ld\n", sizeof(short));
>> printf("sizeof(int) = %ld\n", sizeof(int));
>> printf("sizeof(long) = %ld\n", sizeof(long));
>> printf("sizeof(char *) = %ld\n", sizeof(char *));
>>
>> /* you will likely have to delete one or more of these to compile */
>> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
>> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
>> printf("sizeof(long long) = %ld\n", sizeof(long long));
>> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>>
>> /* if your 64-bit environment has some other
>> oddball-yet-vital 64-bit data types, please add them */
>>
>> exit(0);
>>} /* main */
>
>int main() requires a return value.

No it doesn't. If control passes to the end of the main function, it
returns and undefined termination status to the operating system but,

1. that is permitted by the standard.

2. that doesn't apply here since control never passes to the
end of main.
--
Michael M Rubenstein

Mike McCarty

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <35de92c9...@news.demon.co.uk>,
Bob Cousins <b...@lintilla.demon.co.uk> wrote:
)In comp.arch, Chris Engebretson wrote:
)
)>But fortunately, this can be shortened:
)>
)> printf("sizeof(char) = 1\n");
)
)1 what though?

1 char. The sizeof operator returns size in chars.

CHAR_BIT is the number of bits in a char, if that's what you mean.

Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC. <- They make me say that.

John Hascall

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
Ian_Ameline <no_...@dev.null> wrote:

}Martin Ambuhl wrote:
}> |>But fortunately, this can be shortened:
}> |> printf("sizeof(char) = 1\n");
}> |1 what though?

}> 1 char, of course, you silly. The description of sizeof in the
}> standard says "bytes", but a byte is defined in C to mean only the
}> space a char takes. And the definition of sizeof says explicitly that
}> "When applied to an operand that has type char, unsigned char, or signed
}> char (or a qualified version thereof) the result is 1."

}Yep -- straight out of ANSI X3.159-1989 Section 3.3.3.4, lines 32 and 33.

By focusing in on 'sizeof(char) == 1' it seems to me
that everyone has avoided the real question -- which is:
how do you portably know which printf format specifier
goes with

foo_t

for whatever 'foo' (e.g., size_t).

John Kugelman

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
John Hascall wrote:
>
> By focusing in on 'sizeof(char) == 1' it seems to me
> that everyone has avoided the real question -- which is:
> how do you portably know which printf format specifier
> goes with
>
> foo_t
>
> for whatever 'foo' (e.g., size_t).

You have to cast to a compatible, printable type, such as unsigned long
for size_t.

BTW, you should lose the indentation. It's... strange.

Lei Liu

unread,
Aug 20, 1998, 3:00:00 AM8/20/98
to
-----------------------------------------------------------------------------
Please ignore this message if you received it already
-----------------------------------------------------------------------------

Call for Participation

Compiler and Architecture Support for
Embedded Computing Systems (CASES98)

An International Workshop
November 4-5, 1998
Washington D.C.

Over the past decade, substantial research has gone into the design of
microprocessors embodying parallelism at the instruction-level, as well as
aggressive compiler optimization and analysis techniques for harnessing this
opportunity. Much of this effort has since been validated through the
proliferation of "product quality" general purpose computers based on these
technologies. Growing demand for high performance in embedded computing
systems is creating new opportunities to leverage instruction-level
parallelism (ILP) or Explicitly Parallel Instruction Computing (EPIC)
technology including application-specific domains. Embedded computers are
increasingly present in day to day settings. Examples where ILP may address
the need for high performance and application specific embedded computing
include set-top boxes, hand-held games, mobile and web appliances, and
advanced automotive systems.

However, several novel challenges have to be overcome in order to
harness the opportunities offered by EPIC style architectures in the
context of embedded systems. Constraints on the code size, weight and power
consumption place stringent requirements on the processors and the software
they execute. Also constraints rooted in real-time requirements are often a
significant consideration in many embedded systems. Furthermore, the cost is
a severe constraint on embedded processors. In this regard, the needs of
embedded computing differ from those of more traditional general purpose systems.

----------------------------------------------------------------------------

INVITED SPEAKERS

Josh Fisher, Hewlett-Packard Labs,

Other Speaker(s) TBA

----------------------------------------------------------------------------

About this Workshop

This workshop is an informal forum for researchers to discuss their ideas centered
on emerging technology themes with emphasis on the synergy between processors
that embody instruction level parallelism, and high performance embedded
systems. Thus, enabling high-performance embedded technologies using ILP will
be a significant, albeit not an exclusive goal. Technical as well as position
papers espousing significant novel ideas and technical results are solicited.

Suggested topics include (but are not limited to) the following:

* Application specific design and synthesis.
* Research challenges and solutions in microarchitecture design for
embedded systems based ILP.
* Research directions in embedded system software tools, with emphasis
on light-weight languages for temporal specification. Optimizing
compilers for ILP exploitation in the presence of temporal constraints.
* Harnessing the interaction between the hardware and software layers,
spurred by innovations in reconfigurable or adaptive computing systems.
* Characterizing the need of research infrastructure development for
embedded systems based on ILP and adaptive technologies.
* Synergy between extant parallel computing technologies, such as
notations for expressing concurrency, and instruction level parallel
processing, with emphasis on concerns of embedded computing.
* Compiler Controlled Memory Hierarchy Management and Smart Caches.

Presentation of ongoing work is encouraged. No formal proceedings are
planned; therefore the results presented in the workshop can be published in
archival journals. However, there is a plan to invite high quality papers
presented at the workshop, as the candidates for a special monograph based
on the workshop's theme.

In addition to the presentations, the workshop will have

* A panel constituted of experts from industry, government and academic
research organizations to discuss the topic:

Software Tools for Embedded Computing: Needs, Solutions and Directions.

TO PARTICIPATE, please submit either one copy of an extended abstract not
exceeding FIVE pages to the following email address or FIVE hard copies to the
program chair at the following address specified. Authors will be notified of a final
decision by November 1st, 1998.


Submission deadline: October 1st, 1998.

E-mail address for submission: CAS...@capsl.udel.edu

Mail address for submission:

Krishna V. Palem
Courant Institute of Mathematical Sciences
251 Mercer Street
New York, NY 10012,
USA.

----------------------------------------------------------------------------------------------

Workshop General Chairs:

Krishna V. Palem (NYU)
Guang R. Gao (Univ. of Delaware)

Local Arrangement Chair:

B. Narahari (The George Washington University)

Workshop Committee:

J. Bondi (TI),
K. Ebciogllu (IBM T. J. Watson Research Center),
Guang R. Gao (U. of Delaware),
Lal George (Lucent Technologies),
Rajiv Gupta (U. of Pittsburgh),
Richard Johnson (HP),
Oded Mahler (Grenoble),
Miroslaw Malek (Humboldt and Stanford Universities),
Krishna Palem (NYU),
Bill Mangione-Smith (UCLA),
John Thornley (Caltech),
Wei Zhao (Rockwell Semiconductor Systems)

0 new messages