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

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

Is this code considered to transgress the signed overflow purism?

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

Contents

  Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:13 -0700
    Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:41 -0700
    Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-27 11:59 +0100
      Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 14:35 -0700
        Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 15:13 -0700
          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:58 +0200
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 16:44 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:04 -0700
              Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 08:53 +0200
                Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:23 -0700
                  Re: Is this code considered to transgress the signed overflow purism? Manfred <noname@invalid.add> - 2017-04-28 18:05 +0200
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 09:22 -0700
                    Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 12:24 -0700
                      Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 00:03 +0100
                        Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 16:37 -0700
                          Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 17:09 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 17:34 -0700
                            Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 01:43 +0100
                              Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 21:21 -0700
                                Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-29 02:04 -0700
                                  Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:46 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 12:05 -0500
                                Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:33 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 08:26 -0700
                                    Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 17:58 +0200
                                      Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 09:13 -0700
                                        Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 12:55 +0200
                                          Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 09:17 -0700
                                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 20:35 +0200
                                              Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:39 -0700
                                                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-01 16:21 +0200
                                          Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-02 06:35 -0700
                                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-02 16:29 +0200
                                    Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 20:58 +0100
                  Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:43 +0200
              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 14:09 +0100
                Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 14:23 +0000
                  Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 16:17 +0100
                    Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 15:55 +0000
                    Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-28 19:11 -0700
                      Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:23 +0100
                      Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 11:31 +0100
                        Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 12:01 +0100
                          Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 12:47 +0100
                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:20 +0200
                              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 15:22 +0100
                                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 16:52 +0200
                            Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 15:18 +0100
                          Re: Is this code considered to transgress the signed overflow purism? Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-29 14:25 +0200
                      Re: Is this code considered to transgress the signed overflow purism? Jerry Stuckle <jstucklex@attglobal.net> - 2017-04-29 08:05 -0400
                        Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 13:34 +0100
                        Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-29 05:55 -0700
                          Re: Is this code considered to transgress the signed overflow purism? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 15:11 +0200
                          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:24 +0200
                          Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 14:57 +0100
                          Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 12:17 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-03 16:36 -0700
                        Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 11:26 -0700
                          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-03 21:40 +0200
                            Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 23:46 -0700
                Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:55 -0700
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:20 -0700
            Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:26 -0700
            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:19 +0200
              Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:57 -0400
                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 17:06 +0200
              Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:38 -0700
                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:51 +0200
              Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-29 12:43 -0700
                Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:02 -0700
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:25 -0700
                    Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 15:01 -0700
            Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:48 -0400
            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:07 -0700
              Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:56 +0200
                Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 11:30 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:35 -0700
        Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:54 +0200
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 21:05 -0700
            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:58 +0200
              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 10:50 +0100
            Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 10:01 -0400
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:06 -0700
        Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-28 23:57 +0100
        Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:28 -0700
          Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 12:41 -0700
            Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-30 21:46 +0100
              Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-01 05:41 -0700
                Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-01 13:57 +0100
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:30 -0700
                Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 16:13 +0100
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 09:12 -0700
                    Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 18:15 +0100
                      Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 11:26 -0700
                        Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 21:39 +0100
                          Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 13:53 -0700
                          Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 14:10 -0700
                            Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 22:36 +0100
                              Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 15:27 -0700
                              Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 00:45 -0500
                                Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 11:57 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 13:34 -0500
                                    Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-03 12:05 -0700
                                      Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:58 -0700
                              Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 05:26 -0700
                                Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-03 05:54 -0700
                                  Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:49 -0700
                                    Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:51 -0700
                              Re: Is this code considered to transgress the signed overflow purism? jadill33@gmail.com - 2017-05-03 09:03 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 14:47 -0700
                      Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 17:45 -0700
            Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:42 -0700
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 23:57 -0700
            Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 04:32 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 18:20 -0700
            Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-08 23:12 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-09 19:54 -0700
                Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-09 21:21 -0700
    Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:46 -0400
      Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 08:37 -0700
        Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 09:38 -0700
          Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 10:17 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 12:10 -0700
          Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 13:50 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:11 -0700
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:44 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 22:05 -0700

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#108648

On 28/04/2017 09:58, David Brown wrote:

> It /is/ an overflow, not a truncation.  Mathematically, left shift is
> multiplying by 2.

Only in binary. (I found that out when working in decimal.)

