Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #91781 > unrolled thread

sizeof Data types

Back to article view | Back to comp.lang.c

Contents

  sizeof Data types Real Troll <real.troll@trolls.com> - 2016-08-05 18:45 -0400
    sizeof Data types jameskuyper@verizon.net - 2016-08-05 17:10 -0700
    Re: sizeof Data types raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:35 +0000
    Re: sizeof Data types raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:36 +0000
    Re: sizeof Data types Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-06 22:29 +0200
      Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-09 12:55 -0400
    Re: sizeof Data types BartC <bc@freeuk.com> - 2016-08-06 21:43 +0100
      Re: sizeof Data types jameskuyper@verizon.net - 2016-08-06 15:25 -0700
        Re: sizeof Data types David Brown <david.brown@hesbynett.no> - 2016-08-08 09:48 +0200
          Re: sizeof Data types James Kuyper <jameskuyper@verizon.net> - 2016-08-08 11:05 -0400
            Re: sizeof Data types David Brown <david.brown@hesbynett.no> - 2016-08-08 17:57 +0200
          Re: sizeof Data types supercat@casperkitty.com - 2016-08-08 08:36 -0700
            Re: sizeof Data types David Brown <david.brown@hesbynett.no> - 2016-08-08 19:05 +0200
              Re: sizeof Data types supercat@casperkitty.com - 2016-08-08 14:09 -0700
                Re: sizeof Data types David Brown <david.brown@hesbynett.no> - 2016-08-09 09:38 +0200
                  Re: sizeof Data types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-09 11:23 +0100
                    Re: sizeof Data types Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 07:42 -0700
                      Re: sizeof Data types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 21:38 +0100
                  Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-09 08:12 -0700
                  Re: sizeof Data types supercat@casperkitty.com - 2016-08-10 10:36 -0700
                    Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-10 11:42 -0700
        Re: sizeof Data types Philip Lantz <prl@canterey.us> - 2016-08-11 10:20 -0700
          Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-11 12:04 -0700
          Re: sizeof Data types Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:22 -0700
      Re: sizeof Data types Nobody <nobody@nowhere.invalid> - 2016-08-07 01:32 +0100
        Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-06 18:10 -0700
    Re: sizeof Data types Siri Cruise <chine.bleu@yahoo.com> - 2016-08-06 20:22 -0700
      Re: sizeof Data types Ian Collins <ian-news@hotmail.com> - 2016-08-07 15:40 +1200
      Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-09 13:06 -0400
        Re: sizeof Data types Siri Cruise <chine.bleu@yahoo.com> - 2016-08-09 12:37 -0700
          Re: sizeof Data types Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 09:18 -0700
            Re: sizeof Data types Siri Cruise <chine.bleu@yahoo.com> - 2016-08-11 11:11 -0700
              Re: sizeof Data types Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-11 12:26 -0600
                Re: sizeof Data types David Brown <david.brown@hesbynett.no> - 2016-08-11 23:31 +0200
                  Re: sizeof Data types supercat@casperkitty.com - 2016-08-11 14:59 -0700
                Re: sizeof Data types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 00:15 -0700
              Re: sizeof Data types Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-12 08:05 -0700
    Re: sizeof Data types John Bode <jfbode1029@gmail.com> - 2016-08-08 12:38 -0700
      Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-09 13:08 -0400
        Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-09 10:43 -0700
        Re: sizeof Data types "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-09 13:41 -0400
          Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-10 11:51 -0400
            Re: sizeof Data types "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-10 12:35 -0400
              Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-11 11:53 -0400
                Re: sizeof Data types "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-13 11:29 -0400
                  Re: sizeof Data types supercat@casperkitty.com - 2016-08-13 09:18 -0700
            Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-10 10:13 -0700
              Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-11 11:56 -0400
    Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-09 12:59 -0400
      Re: sizeof Data types "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-09 13:49 -0400
        Re: sizeof Data types Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:08 -0400
      Re: sizeof Data types Keith Thompson <kst-u@mib.org> - 2016-08-09 11:35 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#92027

On 08/09/2016 01:08 PM, Ken Brody wrote:
> On 8/8/2016 3:38 PM, John Bode wrote:
> [...]
>> C99 introduced fixed-size types like int16_t and uint32_t which take up
>> exactly as many bits as it says on the label, but they don't have to be
>> supported by an implementation.
>
> My complaint is that, AFAIK, they didn't specify a way for you to know if a
> given size is supported, short of having the compile fail on you if you used it.
>
> If there is a way, please let me know.

#include <stdint.h>
#ifndef INT16_MAX
#error int16_t is not supported
#endif

[toc] | [prev] | [next] | [standalone]

#92077

On 8/9/2016 1:41 PM, James R. Kuyper wrote:
> On 08/09/2016 01:08 PM, Ken Brody wrote:
[...]
>> My complaint is that, AFAIK, they didn't specify a way for you to know if a
>> given size is supported, short of having the compile fail on you if you
>> used it.
>>
>> If there is a way, please let me know.
>
> #include <stdint.h>
> #ifndef INT16_MAX
> #error int16_t is not supported
> #endif

