Re: long long vs long

Re: long long vs long

[Earnie Boyd]

Or why not set a new standard something like

int8, int16, int32, int64 to indicate the number of bits.


---Graham Murray  wrote:
>
> This is probably a silly question, but rather than having long long
for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars
to
> 64bit longs.
> -
> For help on using this list (especially unsubscribing), send a
message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
> 

==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[$Bill Luebkert]

Earnie Boyd wrote:
> 
> Or why not set a new standard something like
> 
> int8, int16, int32, int64 to indicate the number of bits.

For years I coded all of mine I8, U8, I16, U16, I32, U32.
Actually I'd probably use lower case if I were to start over again,
easier to type.

Now all you would need is to add I64, U64 or i64, u64.  :)

10 years from now you can add i128 and u128.  Or maybe they'll 
do a half-step to i96, u96.  :)

-- 
  ,-/-  __      _  _         $Bill Luebkert   ICQ=14439852
 (_/   /  )    // //       DBE Collectibles
  / ) /--<  o // //      http://www.wgn.net/~dbe/
-/-' /___/_<_</_</_    Mailto:dbe@wgn.net
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[dahms]

Hi Joerg, you wrote:

: > Hopefully ISO reserved the char at ((unsigned int)-1) exactly for
: EOF.
: 
: They can't. To do so, this would require assumptions of the internal
: representation of -1.

You're right! I assumed a 32bit charset will only be available on a
newer platform >=32bit, and all those I know are 2'comp integer,
(except for e.g. IEEE floating point, which is signed-magnitude).


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Joerg Pommnitz]

> Hopefully ISO reserved the char at ((unsigned int)-1) exactly for
EOF.

They can't. To do so, this would require assumptions of the internal
representation of -1.

Regards
	Joerg
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[dahms]

Hi raf, you wrote:

: >With sizeof(char) = sizeof(int) = 1 and looking at K&R II pg. 16,
: >you'd got a problem with getchar() and EOF, if someone invents a
: >32bit charset and assumes to be able to use them all *and* EOF.
: >AFAIK the biggest charsets currently are 16bit (e.g. Unicode),
: >so at the moment you're safe with a 32bit char!
: 
: no, ISO has a 4-byte charset. it's like unicode but
: with separate copies of asian ideographs, one each for
: japanese, korean and chinese.
: 
: if using this charset, EOF would have to be ((long long)-1) :)

Hopefully ISO reserved the char at ((unsigned int)-1) exactly for EOF.


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Christopher G. Faylor]

In article <9807261625.AA18550.cygnus.gnu-win32@frodo>,
sjm <sjm@judgement.com> wrote:
>
>It was written:
> > Long long vs long debate ...
> > 
> > Please take this elsewhere! There's comp.lang.c, which is a much better
> > forum than this mailing list.
> > 
> > I implore you to spare the rest of us from this inane discussion. Would 
> > be nice if some of the posters would bother opening up a standard C 
> > reference before posting.
>
>Suggestion: Add "Re: long long vs long" to your kill file or filter or
>whatever you use. Alternatively consider deleting anything with that subject
>without reading. I measured the time on my keyboard for deleting similar email
>messages. Using vm under emacs I was able to delete in an average of .3
>seconds per message if I did not bother to read the message. That's frankly
>what I do with 95% of the traffic on this list. If it takes you longer I
>suggest changing mailers. 

I agree with whoever posted this.  The "long long" topic has very little
to do with gnu-win32.  When a message thread starts moving outside of
the purpose of a mailing list, the polite thing to do is to move it
elsewhere.

>As long as there is resistance to turning this list into a newsgroup where it
>would be easier to split into subgroups then I have little sympathy for
>complaints about off point discussion. Since this is the only forum for
>discussing cygwin related stuff we shouldn't be too restrictive about how
>closely related the discussion must be.

Resistance?  Where is there resistance?  If you'd like to spearhead the
campaign to turn this into a newsgroup, please feel free to do so.