-- 
bartc

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

#108657

On 04/28/2017 12:05 AM, joel.rees@gmail.com wrote:
...
> But the last time I tried to use sizeof in a context that required 
> the expression to evaluate to a constant at compile time, the 
> compiler said I was being a naughty boy and would get no pudding that 
> day.

The relevant term is "Integer Constant Expression" (ICE). Unless the
argument of sizeof has a variably modified type, it always meets the
requirements to qualify as an ICE. Whatever problem it was that you ran
into, sizeof(unsigned long) wasn't the issue.

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

#109021

James Kuyper <jameskuyper@verizon.net> writes:

> On 04/28/2017 12:05 AM, joel.rees@gmail.com wrote:
> ...
>> But the last time I tried to use sizeof in a context that required
>> the expression to evaluate to a constant at compile time, the
>> compiler said I was being a naughty boy and would get no pudding that
>> day.
>
> The relevant term is "Integer Constant Expression" (ICE).  Unless the
> argument of sizeof has a variably modified type, it always meets the
> requirements to qualify as an ICE.  Whatever problem it was that you ran
> into, sizeof(unsigned long) wasn't the issue.

More precisely, unless the operand of sizeof is a variable length
array type (as distinguished from a variably modified type).  All
variable length array types are variably modified types, but not
all variably modified types are variable length array types.
Hence the distinction is important:  it is only variable length
array types that may require run-time evaluation as operands of
sizeof, and so such expressions are not compile-time constants
(ie, in the sense of "constant expressions" in C).

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

#108701

joel.rees@gmail.com writes:

> On Thursday, April 27, 2017 at 7:59:40 PM UTC+9, Ben Bacarisse wrote:
<snip>
>> Apart from the side effect on i this could be written as
>> 
>>   chMask = -1;
>> 
>> >    byteMask = chMask;
>> 
>> Or this could simply be
>> 
>>   byteMask = (unsigned char)-1;
<snip>
> We have this coddling of brain-damaged CPUs when a left-shift on a
> negative operand is specified on sign-magnitude architectures or
> something, but we have this assurance that casting a -1 to an unsigned
> fills the thing with ones.
<snip>
> And I have a hard time remembering that assurance is in the
> standard. Maybe it's because I don't really use sign-magnitude that
> much.

Sign+magnitude (and 1s complement) are *representations* for signed int,
but much of C is defined at a higher level.  What

  unsigned char c = -1;

means is defined in terms of *values*: the conversion is done by
repeatedly adding or subtracting one more than the maximum value of the
unsigned type to -1.  I.e. UCHAR_MAX+1 is added -1.

The same is true of shifts.  They are defined in terms of values rather
than by making reference to the representation (other than to the
width).

<snip>
-- 
Ben.

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

#108796

joel.rees@gmail.com writes:

> [some parts re-ordered for continuity]
>
> On Thursday, April 27, 2017 at 7:59:40 PM UTC+9, Ben Bacarisse wrote:
>> joel rees@somewhere writes:
>>
>>> ----------------
>>> unsigned byteWidth = 8; /* Not depending on limits.h . */
>>> unsigned byteMask = 0xFF;
>>> unsigned ulBytes = 4; /* Sane throw-away initial values. */
>>>
>>> void setULbytes( void )
>>> {  int i = 0;
>>>    unsigned char chroller = 1;
>>>    unsigned char chMask = 1;
>>>    unsigned long ulroller = 1;
>>>    while ( chroller != 0 )
>>>    {  chroller <<= 1;
>>>       chMask = ( chMask << 1 ) | 1;
>>>       ++i;
>>>    }
>>
>>>    byteWidth = i;
>>>    i = 0;
>>>    while ( ulroller != 0 )
>>>    {  ulroller <<= 1;
>>>       ++i;
>>>    }
>>>    ulBytes = i / byteWidth;
>>> }
>>
>> What's wrong with
>>
>>   ulBytes = sizeof (unsigned long);
>>
>> ?
>
> Well, since you ask, you're right.  Either way requires
> run-time behavior.

Do you mean the value produced cannot be used as part of a
pre-processor conditional?  The 'sizeof' method does
produce a compile-time constant, albeit one that cannot
be used as part of a pre-processor conditional.


