RE: `quad' printf format specifier ?

RE: `quad' printf format specifier ?

[Guillermo A. Loyola]

> Come to think of that, does it imply that we can do 'short 
> short' for an eight-bit byte? =)

From the list of gcc ports that never saw the light of day,
Microunity had one that defined:

		long long : 128 bits
		     long : 64 bits
			int : 64 bits
		    short : 32 bits
	    short short : 16 bits
		     char : 8 bits

Gmo.

RE: `quad' printf format specifier ?

[Alex Buell]

On Mon, 8 Feb 1999, Guillermo A. Loyola wrote:

> >From the list of gcc ports that never saw the light of day,
> Microunity had one that defined:
> 
> 		long long : 128 bits
> 		     long : 64 bits
> 			int : 64 bits
> 		    short : 32 bits
> 	    short short : 16 bits
> 		     char : 8 bits

OK, so an int is always the "native" machine's natural bit-length? ie. on
IA32, it's 32 bits, and on some 64bit architectures it's 64 bits? 

In one of my C++ books, it happens to mention that short int is always 16
bits, and long int is always 32 bits, but an int is always dependent on
the architecture in use. Does this holds true for most C/C++
implementations?

And what will we do if 128 bit architectures comes into wide use? Will we
have to use 'long long long'? Or 'bloody long int'? =) 

I'm just concerned because I have some software that defines its own
datatypes (i.e typedef short int uint8; typedef long int uint32), and I'd
hate to see that break on 64 bit or 128 bit systems.

Is 'short short' really a valid C/C++ data type? And does it gives you an
eight-bit type, assuming that 'short int' is 16 bits?

Cheers,
Alex.

---
I want 'long long long long' for 256 bit data elements!

Re: `quad' printf format specifier ?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9902081436140.307-100000@lo-pc3035a.hitc.com >you wr
ite:
  > OK, so an int is always the "native" machine's natural bit-length? ie. on
  > IA32, it's 32 bits, and on some 64bit architectures it's 64 bits? 
No, you can't assume that.  You can assume:

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


jeff

Re: `quad' printf format specifier ?

[Alex Buell]

On Mon, 8 Feb 1999, Jeffrey A Law wrote:

> No, you can't assume that.  You can assume:
> 
> sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)

Assuming that >= means greater *or* equal to, are you saying that given
'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
64 bits in certain circumstances? 

If that's correct, the expression 'Oh bugger!' is something that comes to
mind. What's the best way to ensure that you get datatypes of a given
bit-length in C/C++?

OK, this is getting off-topic for the egcs mailing list, time to take this
to comp.lang.c or .c++.

Cheers,
Alex.

---

Re: `quad' printf format specifier ?

[Joe Buck]

> On Mon, 8 Feb 1999, Jeffrey A Law wrote:
> 
> > No, you can't assume that.  You can assume:
> > 
> > sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)
> 
> Assuming that >= means greater *or* equal to, are you saying that given
> 'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
> 64 bits in certain circumstances? 

Correct in theory.

> If that's correct, the expression 'Oh bugger!' is something that comes to
> mind. What's the best way to ensure that you get datatypes of a given
> bit-length in C/C++?

If some object must be a signed, 32-bit type, make a typedef int32 and
use that.  Your code won't run when someone tries to port it to a 24-bit
DSP, but that's life.

Re: `quad' printf format specifier ?

[Joe Buck]

> On Mon, 8 Feb 1999, Jeffrey A Law wrote:
> 
> > No, you can't assume that.  You can assume:
> > 
> > sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)
> 
> Assuming that >= means greater *or* equal to, are you saying that given
> 'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
> 64 bits in certain circumstances? 

Correct in theory.

> If that's correct, the expression 'Oh bugger!' is something that comes to
> mind. What's the best way to ensure that you get datatypes of a given
> bit-length in C/C++?

If some object must be a signed, 32-bit type, make a typedef int32 and
use that.  Your code won't run when someone tries to port it to a 24-bit
DSP, but that's life.

Re: `quad' printf format specifier ?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9902081606350.164-100000@lo-pc3035a.hitc.com >you wr
ite:
  > Assuming that >= means greater *or* equal to, are you saying that given
  > 'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
  > 64 bits in certain circumstances? 
