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 1 of 7  [1] 2 3 4 5 6 7  Next page →

#108589 — Is this code considered to transgress the signed overflow purism?

----------------
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;
   }
   byteMask = chMask;
   byteWidth = i;
   i = 0;
   while ( ulroller != 0 )
   {  ulroller <<= 1;
      ++i;
   }
   ulBytes = i / byteWidth;
}
----------------

Yes, there is a reason I am ignoring limits.h. Maybe not a good reason, but I will debate that later.

Right now I just would like to hear whether shifting unsigned values until the bits are supposed to disappear, and testing them for zero, is considered in the range of machine-defined stuff that the current crop of optimization sophomores (pardon my Latin) conflates with undefined. 

Or did I walk off the world when I shifted one too far and filled the unsigned char with ones and it overflowed? (I'll look at that some more now.)

--
Joel Rees

[toc] | [next] | [standalone]

#108591

Never mind. I realized I was just never calling setULbytes(). (And that is completely defined behavior in this case. Heh.)

On Thursday, April 27, 2017 at 7:13:52 PM UTC+9, joel...@gmail.com wrote:
> ----------------
> 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;
>    }
>    byteMask = chMask;
>    byteWidth = i;
>    i = 0;
>    while ( ulroller != 0 )
>    {  ulroller <<= 1;
>       ++i;
>    }
>    ulBytes = i / byteWidth;
> }
> ----------------
> 
> Yes, there is a reason I am ignoring limits.h. Maybe not a good reason, but I will debate that later.
> 
> Right now I just would like to hear whether shifting unsigned values until the bits are supposed to disappear, and testing them for zero, is considered in the range of machine-defined stuff that the current crop of optimization sophomores (pardon my Latin) conflates with undefined. 
> 
> Or did I walk off the world when I shifted one too far and filled the unsigned char with ones and it overflowed? (I'll look at that some more now.)
> 
> --
> Joel Rees

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

#108593

joel.rees@gmail.com 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;
>    }

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;

>    byteWidth = i;
>    i = 0;
>    while ( ulroller != 0 )
>    {  ulroller <<= 1;
>       ++i;
>    }
>    ulBytes = i / byteWidth;

What's wrong with

  ulBytes = sizeof (unsigned long);

?

> }
> ----------------
>
> 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.

> Right now I just would like to hear whether shifting unsigned values
> until the bits are supposed to disappear, and testing them for zero,
> is considered in the range of machine-defined stuff that the current
> crop of optimization sophomores (pardon my Latin) conflates with
> undefined.

Shifting unsigned values is well-defined provided the shift is (a)
positive and (b) less the the type's width.  Your shift, 1, is always
fine.  But, you are *not* shifting unsigned values in the first loop!
unsigned char promotes to (signed) int so you are shifting a positive
signed value by 1.  That is also fine provided the result can be
represented as a signed int.  Unless you have a very odd architecture,
the loop will stop before that can happen.  So again, fine.

> Or did I walk off the world when I shifted one too far and filled the
> unsigned char with ones and it overflowed? (I'll look at that some
> more now.)

Just assign -1.  When -1 is assigned to the unsigned char (or you use a
cast since the unsigned char variable is not really needed anymore) the
result is reduced modulo one more than the maximum value that can be
represented.

-- 
Ben.

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

#108629

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;
> >    }
> 
> 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;

You know, it's funny.

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.

(I know calling it brain-damaged is too extreme, but ...)

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.

The standards committee gets to tilt at windmills, and I get to chase their rainbows. 

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.

A few more hours of their work to help a thousand guys like me to cut a few wasted days off of tilting with our own windmills every now and again.

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

> > }
> > ----------------
> >
> > 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.

> > Right now I just would like to hear whether shifting unsigned values
> > until the bits are supposed to disappear, and testing them for zero,
> > is considered in the range of machine-defined stuff that the current
> > crop of optimization sophomores (pardon my Latin) conflates with
> > undefined.
> 
> Shifting unsigned values is well-defined provided the shift is (a)
> positive and (b) less the the type's width.  Your shift, 1, is always
> fine.  But, you are *not* shifting unsigned values in the first loop!
> unsigned char promotes to (signed) int so you are shifting a positive
> signed value by 1. 