>>> Yes, there is a reason I am ignoring limits.h.  Maybe not a
>>> good reason, but I will debate that later.
>>
>> I don't think you need limits.h for this.
>
> I wanted to be able to use limits.h for it.

Does that mean you weren't able to?  Can you explain why that
was?


> I really wish the standards committee had instead specified a
> means of compile-time testing the architecture for the specific
> corner- and edge-cases and providing a means to either pop up a
> warning to remind the reader of compiler output that the code
> wasn't intended to be compiled on that particular architecture, or
> use conditional compiled sections to deal with the corner-case on
> those CPUs.

If what you want is a regular compile-time constant (ie, but not
usable in a pre-processor conditional), that can be done with a
'sizeof' expression:

    enum { UL_SIZE = sizeof (unsigned long) };

For use in pre-processor conditionals, generally <limits.h> is
needed, because (a) sizeof doesn't work in #if etc, and (b)
even if it did, the sizes of types are potentially different in
the pre-processor than they are in the program.

If what you want is a value that can be used in a pre-processor
conditional, for the size of one of the integer types defined in
<limits.h> and/or <stdint.h>, and the headers in question are
available, these values can be calculated (making reasonable
assumptions) as illustrated in the following example:

    #include <limits.h>

    #define MASK_WIDTH( m ) ( 0U + (unsigned)+(        \
        (m)  /((m)%32767 +1)  /32767  %32767  *15      \
        +  (m)  %32767  /((m)%31 +1)  /31  %31  *5     \
        +  4  -  12 / ((m)%31 + 3)                     \
    ))

    #if  MASK_WIDTH( ULONG_MAX ) % CHAR_BIT == 0
    #define UL_SIZE_PP   (MASK_WIDTH( ULONG_MAX ) / CHAR_BIT)
    #else
    #error Apparently unsigned long has padding bits
    #endif

    #if UL_SIZE_PP == 4
        // unsigned long is 4 bytes
    #elif UL_SIZE_PP == 8
        // unsigned long is 8 bytes
    #else
        // huh?  unsigned long is neither 4 bytes nor 8 bytes
    #endif

(The assumption is that the number of padding bits is either
(a) zero, or (b) non-zero modulo the number of bits in an
unsigned char.)

If there isn't a <limits.h> available then you are pretty
much SOL.

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

#108797

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> For use in pre-processor conditionals, generally <limits.h> is
> needed, because (a) sizeof doesn't work in #if etc, and (b)
> even if it did, the sizes of types are potentially different in
> the pre-processor than they are in the program.

I'm not sure how meaningful your point (b) is.  *If* the preprocessor
were modified to permit sizeof, then it would be reasonable to
require that for example sizeof (long) must reflect the size of
type long on the target system.  In fact, I'd say it would be
unreasonable not to require that.  (In reality, the preprocessor
treats integer expressions as if they were of type intmax_t or
uintmax_t.  N1570 6.10.1p4.)

That reminds me of a discussion on comp.std.c back in 1998.  The
relevant quotation:

| > You are right.  It was nice back in the days when things like
| > 
| > #if (sizeof(int) == 8)
| > 
| > actually worked (on some compilers).
| 
| Must have been before my time.
| 
|      Dennis

Yes, the poster was Dennis Ritchie.

-- 
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]

#108804

On 30/04/2017 20:41, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
> I'm not sure how meaningful your point (b) is.  *If* the preprocessor
> were modified to permit sizeof, then it would be reasonable to
> require that for example sizeof (long) must reflect the size of
> type long on the target system.  In fact, I'd say it would be
> unreasonable not to require that.  (In reality, the preprocessor
> treats integer expressions as if they were of type intmax_t or
> uintmax_t.  N1570 6.10.1p4.)
>
> That reminds me of a discussion on comp.std.c back in 1998.  The
> relevant quotation:
>
> | > You are right.  It was nice back in the days when things like
> | >
> | > #if (sizeof(int) == 8)
> | >
> | > actually worked (on some compilers).
> |

I tried it on my toy compiler. Only a light treatment so the type must 
be a single name like 'int' (otherwise the tokeniser needs to know and 
duplicate type-decl syntax). Then this was possible:

