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


Groups > comp.lang.c > #71996

Re: the language (and the role of Undefined Behavior therein)

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: the language (and the role of Undefined Behavior therein)
Date 2015-10-05 19:39 +0100
Organization A noiseless patient Spider
Message-ID <87wpv1jh23.fsf@bsb.me.uk> (permalink)
References (7 earlier) <kfn1tda6vbp.fsf@x-alumni2.alumni.caltech.edu> <d0caa5eb-5189-46a7-b6d0-84e82f59b199@googlegroups.com> <musvis$1j0$1@speranza.aioe.org> <877fn1lc3f.fsf@bsb.me.uk> <muu4qu$pqj$1@speranza.aioe.org>

Show all headers | View raw


glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>  
>>> supercat@casperkitty.com wrote:
> <snip>
>>>> I have a very strong suspicion that things like the restrictions 
>>>> on pointer- based type punning were never intended to be used for 
>>>> optimization purposes, but were rather intended to allow compilers 
>>>> to enforce more rigid type checking should they choose to do so.  
>
> (snip, I wrote)
>>> As noted, hardware might disallow it. There was a fairly strong
>>> incentive to allow things that hardware allows, and disallow things
>>> that hardware doesn't, even if the latter is relatively rare.
>  
>> I don't think that's not really addressing supercat's point.  The
>> effective type rule renders some accesses undefined, and that is used by
>> some implementations to do what is, to some, surprising things -- like
>> not doing the access at all.  K&R 1st ed. had a notable phrase about
>> pointer conversions which was something like "the result is not
>> specified but should be unsurprising to anyone familiar with the
>> underlying address structure".  I think he or she would like to go back
>> to the days when the result of doing undefined things were largely
>> unsurprising to people in the know.
>
> The standard does separate implementation defined and undefined,
> and I believe optimizers shouldn't do such tricks for the former.

Yes.  It is that latter case -- undefined behaviour being exploited for
optimisation -- that is at issue.

> As for what the hardware might do, consider:
>
> https://en.wikipedia.org/wiki/Tagged_architecture
>
> where the hardware remembers what type of data is stored in
> each memory location.  If that seems too old fashioned, note
> that is pretty much what JVM does. Java has
> ClassCastException if you try to use an object reference
> in the wrong way.

I'm not sure how this information (not new to me BTW!) fits in.  Are you
agreeing, disagreeing, what?  I think supercat would be fine with an
exception in cases where that is what the hardware does.

>> In his or her uint32_t w = *(uint32_t *)p; example I suspect that
>> supercat would be fine with a trap if p is misaligned, or if the result
>> was some odd data that comes from reading the nearest whole word.  The
>> objection (which I don't share) is that the result can be to cue the
>> optimiser to do something unexpected.
>
> On many systems, the hardware trap for unaligned access if fatal,
> so software can assume that it didn't happen.

It can't know (in general) that the access is unaligned.  But I don't
think this is a hardware issue -- it's about a C language rule.

> But yes, I mostly disagree with optimizers assuming some things
> can't happen and optimize on that assumption.

The C rule says it can't happen, even on machines where the hardware is
happy.  That's the point at issue.

<snip>
-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-09-29 15:48 -0700
  Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:57 -0700
    Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-04 19:48 -0700
      Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:50 +0000
        Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 13:43 +0100
          Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 15:26 +0000
            Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 19:39 +0100
              Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 13:32 -0700
              Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 22:06 +0000
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 16:08 -0700
                Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 11:04 +0100
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 08:06 -0700
                Re: the language (and the role of Undefined Behavior therein) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:14 +0200
                Re: the language (and the role of Undefined Behavior therein) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:54 +0200
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 11:20 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-06 10:00 -0700
                Re: the language (and the role of Undefined Behavior therein) David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:44 -0400
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-31 11:08 -0700
                Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-10-31 13:53 -0700
                Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-31 14:06 -0700
          Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-05 09:28 -0700
          Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-10-05 11:20 -0700
            Re: the language (and the role of Undefined Behavior therein) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-05 20:13 +0100
              Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:29 -0700
      Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 10:32 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-12 12:23 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-12 14:42 -0700
        Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-10-14 09:10 -0700
          Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-19 16:11 -0700

csiph-web