I believe they can.  I'm not aware of any such target, but I do not think it
is disallowed by the standard.

I believe the wording typically sounds like a "char is large enough to hold
a character on the target machine" or something like that.

I'm not a language lawyer though.

  > If that's correct, the expression 'Oh bugger!' is something that comes to
  > mind. What's the best way to ensure that you get datatypes of a given
  > bit-length in C/C++?
I'm not sure if there is -- ISO may (or may not) have defined types for
specific sizes.

You can play these kinds of games:

#if UCHAR_MAX == 255
typedef unsigned char uint8;
typedef signed char int8;
#else
#error "Char is not an 8-bit type"
#endif




  > OK, this is getting off-topic for the egcs mailing list, time to take this
  > to comp.lang.c or .c++.
Yup.


jeff

Re: `quad' printf format specifier ?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9902081606350.164-100000@lo-pc3035a.hitc.com >you wr
ite:
  > Assuming that >= means greater *or* equal to, are you saying that given
  > 'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
  > 64 bits in certain circumstances? 
I believe they can.  I'm not aware of any such target, but I do not think it
is disallowed by the standard.

I believe the wording typically sounds like a "char is large enough to hold
a character on the target machine" or something like that.

I'm not a language lawyer though.

  > If that's correct, the expression 'Oh bugger!' is something that comes to
  > mind. What's the best way to ensure that you get datatypes of a given
  > bit-length in C/C++?
I'm not sure if there is -- ISO may (or may not) have defined types for
specific sizes.

You can play these kinds of games:

#if UCHAR_MAX == 255
typedef unsigned char uint8;
typedef signed char int8;
#else
#error "Char is not an 8-bit type"
#endif




  > OK, this is getting off-topic for the egcs mailing list, time to take this
  > to comp.lang.c or .c++.
Yup.


jeff

Re: `quad' printf format specifier ?

[Alex Buell]

On Mon, 8 Feb 1999, Jeffrey A Law wrote:

> No, you can't assume that.  You can assume:
> 
> sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)

Assuming that >= means greater *or* equal to, are you saying that given
'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
64 bits in certain circumstances? 

If that's correct, the expression 'Oh bugger!' is something that comes to
mind. What's the best way to ensure that you get datatypes of a given
bit-length in C/C++?

OK, this is getting off-topic for the egcs mailing list, time to take this
to comp.lang.c or .c++.

Cheers,
Alex.

---

Re: `quad' printf format specifier ?

[Jeffrey A Law]

  In message < Pine.LNX.4.05.9902081436140.307-100000@lo-pc3035a.hitc.com >you wr
ite:
  > OK, so an int is always the "native" machine's natural bit-length? ie. on
  > IA32, it's 32 bits, and on some 64bit architectures it's 64 bits? 
No, you can't assume that.  You can assume:

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


jeff

RE: `quad' printf format specifier ?

[Alex Buell]

On Mon, 8 Feb 1999, Guillermo A. Loyola wrote:

> >From the list of gcc ports that never saw the light of day,
> Microunity had one that defined:
> 
> 		long long : 128 bits
> 		     long : 64 bits
> 			int : 64 bits
> 		    short : 32 bits
> 	    short short : 16 bits
> 		     char : 8 bits

OK, so an int is always the "native" machine's natural bit-length? ie. on
IA32, it's 32 bits, and on some 64bit architectures it's 64 bits? 

In one of my C++ books, it happens to mention that short int is always 16
bits, and long int is always 32 bits, but an int is always dependent on
the architecture in use. Does this holds true for most C/C++
implementations?

And what will we do if 128 bit architectures comes into wide use? Will we
have to use 'long long long'? Or 'bloody long int'? =) 

I'm just concerned because I have some software that defines its own
datatypes (i.e typedef short int uint8; typedef long int uint32), and I'd
hate to see that break on 64 bit or 128 bit systems.

Is 'short short' really a valid C/C++ data type? And does it gives you an
eight-bit type, assuming that 'short int' is 16 bits?

Cheers,
Alex.

---
I want 'long long long long' for 256 bit data elements!

RE: `quad' printf format specifier ?

[Guillermo A. Loyola]

> Come to think of that, does it imply that we can do 'short 
> short' for an eight-bit byte? =)

Re: `quad' printf format specifier ?