Unsigned char promoted to signed int?

That explains what I was fussing with so long ago when I made two different implementations of ctype for shift-JIS characters.

> That is also fine provided the result can be
> represented as a signed int.  Unless you have a very odd architecture,
> the loop will stop before that can happen.  So again, fine.

Yeah, char should have been called byte so that they could call real character types char.

> > Or did I walk off the world when I shifted one too far and filled the
> > unsigned char with ones and it overflowed? (I'll look at that some
> > more now.)
> 
> Just assign -1.  When -1 is assigned to the unsigned char (or you use a
> cast since the unsigned char variable is not really needed anymore) the
> result is reduced modulo one more than the maximum value that can be
> represented.
> 
> -- 
> Ben.

Thanks for walking me through this. 

--
Joel Rees

Chasing windmills and tilting at rainbows
http://defining-computers.blogspot.com/2017/04/lsb-1st-vs-msb-1st-ignore-gulliver.html

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

#108630

joel.rees@gmail.com writes:
[...]
> 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.
>
> (I know calling it brain-damaged is too extreme, but ...)

I suggest you might benefit from describing these things in less
inflammatory terms.

The behavor of left-shifting a negative value is undefined.
This is specified in N1570 6.5.7p4.

(I don't recall that I've ever felt the need to left-shift a negative
integer.)

The behavior of converting an integer (either signed or unsigned) value
to an unsigned type is well defined; the result is adjusted modulo
MAX+1, where MAX is the maximum value of the unsigned type.  This is
described in N1570 6.3.1.3p2.

(N1570 is the latest publicly available draft of the ISO C standard,
available at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf .)

[...]

> Unsigned char promoted to signed int?

Yes.  The promotion rules are in N1570 6.3.1.1p2.  The idea is that
there are no arithmetic operations on types narrower than int or
unsigned int, so anything narrower must be "promoted" before you can
operate on it.

    If an int can represent all values of the original type (as
    restricted by the width, for a bit-field), the value is converted to
    an int; otherwise, it is converted to an unsigned int. These are
    called the *integer promotions*.

The 1989 ANSI C committee had to choose between two schemes, both
implemented by existing compilers at the time: "unsigned preserving" and
"value preserving".  They chose the latter.  (I think I would have
preferred unsigned preserving semantics myself, but I haven't taken the
time to think about possible disadvantages.)  This is discussed in the
C99 Rationale, section 6.3.1.1, available at
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.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]

#108632

On 28/04/17 00:13, Keith Thompson wrote:
> joel.rees@gmail.com writes:
> [...]
>> 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.
>>
>> (I know calling it brain-damaged is too extreme, but ...)
>
> I suggest you might benefit from describing these things in less
> inflammatory terms.
>
> The behavor of left-shifting a negative value is undefined.
> This is specified in N1570 6.5.7p4.
>
> (I don't recall that I've ever felt the need to left-shift a negative
> integer.)
>

I don't remember ever wanting to shift a signed integer, left or right, 
except perhaps an integer constant (such as "1 << 12") without bothering 
to add the "u" suffix.  Bit manipulation, such as shifts and logical bit 
operations, are usually most natural on unsigned types in my experience.

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

#108634

David Brown <david.brown@hesbynett.no> writes:
> On 28/04/17 00:13, Keith Thompson wrote:
>> joel.rees@gmail.com writes:
>> [...]
>>> 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.
>>>
>>> (I know calling it brain-damaged is too extreme, but ...)
>>
>> I suggest you might benefit from describing these things in less
>> inflammatory terms.
>>
>> The behavor of left-shifting a negative value is undefined.
>> This is specified in N1570 6.5.7p4.
>>
>> (I don't recall that I've ever felt the need to left-shift a negative
>> integer.)
>
> I don't remember ever wanting to shift a signed integer, left or right, 
> except perhaps an integer constant (such as "1 << 12") without bothering 
> to add the "u" suffix.  Bit manipulation, such as shifts and logical bit 
> operations, are usually most natural on unsigned types in my experience.