The fact that this is not a newsgroup is one more reason why off-topic
threads such as this one should be squashed.  Some people who are
subscribed to the gnu-win32 mailing list are actually paying for their
connections.  There's no reason for such people to pay for "long long"
discussions.
-- 
cgf@cygnus.com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hello Timothy,

You wrote:

[SNIP]
>> Unfortunately not. I didn't know that this matters so much.
>> 
>> BTW: Do you love splitting hairs? ;)
>
>In defense of the original poster, this is not splitting hairs.  You yourself 
>invoked the _Standard_ to assert:
>
>    1.  short is 16 bits and long is 32 bits
>    2.  a conforming implementation cannot use a 64 bit long
>
>Both statements are incorrect and such commonly held misbeliefs are a
>frequent source of portability problems.  Since this group is very much about
>portability, its important not to spread misinformation where portability is
>concerned.
Okay okay, I said Jehova and now everyone is throwing stones at me. ;)


I now know that my statement about the standard was thoughtless,
sorry. In my little world I thought that longs are 32 bits and that
almost all code relys on this. I simply didn't know about the world
around my little universe. :)

So sorry and till the next mindless mistake...

Micha
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[dahms]

Hi Matt, you wrote:

: Not to be picky, but to quote K&R II pg. 36:
[snip]

: Also, chars are not limited to be only 8 bits, but they must be at least
: 8 bits.  I routinely work on processors (C40, C44) where CHAR_BIT is
: 32.  This results in the pecularity that
: 
: 	sizeof(char) = sizeof(long) = 1
: 
: which is perfectly legal.  I think there is a lot more code in the world
: that asumes that CHAR_BIT is 8 than sizeof(long) is 4.

With sizeof(char) = sizeof(int) = 1 and looking at K&R II pg. 16,
you'd got a problem with getchar() and EOF, if someone invents a
32bit charset and assumes to be able to use them all *and* EOF.
AFAIK the biggest charsets currently are 16bit (e.g. Unicode),
so at the moment you're safe with a 32bit char!


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hello Brian,

You wrote:

>Each compiler is free to choose appropriate sizes for its own hardware,
>subject only to the restriction that shorts and ints are at least 16
>bits, longs are at least 32 bits, and short is no longer than int, which
>is no longer than long.
>...
I've already been intensively kicked for that mistake. ;)

Sorry...

Micha
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hi Harry,

You wrote:

>[SNIP]
>> Unfortunately not. I didn't know that this matters so much.
>> 
>> BTW: Do you love splitting hairs? ;)
>
>     No - but I *do* dislike wrong information!  <grin> And for
>portable programming (which I have to do a lot of) you have to
>be *very* clear on the rules.
Okay, got me. As I've never seen a system that uses longs with more or
less than 32 bits I simply thought that it's pretty useless to argue
about whether the standard says this or that when nearly all code
relys on that fact. But after reading this thread on the list it seems
to me that there are even a lot systems with incredibly long longs and
so I now think you're right. ;)

Yours

Micha
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[sjm]

It was written:
 > Long long vs long debate ...
 > 
 > Please take this elsewhere! There's comp.lang.c, which is a much better
 > forum than this mailing list.
 > 
 > I implore you to spare the rest of us from this inane discussion. Would 
 > be nice if some of the posters would bother opening up a standard C 
 > reference before posting.

Suggestion: Add "Re: long long vs long" to your kill file or filter or
whatever you use. Alternatively consider deleting anything with that subject
without reading. I measured the time on my keyboard for deleting similar email
messages. Using vm under emacs I was able to delete in an average of .3
seconds per message if I did not bother to read the message. That's frankly
what I do with 95% of the traffic on this list. If it takes you longer I
suggest changing mailers. 

Also I have found that not reading mail makes it impossible to be annoyed by
the innanity of that mail because I cannot then tell if the mail is innane or
not. Fortunately I have never seen a mailer that forced me to read mail on an
uninteresting topic.