[Kaveh R. Ghazi]

 > From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
 > 
 > > 	Perhaps the right fix would be for the format check for %qd to
 > > stop examining whether the underlying type is long long, but instead
 > > it should check whether the type of the argument is `quad_t' at some
 > > level of abstraction.  I don't know if this info has been lost at the
 > > point of the test though.
 > 
 > I'm afraid it has been... IF you know how to patch gcc/egcs to make it
 > work at that level, this is VERY fine. Otherwise, we would want egcs
 > to stop assuming that quad_t == long long, since this is plain wrong.
 > 
 > If you prefer: we slightly prefer "%qd" to behave correctly in the
 > presence of (quad_t) than yield possible bogus warnings... the best
 > way would probably be to keep the type-info and ensure that quad_t has
 > been used (though there is a good chance that some code will roll its
 > own), but baring that, equating "%qd" with long long is more annoying
 > than anything.
 > -- 
 > 	Marc Espie		


	I don't think we have to worry about people who roll their own
quad_t.  Remember we're talking about format specifier checks for printf
from libc.  Thus the quad_t in user code must be the same one used when
the printf function from libc was built.  I.e. both must be whatever the
OS's notion of quad_t is.  If the user rolls their own, all bets are off. 

	As for the actual solution, the info is available.  If you look
at the end of function check_format_info() in c-common.c, all the tree
information is there for you.  All you have to do is check if the name
of the type is "quad_t" and make an exception for that case when the
format specifier is 'q'.  There is a problem when using layers of
typedefs.  E.g. 

 > typedef long quad_t; /* From OS header */
 > 
 > typedef quad_t q2; /* In user code */
 > printf("%qd", (q2) 0);

	In this case, when you muck through the tree structure, the
"type" appears to be "q2".  So I think what you need to do is chain
through the typedef declarations somehow (ending when you reach a
builtin type) to see if any of them are "quad_t" and if you find quad_t,
then make the exception.  I'm not an expert on trees so you'll have to
figure out how to do that yourself. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: `quad' printf format specifier ?

[Kaveh R. Ghazi]

 > From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
 > 
 > > 	Perhaps the right fix would be for the format check for %qd to
 > > stop examining whether the underlying type is long long, but instead
 > > it should check whether the type of the argument is `quad_t' at some
 > > level of abstraction.  I don't know if this info has been lost at the
 > > point of the test though.
 > 
 > I'm afraid it has been... IF you know how to patch gcc/egcs to make it
 > work at that level, this is VERY fine. Otherwise, we would want egcs
 > to stop assuming that quad_t == long long, since this is plain wrong.
 > 
 > If you prefer: we slightly prefer "%qd" to behave correctly in the
 > presence of (quad_t) than yield possible bogus warnings... the best
 > way would probably be to keep the type-info and ensure that quad_t has
 > been used (though there is a good chance that some code will roll its
 > own), but baring that, equating "%qd" with long long is more annoying
 > than anything.
 > -- 
 > 	Marc Espie		


	I don't think we have to worry about people who roll their own
quad_t.  Remember we're talking about format specifier checks for printf
from libc.  Thus the quad_t in user code must be the same one used when
the printf function from libc was built.  I.e. both must be whatever the
OS's notion of quad_t is.  If the user rolls their own, all bets are off. 

	As for the actual solution, the info is available.  If you look
at the end of function check_format_info() in c-common.c, all the tree
information is there for you.  All you have to do is check if the name
of the type is "quad_t" and make an exception for that case when the
format specifier is 'q'.  There is a problem when using layers of
typedefs.  E.g. 

 > typedef long quad_t; /* From OS header */
 > 
 > typedef quad_t q2; /* In user code */
 > printf("%qd", (q2) 0);

	In this case, when you muck through the tree structure, the
"type" appears to be "q2".  So I think what you need to do is chain
through the typedef declarations somehow (ending when you reach a
builtin type) to see if any of them are "quad_t" and if you find quad_t,
then make the exception.  I'm not an expert on trees so you'll have to
figure out how to do that yourself. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: `quad' printf format specifier ?