It can be tempting to use "<<" as a replacement for multiplying by
a power of 2.  For example, one might write `n << 3` rather than
`n * 8`.  But it's UB if n is negative -- and it's usually better
to write `n * 8` and let the compiler figure out whether it makes
sense to use a shift instruction.  (Using shifts for multiplications
by powers of 2 is an old trick, appropriate for old compilers that
didn't do that kind of optimization.)

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

#108640

On Friday, April 28, 2017 at 9:01:16 AM UTC+9, Keith Thompson wrote:
> David Brown <> writes:
> > On 28/04/17 00:13, Keith Thompson wrote:
> >> joel rees@somewhere writes:
> >> [...]
> >>> 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.
> >>>
> >>> (I know calling it brain-damaged is too extreme, but ...)
> >>
> >> I suggest you might benefit from describing these things in less
> >> inflammatory terms.
> >>
> >> The behavor of left-shifting a negative value is undefined.
> >> This is specified in N1570 6.5.7p4.
> >>
> >> (I don't recall that I've ever felt the need to left-shift a negative
> >> integer.)
> >
> > I don't remember ever wanting to shift a signed integer, left or right, 
> > except perhaps an integer constant (such as "1 << 12") without bothering 
> > to add the "u" suffix.  Bit manipulation, such as shifts and logical bit 
> > operations, are usually most natural on unsigned types in my experience.
> 
> It can be tempting to use "<<" as a replacement for multiplying by
> a power of 2.  For example, one might write `n << 3` rather than
> `n * 8`.  But it's UB if n is negative -- and it's usually better
> to write `n * 8` and let the compiler figure out whether it makes
> sense to use a shift instruction.  (Using shifts for multiplications
> by powers of 2 is an old trick, appropriate for old compilers that
> didn't do that kind of optimization.)

"Old" is such a relative term.

Particularly when you're bootstrapping a compiler for a new architecture.

Ideally, no. But practically, yes. Sometimes you develop new things without the budget for the latest/greatest, hoping to cover the lack of budget by shortening your expected lifetime with planned unplanned overtime.

But, of course, the standard does not have to be adhered to when building bootstrapping compilers, you just have to get comfortable with the idea that you'll be writing a lot of throwaway code. 

Which is also not really a big deal, especially considering all the bad novels that get written/published. (And bad blog posts and wasted flame wars on newsgroups, ... :-/)

--
Joel Rees

Delusions of being a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html

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

#108645

On 28/04/17 01:44, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/04/17 00:13, Keith Thompson wrote:
>>> joel.rees@gmail.com writes:
>>> [...]
>>>> 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.
>>>>
>>>> (I know calling it brain-damaged is too extreme, but ...)
>>>
>>> I suggest you might benefit from describing these things in less
>>> inflammatory terms.
>>>
>>> The behavor of left-shifting a negative value is undefined.
>>> This is specified in N1570 6.5.7p4.
>>>
>>> (I don't recall that I've ever felt the need to left-shift a negative
>>> integer.)
>>
>> I don't remember ever wanting to shift a signed integer, left or right, 
>> except perhaps an integer constant (such as "1 << 12") without bothering 
>> to add the "u" suffix.  Bit manipulation, such as shifts and logical bit 
>> operations, are usually most natural on unsigned types in my experience.
> 
> It can be tempting to use "<<" as a replacement for multiplying by
> a power of 2.  For example, one might write `n << 3` rather than
> `n * 8`.  But it's UB if n is negative -- and it's usually better
> to write `n * 8` and let the compiler figure out whether it makes
> sense to use a shift instruction.  (Using shifts for multiplications
> by powers of 2 is an old trick, appropriate for old compilers that
> didn't do that kind of optimization.)
> 

I used to work with compilers that did little in the way of
optimisation, and would do this kind of "hand optimisation".  Such tools
were usually for small microcontrollers which may not have things like a
multiply instruction - "(x << 2) + x" could be significantly faster than
"x * 5".  Almost certainly, "x" would have been an unsigned type in such
cases - usually uint8_t (even if I had to define that type myself
because the compiler had no <stdint.h>).

These days, if I want to multiply n by 8 I write "n * 8" - and let the
compiler figure out the code.

And if I want to multiply n by 2^17, I write "n * (1u << 17)" or "n *
0x20000" rather than "n << 17".  I only write "n << 17" if I want to
shift n left 17 bits.  Some people might find the distinction odd -
after all, the result (both mathematically and in generated code) is the
same.  But my emphasis is on the logic and meaning of the code - in one
case, I am thinking about scaling a number, and in the other case I am
thinking of moving bitfields within a bit string.

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

#108664

On Friday, April 28, 2017 at 1:53:53 AM UTC-5, David Brown wrote:
> I used to work with compilers that did little in the way of
> optimisation, and would do this kind of "hand optimisation".  Such tools
> were usually for small microcontrollers which may not have things like a
> multiply instruction - "(x << 2) + x" could be significantly faster than
> "x * 5".  Almost certainly, "x" would have been an unsigned type in such
> cases - usually uint8_t (even if I had to define that type myself
> because the compiler had no <stdint.h>).

For multiplication by a constant, I generally prefer to use multiplication
operator since compilers can pretty consistently figure that out.  If the
scale factor will always be a power of two, but *which* power of two may
vary, and if there's no need to even think about running the code on any
machine that doesn't use two's-complement math, I would regard x<<y as
being clearer than x*(1<<y).  Note that the former has a define case where
the latter doesn't, and on implementations which don't go out of their way
not to expose useful platform behavior it doesn't require knowing the type
of y.

Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely
on platforms that also handle C++, as C++ would require such behavior),
then if "x" is "long long", then a compiler would likely have to generate
code for x*(1<<y) that was equivalent to (y!=31) ? x<<y : -(x<<y), which
would almost certainly be less efficient than x<<y.

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

#108669

On 4/28/2017 5:23 PM, supercat@casperkitty.com wrote:
> Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely
> on platforms that also handle C++, as C++ would require such behavior),
hmm.
I think signed 32-bit int 1<<31 would be -2147483648 on most platforms

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

#108670

supercat@casperkitty.com writes:
[...]
> Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely
> on platforms that also handle C++, as C++ would require such behavior),
> then if "x" is "long long", then a compiler would likely have to generate
> code for x*(1<<y) that was equivalent to (y!=31) ? x<<y : -(x<<y), which
> would almost certainly be less efficient than x<<y.

