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?

Started byjoel.rees@gmail.com
First post2017-04-27 03:13 -0700
Last post2017-04-30 22:05 -0700
Articles 7 on this page of 127 — 21 participants

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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

#108611

FromKeith Thompson <kst-u@mib.org>
Date2017-04-27 09:38 -0700
Message-ID<lna871n6uc.fsf@kst-u.example.com>
In reply to#108608
supercat@casperkitty.com writes:
[...]
> The clear intention of the Standard is that on a sign-magnitude platform
> whose hardware may randomly catch fire if the left-shift instruction is
> fed a negative number, a compiler for such a platform would have no
> obligation to prevent that from happening.  I see no evidence that the
> authors of the Standard expected or intended that implementations
> targeting two's-complement hardware would should not opt to behave "in a
> documented manner characteristic of the environment".  The authors of C89
> deliberately avoided defining behaviors that would be applicable to some
> machines but not others, figuring that compiler writers and programmers
> alike should be able to recognize the obvious useful cases.

The authors of the C89 standard deliberately stated that a left
shift on a negative value has undefined behavior.  "behaving
during translation or program execution in a documented manner
characteristic of the environment" (that's quoted from a note on
the definition of "undefined behavior") is just one of the possible
behaviors, and it is not emphasized over any of the others.

An optimizing compiler may assume that the left operand of a left
shift operator is non-negative.  If that assumption is violated,
the resulting code may behave differently than if the compiler
generated a shift instruction.  A compiler might also generate code
to check that the left operand is non-negative and trap if it isn't.

Don't you get tired of making the same point again and again
and again?

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

#108614

Fromsupercat@casperkitty.com
Date2017-04-27 10:17 -0700
Message-ID<6f83a74b-776e-4941-882a-20b8c7620ce4@googlegroups.com>
In reply to#108611
On Thursday, April 27, 2017 at 11:39:02 AM UTC-5, Keith Thompson wrote:
> The authors of the C89 standard deliberately stated that a left
> shift on a negative value has undefined behavior.  "behaving
> during translation or program execution in a documented manner
> characteristic of the environment" (that's quoted from a note on
> the definition of "undefined behavior") is just one of the possible
> behaviors, and it is not emphasized over any of the others.

Such behavior wouldn't be applicable on all machines, and the Standard
seeks to avoid showing favoritism to particular architectures.  

On the other hand, I'm curious what evidence you could find from before
2000 that would suggest that left-shifting of negative numbers would have
been expected to have any adverse implications *other than incompatibility
with non-two's-complement hardware, or with configuration options that
would explicitly trap it*.

> An optimizing compiler may assume that the left operand of a left
> shift operator is non-negative.  If that assumption is violated,
> the resulting code may behave differently than if the compiler
> generated a shift instruction.  A compiler might also generate code
> to check that the left operand is non-negative and trap if it isn't.

Doing so would not make a compiler non-conforming.  It would merely limit
the range of purposes for which the compiler was suitable.

> Don't you get tired of making the same point again and again
> and again?

Meh--I'm a glutton for punishment.

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

#108616

FromKeith Thompson <kst-u@mib.org>
Date2017-04-27 12:10 -0700
Message-ID<ln60hpmzuf.fsf@kst-u.example.com>
In reply to#108614
supercat@casperkitty.com writes:
> On Thursday, April 27, 2017 at 11:39:02 AM UTC-5, Keith Thompson wrote:
>> The authors of the C89 standard deliberately stated that a left
>> shift on a negative value has undefined behavior.  "behaving
>> during translation or program execution in a documented manner
>> characteristic of the environment" (that's quoted from a note on
>> the definition of "undefined behavior") is just one of the possible
>> behaviors, and it is not emphasized over any of the others.
>
> Such behavior wouldn't be applicable on all machines, and the Standard
> seeks to avoid showing favoritism to particular architectures.  
>
> On the other hand, I'm curious what evidence you could find from before
> 2000 that would suggest that left-shifting of negative numbers would have
> been expected to have any adverse implications *other than incompatibility
> with non-two's-complement hardware, or with configuration options that
> would explicitly trap it*.

I haven't said or implied that there is any such evidence, and I'm not
sufficiently interested in the question to go looking.  I find the
wording of the standard clear enough.

