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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-11-21 05:01 -0600 |
| Message-ID | <8nj05bha7qo58upepjqipdds0fgjkl8umb@4ax.com> |
| In reply to | #76684 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-11-21 05:09 -0600 |
| Message-ID | <m4k05bdossoe7criehdedlhgfpv1lml9rp@4ax.com> |
| In reply to | #76749 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-21 03:31 -0800 |
| Message-ID | <ln7flb8u7t.fsf@kst-u.example.com> |
| In reply to | #76750 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> And, of course, writing to one union member and reading from the other
> is undefined.
Incorrect.
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.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-21 17:43 -0600 |
| Message-ID | <n2qvdu$gqi$1@dont-email.me> |
| In reply to | #76754 |
On 21-Nov-15 05:31, Keith Thompson wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: >> And, of course, writing to one union member and reading from the >> other is undefined. > > Incorrect. > > 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, which is the very definition of an indeterminate value. Reading an indeterminate value invokes undefined behavior, even if it happens to _not_ be a trap representation. 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-21 16:00 -0800 |
| Message-ID | <lnegfi6gyc.fsf@kst-u.example.com> |
| In reply to | #76811 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 21-Nov-15 05:31, Keith Thompson wrote:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>> And, of course, writing to one union member and reading from the
>>> other is undefined.
>>
>> Incorrect.
>>
>> 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, which is the very definition of an
> indeterminate value. Reading an indeterminate value invokes undefined
> behavior, even if it happens to _not_ be a trap representation.
For integer types, it's possible to prove that there are no trap
representations by examining the size and range. Structure and
union types have no trap representations.
The reinterpreted value *might not* be a trap representation,
and if it isn't then reading it is well defined.
If accessing a different member of a union were intended to have
undefined behavior, I don't think the standard would bother to
specify how the representation is reinterpreted.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-22 01:12 -0600 |
| Message-ID | <n2rpp2$g7k$1@dont-email.me> |
| In reply to | #76813 |
On 21-Nov-15 18:00, Keith Thompson wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> On 21-Nov-15 05:31, Keith Thompson wrote: >>> Robert Wessel <robertwessel2@yahoo.com> writes: >>>> And, of course, writing to one union member and reading from >>>> the other is undefined. >>> >>> Incorrect. >>> >>> 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, which is the very definition >> of an indeterminate value. Reading an indeterminate value invokes >> undefined behavior, even if it happens to _not_ be a trap >> representation. > > For integer types, it's possible to prove that there are no trap > representations by examining the size and range. ... but only for integer types that don't actually have any. > Structure and union types have no trap representations. Not themselves, but their members may. > The reinterpreted value *might not* be a trap representation, and if > it isn't then reading it is well defined. Reading an indeterminate value is always UB, even if it happens to not be a trap representation. > If accessing a different member of a union were intended to have > undefined behavior, I don't think the standard would bother to > specify how the representation is reinterpreted. Perhaps that is limited to types without trap representations, which reduces the possibilities to only unspecified values? 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-27 16:42 +0000 |
| Message-ID | <5658851e.13360281@news.xs4all.nl> |
| In reply to | #76813 |
Keith Thompson <kst-u@mib.org> wrote: > Stephen Sprunk <stephen@sprunk.org> writes: > > On 21-Nov-15 05:31, Keith Thompson wrote: > >> Robert Wessel <robertwessel2@yahoo.com> writes: > >>> And, of course, writing to one union member and reading from the > >>> other is undefined. > >> > >> Incorrect. > >> > >> 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, which is the very definition of an > > indeterminate value. Reading an indeterminate value invokes undefined > > behavior, even if it happens to _not_ be a trap representation. > > For integer types, it's possible to prove that there are no trap > representations by examining the size and range. Structure and > union types have no trap representations. > > The reinterpreted value *might not* be a trap representation, > and if it isn't then reading it is well defined. > > If accessing a different member of a union were intended to have > undefined behavior, I don't think the standard would bother to > specify how the representation is reinterpreted. That's technically true, but... It sounds too much like saying that it's not dangerous to cross the highway on foot. What's dangerous is getting hit by a truck! If only you can prove that there will be no truck coming, you'll be just fine. Well, yes, but I'd still prefer children to be taught not to run across the highway, or any other road. Similarly, it's true that accessing a different union member does not _in itself_ have undefined behaviour. It's also true that there are cases (including common ones) where you can prove that the result is also defined. Nevertheless, it's still true that the _general_ result of re-interpreting bytes does have undefined behaviour unless explicit proof to the contrary in that particular case exists. In other words: accessing different union members does not have undefined behaviour, but the general case does _cause_ undefined behaviour further down the line. Exceptions exist and may be many, but (except for unsigned char) are themselves unportable. Running across the highway: Just Say No. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-27 12:38 -0500 |
| Message-ID | <56589500.3090306@verizon.net> |
| In reply to | #77254 |
On 11/27/2015 11:42 AM, Richard Bos wrote: ... > It sounds too much like saying that it's not dangerous to cross the > highway on foot. What's dangerous is getting hit by a truck! If only you > can prove that there will be no truck coming, you'll be just fine. Well, > yes, but I'd still prefer children to be taught not to run across the > highway, or any other road. > Similarly, it's true that accessing a different union member does not > _in itself_ have undefined behaviour. It's also true that there are > cases (including common ones) where you can prove that the result is > also defined. Nevertheless, it's still true that the _general_ result of > re-interpreting bytes does have undefined behaviour unless explicit > proof to the contrary in that particular case exists. > > In other words: accessing different union members does not have > undefined behaviour, but the general case does _cause_ undefined > behaviour further down the line. Exceptions exist and may be many, but > (except for unsigned char) are themselves unportable. Virtually every case where someone deliberately writes such code corresponds to a legitimate exception. No one writes such code unless they have some expectations about what should happen, and those expectations don't come out of nowhere: there are usually systems where those expectations are valid (though it's not at all uncommon for the writer of code to think that such systems are more nearly universal than they actually are). That's what I meant by saying it "corresponds to a legitimate exception" rather than "is a legitimate exception". If the writer expected the code to work in a wider domain than is actually justified, it's not a legitimate exception. However, if you restrict the use of such code to those platforms where those expectations are valid, the implementation-defined representations of the two types combine with 6.5.2.3p3 to fully justify relying upon those expectations in that restricted domain.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-27 11:09 -0800 |
| Message-ID | <22d07741-1941-4830-8890-4f8f27291679@googlegroups.com> |
| In reply to | #77262 |
On Friday, November 27, 2015 at 11:38:17 AM UTC-6, James Kuyper wrote:
> If the
> writer expected the code to work in a wider domain than is actually
> justified, it's not a legitimate exception. However, if you restrict the
> use of such code to those platforms where those expectations are valid,
> the implementation-defined representations of the two types combine with
> 6.5.2.3p3 to fully justify relying upon those expectations in that
> restricted domain.
Unfortunately, for some reason compiler writers often fail to note all the
guarantees they offer beyond what the Standard requires, even in cases where
writing efficient code would be essentially impossible without such
guarantees. As a simple example, consider the following code:
volatile *out_buff_ptr, out_buff_count;
unsigned char out_buffer[256];
// Returns 0 if data enqueued; a negative value on failure
int start_sending(void *src, int n)
{
if (out_buff_count) return; // Previous operation still in progress
memcpy(out_buffer, src, n);
out_buff_ptr = out_storage;
out_buff_count = n;
}
From the point of view of the Standard, the memcpy operation would be
unsequenced relative to the operations involving the volatile variables,
and making "out_buffer" volatile would preclude the use of memcpy on it
at all. For start_sending to be type-agnostic, it would have to copy
data a byte at a time, which would likely take four times as long (if
not longer) than copying it a word at a time. While using memcpy to
copy the data to a uint32_t[] and then using uint32_t operations to copy
that to a volatile uint32_t would be legal, and might be faster than
manually copying to an "unsigned char[]" it would still almost certainly
be slower than the optimal code.
What's needed is a way of having "out_buffer" supply semantics which are
looser than "volatile", but stronger than anything else which C provides
for. The "no strict aliasing" versions of C have such semantics; do you
know of any other way to achieve them efficiently?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-21 19:06 -0500 |
| Message-ID | <56510709.8000908@verizon.net> |
| In reply to | #76811 |
On 11/21/2015 06:43 PM, Stephen Sprunk wrote: > On 21-Nov-15 05:31, Keith Thompson wrote: >> Robert Wessel <robertwessel2@yahoo.com> writes: >>> And, of course, writing to one union member and reading from the >>> other is undefined. >> >> Incorrect. >> >> 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. When you read the value of one member of a union after having set the value of a different member, the key point is that "the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type". That is defined behavior - though exactly what the behavior is that it defines depends upon the representation of the two types. "Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined." (6.2.6.1p2) So the implementation-specific representations of those types must be documented, and if you read that documentation you can write such code in a way that relies upon that documentation. You never need to fear reading any unexpected trap representations - because you have enough information to make them expected, when they come up. Such code is not portable, so it must be avoided if portability is sufficiently important. But not all code needs to be perfectly portable. Such code can be perfectly safe on the platforms for which it was written. > ... Reading an indeterminate value invokes undefined > behavior, even if it happens to _not_ be a trap representation. Citation, please? The only argument I know of for undefined behavior from the use of indeterminate values depends upon the fact that a trap representation is a possibility. That argument therefore breaks down if it's a type that is guaranteed to have no trap representations (such as unsigned char) or a type that happens to have no trap representations on the current platform. Now if, for example, you subscript an array with a unspecified value that could in fact be equal to or greater than the length of the array, then the behavior could be undefined - but it is the behavior of the subscript operation that is undefined, not the retrieval of the unspecified value.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-21 17:00 -0800 |
| Message-ID | <32add040-47e0-415c-91fa-fe0fdb131887@googlegroups.com> |
| In reply to | #76814 |
On Saturday, November 21, 2015 at 6:06:42 PM UTC-6, James Kuyper wrote:
> Citation, please? The only argument I know of for undefined behavior
> from the use of indeterminate values depends upon the fact that a trap
> representation is a possibility. That argument therefore breaks down if
> it's a type that is guaranteed to have no trap representations (such as
> unsigned char) or a type that happens to have no trap representations on
> the current platform.
Some types may be stored differently in registers than in memory, and it's
possible for the register format to have trap representations even if the
memory format does not.
As a simple example, given the code:
uint32_t foo(uint32_t mode)
{
uint16_t temp;
switch(mode & 3)
{
case 0: break;
case 1: temp = 1; break;
case 2: temp = 2; break;
case 3: temp = 3; break;
}
switch(mode & 12)
{
case 0: break;
case 4: temp = 4; break;
case 8: temp = 5; break;
case 12: temp = 6; break;
default: break;
}
return temp;
}
A compiler for a 32-bit CPU might very well decide to allocate a 32-bit
register to temp, write that register in any of the cases that write to
temp, and then return the contents of that register to the caller. If
the passed-in value of mode doesn't cause anything to write to temp, then
the function would likely return whatever happened to be in that register
when it was invoked, which might not be in the allowable range of uint16_t.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-22 14:44 +0000 |
| Message-ID | <n2skcb$10d$2@speranza.aioe.org> |
| In reply to | #76819 |
supercat@casperkitty.com wrote: (snip on trap representation) > Some types may be stored differently in registers than in memory, and it's > possible for the register format to have trap representations even if the > memory format does not. The x87 always stores an 80 bit format in registers. I don't remember if it has a trap representation. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-22 01:55 -0600 |
| Message-ID | <n2rs8j$mpf$1@dont-email.me> |
| In reply to | #76814 |
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: >>> Robert Wessel <robertwessel2@yahoo.com> writes: >>>> And, of course, writing to one union member and reading from the >>>> other is undefined. >>> >>> Incorrect. >>> >>> 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. > When you read the value of one member of a union after having set > the value of a different member, the key point is that "the > appropriate part of the object representation of the value is > reinterpreted as an object representation in the new type". That is > defined behavior - though exactly what the behavior is that it > defines depends upon the representation of the two types. ... and, assuming the read member's type _has_ trap representations, that could result in either a valid value or a trap representation. If not, then that leaves only valid values, and there would seem to be no problem--but see below. >> ... 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." 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. > The only argument I know of for undefined behavior from the use of > indeterminate values depends upon the fact that a trap representation > is a possibility. To be fair, that's the only case where I'd expect an actual problem. > That argument therefore breaks down if it's a type that is guaranteed > to have no trap representations (such as unsigned char) or a type that > happens to have no trap representations on the current platform. 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. 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-22 00:03 -0800 |
| Message-ID | <lna8q65um9.fsf@kst-u.example.com> |
| In reply to | #76839 |
Stephen Sprunk <stephen@sprunk.org> writes:
[...]
> 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.
[...]
42 is either a valid value or a trap representation.
The definition of an "indeterminate value" is "either an unspecified
value or a trap representation", and an "unspecified value" is a "valid
value of the relevant type where this International Standard imposes no
requirements on which value is chosen in any instance". The standard
*does* impose some requirements on the value of a union member after a
different union member has been written.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-22 10:18 +0000 |
| Message-ID | <87oaeml4kv.fsf@bsb.me.uk> |
| In reply to | #76840 |
Keith Thompson <kst-u@mib.org> writes: > Stephen Sprunk <stephen@sprunk.org> writes: > [...] >> 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. > [...] > > 42 is either a valid value or a trap representation. > > The definition of an "indeterminate value" is "either an unspecified > value or a trap representation", and an "unspecified value" is a "valid > value of the relevant type where this International Standard imposes no > requirements on which value is chosen in any instance". The standard > *does* impose some requirements on the value of a union member after a > different union member has been written. And a small, but significant, detail I've only recently noticed... 6.2.6.1 p7 says (my emphasis) "When a value is stored in a member of an object of union type, the *bytes* of the object representation that do not correspond to that member but do correspond to other members take unspecified values." It does not say that the other objects take on unspecified values, simply that the bytes of their representations do. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-23 03:21 -0800 |
| Message-ID | <kfny4dp3qsi.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76845 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Keith Thompson <kst-u@mib.org> writes: > >> Stephen Sprunk <stephen@sprunk.org> writes: >> [...] >>> 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. >> >> [...] >> >> 42 is either a valid value or a trap representation. >> >> The definition of an "indeterminate value" is "either an unspecified >> value or a trap representation", and an "unspecified value" is a "valid >> value of the relevant type where this International Standard imposes no >> requirements on which value is chosen in any instance". The standard >> *does* impose some requirements on the value of a union member after a >> different union member has been written. > > And a small, but significant, detail I've only recently noticed... > 6.2.6.1 p7 says (my emphasis) > > "When a value is stored in a member of an object of union type, the > *bytes* of the object representation that do not correspond to that > member but do correspond to other members take unspecified values." > > It does not say that the other objects take on unspecified values, > simply that the bytes of their representations do. Yes, and only those bytes that do not correspond to the member being stored. The bytes that /do/ correspond to the member being stored have their values determined by the object representation of the stored member's new value.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-22 10:53 -0500 |
| Message-ID | <5651E4F7.3060208@verizon.net> |
| In reply to | #76839 |
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. That's not quite true: if the first type has multiple representations for the same value, it might contain any one of those representations, but that's far less uncertainty than applies when the value is indeterminate. >> When you read the value of one member of a union after having set >> the value of a different member, the key point is that "the >> appropriate part of the object representation of the value is >> reinterpreted as an object representation in the new type". That is >> defined behavior - though exactly what the behavior is that it >> defines depends upon the representation of the two types. > > ... and, assuming the read member's type _has_ trap representations, > that could result in either a valid value or a trap representation. Yes, and because the value is not indeterminate, but is instead precisely determined by the combination of 6.5.2.3p3 and the implementation-defined representations of the two types, it's possible for the programmer to know, with a certainty, which valid value it will be, and whether or not it will be a trap representation. That's something that would be impossible with an indeterminate value. > If not, then that leaves only valid values, and there would seem to be > no problem--but see below. > >>> ... 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. 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. 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. > 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? >> The only argument I know of for undefined behavior from the use of >> indeterminate values depends upon the fact that a trap representation >> is a possibility. > > To be fair, that's the only case where I'd expect an actual problem. > >> That argument therefore breaks down if it's a type that is guaranteed >> to have no trap representations (such as unsigned char) or a type that >> happens to have no trap representations on the current platform. > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-22 20:28 -0600 |
| Message-ID | <n2ttfv$6l9$1@dont-email.me> |
| In reply to | #76880 |
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? 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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-22 18:52 -0800 |
| Message-ID | <546b744e-ef61-48e2-bb74-2c4264cda0cd@googlegroups.com> |
| In reply to | #76956 |
On Sunday, November 22, 2015 at 8:28:42 PM UTC-6, Stephen Sprunk wrote:
> 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.
Consider the code:
uint16_t foo(uint32_t hey)
{
uint16_t blah;
if (hey < 65000)
blah = hey;
return blah;
}
The most straightforward translation of that function in ARM code would
allocate a register for "blah" and load that register with the contents of
hey if it's less than 65000. Then, whether the register was loaded or not,
return its contents. This may result in the function returning a uint16_t
value outside the range 0 to 65535--something which cannot happen in any
defined circumstance, and no code has any particular obligations as to what
it might do if it receives such a uint16_t value.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-23 11:58 -0600 |
| Message-ID | <n2vk0m$16t$1@dont-email.me> |
| In reply to | #76958 |
On 22-Nov-15 20:52, supercat@casperkitty.com wrote:
> Stephen Sprunk wrote:
>> 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.
>
> Consider the code:
>
> uint16_t foo(uint32_t hey)
> {
> uint16_t blah;
> if (hey < 65000)
> blah = hey;
> return blah;
> }
>
> The most straightforward translation of that function in ARM code
> would allocate a register for "blah" and load that register with the
> contents of hey if it's less than 65000. Then, whether the register
> was loaded or not, return its contents. This may result in the
> function returning a uint16_t value outside the range 0 to
> 65535--something which cannot happen in any defined circumstance, and
> no code has any particular obligations as to what it might do if it
> receives such a uint16_t value.
There is no such thing as a uint16_t value greater than 65535, but since
the code invokes UB if hey >= 65000, all bets are off anyway.
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.
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]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web