In other words I suggest you lighten up. This is a support group, not a
private list for insiders. Since gcc supports "long long" the argument could
be made that this is a vaguely on point topic. I could also make an arguement
based on its relatedness to portability. Less on point topics have been
discussed here without complaint.

As long as there is resistance to turning this list into a newsgroup where it
would be easier to split into subgroups then I have little sympathy for
complaints about off point discussion. Since this is the only forum for
discussing cygwin related stuff we shouldn't be too restrictive about how
closely related the discussion must be.

Steve Morris
sjm@judgement.com

PS. I agree that we have beaten this one nearly to death and will personally
be relieved when the topic finally dies out.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Timothy Writer]

michael@weiser.saale-net.de (Michael Weiser) writes:

> Hi Harry,
> 
> You wrote:
> 
> >> No because the standard says
> >> short == 16 bit
> >> long  == 32 bit
> >> int   == 16 or 32 depending on the machine's architecture
> >> 
> >> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> >> 32 bit.
> >> So there's no way for long to be 64 bit while conforming to the
> >> standard.
> >  Oh dear - this seems to be a common belief.  Can you give the
> >para in the standard where it says this?
> Unfortunately not. I didn't know that this matters so much.
> 
> BTW: Do you love splitting hairs? ;)

In defense of the original poster, this is not splitting hairs.  You yourself 
invoked the _Standard_ to assert:

    1.  short is 16 bits and long is 32 bits
    2.  a conforming implementation cannot use a 64 bit long

Both statements are incorrect and such commonly held misbeliefs are a
frequent source of portability problems.  Since this group is very much about
portability, its important not to spread misinformation where portability is
concerned.

BTW, I'm not speaking from an "Ivory tower".  I recently had the job of
porting an application from NT to Digital UNIX with, you guessed it, 64 bit
longs.  The code is full of assumptions that a short is exactly 16 bits and a
long is exactly 32 bits.  Furthermore, the programmers never use int because
they don't know its size.  Needless to say the port was costly.  So, you see,
such distinctions do matter.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Timothy Writer]

Larry Hall <lhall@rfk.com> writes:

> At 01:48 PM 7/23/98 -0400, Timothy Writer wrote:
> >Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
> >integer types, designated as signed char, short int, int, and long int."  It
> >then goes on to say, "In the list of signed integer types above, the range of 
> >values of each type is a subrange of the values of the next type in the
> >list."
> >
> >In other words,
> >
> >    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> >
> >and
> >
> >    sizeof(char)  == 1
> >    sizeof(short) >= 2
> >    sizeof(int)   >= 2
> >    sizeof(long)  >= 4
> >
> 
> Sorry but this doesn't seem to follow.  I agree with the interpretation of
> the standard, namely:
> 
>   sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> 
> However, this does NOT imply what follows (the sizeof lines after the "and".)
> The implication from the standard is:
> 
>   sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> 
> AND
> 
>   sizeof(char)  == 1
>   sizeof(short) >= 1
>   sizeof(int)   >= 1
>   sizeof(long)  >= 1
> 
> which someone on this list pointed out previously.  I think the key words 
> here are that "the range of values of each type is a subrange of the values 
> of the next type in the list."  Are we getting a little too far off topic 
> for this list?

This follows from the earlier section of the standard I posted which states
the minimum ranges for each type, namely -127 to +127 for signed char, -32767
to +32767 for signed short, etc.  These imply that char is at least 8 bits,
short is at least 16 bits, and int and long are at least 32 bits.  Assuming a
char is exacly eight bits (it's not clear to me whether the standard requires
that or not) it follows that:

    sizeof(char)  == 1
    sizeof(short) >= 2
    sizeof(int)   >= 2
    sizeof(long)  >= 4

As to whether we're getting off topic.  Clearly this group is about
portability and I was disturbed by the number of misinformed posters
spreading incorrect information about something so fundamental to porability.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Larry Hall]