[Kaveh R. Ghazi]

 > From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
 > 
 > On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
 > > It makes sense now.  I can make a case for fixing gcc or for changing
 > > your definition of quad_t:
 > 
 > > - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
 > > then we shouldn't warn when %qd is used to print something with base
 > > type long.
 > Yes, this should make sense.


	No, this does not ensure your printf code is portable.



 > > - but long isn't 64 bits everywhere, so portable code must use int64_t
 > > and/or long long to get 64 bits reliably; therefore %qd and %lld
 > > should warn when given something with base type long.
 > Current definition of quad_t is encapsulated in machine/cdefs.h, or
 > something like this, so this is not a portability issue.
 > `quad_t' will be 64 bits, but the underlying `true' type may change...
 > what's interesting for us is to get something sensible according to
 > whether or not the current base type has the same size as the underlying
 > type or not.   I believe such portability warnings belong in the 
 > -ansi -pedantic class.


	You should never mix format specifiers (which pair with builtin
types, quad_t being an exception) and int64_t because this is completely
non-portable.  -ansi and -pedantic are for standards compliance
warnings.  Since %qd is a BSDism, I don't think quad_t formats relates
to it. 



 > If there is no actual standard to enforce, I fail to see how OpenBSD
 > could get it `wrong', and I'm mainly trying to keep current practice
 > from breaking without disturbing correct code. 
 > 	Marc Espie		


	The root of the problem is that gcc assumes quad_t == long long
in its -Wformat check.  You can see this in c-common.c:check_format_info().

The -Wformat checks don't care (and shouldn't care) if the format
specifier and the type used happen to be the same _size_.  That test
would only be valid on the CPU in question.  A true portability test
checks the argument's _type_ and that's what's causing the problem
because quad_t is not a builtin type.  However we should not break this
correct feature of the -Wformat checks even for quad_t. 

	Since quad_t is not a builtin type and I've not read in this
thread that an official standard governs its _typedef_, I don't think
gcc can make any assumption about it.  I.e.  OpenBSD is not wrong to use
plain `long' if that type is in fact 64 bits on the arch in question. 

	Perhaps the right fix would be for the format check for %qd to
stop examining whether the underlying type is long long, but instead
it should check whether the type of the argument is `quad_t' at some
level of abstraction.  I don't know if this info has been lost at the
point of the test though.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: `quad' printf format specifier ?

[Kaveh R. Ghazi]

 > From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
 > 
 > On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
 > > It makes sense now.  I can make a case for fixing gcc or for changing
 > > your definition of quad_t:
 > 
 > > - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
 > > then we shouldn't warn when %qd is used to print something with base
 > > type long.
 > Yes, this should make sense.


	No, this does not ensure your printf code is portable.



 > > - but long isn't 64 bits everywhere, so portable code must use int64_t
 > > and/or long long to get 64 bits reliably; therefore %qd and %lld
 > > should warn when given something with base type long.
 > Current definition of quad_t is encapsulated in machine/cdefs.h, or
 > something like this, so this is not a portability issue.
 > `quad_t' will be 64 bits, but the underlying `true' type may change...
 > what's interesting for us is to get something sensible according to
 > whether or not the current base type has the same size as the underlying
 > type or not.   I believe such portability warnings belong in the 
 > -ansi -pedantic class.


	You should never mix format specifiers (which pair with builtin
types, quad_t being an exception) and int64_t because this is completely
non-portable.  -ansi and -pedantic are for standards compliance
warnings.  Since %qd is a BSDism, I don't think quad_t formats relates
to it. 



 > If there is no actual standard to enforce, I fail to see how OpenBSD
 > could get it `wrong', and I'm mainly trying to keep current practice
 > from breaking without disturbing correct code. 
 > 	Marc Espie		


	The root of the problem is that gcc assumes quad_t == long long
in its -Wformat check.  You can see this in c-common.c:check_format_info().

The -Wformat checks don't care (and shouldn't care) if the format
specifier and the type used happen to be the same _size_.  That test
would only be valid on the CPU in question.  A true portability test
checks the argument's _type_ and that's what's causing the problem
because quad_t is not a builtin type.  However we should not break this
correct feature of the -Wformat checks even for quad_t. 

	Since quad_t is not a builtin type and I've not read in this
thread that an official standard governs its _typedef_, I don't think
gcc can make any assumption about it.  I.e.  OpenBSD is not wrong to use
plain `long' if that type is in fact 64 bits on the arch in question. 

	Perhaps the right fix would be for the format check for %qd to