#if sizeof(int)==8
     #message "sizeof(int) == 8"
#else
     #message "sizeof(int) != 8"
#endif

('#message' is a debugging feature.)

Not a proposed extension, I just wanted to know how hard it was. Not 
very. (Not when the preprocessor is an integrated part of the compiler.)

 >> For use in pre-processor conditionals, generally <limits.h> is
 >> needed, because (a) sizeof doesn't work in #if etc, and (b)
 >> even if it did, the sizes of types are potentially different in
 >> the pre-processor than they are in the program.

Under what circumstances? (Such a feature would mainly be used on the 
primitive types.)


-- 
bartc

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

#108861

On Sunday, April 30, 2017 at 5:46:23 PM UTC-3, Bart wrote:
> On 30/04/2017 20:41, Keith Thompson wrote:
> > Tim Rentsch writes:
> > [...]
> > I'm not sure how meaningful your point (b) is.  *If* the preprocessor
> > were modified to permit sizeof, then it would be reasonable to
> > require that for example sizeof (long) must reflect the size of
> > type long on the target system.  In fact, I'd say it would be
> > unreasonable not to require that.  (In reality, the preprocessor
> > treats integer expressions as if they were of type intmax_t or
> > uintmax_t.  N1570 6.10.1p4.)
> >
> > That reminds me of a discussion on comp.std.c back in 1998.  The
> > relevant quotation:
> >
> > | > You are right.  It was nice back in the days when things like
> > | >
> > | > #if (sizeof(int) == 8)
> > | >
> > | > actually worked (on some compilers).
> > |
> 
> I tried it on my toy compiler. Only a light treatment so the type must 
> be a single name like 'int' (otherwise the tokeniser needs to know and 
> duplicate type-decl syntax). Then this was possible:
> 
> #if sizeof(int)==8
>      #message "sizeof(int) == 8"
> #else
>      #message "sizeof(int) != 8"
> #endif
> 

If the preprocessor is integrated (have access to the symbols) 
then this sample and more is possible.

The way I have the preprocessor in my C parser can access the AST (build so far).

I could do this:
#if symbol_defined MyFunc || symbol_defined MyVar 
#endif

