Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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