stop examining whether the underlying type is long long, but instead
it should check whether the type of the argument is `quad_t' at some
level of abstraction.  I don't know if this info has been lost at the
point of the test though.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: `quad' printf format specifier ?

[John Breen]

From: Jeffrey A Law <law@hurl.cygnus.com>
>  In message 
< Pine.LNX.4.05.9902081606350.164-100000@lo-pc3035a.hitc.com >you wr
>ite:
>  > [...] then 'long', 'int', 'short' and 'char' can also be
>  > 64 bits in certain circumstances? 
>I believe they can.  I'm not aware of any such target, but I do not
>think it is disallowed by the standard.

TI's C compiler for the C40 declares long, int, short, and char to all 
be 32 bits (all memory accesses on the C40 are 32 bits).  I haven't 
checked the c4x port in egcs.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Re: `quad' printf format specifier ?

[Alan Lehotsky]

jab3@hotmail.com said...
> 
> From: Jeffrey A Law <law@hurl.cygnus.com>
> >  In message 
> < Pine.LNX.4.05.9902081606350.164-100000@lo-pc3035a.hitc.com >you wr
> >ite:
> >  > [...] then 'long', 'int', 'short' and 'char' can also be
> >  > 64 bits in certain circumstances? 
> >I believe they can.  I'm not aware of any such target, but I do not
> >think it is disallowed by the standard.
> 
> TI's C compiler for the C40 declares long, int, short, and char to all 
> be 32 bits (all memory accesses on the C40 are 32 bits).  I haven't 
> checked the c4x port in egcs.
> --
> John A. Breen
> jab3@hotmail.com
> 
> 

	ADI's SHARC goes that even better.  It also says

	sizeof(double) == sizeof(float) == sizeof(long) ==
	sizeof(int) == sizeof(short) == sizeof(char)

	Although, the hardware is capable of doing either

		16 bit
		32 bit
		40 bit
		48 bit 

	memory fetches!  Of course all arithmetic is done on 32 bits
	(unless you use the multiplier accumulator in which case you
	can do 80 bit!)

-- Al Lehotsky

Re: `quad' printf format specifier ?

[Ross Smith]

From: Alex Buell <alex.buell@tahallah.demon.co.uk>
>On Mon, 8 Feb 1999, Jeffrey A Law wrote:
>
>> No, you can't assume that.  You can assume:
>> 
>> sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)
>
>Assuming that >= means greater *or* equal to, are you saying that given
>'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
>64 bits in certain circumstances? 
>
>If that's correct, the expression 'Oh bugger!' is something that comes to
>mind. What's the best way to ensure that you get datatypes of a given
>bit-length in C/C++?

It depends on exactly what you mean by "a given bit-length".

When C was originally specified, the intention was that "int" would
always be the host machine's natural word size. That way, you could
use "int" in your code and be reasonably sure of getting maximally
efficient arithmetic. If you needed space efficiency and didn't need
large values, you used "short"; if you needed to be sure that large
values (over 16 bits) were valid, you used "long".

At that time, most hardware (at least, most hardware that ran C
compilers) was 16-bit or 32-bit. Now, with 64-bit CPUs becoming more
common, a lot of people porting compilers to those machines have
chosen to use 16-bit short, 32-bit int, and 64-bit long. I suppose
that seems natural if you're not familiar with the reasoning behind
the standard requirements, but it breaks the "int is best" assumption.
It's no longer possible to write code that works efficiently on both
32-bit and 64-bit platforms, without using your own typedef for "best
integer type".

(Java actually *requires* the s16/i32/l64 scheme, because its design
philosophy is that absolutely predictable behaviour is more important
than efficiency.)

The proposed C9X standard includes a whole bunch of integer typedefs,
which fall into three categories:

  The fastest integer with at least N bits (time optimisation)
  The smallest integer with at least N bits (space optimisation)
  Integers with exactly N bits (fatal error if no such type exists)