(I liked #message option)

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

#108863

On 01/05/2017 13:41, Thiago Adams wrote:
> On Sunday, April 30, 2017 at 5:46:23 PM UTC-3, Bart wrote:

>> #if sizeof(int)==8

> If the preprocessor is integrated (have access to the symbols)
> then this sample and more is possible.
>
> The way I have the preprocessor in my C parser can access the AST (build so far).
>
> I could do this:
> #if symbol_defined MyFunc || symbol_defined MyVar
> #endif

That might be harder, depending on exactly what symbol_defined does.

The problem is that MyFunc and Myvar can have multiple instances 
throughout the program. They might be defined, but not visible (be in a 
different scope) from the place where you do '#if symbol_defined'.

Understanding blocks and scopes and doing name-resolution is beyond what 
a tokeniser can and ought to do, I think. (Maybe a job for your 
parser-level conditional code.)

If the case of 'sizeof', the 'int' is treated as a reserved word 
independent of scope. ('int' can be #defined, but the replacement text 
is then used for sizeof.)

-- 
bartc

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

#109024

bartc <bc@freeuk.com> writes:

> On 30/04/2017 20:41, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>
>>> For use in pre-processor conditionals, generally <limits.h> is
>>> needed, because (a) sizeof doesn't work in #if etc, and (b)
>>> even if it did, the sizes of types are potentially different in
>>> the pre-processor than they are in the program.
>
> Under what circumstances?  (Such a feature would mainly be used
> on the primitive types.)

Try running the following program (ie, on a 32-bit platform).

    #include <stdio.h>

    int
    main(){
        if(  -1U == 0xFFFFFFFF  ){
            printf( "  unsigned is 32 bits\n" );
        } else {
            printf( "  unsigned is NOT 32 bits\n" );
        }

        #if  -1U == 0xFFFFFFFF
            printf( "  unsigned in pre-processor is 32 bits\n" );
        #else
            printf( "  unsigned in pre-processor is NOT 32 bits\n" );
        #endif

        return  0;
    }

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

#109029

On 02/05/2017 13:30, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>
>> On 30/04/2017 20:41, Keith Thompson wrote:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>
>>>> For use in pre-processor conditionals, generally <limits.h> is
>>>> needed, because (a) sizeof doesn't work in #if etc, and (b)
>>>> even if it did, the sizes of types are potentially different in
>>>> the pre-processor than they are in the program.
>>
>> Under what circumstances?  (Such a feature would mainly be used
>> on the primitive types.)
>
> Try running the following program (ie, on a 32-bit platform).
>
>     #include <stdio.h>
>
>     int
>     main(){
>         if(  -1U == 0xFFFFFFFF  ){
>             printf( "  unsigned is 32 bits\n" );
>         } else {
>             printf( "  unsigned is NOT 32 bits\n" );
>         }
>
>         #if  -1U == 0xFFFFFFFF
>             printf( "  unsigned in pre-processor is 32 bits\n" );
>         #else
>             printf( "  unsigned in pre-processor is NOT 32 bits\n" );
>         #endif
>
>         return  0;
>     }

What's supposed to be the correct output?

Out of 5 C compilers, two say is/is NOT, three say is/is. (And actually 
the four that also work in 64 bits, give the same results in 64 bits.)

(Mine [64-bits] says is/is NOT, after it was tweaked to pay to take 
notice of suffixes such as U and LL which it previously ignored.)

(BTW what is the type of 0xFFFFFFFF ? My reading of the standard 
suggests it is long long int, ie. 0x00000000FFFFFFFF.

While the 1U is 32-bit 0x00000001 unsigned, negated to 0xFFFFFFFF, then 
widened to 0x00000000FFFFFFFF to match the rhs. The latter is converted 
to unsigned because of the mixed operation. So the comparison is done in 
64 bits. But I might be wrong...)


Anyway, I don't think this is related to whether or not a specific type, 
rather than an evaluation of an expression, might be different at in the 
preprocessor.

-- 
bartc

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

#109030

bartc <bc@freeuk.com> writes:
> On 02/05/2017 13:30, Tim Rentsch wrote:
[...]
>> Try running the following program (ie, on a 32-bit platform).
>>
>>     #include <stdio.h>
>>
>>     int
>>     main(){
>>         if(  -1U == 0xFFFFFFFF  ){
>>             printf( "  unsigned is 32 bits\n" );
>>         } else {
>>             printf( "  unsigned is NOT 32 bits\n" );
>>         }
>>
>>         #if  -1U == 0xFFFFFFFF
>>             printf( "  unsigned in pre-processor is 32 bits\n" );
>>         #else
>>             printf( "  unsigned in pre-processor is NOT 32 bits\n" );
>>         #endif
>>
>>         return  0;
>>     }
>
> What's supposed to be the correct output?

It should be

  unsigned is 32 bits
  unsigned in pre-processor is NOT 32 bits

> Out of 5 C compilers, two say is/is NOT, three say is/is. (And actually 
> the four that also work in 64 bits, give the same results in 64 bits.)

It seems you have three non-conforming compilers.

N1570 6.10.1p4:

    For the purposes of this token conversion and evaluation, all
    signed integer types and all unsigned integer types act as if
    they have the same representation as, respectively, the types
    intmax_t and uintmax_t defined in the header <stdint.h>.

intmax_t and uintmax_t must be at least 64 bits.

> (Mine [64-bits] says is/is NOT, after it was tweaked to pay to take 
> notice of suffixes such as U and LL which it previously ignored.)
>
> (BTW what is the type of 0xFFFFFFFF ? My reading of the standard 
> suggests it is long long int, ie. 0x00000000FFFFFFFF.

The type of an unsuffixed hexadecimal integer constant is the first of
    int
    unsigned int
    long int
    unsigned long int
    long long int
    unsigned long long int
in which its value fits.  Since unsigned long int is at least 32 bits,
it can't long long int or unsigned long long int.  If int is 32 bits,
then the type of 0xFFFFFFFF is unsigned int.

In a preprocessor expression, unsigned int acts like uintmax_t (probably
64 bits).

> While the 1U is 32-bit 0x00000001 unsigned, negated to 0xFFFFFFFF, then 
> widened to 0x00000000FFFFFFFF to match the rhs. The latter is converted 
> to unsigned because of the mixed operation. So the comparison is done in 
> 64 bits. But I might be wrong...)

See above.  In a non-preprocessor expression, it's not widened, since
0xFFFFFFFF is (probably) of type unsigned int.  In a preprocessor
expression, it's not widened because it's already 64 bits.

> Anyway, I don't think this is related to whether or not a specific type, 
> rather than an evaluation of an expression, might be different at in the 
> preprocessor.

It is.

-- 
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]