Ah...  Obvious when you think about it.

Section 7.18.2 (n1124).

Thank you.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#92085

On 08/10/2016 11:51 AM, Ken Brody wrote:
> On 8/9/2016 1:41 PM, James R. Kuyper wrote:
>> On 08/09/2016 01:08 PM, Ken Brody wrote:
> [...]
>>> My complaint is that, AFAIK, they didn't specify a way for you to know if a
>>> given size is supported, short of having the compile fail on you if you
>>> used it.
>>>
>>> If there is a way, please let me know.
>>
>> #include <stdint.h>
>> #ifndef INT16_MAX
>> #error int16_t is not supported
>> #endif
>
> Ah...  Obvious when you think about it.
>
> Section 7.18.2 (n1124).

A key point, which I should have mentioned, is that the C standard says 
"For each type described herein that the implementation provides,261) 
<stdint.h> shall declare that typedef name and define the associated 
macros. Conversely, for each type described herein that the 
implementation does not provide, <stdint.h> shall not declare that 
typedef name nor shall it define the associated macros." (7.20p4 - 
n1570). If it weren't for the "shall not" clause, this test wouldn't be 
reliable.

[toc] | [prev] | [next] | [standalone]

#92129

On 8/10/2016 12:35 PM, James R. Kuyper wrote:
> On 08/10/2016 11:51 AM, Ken Brody wrote:
>> On 8/9/2016 1:41 PM, James R. Kuyper wrote:
[...]
>>> #include <stdint.h>
>>> #ifndef INT16_MAX
>>> #error int16_t is not supported
>>> #endif
>>
>> Ah...  Obvious when you think about it.
>>
>> Section 7.18.2 (n1124).
>
> A key point, which I should have mentioned, is that the C standard says "For
> each type described herein that the implementation provides,261) <stdint.h>
> shall declare that typedef name and define the associated macros.
> Conversely, for each type described herein that the implementation does not
> provide, <stdint.h> shall not declare that typedef name nor shall it define
> the associated macros." (7.20p4 - n1570). If it weren't for the "shall not"
> clause, this test wouldn't be reliable.

It should be obvious that, if an implementation doesn't include an X-bit 
integer, there shouldn't be an INTx_MAX define for it.  ("We don't supply a 
64-bit integer, but if we did, it's max value would have been...")  But, 
it's good that the Standard specifically says "shall not".

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#92224

On 08/11/2016 11:53 AM, Ken Brody wrote:
> On 8/10/2016 12:35 PM, James R. Kuyper wrote:
...
>> A key point, which I should have mentioned, is that the C standard says "For
>> each type described herein that the implementation provides,261) <stdint.h>
>> shall declare that typedef name and define the associated macros.
>> Conversely, for each type described herein that the implementation does not
>> provide, <stdint.h> shall not declare that typedef name nor shall it define
>> the associated macros." (7.20p4 - n1570). If it weren't for the "shall not"
>> clause, this test wouldn't be reliable.
>
> It should be obvious that, if an implementation doesn't include an X-bit
> integer, there shouldn't be an INTx_MAX define for it.  ("We don't supply a
> 64-bit integer, but if we did, it's max value would have been...") ...

More plausibly, "The 64-bit integer we supply doesn't meet the 
standard's requirements for int64_t, but we're going to typedef int64_t 
to refer to it anyway, and we'll #define corresponding macros.". Real 
implementations have done comparably annoying things in the past, so 
explicitly prohibiting them from doing so has some value.

> ... But,
> it's good that the Standard specifically says "shall not".
>

[toc] | [prev] | [next] | [standalone]

#92227

On Saturday, August 13, 2016 at 10:29:42 AM UTC-5, James R. Kuyper wrote:
> More plausibly, "The 64-bit integer we supply doesn't meet the 
> standard's requirements for int64_t, but we're going to typedef int64_t 
> to refer to it anyway, and we'll #define corresponding macros.". Real 
> implementations have done comparably annoying things in the past, so 
> explicitly prohibiting them from doing so has some value.

What would have even more value would be a means via which a program can
specify what its requirements are, so that a system which e.g. uses 9/18/36
integer types would be able to support code that requires unsigned integer
types that wrap mod 256, 65,536, or 4,294,967,296, but doesn't care about
padding bits (the generated code may not be as efficient as for types that
wrap mod 512, 262,144, or 68,719,476,736 but being able to run code which
isn't speed-critical without modification may be more useful than having to
modify code to make it work at all).

[toc] | [prev] | [next] | [standalone]

#92087

Ken Brody <kenbrody@spamcop.net> writes:
[...]
> Ah...  Obvious when you think about it.
>
> Section 7.18.2 (n1124).

Why are you still using n1124?  n1256 is a later and better draft of the
C99 standard (it includes the standard with all three Technical
Corrigenda merged into it), and n1570 is the most current draft of the
current C11 standard.

I've mentioned this to you before.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#92130

On 8/10/2016 1:13 PM, Keith Thompson wrote:
[...]
> Why are you still using n1124?  n1256 is a later and better draft of the
> C99 standard (it includes the standard with all three Technical
> Corrigenda merged into it), and n1570 is the most current draft of the
> current C11 standard.
>
> I've mentioned this to you before.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Old habits die hard?