It also adds the "long long" type, which is apparently for those who
want a 64-bit type on 32-bit hardware. (Given the typedefs, which
provide the same facility more consistently, this seems silly.)

If you want something with more reliable behaviour than short, int,
and long, you can use the C9X typedefs if you have them, or you can
easily synthesise the same sort of thing in C++. You can see my
implementation at
http://animal.ihug.co.nz/c++/integer_bits.hpp

>OK, this is getting off-topic for the egcs mailing list, time to take this
>to comp.lang.c or .c++.

Probably. (But use the respective .moderated groups, the old
unmoderated ones have long since collapsed into unreadable cesspools.)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
    To err is human. To really screw up requires the root password.

Re: `quad' printf format specifier ?

[Ross Smith]

From: Alex Buell <alex.buell@tahallah.demon.co.uk>
>On Mon, 8 Feb 1999, Jeffrey A Law wrote:
>
>> No, you can't assume that.  You can assume:
>> 
>> sizeof (long long) >=  sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char)
>
>Assuming that >= means greater *or* equal to, are you saying that given
>'long long' is 64 bits then 'long', 'int', 'short' and 'char' can also be
>64 bits in certain circumstances? 
>
>If that's correct, the expression 'Oh bugger!' is something that comes to
>mind. What's the best way to ensure that you get datatypes of a given
>bit-length in C/C++?

It depends on exactly what you mean by "a given bit-length".

When C was originally specified, the intention was that "int" would
always be the host machine's natural word size. That way, you could
use "int" in your code and be reasonably sure of getting maximally
efficient arithmetic. If you needed space efficiency and didn't need
large values, you used "short"; if you needed to be sure that large
values (over 16 bits) were valid, you used "long".

At that time, most hardware (at least, most hardware that ran C
compilers) was 16-bit or 32-bit. Now, with 64-bit CPUs becoming more
common, a lot of people porting compilers to those machines have
chosen to use 16-bit short, 32-bit int, and 64-bit long. I suppose
that seems natural if you're not familiar with the reasoning behind
the standard requirements, but it breaks the "int is best" assumption.
It's no longer possible to write code that works efficiently on both
32-bit and 64-bit platforms, without using your own typedef for "best
integer type".

(Java actually *requires* the s16/i32/l64 scheme, because its design
philosophy is that absolutely predictable behaviour is more important
than efficiency.)

The proposed C9X standard includes a whole bunch of integer typedefs,
which fall into three categories:

  The fastest integer with at least N bits (time optimisation)
  The smallest integer with at least N bits (space optimisation)
  Integers with exactly N bits (fatal error if no such type exists)

It also adds the "long long" type, which is apparently for those who
want a 64-bit type on 32-bit hardware. (Given the typedefs, which
provide the same facility more consistently, this seems silly.)

If you want something with more reliable behaviour than short, int,
and long, you can use the C9X typedefs if you have them, or you can
easily synthesise the same sort of thing in C++. You can see my
implementation at
http://animal.ihug.co.nz/c++/integer_bits.hpp

>OK, this is getting off-topic for the egcs mailing list, time to take this
>to comp.lang.c or .c++.

Probably. (But use the respective .moderated groups, the old
unmoderated ones have long since collapsed into unreadable cesspools.)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
    To err is human. To really screw up requires the root password.

Re: `quad' printf format specifier ?

[Zack Weinberg]