#109033

On 02/05/2017 17:12, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> Anyway, I don't think this is related to whether or not a specific type,
>> rather than an evaluation of an expression, might be different in the
>> preprocessor.
>
> It is.

How?

For preprocessor expressions used in #if, the PP just uses the maximum 
int width available, which appears to be long long or 64 bits even when 
the compiler has a 32-bit target and 32-bit ints.

But I don't think the type of expressions used in #if is anything to do 
with the types normally used in the code. Unless someone specifically 
wants to make use of intmax_t.

Even then, I can't see how that can be different between preprocessor 
and the rest of the compiler, unless someone deliberately redefines 
intmax_t. Which they can do for any type, whether the preprocessor is 
involved or not.

-- 
bartc

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

#109040

bartc <bc@freeuk.com> writes:
> On 02/05/2017 17:12, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> Anyway, I don't think this is related to whether or not a specific type,
>>> rather than an evaluation of an expression, might be different in the
>>> preprocessor.
>>
>> It is.
>
> How?

In an ordinary expression, the constant 1U, for example, is of type
unsigned int, which might commonly be 32 bits.

In a preprocessor expression, it's still logically of type unsigned
int, but the type unsigned int is treated as if it had the same
size and representation as uintmax_t, which is commonly 64 bits.

One consequence is that the expression -1U likely has a different
value depending on whether or not it's part of a preprocessor
expression.

I frankly don't understand your question well enough to be sure
that I've answered it, but in any case I think you have enough
information to answer it yourself.

[...]

-- 
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]

#109052

On 02/05/2017 19:26, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 02/05/2017 17:12, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>>>> Anyway, I don't think this is related to whether or not a specific type,
>>>> rather than an evaluation of an expression, might be different in the
>>>> preprocessor.
>>>
>>> It is.
>>
>> How?
>
> In an ordinary expression, the constant 1U, for example, is of type
> unsigned int, which might commonly be 32 bits.
>
> In a preprocessor expression, it's still logically of type unsigned
> int, but the type unsigned int is treated as if it had the same
> size and representation as uintmax_t, which is commonly 64 bits.
>
> One consequence is that the expression -1U likely has a different
> value depending on whether or not it's part of a preprocessor
> expression.

> I frankly don't understand your question well enough to be sure
> that I've answered it, but in any case I think you have enough
> information to answer it yourself.

Wasn't this about being able to use sizeof() in a preprocessor 
expression? Then it would necessarily have to be applied to a type, not 
an arbitrary expression, otherwise the PP would have to duplicate the 
full expression parsing and type processing done in the later stages, 
plus employ the same name resolving algorithms.

It won't work.

On the other hand, I can't see why sizeof can't be applied to a basic 
type, to quickly establish whether an int is 2, 4 or 8 bytes, without 
messing around with ranges and relying on comparing INT_MAX etc against 
limits.

However, it was suggested that such a type might give a different sizeof 
result in a PP expression, compared with a normal expression. That's why 
I asked for an example.

-- 
bartc

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

#109055

On Tuesday, May 2, 2017 at 3:39:00 PM UTC-5, Bart wrote:
> Wasn't this about being able to use sizeof() in a preprocessor 
> expression? Then it would necessarily have to be applied to a type, not 
> an arbitrary expression, otherwise the PP would have to duplicate the 
> full expression parsing and type processing done in the later stages, 
> plus employ the same name resolving algorithms.
> 
> It won't work.

Some compilers integrate the preprocessor into the compiler as a whole; it
may be easier for them to use essentially the same expression-evaluation code
for preprocessor expressions as other kinds, in which case the preprocessor
would be able to handle just about any kinds of expressions the main compiler
could handle, save for those which are expressly disabled as a consequence of
an "evaluating a preprocessor expression" flag.