No, 1<<31 has undefined behavior in C++ if 2147483648 cannot be
represented as an int.  (C++11 standard, section 5.8 [expr.shift],
unchanged in N4618.)

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

#108685

Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
> [...]
>> Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely
>> on platforms that also handle C++, as C++ would require such behavior),
>> then if "x" is "long long", then a compiler would likely have to generate
>> code for x*(1<<y) that was equivalent to (y!=31) ? x<<y : -(x<<y), which
>> would almost certainly be less efficient than x<<y.
>
> No, 1<<31 has undefined behavior in C++ if 2147483648 cannot be
> represented as an int.  (C++11 standard, section 5.8 [expr.shift],
> unchanged in N4618.)

I was mistaken on this point.  N4618, which is a draft of C++17, makes
1<<31 equivalent to (int)2147483648U (for 32-bit int and unsigned int).

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

#108702

Keith Thompson <kst-u@mib.org> writes:

> Keith Thompson <kst-u@mib.org> writes:
>> supercat@casperkitty.com writes:
>> [...]
>>> Incidentally, if a platform with 32-bit "int" defines 1<<31 as -1 (likely
>>> on platforms that also handle C++, as C++ would require such behavior),
>>> then if "x" is "long long", then a compiler would likely have to generate
>>> code for x*(1<<y) that was equivalent to (y!=31) ? x<<y : -(x<<y), which
>>> would almost certainly be less efficient than x<<y.
>>
>> No, 1<<31 has undefined behavior in C++ if 2147483648 cannot be
>> represented as an int.  (C++11 standard, section 5.8 [expr.shift],
>> unchanged in N4618.)
>
> I was mistaken on this point.  N4618, which is a draft of C++17, makes
> 1<<31 equivalent to (int)2147483648U (for 32-bit int and unsigned
> int).