I've grabbed the PDFs from the links you gave, and renamed n1124 out of the way.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#92022

On 8/5/2016 6:45 PM, Real Troll wrote:
>
> Does this look right for various basic data types:
>
>> Storage size for char : 1
>> Storage size for signed char : 1
>> Storage size for unsigned char : 1
>> Storage size for int : 4
>> Storage size for unsigned int : 4
>> Storage size for float : 4
>> Storage size for double : 8
>> Storage size for short : 2
>> Storage size for unsigned short : 2
>> Storage size for long : 4
>> Storage size for unsigned long : 4

As noted elsethread, except for the three "char" variants, which must be 1, 
the others can be virtually anything.  (The only restrictions are that some 
must be "at least" as large as something else -- such as "long" must be "at 
least" as big as "int".)

Note that, as far as C is concerned, all of the above could be "1".  (Given 
a sufficiently large CHAR_BITS.)

The numbers you see above are probably typical for a 32-bit system.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#92028

On 08/09/2016 12:59 PM, Ken Brody wrote:
> On 8/5/2016 6:45 PM, Real Troll wrote:
>>
>> Does this look right for various basic data types:
>>
>>> Storage size for char : 1
>>> Storage size for signed char : 1
>>> Storage size for unsigned char : 1
>>> Storage size for int : 4
>>> Storage size for unsigned int : 4
>>> Storage size for float : 4
>>> Storage size for double : 8
>>> Storage size for short : 2
>>> Storage size for unsigned short : 2
>>> Storage size for long : 4
>>> Storage size for unsigned long : 4
>
> As noted elsethread, except for the three "char" variants, which must be 1,
> the others can be virtually anything.  (The only restrictions are that some
> must be "at least" as large as something else -- such as "long" must be "at
> least" as big as "int".)

There's no such requirement. There is a requirement that "For any two 
integer types with the same signedness and different integer conversion 
rank (see 6.3.1.1), the range of values of the type with smaller integer 
conversion rank is a subrange of the values of the other type." 
(6.2.5p8), but it's entirely possible to meet that requirement while 
giving 'int' enough padding bits that it ends up being bigger than 
'long'. There's no good reason why anyone should give it that many 
padding bits, but no requirement imposed by the standard would be 
violated by an implementation that did so.

It does violate a requirement imposed by Jerry Stuckle, but his 
authority is far less widely acknowledged than that of ISO.

[toc] | [prev] | [next] | [standalone]

#92078

On 8/9/2016 1:49 PM, James R. Kuyper wrote:
> On 08/09/2016 12:59 PM, Ken Brody wrote:
[...]
>> As noted elsethread, except for the three "char" variants, which must be 1,
>> the others can be virtually anything.  (The only restrictions are that some
>> must be "at least" as large as something else -- such as "long" must be "at
>> least" as big as "int".)
>
> There's no such requirement. There is a requirement that "For any two
> integer types with the same signedness and different integer conversion rank
> (see 6.3.1.1), the range of values of the type with smaller integer
> conversion rank is a subrange of the values of the other type." (6.2.5p8),
> but it's entirely possible to meet that requirement while giving 'int'
> enough padding bits that it ends up being bigger than 'long'. There's no
> good reason why anyone should give it that many padding bits, but no
> requirement imposed by the standard would be violated by an implementation
> that did so.
[...]

I stand corrected.

(I haven't seen it mentioned in a while, but I think it was the "DS-9000" 
computer which implemented everything in the most non-optimal way allowed by 
the Standard?)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#92031

Ken Brody <kenbrody@spamcop.net> writes:
> On 8/5/2016 6:45 PM, Real Troll wrote:
>>
>> Does this look right for various basic data types:
>>
>>> Storage size for char : 1
>>> Storage size for signed char : 1
>>> Storage size for unsigned char : 1
>>> Storage size for int : 4
>>> Storage size for unsigned int : 4
>>> Storage size for float : 4
>>> Storage size for double : 8
>>> Storage size for short : 2
>>> Storage size for unsigned short : 2
>>> Storage size for long : 4
>>> Storage size for unsigned long : 4
>
> As noted elsethread, except for the three "char" variants, which must be 1, 
> the others can be virtually anything.  (The only restrictions are that some 
> must be "at least" as large as something else -- such as "long" must be "at 
> least" as big as "int".)

As discussed previously, the standard imposes requirements on
the ranges, not the sizes.  For example, the range of int must
be at least -32767..+32767, the range of long must be at least
-2147483647..+2147483647, and the range of int must be a subrange
of the range of long.  In the presence of an implausibly perverse
number of padding bits, sizeof (int) *could* exceed sizeof (long)
(by which I mean only that such an implementation would not violate
the standard).

> Note that, as far as C is concerned, all of the above could be "1".
> (Given a sufficiently large CHAR_BITS.)

Yes (except that it's CHAR_BIT).

> The numbers you see above are probably typical for a 32-bit system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web