The Standard deliberately doesn't require that compilers work that way, but
for some purposes it might be helpful to recognize a category of compilers
that do so.

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

#109056

bartc <bc@freeuk.com> writes:
[...]
> Wasn't this about being able to use sizeof() in a preprocessor 
> expression?

That was part of the discussion, yes.

>             Then it would necessarily have to be applied to a type, not 
> an arbitrary expression, otherwise the PP would have to duplicate the 
> full expression parsing and type processing done in the later stages, 
> plus employ the same name resolving algorithms.
>
> It won't work.
>
> On the other hand, I can't see why sizeof can't be applied to a basic 
> type, to quickly establish whether an int is 2, 4 or 8 bytes, without 
> messing around with ranges and relying on comparing INT_MAX etc against 
> limits.

It could be.  It isn't.

> However, it was suggested that such a type might give a different sizeof 
> result in a PP expression, compared with a normal expression. That's why 
> I asked for an example.

Which I gave you.  1U is of type unsigned int.  In a typical
implementation, unsigned int might be 4 bytes, but it would be
treated by the preprocessor as if it were 8 bytes.

The simplest enhancement of the preprocessor to handle
`sizeof (unsigned int)` would have it yield 8 -- which would not
be useful.

To make it useful, you'd have to make the preprocessor aware that
unsigned int has a size of 4 bytes on the target system, overriding
the current wording of 6.10.1p4.  You'd also need to define a
somewhat arbitrary division between types that are "basic" enough
for the preprocessor to know their sizes, and types that aren't.
You'd want to recognize typedefs, so `sizeof (size_t)` would work,
but for an implementation where char* and struct* have different
sizes, expecting the preprocessor to recognize `sizeof (FOO)`
as the size of a structure type seems a bit much.

A much less complicated solution would be to add some predefined
macros to <limits.h>, such as _SIZEOF_INT, _SIZEOF_LONG, etc.,
and probably some similar macros in <stdint.h>.

I don't recall that I've ever needed such macros myself, but if
they're sufficiently useful I wouldn't object to adding them in a
future standard.

-- 
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]

#109058

On 02/05/2017 22:10, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:


>> However, it was suggested that such a type might give a different sizeof
>> result in a PP expression, compared with a normal expression. That's why
>> I asked for an example.
>
> Which I gave you.  1U is of type unsigned int.  In a typical
> implementation, unsigned int might be 4 bytes, but it would be
> treated by the preprocessor as if it were 8 bytes.
>
> The simplest enhancement of the preprocessor to handle
> `sizeof (unsigned int)` would have it yield 8 -- which would not
> be useful.

We might be talking at cross purposes.

The preprocessor is one thing; the parser and rest of the compiler is 
another.

How the preprocessors deals with #if expressions, and what type they 
might have is its own business.

But when you ask it to evaluate sizeof(int) (in a possible extension), 
then that would necessarily have to be the size of the int used in the 
rest of the compiler.

As an illustration, what should be the sizeof() return here:

  #if sizeof(float)==4

The preprocessor doesn't do floating point; this would only be 
meaningful and useful for the 'float' type used in the rest of the 
compiler. The same with int types.

I would expect them to be coupled closely enough that the preprocessor 
can access the sizes of the standard, built-in types.

> To make it useful, you'd have to make the preprocessor aware that
> unsigned int has a size of 4 bytes on the target system, overriding
> the current wording of 6.10.1p4.  You'd also need to define a
> somewhat arbitrary division between types that are "basic" enough
> for the preprocessor to know their sizes, and types that aren't.
> You'd want to recognize typedefs, so `sizeof (size_t)` would work,

size_t are harder because typedefs can exist in different scopes. You 
don't want to PP to need to know C's block scope rules, otherwise you'd 
be writing a back-to-front compiler.

That's a problem with the language that size_t types have just been 
bolted on as a set of macros. But anyway, with size_t, usually the name 
of the type gives a clue to the size!

> I don't recall that I've ever needed such macros myself, but if
> they're sufficiently useful I wouldn't object to adding them in a
> future standard.