At 01:48 PM 7/23/98 -0400, Timothy Writer wrote:
>Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
>integer types, designated as signed char, short int, int, and long int."  It
>then goes on to say, "In the list of signed integer types above, the range of 
>values of each type is a subrange of the values of the next type in the
>list."
>
>In other words,
>
>    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
>
>and
>
>    sizeof(char)  == 1
>    sizeof(short) >= 2
>    sizeof(int)   >= 2
>    sizeof(long)  >= 4
>

Sorry but this doesn't seem to follow.  I agree with the interpretation of
the standard, namely:

  sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

However, this does NOT imply what follows (the sizeof lines after the "and".)
The implication from the standard is:

  sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

AND

  sizeof(char)  == 1
  sizeof(short) >= 1
  sizeof(int)   >= 1
  sizeof(long)  >= 1

which someone on this list pointed out previously.  I think the key words 
here are that "the range of values of each type is a subrange of the values 
of the next type in the list."  Are we getting a little too far off topic 
for this list?





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                    http://www.rfk.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Mumit Khan]

Long long vs long debate ...

Please take this elsewhere! There's comp.lang.c, which is a much better
forum than this mailing list.

I implore you to spare the rest of us from this inane discussion. Would 
be nice if some of the posters would bother opening up a standard C 
reference before posting.

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Earnie Boyd]

---sjm  wrote:
>
> 
> Earnie Boyd writes:
>  > Or why not set a new standard something like
>  > 
>  > int8, int16, int32, int64 to indicate the number of bits.
> 
> Right! The ambiguity of variable sizes has been the most unportable
feature of
> C. I know why they did it but it is still a pain. In those days the
world
> hadn't decided whether word sizes would be a multiple of 6 or 8 bits.
> Implementing a 32 bit data type on an 18 bit (or 24 bit) machine
would have
> been a disaster. Some machines would have wanted int6, int12, int18
and int24
> as bacic integer sizes. It was better to leave word sizes ambiguous
and accept
> the portability problem.
> 

If the compiler were to recognize the number following the `int' as
the number of bits to be used then one could specify whatever they
wished.  This would lend itself to `no problem' when porting assuming
the compiler could recognize this format.

BTW, IMHO, short should be the sizeof(int)/2 and long should be
sizeof(int)*2.

==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Benjamin Riefenstahl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

Hi Michael,


Michael H. Warfield wrote:
>         Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

No, it only specifies the *minimum* ranges that each type must cover and
it gives some relations like all values representable by "short" must
also be representable by "int" and "long" etc. The net result for most
current architectures are the conditions (I hope I don't miss anything
important)

  sizeof(char) == 1  // that's a definition actually, not a condition
  sizeof(char) * CHAR_BITS >= 8
  sizeof(short) * CHAR_BITS >= 16
  sizeof(int) * CHAR_BITS >= 16
  sizeof(long) * CHAR_BITS >= 32
  sizeof(int) >= sizeof(short)
  sizeof(long) >= sizeof(int)

The language standard does not say that "int" must be similar to one of
"short" or "long", so an implementation that does

  sizeof(short) * CHAR_BITS == 16
  sizeof(int) * CHAR_BITS == 32
  sizeof(long) * CHAR_BITS == 64

is prefectly comforming.

The main argument for a new type "long long" as I understood it in the
Newsgroup discussions was that there was just too much code out there
that relies on binary compatibility for the "long" type. A compiler that
wants binary compatibility *and* a 64 bits type must introduce a new
type.

One argument against was that the current standard guarantees that
"long" is the type with the largest range of them all. This makes code
like this legal and portable:

  size_t size = sizeof(someobject);
  fprintf( somefile, "%lu", (unsigned long) size );

with the guarantee that the cast will not truncate the value. The new
type can change this code without warning, because with a new type
size_t might be an alias for "long long" instead of maximally "long".
This was probably considered a rather obscure point by some. But than I
sometimes feel like portability issue often are about rather obscure
points, which is probably why they get missed so often.

I can only recommend to search the comp.std.c newsgroup for the topic in
Dejanews.


so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
Crocodial Communications EntwicklungsGmbH
Ruhrstraße 61, D-22761 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Matthew Donadio]