On Sat, 6 Feb 1999 13:31:20 +0100, Marc Espie wrote:
>On Fri, Feb 05, 1999 at 08:55:28PM -0500, Zack Weinberg wrote:
>> If sizeof (long long) == sizeof (long) on openbsd-alpha, it should work
>> anyway - i.e. %ld, %lld, and %qd should be interchangeable.  What problems
>> are you seeing?
>
>Warnings when using __attribute((format(printf,...))
>
>> (Note this is a libc issue, not a compiler issue, unless your problem is
>> with gcc's format checking.)
>
>Precisely...
>I probably wasn't clear enough in my message, wasn't I ?

It makes sense now.  I can make a case for fixing gcc or for changing
your definition of quad_t:

- %qd is defined to print a 64 bit quantity, so if long is 64 bits,
then we shouldn't warn when %qd is used to print something with base
type long.

- but long isn't 64 bits everywhere, so portable code must use int64_t
and/or long long to get 64 bits reliably; therefore %qd and %lld
should warn when given something with base type long.

It really boils down to whether you think `long long' is an
abomination or not.

zw

Re: `quad' printf format specifier ?

[Alex Buell]

On Sat, 6 Feb 1999, Zack Weinberg wrote:

> It really boils down to whether you think `long long' is an
> abomination or not.

Come to think of that, does it imply that we can do 'short short' for an
eight-bit byte? =)

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - Leaving the States for good!

Re: `quad' printf format specifier ?

[Alex Buell]

On Sat, 6 Feb 1999, Zack Weinberg wrote:

> It really boils down to whether you think `long long' is an
> abomination or not.

Come to think of that, does it imply that we can do 'short short' for an
eight-bit byte? =)

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - Leaving the States for good!

Re: `quad' printf format specifier ?

[Marc Espie]

On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
> It makes sense now.  I can make a case for fixing gcc or for changing
> your definition of quad_t:

> - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
> then we shouldn't warn when %qd is used to print something with base
> type long.
Yes, this should make sense.

> - but long isn't 64 bits everywhere, so portable code must use int64_t
> and/or long long to get 64 bits reliably; therefore %qd and %lld
> should warn when given something with base type long.
Current definition of quad_t is encapsulated in machine/cdefs.h, or
something like this, so this is not a portability issue.
`quad_t' will be 64 bits, but the underlying `true' type may change...
what's interesting for us is to get something sensible according to
whether or not the current base type has the same size as the underlying
type or not.   I believe such portability warnings belong in the 
-ansi -pedantic class.

> It really boils down to whether you think `long long' is an
> abomination or not.
I'm not familiar enough with C9X to have a definite opinion. All I know
is that both `long long' and C9X somewhat break portable old code, where
casting to long and using %ld to print values was enough to ensure
portability, which is precisely why I'm asking for guidance (I also have
heard that C9X confused some C++ related issues and what's going to come
out is currently thoroughly incompatible with the C++ standard, but this
is another issue).

I would very much like to know what's the exact status of stuff such as
atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
or is it just a common extension that is supposed to work in a given way ?

If there is no actual standard to enforce, I fail to see how OpenBSD could
get it `wrong', and I'm mainly trying to keep current practice from breaking
without disturbing correct code.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

Re: `quad' printf format specifier ?

[Andreas Schwab]

Marc Espie <Marc.Espie@liafa.jussieu.fr> writes:

|> I would very much like to know what's the exact status of stuff such as
|> atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
|> or is it just a common extension that is supposed to work in a given way ?

The C9X standard has atoll and printf("%lld"), and generally uses the ll
suffix for long long variants of funtions.  The `q' variants are just BSD
extensions.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: `quad' printf format specifier ?

[Andreas Schwab]

Marc Espie <Marc.Espie@liafa.jussieu.fr> writes:

|> I would very much like to know what's the exact status of stuff such as
|> atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
|> or is it just a common extension that is supposed to work in a given way ?

The C9X standard has atoll and printf("%lld"), and generally uses the ll
suffix for long long variants of funtions.  The `q' variants are just BSD
extensions.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: `quad' printf format specifier ?

[Zack Weinberg]

On Sat, 6 Feb 1999 22:23:05 +0100, Marc Espie wrote:
>On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
>> It makes sense now.  I can make a case for fixing gcc or for changing
>> your definition of quad_t:
>
>> - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
>> then we shouldn't warn when %qd is used to print something with base
>> type long.
>Yes, this should make sense.
>
>> - but long isn't 64 bits everywhere, so portable code must use int64_t
>> and/or long long to get 64 bits reliably; therefore %qd and %lld
>> should warn when given something with base type long.
>Current definition of quad_t is encapsulated in machine/cdefs.h, or
>something like this, so this is not a portability issue.
>`quad_t' will be 64 bits, but the underlying `true' type may change...
>what's interesting for us is to get something sensible according to
>whether or not the current base type has the same size as the underlying
>type or not.   I believe such portability warnings belong in the 
>-ansi -pedantic class.

Both quad_t and %qd are BSD extensions, and they're intended to work
together as I understand it, so BSD should get to say what types gcc
accepts for %qd.  It sounds like we should either accept any DImode
type, or just the quad_t typedef.

zw

Re: `quad' printf format specifier ?

[Zack Weinberg]

On Sat, 6 Feb 1999 22:23:05 +0100, Marc Espie wrote:
>On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
>> It makes sense now.  I can make a case for fixing gcc or for changing
>> your definition of quad_t:
>
>> - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
>> then we shouldn't warn when %qd is used to print something with base
>> type long.
>Yes, this should make sense.
>
>> - but long isn't 64 bits everywhere, so portable code must use int64_t
>> and/or long long to get 64 bits reliably; therefore %qd and %lld
>> should warn when given something with base type long.
>Current definition of quad_t is encapsulated in machine/cdefs.h, or
>something like this, so this is not a portability issue.
>`quad_t' will be 64 bits, but the underlying `true' type may change...
>what's interesting for us is to get something sensible according to
>whether or not the current base type has the same size as the underlying
>type or not.   I believe such portability warnings belong in the 
>-ansi -pedantic class.

Both quad_t and %qd are BSD extensions, and they're intended to work
together as I understand it, so BSD should get to say what types gcc
accepts for %qd.  It sounds like we should either accept any DImode
type, or just the quad_t typedef.

zw

Re: `quad' printf format specifier ?

[Marc Espie]

On Sat, Feb 06, 1999 at 02:04:00PM -0500, Zack Weinberg wrote:
> It makes sense now.  I can make a case for fixing gcc or for changing
> your definition of quad_t:

> - %qd is defined to print a 64 bit quantity, so if long is 64 bits,
> then we shouldn't warn when %qd is used to print something with base
> type long.
Yes, this should make sense.

> - but long isn't 64 bits everywhere, so portable code must use int64_t
> and/or long long to get 64 bits reliably; therefore %qd and %lld
> should warn when given something with base type long.
Current definition of quad_t is encapsulated in machine/cdefs.h, or
something like this, so this is not a portability issue.
`quad_t' will be 64 bits, but the underlying `true' type may change...
what's interesting for us is to get something sensible according to
whether or not the current base type has the same size as the underlying
type or not.   I believe such portability warnings belong in the 
-ansi -pedantic class.

> It really boils down to whether you think `long long' is an
> abomination or not.
I'm not familiar enough with C9X to have a definite opinion. All I know
is that both `long long' and C9X somewhat break portable old code, where
casting to long and using %ld to print values was enough to ensure
portability, which is precisely why I'm asking for guidance (I also have
heard that C9X confused some C++ related issues and what's going to come
out is currently thoroughly incompatible with the C++ standard, but this
is another issue).