I've needed to know the size of a pointer. The size of an int tends to 
be 4, but long can be variable so that can be useful to know too.

-- 
bartc

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

#109062

bartc <bc@freeuk.com> writes:
> On 02/05/2017 22:10, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> However, it was suggested that such a type might give a different sizeof
>>> result in a PP expression, compared with a normal expression. That's why
>>> I asked for an example.
>>
>> Which I gave you.  1U is of type unsigned int.  In a typical
>> implementation, unsigned int might be 4 bytes, but it would be
>> treated by the preprocessor as if it were 8 bytes.
>>
>> The simplest enhancement of the preprocessor to handle
>> `sizeof (unsigned int)` would have it yield 8 -- which would not
>> be useful.
>
> We might be talking at cross purposes.

I don't believe we are.

> The preprocessor is one thing; the parser and rest of the compiler is 
> another.

Certainly.

> How the preprocessors deals with #if expressions, and what type they 
> might have is its own business.
>
> But when you ask it to evaluate sizeof(int) (in a possible extension), 
> then that would necessarily have to be the size of the int used in the 
> rest of the compiler.

As I acknowledged upthread (and you snipped):

    To make it useful, you'd have to make the preprocessor aware that
    unsigned int has a size of 4 bytes on the target system, overriding
    the current wording of 6.10.1p4.

> As an illustration, what should be the sizeof() return here:
>
>   #if sizeof(float)==4

For that construct to be at all useful, of course sizeof(float) should
yield the same value that it yields in a non-preprocessor expression.
The difficulty of rigorously defining that and then implementing it is
probably why C doesn't currently define such a feature.

[...]

-- 
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]

#109086

On Tue, 2 May 2017 22:36:43 +0100, bartc <bc@freeuk.com> wrote:

>On 02/05/2017 22:10, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>
>>> However, it was suggested that such a type might give a different sizeof
>>> result in a PP expression, compared with a normal expression. That's why
>>> I asked for an example.
>>
>> Which I gave you.  1U is of type unsigned int.  In a typical
>> implementation, unsigned int might be 4 bytes, but it would be
>> treated by the preprocessor as if it were 8 bytes.
>>
>> The simplest enhancement of the preprocessor to handle
>> `sizeof (unsigned int)` would have it yield 8 -- which would not
>> be useful.
>
>We might be talking at cross purposes.
>
>The preprocessor is one thing; the parser and rest of the compiler is 
>another.
>
>How the preprocessors deals with #if expressions, and what type they 
>might have is its own business.
>
>But when you ask it to evaluate sizeof(int) (in a possible extension), 
>then that would necessarily have to be the size of the int used in the 
>rest of the compiler.
>
>As an illustration, what should be the sizeof() return here:
>
>  #if sizeof(float)==4
>
>The preprocessor doesn't do floating point; this would only be 
>meaningful and useful for the 'float' type used in the rest of the 
>compiler. The same with int types.
>
>I would expect them to be coupled closely enough that the preprocessor 
>can access the sizes of the standard, built-in types.
>
>> To make it useful, you'd have to make the preprocessor aware that
>> unsigned int has a size of 4 bytes on the target system, overriding
>> the current wording of 6.10.1p4.  You'd also need to define a
>> somewhat arbitrary division between types that are "basic" enough
>> for the preprocessor to know their sizes, and types that aren't.
>> You'd want to recognize typedefs, so `sizeof (size_t)` would work,
>
>size_t are harder because typedefs can exist in different scopes. You 
>don't want to PP to need to know C's block scope rules, otherwise you'd 
>be writing a back-to-front compiler.
>
>That's a problem with the language that size_t types have just been 
>bolted on as a set of macros. But anyway, with size_t, usually the name 
>of the type gives a clue to the size!
>
>> I don't recall that I've ever needed such macros myself, but if
>> they're sufficiently useful I wouldn't object to adding them in a
>> future standard.
>
>I've needed to know the size of a pointer. The size of an int tends to 
>be 4, but long can be variable so that can be useful to know too.


Couldn't most or all of that be done more simply with some predefined
macros?  Or ones defined in stdint.h and such?

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

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

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

csiph-web