Timothy Writer wrote:
>     sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> and
>     sizeof(char)  == 1
>     sizeof(short) >= 2
>     sizeof(int)   >= 2
>     sizeof(long)  >= 4

Not necessarilly.  By definition sizeof(char) is always 1 no matter what
CHAR_BIT is defined to be.  But the values for the other sizeof's are
not correct for all machines.

For example, on the TMS320C3x and TMS320C4x families, the minimum
addressable memory unit is 32 bits, so CHAR_BIT for this machine is 32. 
It also happens that all other intergral types (short, int, and long)
are 32 bits (the exact size of char), so

sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) == 1

Weird, but legal.

-- 
Matt Donadio (donadio@isptechinc.com) | 43 Leopard Rd, Suite 102
Sr. Software Engineer                 | Paoli, PA 19301-1552
Image & Signal Processing, Inc.       | Phone: +1 610 407 4391
http://www.isptechinc.com             | FAX:   +1 610 407 4405
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Michael Weiser said:
> 
> Hi Harry,
> 
[SNIP]
> Unfortunately not. I didn't know that this matters so much.
> 
> BTW: Do you love splitting hairs? ;)

     No - but I *do* dislike wrong information!  <grin> And for
portable programming (which I have to do a lot of) you have to
be *very* clear on the rules.

   Regards,
       Harry.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Robert.Cross]

nleroy@norland.com  wrote:

#Technically, it doesn't make sense, at least in the PC world, where
#all processors are <=32bits. 
PICKY_MODE = TRUE
surely not *all* PC processors - what about the Alpha's? I realise that 
they're not really widespread, but they are out there. I suppose you could
also count PowerPC in that vein.
PICKY_MODE = FALSE

#Probably the more pervasive reason, however, is that there exists A
#LOT of code out there which expects sizeof(long)==4.  It's sort-of an
#un-official C standard.  In particular, legacy code dealing with
#networking, etc., is frequently very loaded with such assumptions.
#IIRC, the original CRAY C compiler used a 32-bit long and a 64-bit
#int, just because so much code had this expectation. 
Yes, and just to confuse the issue, the later compilers used 48bit as the
default. Although you could say '-i64' on the command line to promote these 
variables
all to 64bit.

#IMHO: C should have included standard data sizes, as well as it's generic 
types.  It
#would have made many things a lot simpler.
Agreed. Personally I cannot see a problem with :
short = 8bits, int=16bits, long=32bits, (long long = 64 bits)
other than possible problems when Merced et al are around, rumour has it that 
this
is 128bit native? So what would this be - "long long long" perhaps?

Bob Cross.

Re: long long vs long

[massimo morara]

Can be useful (I hope so)

http://www.UNIX-systems.org/version2/whatsnew/login_64bit.html


					massimo
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hi Harry,

You wrote:

>> No because the standard says
>> short == 16 bit
>> long  == 32 bit
>> int   == 16 or 32 depending on the machine's architecture
>> 
>> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
>> 32 bit.
>> So there's no way for long to be 64 bit while conforming to the
>> standard.
>  Oh dear - this seems to be a common belief.  Can you give the
>para in the standard where it says this?
Unfortunately not. I didn't know that this matters so much.

BTW: Do you love splitting hairs? ;)

bye

Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Timothy Writer]

"Michael H. Warfield" <mhw@alcove.wittsend.com> writes:

> Graham Murray enscribed thusly:
> > This is probably a silly question, but rather than having long long for
> > 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> > short <= int <= long.  So, it should be possible for long to be 64 bit
> > rather than 32. This would give a simple progression from 8bit chars to
> > 64bit longs.
> 
> 	Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