I would very much like to know what's the exact status of stuff such as
atoq(), or printf("%qd").  Does it correspond to any current standard/draft,
or is it just a common extension that is supposed to work in a given way ?

If there is no actual standard to enforce, I fail to see how OpenBSD could
get it `wrong', and I'm mainly trying to keep current practice from breaking
without disturbing correct code.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

Re: `quad' printf format specifier ?

[Zack Weinberg]

On Sat, 6 Feb 1999 13:31:20 +0100, Marc Espie wrote:
>On Fri, Feb 05, 1999 at 08:55:28PM -0500, Zack Weinberg wrote:
>> If sizeof (long long) == sizeof (long) on openbsd-alpha, it should work
>> anyway - i.e. %ld, %lld, and %qd should be interchangeable.  What problems
>> are you seeing?
>
>Warnings when using __attribute((format(printf,...))
>
>> (Note this is a libc issue, not a compiler issue, unless your problem is
>> with gcc's format checking.)
>
>Precisely...
>I probably wasn't clear enough in my message, wasn't I ?

It makes sense now.  I can make a case for fixing gcc or for changing
your definition of quad_t:

- %qd is defined to print a 64 bit quantity, so if long is 64 bits,
then we shouldn't warn when %qd is used to print something with base
type long.

- but long isn't 64 bits everywhere, so portable code must use int64_t
and/or long long to get 64 bits reliably; therefore %qd and %lld
should warn when given something with base type long.

It really boils down to whether you think `long long' is an
abomination or not.

zw