Harmonising C and C++ was proposed in DR463.  The response was

  "This is not a defect.
   The committee will track this and consider it for the next revision of
   the standard."

-- 
Ben.

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

#108705

On Friday, April 28, 2017 at 6:03:20 PM UTC-5, Ben Bacarisse wrote:
> Harmonising C and C++ was proposed in DR463.  The response was
> 
>   "This is not a defect.
>    The committee will track this and consider it for the next revision of
>    the standard."

There are sound reasons why certain C [or for that matter C++]
implementations should be allowed to evaluate the expression in a way
other than as described in the present C++ Standard.  There are also
sound reasons why implementations should not be required to reject
such code in templates.

Both needs could be accommodated by saying that an implementation must
define macros to indicate or validate whether it treats certain constructs
as yielding particular defined behaviors.  An implementation would be free
to report that 1<<31 will yield a defined value, and allow that expression
within template expansions, or to report that it will not yield a defined
value and not consider any template expansions which would try to evaluate
it.

If an implementation specifies that e.g. x<<32 might yield either 0 or
x, chosen in Unspecified fashion, the C++ Standard might need to specify
whether an implementation would be allowed or required to reject templates
wherein the expressions 0<<32 or (x>>0)|(x<<32) appear.  In the former case,
the fact that the left operand is zero would make it obvious that yielding
0 and yielding x are equivalent.  In the latter case, the expression would
yield the same value regardless of whether x<<32 yielded 0 or x, but it would
be a bit less obvious.  I think allowing implementations to accept or reject
such templates is probably the best approach (since in most cases where such
ambiguities would arise, either choice would probably work just fine) but
can imagine that it might be necessary to ensure consistency within a given
implementation.  That level of detail would really only be important for C++,
however, rather than for C.

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

#108706

On Friday, April 28, 2017 at 4:38:02 PM UTC-7, supe...@casperkitty.com wrote:
> On Friday, April 28, 2017 at 6:03:20 PM UTC-5, Ben Bacarisse wrote:
> > Harmonising C and C++ was proposed in DR463.  The response was
> > 
> >   "This is not a defect.
> >    The committee will track this and consider it for the next revision of
> >    the standard."
> 
> There are sound reasons why certain C [or for that matter C++]
> implementations should be allowed to evaluate the expression in a way
> other than as described in the present C++ Standard.  There are also
> sound reasons why implementations should not be required to reject
> such code in templates.
> 
> Both needs could be accommodated by saying that an implementation must
> define macros to indicate or validate whether it treats certain constructs
> as yielding particular defined behaviors.  An implementation would be free
> to report that 1<<31 will yield a defined value, and allow that expression
> within template expansions, or to report that it will not yield a defined
> value and not consider any template expansions which would try to evaluate
> it.
> 
> If an implementation specifies that e.g. x<<32 might yield either 0 or
> x, chosen in Unspecified fashion, the C++ Standard might need to specify
> whether an implementation would be allowed or required to reject templates
> wherein the expressions 0<<32 or (x>>0)|(x<<32) appear.  In the former case,
> the fact that the left operand is zero would make it obvious that yielding
> 0 and yielding x are equivalent.  In the latter case, the expression would
> yield the same value regardless of whether x<<32 yielded 0 or x, but it would
> be a bit less obvious.  I think allowing implementations to accept or reject
> such templates is probably the best approach (since in most cases where such
> ambiguities would arise, either choice would probably work just fine) but
> can imagine that it might be necessary to ensure consistency within a given
> implementation.  That level of detail would really only be important for C++,
> however, rather than for C.

One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any
problems go away. But that must have been too easy when the
standard was developed. 