The standard says no such thing.  In section 5.2.4.2.1 Sizes of integral
types <limits.h>, it says

        The values given below shall be replaced by constant expressions
    suitable for use in #if preprocessing directives....  Their
    implementation defined values shall be EQUAL or GREATER [emphasis
    mine] in magnitude (absolute value) to those shown, with the same
    sign.

    -- number of bits for smallest object that is not a bit field (byte)
       CHAR_BIT				8

    ....

    -- minimum value for an object of type short int
       SHRT_MIN			   -32767

    -- maximum value for an object of type short int
       SHRT_MAX			   +32767

    ....

    -- minimum value for an object of type int
       INT_MIN			   -32767

    -- maximum value for an object of type int
       INT_MAX			   +32767
  
    ....

    -- minimum value for an object of type long int
       LONG_MIN		      -2147483647

    -- maximum value for an object of type long int
       LONG_MAX		      +2147483647

The first paragraph clearly states that these values are implementation
defined and that the sample values are suitable minimums.

Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
integer types, designated as signed char, short int, int, and long int."  It
then goes on to say, "In the list of signed integer types above, the range of 
values of each type is a subrange of the values of the next type in the
list."

In other words,

    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

and

    sizeof(char)  == 1
    sizeof(short) >= 2
    sizeof(int)   >= 2
    sizeof(long)  >= 4

While I agree that there is a large body of code that assumes long is 32
bits, such code is not portable.  And not because of a flaw in the Standard,
but because the programmer(s) responsible either didn't know the above or
didn't care.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Matthew Donadio]

Michael H. Warfield wrote:
> Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

Not to be picky, but to quote K&R II pg. 36:

"Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16
bits, longs are at least 32 bits, and short is no longer than int, which
is no longer than long."

Also, chars are not limited to be only 8 bits, but they must be at least
8 bits.  I routinely work on processors (C40, C44) where CHAR_BIT is
32.  This results in the pecularity that 

	sizeof(char) = sizeof(long) = 1

which is perfectly legal.  I think there is a lot more code in the world
that asumes that CHAR_BIT is 8 than sizeof(long) is 4.

-- 
Matt Donadio (donadio@isptechinc.com) | 43 Leopard Rd, Suite 102
Sr. Software Engineer                 | Paoli, PA 19301-1552
Image & Signal Processing, Inc.       | Phone: +1 610 407 4391
http://www.isptechinc.com             | FAX:   +1 610 407 4405
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[sjm]

Earnie Boyd writes:
 > Or why not set a new standard something like
 > 
 > int8, int16, int32, int64 to indicate the number of bits.

Right! The ambiguity of variable sizes has been the most unportable feature of
C. I know why they did it but it is still a pain. In those days the world
hadn't decided whether word sizes would be a multiple of 6 or 8 bits.
Implementing a 32 bit data type on an 18 bit (or 24 bit) machine would have
been a disaster. Some machines would have wanted int6, int12, int18 and int24
as bacic integer sizes. It was better to leave word sizes ambiguous and accept
the portability problem.

Did you ever wonder why octal was so popular and why many C constants were
originally only defineable as octal? Octal makes sense in an environment with
word sizes of multiples of 3 bits. Hex is only useful with multiples of 4
bits.

For those who don't remember, early DEC and IBM machines were 6 bit based. For
example the PDP-8 has a 12 bit word size. The IBM 360 was 36 bits. Radix 6
character encoding was quit popular on such machines.

Even worse, many processors only supported one word size. For example special
code needed to be emitted to access bytes on the 16 bit Nova machines. There
were no byte instructions; a lot of shifting and masking. That is what "int"
was for. It was intended to be the native "fast" data type that could be
accessed with single instructions. On a 16 bit machine a 32 bit word was
accessed as two words and implemented as multiple word arithmetic. Of course
that is how "long long" is implemented on most machines today.

Now that bytes have become a defacto standard for word size multiple and
variable word size inctructions exist everywhere one would think C could move
forward. Then again maybe intel is going to jump from variable 64 to a fixed
96 bits for the p96 generation.

Steve Morris
sjm@judgement.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: long long vs long

[Martin Portmann]

   That's why portable code use some typedefs that will be 
   redefined according to the CPU/OS.

   -----------------------------------------------------
   Martin Portmann               Mobile +41 79 330 60 12
   Software Department            Phone +41 62 896 42 40 
   Graph-Tech AG, Switzerland          map@graph-tech.ch
            http://www.graph-tech.ch/english/people/map/



