Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #75624 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-11-10 09:10 -0800 |
| Last post | 2015-11-10 10:50 -0800 |
| Articles | 20 on this page of 184 — 23 participants |
Back to article view | Back to comp.lang.c
Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 09:10 -0800
Re: Objective C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 09:16 -0800
Re: Objective C Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 17:17 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-10 09:32 -0800
Re: Objective C Mark Storkamp <mstorkamp@yahoo.com> - 2015-11-10 11:38 -0600
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-10 12:36 -0500
Re: Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 11:15 -0800
Re: Objective C Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 21:51 +0000
Re: Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 23:13 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-13 16:01 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 01:07 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-14 06:26 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 22:22 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-14 15:46 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 01:47 +0000
Re: Objective C BartC <bc@freeuk.com> - 2015-11-15 10:43 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-15 13:19 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 15:43 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-15 23:50 +0100
Re: Objective C gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-16 00:05 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:10 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-16 09:11 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-16 11:57 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 20:38 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 13:20 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 22:28 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 15:33 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-16 15:56 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 01:43 +0000
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 01:21 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 18:11 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-16 20:12 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:59 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-18 22:46 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 14:25 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-19 07:58 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 22:13 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-19 15:29 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 08:44 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 01:26 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-16 21:48 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-16 20:27 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 13:58 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-17 12:28 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 13:00 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 12:31 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 16:43 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 15:57 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-19 19:09 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-19 19:05 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-20 15:00 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-20 15:30 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 17:11 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 15:53 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 13:51 -0600
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-24 12:00 +0000
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-17 10:26 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-17 06:20 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-17 16:41 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-17 12:08 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 16:27 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-17 14:55 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 13:59 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 13:06 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-24 14:24 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-24 15:11 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-26 17:02 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-27 07:26 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-18 21:56 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 02:17 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 07:16 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-26 17:11 -0600
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-22 19:09 +0000
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:28 -0600
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-18 15:33 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-18 23:06 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-19 09:12 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-19 09:25 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-19 21:06 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:49 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 05:01 -0600
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 05:09 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-21 03:31 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 17:43 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-21 16:00 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 01:12 -0600
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:42 +0000
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-27 12:38 -0500
Re: Objective C supercat@casperkitty.com - 2015-11-27 11:09 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-21 19:06 -0500
Re: Objective C supercat@casperkitty.com - 2015-11-21 17:00 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:44 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 01:55 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-22 00:03 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-22 10:18 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 03:21 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-22 10:53 -0500
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 20:28 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 18:52 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 11:58 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-23 15:24 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 09:46 -0500
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-23 08:13 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 12:04 -0500
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 11:52 -0600
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 16:05 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-24 09:09 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-08 08:48 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-12-08 10:40 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 12:34 -0800
Re: Objective C supercat@casperkitty.com - 2015-12-08 10:50 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 12:42 -0800
Re: Objective C supercat@casperkitty.com - 2015-12-09 13:38 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-12-10 19:54 +0000
Re: Objective C David Thompson <dave.thompson2@verizon.net> - 2015-12-06 08:02 -0500
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:36 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-23 00:41 -0600
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 07:39 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:23 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-17 10:24 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-18 15:40 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 16:02 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-21 15:53 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-21 08:58 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-22 22:14 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 03:39 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-23 13:24 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-26 09:39 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-26 13:16 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-26 12:25 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:34 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-26 12:39 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:43 +0000
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-27 09:29 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:18 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 22:35 +0000
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 17:40 -0500
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-24 05:35 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-25 12:15 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 22:49 +0000
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:44 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:03 -0800
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-29 09:29 +0000
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-22 19:01 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 07:31 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-23 07:43 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-23 08:17 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-23 17:34 +0100
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-23 22:02 +0000
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-24 10:12 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 08:39 -0800
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-14 18:24 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 12:23 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 12:36 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 13:13 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 14:04 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 14:15 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 14:29 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 15:39 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 16:37 -0800
Re: Objective C Ian Collins <ian-news@hotmail.com> - 2015-11-15 13:46 +1300
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 02:06 +0000
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-15 03:25 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 12:56 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-15 07:53 -0600
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-15 07:19 -0600
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 13:29 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-15 10:56 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-15 14:35 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-15 16:52 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:49 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 11:02 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-16 10:36 -0800
Re: Objective C David Thompson <dave.thompson2@verizon.net> - 2015-12-06 08:03 -0500
Re: Objective C Melzzzzz <mel@zzzzz.com> - 2015-11-16 02:01 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:34 -0800
Re: Objective C Chad <cdalten@gmail.com> - 2015-11-15 19:54 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:36 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-17 15:27 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-17 21:15 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 22:08 +0000
Re: Objective C fir <profesor.fir@gmail.com> - 2015-11-27 14:36 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-10 19:03 +0100
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-10 10:50 -0800
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-23 15:24 -0800 |
| Message-ID | <cd219b13-ff7f-44ff-bc6a-74c6af2f4f87@googlegroups.com> |
| In reply to | #77017 |
On Monday, November 23, 2015 at 11:59:13 AM UTC-6, Stephen Sprunk wrote: > I agree that's a straightforward translation of the code on a CPU that > does not have actual 16-bit registers (which is most of them, these > days), but at least in the absence of UB, the relevant ABI should > require that either the callee mask off the excess bits before return > and/or the caller ignore them. A typical ABI would require that the called function mask off the excess bits, but the point was that the UB-ness of returning the indeterminate automatic- scope variable is in no way dependent upon uint16_t having any trap representations. It's extremely plausible that code which calls the above function might malfunction in really weird and bizarre ways if it receives a value greater than 65535, so such values would effectively behave as trap representations even though uint16_t normally wouldn't have any.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-23 09:46 -0500 |
| Message-ID | <n2v8oc$fjb$1@dont-email.me> |
| In reply to | #76956 |
On 11/22/2015 09:28 PM, Stephen Sprunk wrote: > On 22-Nov-15 09:53, James Kuyper wrote: >> On 11/22/2015 02:55 AM, Stephen Sprunk wrote: >>> On 21-Nov-15 18:06, James Kuyper wrote: >>>> On 11/21/2015 06:43 PM, Stephen Sprunk wrote: >>>>> On 21-Nov-15 05:31, Keith Thompson wrote: >> .... >>>>>> N1570 6.5.2.3p3, footnote: >>>>>> >>>>>> If the member used to read the contents of a union object is >>>>>> not the same as the member last used to store a value in the >>>>>> object, the appropriate part of the object representation of >>>>>> the value is reinterpreted as an object representation in the >>>>>> new type as described in 6.2.6 (a process sometimes called >>>>>> "type punning"). This might be a trap representation. >>>>> >>>>> That says the representation in the new type could be either a >>>>> valid value or a trap representation, ... >>>> >>>> True. >>>> >>>>> ... which is the very definition of an indeterminate value. ... >>>> >>>> No, it is not. When you have an indeterminate value, which value >>>> you have (including whether or not it's a trap representation) >>>> is completely unspecified. >>> >>> That's what I see above: the result is either a valid value or a >>> trap representation, and that is the definition of indeterminate >>> value. >> >> No - the lack of specification is a key component of the definition >> of an indeterminate value, and the combination of 6.5.2.3p3 and the >> implementation-defined representation of the two types specifies >> precisely what the resulting value will be, including whether or not >> it will have a trap representation. ... > > But the Standard doesn't actually specify what the value will be; at It specifies how the implementation-defined representations for the two types determines what the result will be. > best, it is implementation-defined, which is uncomfortably close to > being unspecified--and would bring us back to indeterminate. But the procedure is standard-defined, and the representations are implementation-defined. You might feel that implementation-defined is too close to being unspecified - but it is NOT unspecified - and therefore not indeterminate. >>>>> ... Reading an indeterminate value invokes undefined behavior, >>>>> even if it happens to _not_ be a trap representation. >>>> >>>> Citation, please? >>> >>> N1570 J.2 >>> "1 The behavior is undefined in the following circumstances: >>> ... >>> -- The value of an object with automatic storage duration is used >>> while its value is indeterminate." >> >> J.2 is listed as informative; it has no authority in itself. > > The wording certainly appears normative, regardless of location. An explicit statement that it's normative, which appears at the top of section J, overrides any and all appearances of being normative. >> J.2 cites 6.2.4, 6.7.9, and 6.8 as the supporting sections from >> the normative part of the standard. >> ... > > I agree that nothing in those sections seems to support J.2's claim that > accessing indeterminate values other than trap representations is always > undefined behavior, yet that's exactly what J.2 clearly says. If two normative clauses conflict, either one (or neither, for that matter) might be right. If one normative clause is more specific than another, the more specific one applies. However, informative text that says something which cannot be backed up by normative text is simply wrong. >>> That doesn't apply to non-auto objects, which I wasn't aware of, >>> but it seems clear that if an auto object with indeterminate value >>> happens to have a valid value rather than a trap representation >>> (and even if its type doesn't _have_ trap representations), using >>> it still invokes undefined behavior. >> >> Can you find a normative clause supporting J.2's claim? > > Unfortunately, no. Several places throughout the Standard say that it > _may_ result in undefined behavior, but none that it _will_. > >>> That's what I assume the intent was--and what I assume every >>> compiler actually implements, but I'm not sure that a strict >>> reading of the wording actually promises that. >> >> As far as I can tell, it does, and J.2 is in error in this regard. > > So I actually found a defect in the Standard? What is the process to > report that to the Committee? Convince a committee member to file a Defect Report on your behalf. Larry Jones is the committee secretary, and Douglas A. Gwyn is a member (But I can't locate any messages posted by him to comp.lang.c or comp.std.c more recent than 2008-07-08, so that may no longer be true), those are the only two I have any idea how to contact. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-23 08:13 -0800 |
| Message-ID | <lnwpt83d8y.fsf@kst-u.example.com> |
| In reply to | #76991 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/22/2015 09:28 PM, Stephen Sprunk wrote:
>> On 22-Nov-15 09:53, James Kuyper wrote:
[...]
>>> J.2 is listed as informative; it has no authority in itself.
>>
>> The wording certainly appears normative, regardless of location.
>
> An explicit statement that it's normative, which appears at the top of
> section J, overrides any and all appearances of being normative.
You meant to write:
An explicit statement that it's *informative*, which appears at the top of
section J, overrides any and all appearances of being normative.
[...]
--
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]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-23 12:04 -0500 |
| Message-ID | <56534718.3070902@verizon.net> |
| In reply to | #76999 |
On 11/23/2015 11:13 AM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: >> On 11/22/2015 09:28 PM, Stephen Sprunk wrote: >>> On 22-Nov-15 09:53, James Kuyper wrote: > [...] >>>> J.2 is listed as informative; it has no authority in itself. >>> >>> The wording certainly appears normative, regardless of location. >> >> An explicit statement that it's normative, which appears at the top of >> section J, overrides any and all appearances of being normative. > > You meant to write: > > An explicit statement that it's *informative*, which appears at the top of > section J, overrides any and all appearances of being normative. Yes, I did.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-23 11:52 -0600 |
| Message-ID | <n2vjjm$v7k$1@dont-email.me> |
| In reply to | #76991 |
On 23-Nov-15 08:46, James Kuyper wrote: > On 11/22/2015 09:28 PM, Stephen Sprunk wrote: >> On 22-Nov-15 09:53, James Kuyper wrote: >>> On 11/22/2015 02:55 AM, Stephen Sprunk wrote: >>>> That's what I see above: the result is either a valid value or >>>> a trap representation, and that is the definition of >>>> indeterminate value. >>> >>> No - the lack of specification is a key component of the >>> definition of an indeterminate value, and the combination of >>> 6.5.2.3p3 and the implementation-defined representation of the >>> two types specifies precisely what the resulting value will be, >>> including whether or not it will have a trap representation. ... >> >> But the Standard doesn't actually specify what the value will be; > > It specifies how the implementation-defined representations for the > two types determines what the result will be. Hmm. I'm not fully convinced, but it turns out below that it doesn't matter anyway, so I'll concede the point. >>>> N1570 J.2 >>>> "1 The behavior is undefined in the following circumstances: >>>> ... >>>> -- The value of an object with automatic storage duration is used >>>> while its value is indeterminate." >>> >>> J.2 is listed as informative; it has no authority in itself. >> >> The wording certainly appears normative, regardless of location. > > An explicit statement that it's normative, which appears at the top of > section J, overrides any and all appearances of being normative. Fair enough. >>> J.2 cites 6.2.4, 6.7.9, and 6.8 as the supporting sections from >>> the normative part of the standard. >>> ... >> >> I agree that nothing in those sections seems to support J.2's claim >> that accessing indeterminate values other than trap representations >> is always undefined behavior, yet that's exactly what J.2 clearly >> says. > > If two normative clauses conflict, either one (or neither, for that > matter) might be right. If one normative clause is more specific > than another, the more specific one applies. However, informative > text that says something which cannot be backed up by normative text > is simply wrong. Got it. >>>> That's what I assume the intent was--and what I assume every >>>> compiler actually implements, but I'm not sure that a strict >>>> reading of the wording actually promises that. >>> >>> As far as I can tell, it does, and J.2 is in error in this >>> regard. >> >> So I actually found a defect in the Standard? What is the process >> to report that to the Committee? > > Convince a committee member to file a Defect Report on your behalf. > Larry Jones is the committee secretary, and Douglas A. Gwyn is a > member (But I can't locate any messages posted by him to comp.lang.c > or comp.std.c more recent than 2008-07-08, so that may no longer be > true), those are the only two I have any idea how to contact. Thanks; I'll look into that. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-23 16:05 -0800 |
| Message-ID | <kfn610s45z3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76956 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 22-Nov-15 09:53, James Kuyper wrote:
>> On 11/22/2015 02:55 AM, Stephen Sprunk wrote:
>>> On 21-Nov-15 18:06, James Kuyper wrote:
>>>> On 11/21/2015 06:43 PM, Stephen Sprunk wrote:
>>>>> On 21-Nov-15 05:31, Keith Thompson wrote:
>>
>> ....
>>
>>>>>> N1570 6.5.2.3p3, footnote:
>>>>>>
>>>>>> If the member used to read the contents of a union object is
>>>>>> not the same as the member last used to store a value in the
>>>>>> object, the appropriate part of the object representation of
>>>>>> the value is reinterpreted as an object representation in the
>>>>>> new type as described in 6.2.6 (a process sometimes called
>>>>>> "type punning"). This might be a trap representation.
>>>>>
>>>>> That says the representation in the new type could be either a
>>>>> valid value or a trap representation, ...
>>>>
>>>> True.
>>>>
>>>>> ... which is the very definition of an indeterminate value. ...
>>>>
>>>> No, it is not. When you have an indeterminate value, which value
>>>> you have (including whether or not it's a trap representation) is
>>>> completely unspecified.
>>>
>>> That's what I see above: the result is either a valid value or a
>>> trap representation, and that is the definition of indeterminate
>>> value.
>>
>> No - the lack of specification is a key component of the definition
>> of an indeterminate value, and the combination of 6.5.2.3p3 and the
>> implementation-defined representation of the two types specifies
>> precisely what the resulting value will be, including whether or
>> not it will have a trap representation. ...
>
> But the Standard doesn't actually specify what the value will be;
> at best, it is implementation-defined, which is uncomfortably
> close to being unspecified--and would bring us back to
> indeterminate.
>
>>>>> ... Reading an indeterminate value invokes undefined behavior,
>>>>> even if it happens to _not_ be a trap representation.
>>>>
>>>> Citation, please?
>>>
>>> N1570 J.2
>>> "1 The behavior is undefined in the following circumstances:
>>> ...
>>> -- The value of an object with automatic storage duration is used
>>> while its value is indeterminate."
>>
>> J.2 is listed as informative; it has no authority in itself.
>
> The wording certainly appears normative, regardless of location.
>
>> J.2 cites 6.2.4, 6.7.9, and 6.8 as the supporting sections from
>> the normative part of the standard.
>> ...
>
> I agree that nothing in those sections seems to support J.2's
> claim that accessing indeterminate values other than trap
> representations is always undefined behavior, yet that's exactly
> what J.2 clearly says.
>
>>> That doesn't apply to non-auto objects, which I wasn't aware of,
>>> but it seems clear that if an auto object with indeterminate value
>>> happens to have a valid value rather than a trap representation
>>> (and even if its type doesn't _have_ trap representations), using
>>> it still invokes undefined behavior.
>>
>> Can you find a normative clause supporting J.2's claim?
>
> Unfortunately, no. Several places throughout the Standard say
> that it _may_ result in undefined behavior, but none that it
> _will_.
>
>>> That's what I assume the intent was--and what I assume every
>>> compiler actually implements, but I'm not sure that a strict
>>> reading of the wording actually promises that.
>>
>> As far as I can tell, it does, and J.2 is in error in this regard.
>
> So I actually found a defect in the Standard? What is the process
> to report that to the Committee?
Let me jump in and see if I can help here. The discussion has
gone in several different directions, so rounding things up may
take a bit of travelling, but I think the result will be worth
the trip. After each of the points below there will follow an
explanation, which is there not to argue that the point is true
but to help understand why I say what I'm saying. Also, to
simplify the discussion, assume that all union members talked
about below have the same size.
First: It's true that the object representation of a union
member other than the last one written might be a trap
representation, but its value is not indeterminate.
Why: Note the difference between the Standard saying the value
of an object /is/ indeterminate and saying something /might/ be
a trap representation. The first is a degree of freedom given
to an implementation; the second is a deduction about what
might follow as a consequence of other specifications. For
example, if the bytes that make up, say, an int * object, are
given values that come out of a random number generator, the
result might be a trap representation. But that doesn't mean
the value is indeterminate: the bits are whatever they are, and
if the resulting object representation happens not to be a legal
value then it's a trap representation. Because the bits are
determined, rather than being a free choice given to the
implementation, what the object holds is not an "indeterminate
value" in the sense that the Standard uses the term.
Second: Reading an object that has an indeterminate value is
not automatically undefined behavior. (Of course there is
undefined behavior if the bytes of the object hold a trap
representation for the object's type, but not otherwise.)
Why: There is a powerful tool for understanding how to read
what the Standard says. That tool is this: the exception
proves the rule, in cases not excepted. That is, if the text
goes to some effort to establish property P in some specific
circumstance C, then we may reasonably infer that property P
does /not/ hold in circumstances other than C. The Standard
gives us an excellent example. The last sentence of 6.3.2.1 p2
(added in C11) says:
If the lvalue designates an object of automatic storage
duration that could have been declared with the register
storage class (never had its address taken), and that object
is uninitialized (not declared with an initializer and no
assignment to it has been performed prior to use), the
behavior is undefined.
There is no reason for this sentence to be there if accessing
an indeterminate value is already undefined behavior. The
Standard is quite careful never to say anything twice (ie, in
normative text - footnotes don't count). Hence we may conclude
that reading an indeterminate value is not, in and of itself,
undefined behavior.
(Incidentally, my understanding is that this proviso of C11 was
added to allow use of the "Not a Thing" bit in the HP/Intel
Itanium architecture, without violating the ISO C standard.)
Third: The semantics of reading a union member other than the
last one written is defined in the sense that it is completely[*]
determined by normative text and other implementation-defined
behaviors. (The [*] is there because there can be cases that
don't have 1-to-1 mappings, such as treatment of negative zeros;
not counting these little glitches, what has to happen has no
wiggle room.) The behavior depends on implementation-defined
behaviors, but implementations have no additional freedom beyond
that allowed by other implementation-defined behavior.
Why: I think James Kuyper has already given citations for the
normative passages in the Standard that provide the underpinnings
for the semantics of how union member access has to work in such
cases. I went through this exercise myself several years ago and
reached the conclusions (at least I think they're the same - I
only skimmed James's recent posting). If you look at those
passages yourself you might or might not find them convincing.
In this particular case a better source is looking at various
historical documents. The famous "type punning" footnote was not
always in C99; it was added as a result of a Technical
Corrigendum. Furthermore there are differences in the text
between C90 and C99 that look like there might actually be some
differences in this area between the two languages. However, if
other historical documents (available on the same website as the
N1256 and N1570 downloads) are consulted, the discussion makes it
clear that what is intended has been the same all along, namely,
doing a read simply re-interprets the bits written to the other
member. And in fact the footnote was added precisely because
there was some concern that the Standard didn't convey this
clearly, even thought what the committee intended hadn't changed
since the earliest version of the Standard (and presumably also
before that).
Fourth: As regards the statement in J.2, it is IMO misleading,
or at the very least an oversimplification. Despite that, I
wouldn't suggest you write a defect report (and see below for why
not).
Why: I agree that the J.2 statement mentioned deserves
re-writing. I just don't think it's likely that the Standard
will be changed to do that. If you look through the committee
reactions in old defect reports, in lots of cases their reaction
is basically "the standard is clear enough as it is", even for
things that IMO are much worse than this. I can almost predict
what the reaction would be: most people will understand it fine;
it's informative text anyway; and even if developers do
misunderstand it there is no real harm, because implementors will
be careful to check the normative text and do the right thing.
I'm not saying I have any special insight here, I think the kind
of reaction that is likely can be seen by reading other defect
reports. So at the very least I guess I recommend you read a few
dozen old defect reports and see for yourself.
Okay, we're at the end now. I hope this helped. :)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-24 09:09 -0800 |
| Message-ID | <e39b4cf1-fff2-414a-819c-0adadc58267b@googlegroups.com> |
| In reply to | #77048 |
On Monday, November 23, 2015 at 6:05:39 PM UTC-6, Tim Rentsch wrote: > Fourth: As regards the statement in J.2, it is IMO misleading, > or at the very least an oversimplification. Despite that, I > wouldn't suggest you write a defect report (and see below for why > not). There exist implementations where an uninitialized automatic variable may behave in a fashion inconsistent with its type even when that type would otherwise have no trap representations. To forbid implementations from behaving in that fashion would require compilers to generate extra code. I think it would be thus fair to say that regardless of whether J.2 is supposed to be normative, some compiler writers (even those for generally- conservative compilers) behave as though it is.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-12-08 08:48 -0800 |
| Message-ID | <kfn4mfsyji3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77111 |
supercat@casperkitty.com writes: > On Monday, November 23, 2015 at 6:05:39 PM UTC-6, Tim Rentsch wrote: >> Fourth: As regards the statement in J.2, it is IMO misleading, >> or at the very least an oversimplification. Despite that, I >> wouldn't suggest you write a defect report (and see below for why >> not). > > There exist implementations where an uninitialized automatic > variable may behave in a fashion inconsistent with its type even > when that type would otherwise have no trap representations. > [...] If there are such implementations then they are not conforming. There really isn't much else to say about them.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-08 10:40 -0800 |
| Message-ID | <lna8pkokce.fsf@kst-u.example.com> |
| In reply to | #78182 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> supercat@casperkitty.com writes:
>> On Monday, November 23, 2015 at 6:05:39 PM UTC-6, Tim Rentsch wrote:
>>> Fourth: As regards the statement in J.2, it is IMO misleading,
>>> or at the very least an oversimplification. Despite that, I
>>> wouldn't suggest you write a defect report (and see below for why
>>> not).
>>
>> There exist implementations where an uninitialized automatic
>> variable may behave in a fashion inconsistent with its type even
>> when that type would otherwise have no trap representations.
>> [...]
>
> If there are such implementations then they are not conforming.
> There really isn't much else to say about them.
How so?
N1570 6.3.2.1p2:
Except when it is the operand of [...], an lvalue that does
not have array type is converted to the value stored in the
designated object (and is no longer an lvalue); this is called
*lvalue conversion*. [...] If the lvalue designates an object
of automatic storage duration that could have been declared with
the register storage class (never had its address taken), and
that object is uninitialized (not declared with an initializer
and no assignment to it has been performed prior to use),
the behavior is undefined.
So this:
#include <stdio.h>
int main(void) {
unsigned char c;
printf("%u\n", (unsigned)c);
}
has undefined behavior, even though unsigned char has no trap
representations.
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-12-09 12:34 -0800 |
| Message-ID | <kfn7fknuzse.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #78193 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> supercat@casperkitty.com writes:
>>> On Monday, November 23, 2015 at 6:05:39 PM UTC-6, Tim Rentsch wrote:
>>>> Fourth: As regards the statement in J.2, it is IMO misleading,
>>>> or at the very least an oversimplification. Despite that, I
>>>> wouldn't suggest you write a defect report (and see below for why
>>>> not).
>>>
>>> There exist implementations where an uninitialized automatic
>>> variable may behave in a fashion inconsistent with its type even
>>> when that type would otherwise have no trap representations.
>>> [...]
>>
>> If there are such implementations then they are not conforming.
>> There really isn't much else to say about them.
>
> How so?
>
> N1570 6.3.2.1p2:
>
> Except when it is the operand of [...], an lvalue that does
> not have array type is converted to the value stored in the
> designated object (and is no longer an lvalue); this is called
> *lvalue conversion*. [...] If the lvalue designates an object
> of automatic storage duration that could have been declared with
> the register storage class (never had its address taken), and
> that object is uninitialized (not declared with an initializer
> and no assignment to it has been performed prior to use),
> the behavior is undefined.
>
> So this:
>
> #include <stdio.h>
> int main(void) {
> unsigned char c;
> printf("%u\n", (unsigned)c);
> }
>
> has undefined behavior, even though unsigned char has no trap
> representations.
What I meant was implementations that treat all variables that
way, regardless of whether they have had their address taken or
not, are non-conforming. And pre-C11 implementations that do
this with any variable are not conforming, since the sentence
that makes such cases undefined behavior was added only in C11.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-08 10:50 -0800 |
| Message-ID | <b0000704-c3df-40b6-b4ae-7985a08a638d@googlegroups.com> |
| In reply to | #78182 |
On Tuesday, December 8, 2015 at 10:48:12 AM UTC-6, Tim Rentsch wrote:
> If there are such implementations then they are not conforming.
> There really isn't much else to say about them.
If the act of reading such variables as character types turns them into
Unspecified Values, what's the problem? Reading them as their own type
yields Undefined Behavior. Given:
uint16_t foo(uint32_t x) { uint16_t q; if (x < 23) q=x; return q; }
uint32_t bar(uint32_t x) { return foo(x); }
would an implementation of "bar" that blindly returned x be in any way
illegitimate?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-12-09 12:42 -0800 |
| Message-ID | <kfn37vbuzej.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #78196 |
supercat@casperkitty.com writes:
> On Tuesday, December 8, 2015 at 10:48:12 AM UTC-6, Tim Rentsch wrote:
>> If there are such implementations then they are not conforming.
>> There really isn't much else to say about them.
>
> If the act of reading such variables as character types turns them into
> Unspecified Values, what's the problem? Reading them as their own type
> yields Undefined Behavior.
No, it doesn't. There is undefined behavior (to be clear, when
the type in question has no trap representations) in some
particular cases in C11, but not otherwise, and there is never
undefined behavior in such situations in C99 or C90.
> Given:
>
> uint16_t foo(uint32_t x) { uint16_t q; if (x < 23) q=x; return q; }
> uint32_t bar(uint32_t x) { return foo(x); }
>
> would an implementation of "bar" that blindly returned x be in any way
> illegitimate?
In C90 and C99, yes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-09 13:38 -0800 |
| Message-ID | <e0431945-cb9c-43a2-8a5c-eb1a051a7a94@googlegroups.com> |
| In reply to | #78289 |
On Wednesday, December 9, 2015 at 2:42:54 PM UTC-6, Tim Rentsch wrote:
> supercat writes:
> > Given:
> >
> > uint16_t foo(uint32_t x) { uint16_t q; if (x < 23) q=x; return q; }
> > uint32_t bar(uint32_t x) { return foo(x); }
> >
> > would an implementation of "bar" that blindly returned x be in any way
> > illegitimate?
>
> In C90 and C99, yes.
Interesting. I've seen and used a lot of compilers which, given code like
the above, will use 32-bit registers for 16-bit variables and return
values, and which will return whatever happens to be in a register if its
value is never written; I've never thought anything of it.
Given the above code, gcc 4.8.2 for the ARM will return x if it's less than
23 or else return whatever happened to be in register 2. If bar was called
by a method which took three parameters, the third of which was a uint32_t,
it would yield the value of that parameter without regard for whether it was
within range for an int16_t.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-12-10 19:54 +0000 |
| Message-ID | <5669d5af.26143140@news.xs4all.nl> |
| In reply to | #78301 |
supercat@casperkitty.com wrote:
> On Wednesday, December 9, 2015 at 2:42:54 PM UTC-6, Tim Rentsch wrote:
> > supercat writes:
> > > Given:
> > >
> > > uint16_t foo(uint32_t x) { uint16_t q; if (x < 23) q=x; return q; }
> > > uint32_t bar(uint32_t x) { return foo(x); }
> > >
> > > would an implementation of "bar" that blindly returned x be in any way
> > > illegitimate?
> >
> > In C90 and C99, yes.
Well, except that uint<foo>_t weren't in C90...
> Interesting. I've seen and used a lot of compilers which, given code like
> the above, will use 32-bit registers for 16-bit variables and return
> values, and which will return whatever happens to be in a register if its
> value is never written; I've never thought anything of it.
Values of x are possible which don't fit in a uint16_t, and therefore
cannot be returned from foo().
Since uint16_t cannot have padding bits, it can also not have any trap
values - it has exactly 16 bits, each of which is a value bit, so the
value of each representation is well-defined. Therefore, q is
initialised to have an unknown, but valid value; returning it cannot
invoke undefined behaviour. This value _must_ be lower than 2^^16; thus,
if x > 2^^16 (and therefore also >= 23!), the value returned from foo()
cannot be equal to q, but also, cannot be a trap representation and
invoke UB. Therefore, in those cases, bar(x) == foo(x) != x.
The situation is different for types which _can_ have trap
representations, such as int_least16_t.
Richard
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-06 08:02 -0500 |
| Message-ID | <0ec86bdqjaj723rulpsohle1uq8jk2eq27@4ax.com> |
| In reply to | #76880 |
On Sun, 22 Nov 2015 10:53:27 -0500, James Kuyper <jameskuyper@verizon.net> wrote: > On 11/22/2015 02:55 AM, Stephen Sprunk wrote: <snip: typepunning via union> > > N1570 J.2 > > "1 The behavior is undefined in the following circumstances: > > ... > > -- The value of an object with automatic storage duration is used while > > its value is indeterminate." > > J.2 is listed as informative; it has no authority in itself. J.2 cites > 6.2.4, 6.7.9, and 6.8 as the supporting sections from the normative part > of the standard. > > The only thing that 6.2.4 says which seems relevant is paragraph 6, > referring to objects of automatic storage duration: "The initial value > of the object is indeterminate. If an initialization is specified for > the object, it is performed each time the declaration or compound > literal is reached in the execution of the block; otherwise, the value > becomes indeterminate each time the declaration is reached.". Paragraph > 7 says the same thing about objects with variable length array type. > > The only thing that 6.7.9 says which seems relevant is in paragraph 10: > "If an object that has automatic storage duration is not initialized > explicitly, its value is indeterminate." > > I can't figure out what 6.8 says that might be considered relevant. > All say the same thing from different points of view: 6.2.4 is about objects, and for auto objects says their lifetime is the block execution (or for VLA part of same) and are intialized if there is an initializer and otherwise indeterminate. 6.7.9 is about initializers, and for auto objects says if there is not an initializer they are indeterminate. 6.8 is about block execution, and for auto objects it does not mention the lifetime but does say they are initialized if there is an initializer and otherwise indeterminate. > So the only thing that those clauses seem to specify is that the value > is indeterminate. An indeterminate value can be have trap > representation, and if it does, attempting to read it does have > undefined behavior. But any situation which allows you to rule out the > possibility of a trap representation renders such code safe. > Concur entirely. <snip rest>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-22 14:36 -0800 |
| Message-ID | <kfnfuzx64rh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76750 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Sat, 21 Nov 2015 05:01:53 -0600, Robert Wessel > <robertwessel2@yahoo.com> wrote: > >> On Fri, 20 Nov 2015 13:49:10 -0800, Tim Rentsch >> <txr@alumni.caltech.edu> wrote: >> >>> Robert Wessel <robertwessel2@yahoo.com> writes: >>> >>>> On Tue, 17 Nov 2015 16:41:22 +0100, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>> >>>>> On 17/11/15 15:20, supercat@casperkitty.com wrote: >>>>> >>>>>> On a lot of small-system compilers, memcpy is horribly inefficient. >>>>> >>>>> And on a lot of systems, it is very efficient - because the compiler >>>>> will optimise it inline, using all the information available about >>>>> alignment, etc. And for more limited compilers, there is no problem >>>>> anyway because they don't do much optimisation. You can't have it both >>>>> ways. >>>>> >>>>>> Besides, in C99 memcpy() can apply the effective type of the source to the >>>>>> destination, so >>>>>> >>>>>> void *p1 = malloc(4), *p2=malloc(4); >>>>>> *((float*)p1) = 12.34; >>>>>> memcpy(p2,p1,4); >>>>>> int q=*((int*)p2); >>>>>> >>>>>> would still yield UB. >>>>> >>>>> Code like that fails any sort of code review. I really don't >>>>> /care/ if the compiler sees that as undefined behaviour or not - >>>>> the code is /wrong/. >>>>> >>>>> Write your code sensibly, using proper types and proper code >>>>> structure. Here's a hint to get you started - if you are using >>>>> void* explicitly, or casting your pointer types, your code is >>>>> probably bad or at least warrants special care. >>>>> >>>>> (That's enough of this nonsense for me. I am happy writing code >>>>> that has defined behaviour and works efficiently and correctly. >>>>> I don't need to concern myself about hypothetical function >>>>> specifications, badly structured programs, and paranoia.) >>>> >>>> So I take it you really don't like the famous fast inverse square >>>> root hack? >>>> >>>> https://en.wikipedia.org/wiki/Fast_inverse_square_root >>> >>> This algorithm can be implemented both efficiently and correctly >>> using unions rather than pointer casting. >> >> FSVO "correctly". Only if you know the layout of both the FP and >> integer field. > > And, of course, writing to one union member and reading from the > other is undefined. Given the followups, have you changed your view on this? I agree with the downstream comments made by Keith Thompson and James Kuyper - the behavior depends on implementation-defined aspects, but otherwise is defined, assuming the type for reading has no trap representations.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-11-23 00:41 -0600 |
| Message-ID | <gjc55b9fteun8e9eb8m5hrastej7rqgkbn@4ax.com> |
| In reply to | #76934 |
On Sun, 22 Nov 2015 14:36:18 -0800, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Sat, 21 Nov 2015 05:01:53 -0600, Robert Wessel
>> <robertwessel2@yahoo.com> wrote:
>>
>>> On Fri, 20 Nov 2015 13:49:10 -0800, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>>>
>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>
>>>>> On Tue, 17 Nov 2015 16:41:22 +0100, David Brown
>>>>> <david.brown@hesbynett.no> wrote:
>>>>>
>>>>>> On 17/11/15 15:20, supercat@casperkitty.com wrote:
>>>>>>
>>>>>>> On a lot of small-system compilers, memcpy is horribly inefficient.
>>>>>>
>>>>>> And on a lot of systems, it is very efficient - because the compiler
>>>>>> will optimise it inline, using all the information available about
>>>>>> alignment, etc. And for more limited compilers, there is no problem
>>>>>> anyway because they don't do much optimisation. You can't have it both
>>>>>> ways.
>>>>>>
>>>>>>> Besides, in C99 memcpy() can apply the effective type of the source to the
>>>>>>> destination, so
>>>>>>>
>>>>>>> void *p1 = malloc(4), *p2=malloc(4);
>>>>>>> *((float*)p1) = 12.34;
>>>>>>> memcpy(p2,p1,4);
>>>>>>> int q=*((int*)p2);
>>>>>>>
>>>>>>> would still yield UB.
>>>>>>
>>>>>> Code like that fails any sort of code review. I really don't
>>>>>> /care/ if the compiler sees that as undefined behaviour or not -
>>>>>> the code is /wrong/.
>>>>>>
>>>>>> Write your code sensibly, using proper types and proper code
>>>>>> structure. Here's a hint to get you started - if you are using
>>>>>> void* explicitly, or casting your pointer types, your code is
>>>>>> probably bad or at least warrants special care.
>>>>>>
>>>>>> (That's enough of this nonsense for me. I am happy writing code
>>>>>> that has defined behaviour and works efficiently and correctly.
>>>>>> I don't need to concern myself about hypothetical function
>>>>>> specifications, badly structured programs, and paranoia.)
>>>>>
>>>>> So I take it you really don't like the famous fast inverse square
>>>>> root hack?
>>>>>
>>>>> https://en.wikipedia.org/wiki/Fast_inverse_square_root
>>>>
>>>> This algorithm can be implemented both efficiently and correctly
>>>> using unions rather than pointer casting.
>>>
>>> FSVO "correctly". Only if you know the layout of both the FP and
>>> integer field.
>>
>> And, of course, writing to one union member and reading from the
>> other is undefined.
>
>Given the followups, have you changed your view on this? I agree
>with the downstream comments made by Keith Thompson and James
>Kuyper - the behavior depends on implementation-defined aspects,
>but otherwise is defined, assuming the type for reading has no
>trap representations.
Yes...
There was a semi-recent discussion about a common pattern somewhere
along these lines (and I though it was this, but I appear to have
misremembered), where the actual portable construct required a memcpy.
And, I finally managed to dredge up the thread. It's changing the
access type by casting the type of a pointer. IOW, it's the following
which is undefined:
inline uint32_t float2unsigned(float f)
{
return *(uint32_t *) &f;
}
(code snippet written by Terje Mathisen)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-23 07:39 -0800 |
| Message-ID | <kfnegfg4tdy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76967 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 22 Nov 2015 14:36:18 -0800, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Sat, 21 Nov 2015 05:01:53 -0600, Robert Wessel
>>> <robertwessel2@yahoo.com> wrote:
>>>
>>>> On Fri, 20 Nov 2015 13:49:10 -0800, Tim Rentsch
>>>> <txr@alumni.caltech.edu> wrote:
>>>>
>>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>>
>>>>>> On Tue, 17 Nov 2015 16:41:22 +0100, David Brown
>>>>>> <david.brown@hesbynett.no> wrote:
>>>>>>
>>>>>>> On 17/11/15 15:20, supercat@casperkitty.com wrote:
>>>>>>>
>>>>>>>> On a lot of small-system compilers, memcpy is horribly inefficient.
>>>>>>>
>>>>>>> And on a lot of systems, it is very efficient - because the compiler
>>>>>>> will optimise it inline, using all the information available about
>>>>>>> alignment, etc. And for more limited compilers, there is no problem
>>>>>>> anyway because they don't do much optimisation. You can't have it both
>>>>>>> ways.
>>>>>>>
>>>>>>>> Besides, in C99 memcpy() can apply the effective type of the source to the
>>>>>>>> destination, so
>>>>>>>>
>>>>>>>> void *p1 = malloc(4), *p2=malloc(4);
>>>>>>>> *((float*)p1) = 12.34;
>>>>>>>> memcpy(p2,p1,4);
>>>>>>>> int q=*((int*)p2);
>>>>>>>>
>>>>>>>> would still yield UB.
>>>>>>>
>>>>>>> Code like that fails any sort of code review. I really don't
>>>>>>> /care/ if the compiler sees that as undefined behaviour or not -
>>>>>>> the code is /wrong/.
>>>>>>>
>>>>>>> Write your code sensibly, using proper types and proper code
>>>>>>> structure. Here's a hint to get you started - if you are using
>>>>>>> void* explicitly, or casting your pointer types, your code is
>>>>>>> probably bad or at least warrants special care.
>>>>>>>
>>>>>>> (That's enough of this nonsense for me. I am happy writing code
>>>>>>> that has defined behaviour and works efficiently and correctly.
>>>>>>> I don't need to concern myself about hypothetical function
>>>>>>> specifications, badly structured programs, and paranoia.)
>>>>>>
>>>>>> So I take it you really don't like the famous fast inverse square
>>>>>> root hack?
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Fast_inverse_square_root
>>>>>
>>>>> This algorithm can be implemented both efficiently and correctly
>>>>> using unions rather than pointer casting.
>>>>
>>>> FSVO "correctly". Only if you know the layout of both the FP and
>>>> integer field.
>>>
>>> And, of course, writing to one union member and reading from the
>>> other is undefined.
>>
>> Given the followups, have you changed your view on this? I agree
>> with the downstream comments made by Keith Thompson and James
>> Kuyper - the behavior depends on implementation-defined aspects,
>> but otherwise is defined, assuming the type for reading has no
>> trap representations.
>
> Yes...
>
> There was a semi-recent discussion about a common pattern somewhere
> along these lines (and I though it was this, but I appear to have
> misremembered), where the actual portable construct required a memcpy.
>
> And, I finally managed to dredge up the thread. It's changing the
> access type by casting the type of a pointer. IOW, it's the following
> which is undefined:
>
> inline uint32_t float2unsigned(float f)
> {
> return *(uint32_t *) &f;
> }
Right, that's undefined behavior. The function body can be made
into (implemenation-specific) defined behavior by using a union:
inline uint32_t float2unsigned(float f)
{
return (union { float f; uint32_t u; }){ f }.u;
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-22 14:23 -0800 |
| Message-ID | <kfnk2p965d5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76749 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Fri, 20 Nov 2015 13:49:10 -0800, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> Robert Wessel <robertwessel2@yahoo.com> writes: >> >>> On Tue, 17 Nov 2015 16:41:22 +0100, David Brown >>> <david.brown@hesbynett.no> wrote: >>> >>>> On 17/11/15 15:20, supercat@casperkitty.com wrote: >>>> >>>>> On a lot of small-system compilers, memcpy is horribly inefficient. >>>> >>>> And on a lot of systems, it is very efficient - because the compiler >>>> will optimise it inline, using all the information available about >>>> alignment, etc. And for more limited compilers, there is no problem >>>> anyway because they don't do much optimisation. You can't have it both >>>> ways. >>>> >>>>> Besides, in C99 memcpy() can apply the effective type of the source to the >>>>> destination, so >>>>> >>>>> void *p1 = malloc(4), *p2=malloc(4); >>>>> *((float*)p1) = 12.34; >>>>> memcpy(p2,p1,4); >>>>> int q=*((int*)p2); >>>>> >>>>> would still yield UB. >>>> >>>> Code like that fails any sort of code review. I really don't >>>> /care/ if the compiler sees that as undefined behaviour or not - >>>> the code is /wrong/. >>>> >>>> Write your code sensibly, using proper types and proper code >>>> structure. Here's a hint to get you started - if you are using >>>> void* explicitly, or casting your pointer types, your code is >>>> probably bad or at least warrants special care. >>>> >>>> (That's enough of this nonsense for me. I am happy writing code >>>> that has defined behaviour and works efficiently and correctly. >>>> I don't need to concern myself about hypothetical function >>>> specifications, badly structured programs, and paranoia.) >>> >>> So I take it you really don't like the famous fast inverse square >>> root hack? >>> >>> https://en.wikipedia.org/wiki/Fast_inverse_square_root >> >> This algorithm can be implemented both efficiently and correctly >> using unions rather than pointer casting. > > FSVO "correctly". Only if you know the layout of both the FP and > integer field. Right, I meant correctly under the same platform assumptions as the original (sizes, representations, and layouts of the two types involved). The key point is that it depends only on implementation-defined behavior, not undefined behavior, and that the generated code will (under modest optimization settings) be the same as the pointer-type-punning method.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-17 10:24 -0800 |
| Message-ID | <kfn37w4o56e.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76167 |
David Brown <david.brown@hesbynett.no> writes: > Code that /requires/ -fno-strict-alias is broken code. Nonsense. This is like saying code that assumes uint8_t is the same type as unsigned char is broken code. It isn't portable, but it isn't necessarily broken either.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web