Left-shifting of negative numbers is not an operation that's
supported by C, so I'm not going to try to use it.

>> An optimizing compiler may assume that the left operand of a left
>> shift operator is non-negative.  If that assumption is violated,
>> the resulting code may behave differently than if the compiler
>> generated a shift instruction.  A compiler might also generate code
>> to check that the left operand is non-negative and trap if it isn't.
>
> Doing so would not make a compiler non-conforming.  It would merely limit
> the range of purposes for which the compiler was suitable.

It would be more useful for the purpose of detecting code whose behavior
is undefined.

[...]

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

#108805

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-04-30 13:50 -0700
Message-ID<kfnbmrd1uy7.fsf@x-alumni2.alumni.caltech.edu>
In reply to#108611
Keith Thompson <kst-u@mib.org> writes:

> The authors of the C89 standard deliberately stated that a left
> shift on a negative value has undefined behavior. [...]

Did you mean the C99 standard?  In C89/C90 left shifting
a negative value is implementation-defined behavior, not
undefined behavior.

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

#108808

FromKeith Thompson <kst-u@mib.org>
Date2017-04-30 14:11 -0700
Message-ID<ln7f21k3c6.fsf@kst-u.example.com>
In reply to#108805
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> The authors of the C89 standard deliberately stated that a left
>> shift on a negative value has undefined behavior. [...]
>
> Did you mean the C99 standard?  In C89/C90 left shifting
> a negative value is implementation-defined behavior, not
> undefined behavior.

No, I *meant* C89, but I was mistaken.

However, C89/C90 doesn't say that a left shift of a negative value has
implementation-defined behavior, at least not explicitly.  (It does say
so for right shift.)  It defines the behavior in terms of bit positions,
not values.  It then clarifies the semantics in terms of values when E1
has an unsigned type, but not when E1 has a signed type.  I suppose you
could say that the result depends on the representation, which is
implementation-defined.

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

#108813

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-04-30 14:44 -0700
Message-ID<kfntw55zi38.fsf@x-alumni2.alumni.caltech.edu>
In reply to#108808
Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> The authors of the C89 standard deliberately stated that a left
>>> shift on a negative value has undefined behavior.  [...]
>>
>> Did you mean the C99 standard?  In C89/C90 left shifting
>> a negative value is implementation-defined behavior, not
>> undefined behavior.
>
> No, I *meant* C89, but I was mistaken.
>
> However, C89/C90 doesn't say that a left shift of a negative value has
> implementation-defined behavior, at least not explicitly.  (It does say
> so for right shift.)  It defines the behavior in terms of bit positions,
> not values.  It then clarifies the semantics in terms of values when E1
> has an unsigned type, but not when E1 has a signed type.  I suppose you
> could say that the result depends on the representation, which is
> implementation-defined.

I see you have responded to my other posting so I will
follow up there.

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

#108847

Fromjoel.rees@gmail.com
Date2017-04-30 22:05 -0700
Message-ID<6d0a58c4-ccc6-4862-8863-83b1946f64b9@googlegroups.com>
In reply to#108808
On Monday, May 1, 2017 at 6:12:07 AM UTC+9, Keith Thompson wrote:
> Tim Rentsch <> writes:
> > Keith Thompson <> writes:
> >> The authors of the C89 standard deliberately stated that a left
> >> shift on a negative value has undefined behavior. [...]
> >
> > Did you mean the C99 standard?  In C89/C90 left shifting
> > a negative value is implementation-defined behavior, not
> > undefined behavior.
> 
> No, I *meant* C89, but I was mistaken.
> 
> However, C89/C90 doesn't say that a left shift of a negative value has
> implementation-defined behavior, at least not explicitly.  (It does say
> so for right shift.)  It defines the behavior in terms of bit positions,
> not values.  It then clarifies the semantics in terms of values when E1
> has an unsigned type, but not when E1 has a signed type.  I suppose you
> could say that the result depends on the representation, which is
> implementation-defined.

Thanks, Keith.

That clears up a lot for me.

--
Joel Rees

http://reiisi.blogspot.com

[toc] | [prev] | [standalone]

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

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

csiph-web