> -----Original Message-----
> From:	michael@weiser.saale-net.de [SMTP:michael@weiser.saale-net.de]
> Sent:	Wednesday, July 22, 1998 9:20 PM
> To:	gnu-win32@cygnus.com
> Subject:	Re: long long vs long
> 
> Hi Graham,
> 
> You wrote:
> 
> >This is probably a silly question, but rather than having long long
> for
> >64 bit, why was long not made 64bit? The standard (AFAIK) states that
> >short <= int <= long.  So, it should be possible for long to be 64
> bit
> >rather than 32. This would give a simple progression from 8bit chars
> to
> >64bit longs.
> No because the standard says
> short == 16 bit
> long  == 32 bit
> int   == 16 or 32 depending on the machine's architecture
> 
> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> 32 bit.
> So there's no way for long to be 64 bit while conforming to the
> standard.
> 
> bye
> 
> Michael
> -
> For help on using this list (especially unsubscribing), send a message
> to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Michael Weiser said:
> 
[SNIP]

> No because the standard says
> short == 16 bit
> long  == 32 bit
> int   == 16 or 32 depending on the machine's architecture
> 
> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> 32 bit.
> So there's no way for long to be 64 bit while conforming to the
> standard.

  Oh dear - this seems to be a common belief.  Can you give the
para in the standard where it says this?

  Regards,
      Harry.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Brian Osman]

Michael Weiser wrote:
> 
> No because the standard says
> short == 16 bit
> long  == 32 bit
> int   == 16 or 32 depending on the machine's architecture
> 
> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> 32 bit. So there's no way for long to be 64 bit while conforming to > the standard.
> 
> bye
> 
> Michael

Hmmm. I don't have a copy of the standard laying around, but I do have
Kernighan & Ritchite (2nd ed.) which says

Section 2.2:
...
Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16
bits, longs are at least 32 bits, and short is no longer than int, which
is no longer than long.
...

-Brian
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Michael H. Warfield said:
> 
[SNIP]

> 	Unfortunately the standard also specifies the length of several
> types.

  Really?  Can you give the paras where it does this?  AFAIK
short, int and long are nowhere defined in length.

   Regards,
      Harry.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[John Estabrook]

It would have caused a lot of grief for people who have a lot of 
code to maintain...  all the sudden a long is not 4 bytes, and a 
long isn't the same size as a pointer.  

Just recompiling your applications could render your old data files 
unreadable because people do things like read in sizeof(long) bytes.
When the files were written a long was 32 bits, if a long was changed 
to 64 then it wouldn't work.

They are tackling the 64-bit long in 64-bit compilers for 64-bit OS's.
If for whatever reason you feel the need to port an app from a 
32-bit compiler to a 64-bit compiler then you have to go back and 
work on your code to remove trouble spots.

As an aside, look at the kind of trouble people run into by C++ 
defining a bool as an integer, and C not having a bool.   Many times 
a bool was typedef'd as a char in old C code.  Now you can get 
situations where a structure containing a bool has a different size 
in C than in C++.  There's so much legacy code out there that you 
really have to be careful when messing with the old order of things.

There are links that discusses these issues if you are interested:

http://www.rdg.opengroup.org/public/tech/aspen/lp64_wp.htm
http://www.sun.com/software/events/presentations/SPG3.Goyal/SPG3.Goyal.html
http://www.unix-systems.org/version2/whatsnew/datasize.html


> Graham Murray said:
> > 
> > This is probably a silly question, but rather than having long long for
> > 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> > short <= int <= long.  So, it should be possible for long to be 64 bit
> > rather than 32. This would give a simple progression from 8bit chars to
> > 64bit longs.
> 

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Andrew Sharp]

Graham Murray wrote:
> 
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