PS: And even x<<(-n) as x/(2^n) and so on.

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

#108707

On Friday, April 28, 2017 at 7:10:03 PM UTC-5, David Kleinecke wrote:
> One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any
> problems go away. But that must have been too easy when the
> standard was developed. 

If there exists a ones'-complement platform whose fastest way of
shifting left shifts in zeroes, and another where the fastest
shift operation would copy the sign bit, it would be logical for
implementations on each platform to, by default, do the shift in
whichever way the platform can process most efficiently, and I
doubt the authors of C89 would have wanted to compel them to do
otherwise.  Note, however, that shift-right of negative numbers
should definitely not be equivalent to using the "/" operator,
since in two's-complement form, ~8>>1 [i.e. -9] should be ~4
[i.e. -5], not ~3 [i.e. -4].

> PS: And even x<<(-n) as x/(2^n) and so on.

On many platforms, that would be expensive.

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

#108708

David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
> One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any
> problems go away.

For the cases that are well-defined, that is exactly how they are
defined.  But that would *cause* problem were that extended to the other
cases.  The committee wanted to avoid imposing a burden on
implementations for hardware that did not match C's definition of a
shift.

> But that must have been too easy when the standard was developed.

That's implausible.  The core meaning is defined exactly as you say, but
the extra bits are not there because the committee never thought to
remove them.

> PS: And even x<<(-n) as x/(2^n) and so on.

It is not in the spirit of C to impose that sort of cost on a primitive
operation like a bit shift.

-- 
Ben.

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

#108711

On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> <snip>
> > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any
> > problems go away.
> 
> For the cases that are well-defined, that is exactly how they are
> defined.  But that would *cause* problem were that extended to the other
> cases.  The committee wanted to avoid imposing a burden on
> implementations for hardware that did not match C's definition of a
> shift.
> 
> > But that must have been too easy when the standard was developed.
> 
> That's implausible.  The core meaning is defined exactly as you say, but
> the extra bits are not there because the committee never thought to
> remove them.
> 
> > PS: And even x<<(-n) as x/(2^n) and so on.
> 
> It is not in the spirit of C to impose that sort of cost on a primitive
> operation like a bit shift.

I admit I was thinking about computers which work on atoms
of information other than 2 -like quantum computers seem to
be headed for. If information is not expressed in bits it is
hard to say what all those edge cases "should" do.

Or I suppose you could claim that C was never intended for
such hardware. If so - why not?

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

#108713

On Saturday, April 29, 2017 at 1:21:47 PM UTC+9, David Kleinecke wrote:
> On Friday, April 28, 2017 at 5:43:18 PM UTC-7, Ben Bacarisse wrote:
> > David Kleinecke <> writes:
> > <snip>
> > > One could define x<<n as x*(2^n) and x>>n as x/(2^n) and any
> > > problems go away.
> > 
> > For the cases that are well-defined, that is exactly how they are
> > defined.  But that would *cause* problem were that extended to the other
> > cases.  The committee wanted to avoid imposing a burden on
> > implementations for hardware that did not match C's definition of a
> > shift.
> > 
> > > But that must have been too easy when the standard was developed.
> > 
> > That's implausible.  The core meaning is defined exactly as you say, but
> > the extra bits are not there because the committee never thought to
> > remove them.
> > 
> > > PS: And even x<<(-n) as x/(2^n) and so on.
> > 
> > It is not in the spirit of C to impose that sort of cost on a primitive
> > operation like a bit shift.
> 
> I admit I was thinking about computers which work on atoms
> of information other than 2 -like quantum computers seem to
> be headed for. If information is not expressed in bits it is
> hard to say what all those edge cases "should" do.
> 
> Or I suppose you could claim that C was never intended for
> such hardware. If so - why not?

Unless something has changed since the last time I read the 
standard (more than two back, apparently), ternary and base 
four were intended to be covered. 

It seems like there was at least a draft that even took up C 
for a native decimal CPU.

That's probably where the conflating shift and multiplying 
by a power of two came from.

--
Joel Rees

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

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

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

csiph-web