You're right, it is a silly question.  ~:^)  I did a lot of 64bit unix
kernel porting work a few years back, and the reason that something
other than 'long' had to be used is that there is about 6 trillion lines
of C code in the world that would seriously break if long's suddenly
became 64 bits, because coders have been using 'long' for more than a
decade with the belief that they are the same size as 'int'.  Avoiding
the discussion of why they didn't use 'int' all those times, suffice it
to say that a new type was created for the sake of expediency.  Everyone
who has written code that might require some fixin' if long's changed to
64 bits, raise your hand.

The irony is that types like 'long long' are usually accomplished in
some basic header, not as a base compiler type.  The base compiler 64bit
types are almost always of the form '_int64' or some such.  It seems we
just can't ever separate int's and long's!

a
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hi Graham,

You wrote:

>This is probably a silly question, but rather than having long long for
>64 bit, why was long not made 64bit? The standard (AFAIK) states that
>short <= int <= long.  So, it should be possible for long to be 64 bit
>rather than 32. This would give a simple progression from 8bit chars to
>64bit longs.
No because the standard says
short == 16 bit
long  == 32 bit
int   == 16 or 32 depending on the machine's architecture

For example: Under DOS int is 16 bit while under Win32 und UN*X it is
32 bit.
So there's no way for long to be 64 bit while conforming to the
standard.

bye

Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Nicholas R LeRoy]

On Jul 21,  8:01am, Graham Murray wrote:
> Subject: long long vs long
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

Several reasons, actually.

Technically, it doesn't make sense, at least in the PC world, where
all processors are <=32bits.  Any 64-bit operation takes 2 separate
accesses and math, etc., becomes more complicated (and requires more
instructions and time).

Probably the more pervasive reason, however, is that there exists A
LOT of code out there which expects sizeof(long)==4.  It's sort-of an
un-official C standard.  In particular, legacy code dealing with
networking, etc., is frequently very loaded with such assumptions.
IIRC, the original CRAY C compiler used a 32-bit long and a 64-bit
int, just because so much code had this expectation.  IMHO: C should
have included standard data sizes, as well as it's generic types.  It
would have made many things a lot simpler.

Just my $.02 worth.

-Nick

-- 
+-------------------------------+--------------------------------------------+
| /`--_   Nicholas R LeRoy      | In a world without fences, Who needs Gates?|
|{     }/ Norland Corporation   |        ---- Experience Linux! ----         |
| \ *  / W6340 Hackbarth Rd     | http://www.linux.org | http://www.ssc.com  |
| |___| Fort Atkinson, WI 53538 +--------------------------------------------+
|      nick.leroy@norland.com   | #include <disclaimer.h>                    |
| http://www.norland.com/~nleroy | These are my own ideas, not my employer's. |
+----------------------------------------------------------------------------+
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael H. Warfield]

Graham Murray enscribed thusly:
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

	Unfortunately the standard also specifies the length of several
types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.
The int type is NOT a specific length but is platform dependent, so an int
on earlier (XENIX and MS-DOS) systems use to be 16 bits while on modern
systems it's 32 bits.  Specifically, an int is defined as the "native"
integer number representation.  Of course, all of these types are "signed"
and have "unsigned" equivalences.  And before have the list jumps on me,
yes I know that unsigned and signed char's get into some interesting
ambiguities, particularly with old code that assumed that a char was
unsigned...

	Most code uses "int" where it wants the native number
representation.  That same code uses "short" and "long" where it wants
specific field lengths.  Imagine the havock that will transpire in code
with masks such as "foo = bar & 0xffff0000L" if you were to expand
long to be 64 bits.  The porting nightmare would make a sequel to
"Nightmare on Elm Street".

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Graham Murray said:
> 
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

   This is a frequent question.  I am told that while it would
be thoreticaly a good idea, so much existing code would break as
to make it unviable.  (This from a member of the C9x committee.)

   Regards,
       Harry.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

long long vs long

[Graham Murray]

This is probably a silly question, but rather than having long long for
64 bit, why was long not made 64bit? The standard (AFAIK) states that
short <= int <= long.  So, it should be possible for long to be 64 bit
rather than 32. This would give a simple progression from 8bit chars to
64bit longs.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".