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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-18 15:40 +0100 |
| Message-ID | <n2i2g6$t8l$1@dont-email.me> |
| In reply to | #76259 |
On 17/11/15 19:24, Tim Rentsch wrote: > 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. > I use the term "broken code" in quite a wide sense - I mean code that I would not consider as good enough quality, and which I would reject during a code review. In the same way, I'd consider excessively hard-to-read code as "broken" even if it works correctly. I appreciate that requiring -fno-strict-alias might occasionally be acceptable in some circumstances, but not until all other possibilities have been considered. (I don't have a problem with non-portable code - much of my code is target specific, so it can be dependent on certain features of the target. So I will usually write "uint8_t" even if "uint_fast8_t" or "uint_least8_t" would be more portable.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-20 16:02 -0800 |
| Message-ID | <kfnziy86wy6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76404 |
David Brown <david.brown@hesbynett.no> writes: > On 17/11/15 19:24, Tim Rentsch wrote: >> 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. > > I use the term "broken code" in quite a wide sense - I mean code > that I would not consider as good enough quality, and which I > would reject during a code review. [...] Well then you should use a different term to describe it, like "personally unacceptable" or something along those lines. The phrase "broken code" is almost always taken to mean code that behaves incorrectly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-21 15:53 +0100 |
| Message-ID | <n2q0d8$j7t$2@dont-email.me> |
| In reply to | #76698 |
On 21/11/15 01:02, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 17/11/15 19:24, Tim Rentsch wrote: >>> 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. >> >> I use the term "broken code" in quite a wide sense - I mean code >> that I would not consider as good enough quality, and which I >> would reject during a code review. [...] > > Well then you should use a different term to describe it, like > "personally unacceptable" or something along those lines. The > phrase "broken code" is almost always taken to mean code that > behaves incorrectly. > If the code requires -fno-strict-alias, then it will behave incorrectly when that flag is not used, or on compilers that don't support such a mode. So the code /is/ broken, at least in those circumstances.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-21 08:58 -0800 |
| Message-ID | <9a1f4cfe-9a3e-4629-b1eb-c3d94f9d6465@googlegroups.com> |
| In reply to | #76772 |
On Saturday, November 21, 2015 at 8:53:51 AM UTC-6, David Brown wrote: > If the code requires -fno-strict-alias, then it will behave incorrectly > when that flag is not used, or on compilers that don't support such a > mode. So the code /is/ broken, at least in those circumstances. And code which requires CHAR_BITS==8 will behave incorrectly on DSPs where CHAR_BITS==16, so such code would be broken, at least in those circumstances. And code which is supposed to play audio won't work correctly on machines which don't have any sound hardware, etc. Certain kinds of code can only be written efficiently in the variant of C which uses -fno-strict-aliasing, and it should be recognized as being a portability constraint like any other, except that most compilers have some means of running (or at least "leisurely strolling") code which would require the flag. At minimum, consider that certain kinds of code would require the ability to use memory as different types at different times in ways that would require calling free() and malloc() between those uses, but there is no requirement that freestanding implementations support malloc*. As a fairly common real- world situation, an implementation might need to use half its RAM as a 16-bit-per-pixel graphics buffer much of the time, but occasionally perform some task which doesn't need the buffer for graphics but needs the RAM for some purpose other than an array of 16-bit integers. Easily doable with -fno-strict-aliasing, but not with any other approach allowed in Standard C. Making the graphics code use 8-bit accesses for everything would pose a huge performance hit there, being unable to pass around any pointers to the graphics data would be rather annoying and cumbersome and may cause a major performance hit unless the compiler can convert indexed accesses to marching pointers or the processor supports indexed addressing as fast as pointer addressing. And rewriting all the other code that uses the memory to use uint16_t or character types even when using 32-bit or floating-point data might sometimes be survivable from a performance perspective, but would go totally against the purpose of using a high-level language in the first place. Using a C variant without those aliasing rules eliminates all those problems. What is sad is that while the Standard acknowledges that malloc() and friends may not be available to code running on a free-standing implementation, it makes no effort to supply any of the facilities or guarantees that would be necessary to allow memory reuse without malloc() and friends. I don't think there is any processor for which a compiler would not be able to implement a __TYPE_ALIAS_BARRIER() directive with the rule that reuse of memory as different types would be illegal *unless* there was a barrier between any two writes of different types, or between any write and read of different types. Given that C was invented for the purpose of systems programming, and one of the primary requirements in systems programming is to be able to perform type-agnostic memory allocation and recycling, I find that omission very odd.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-22 22:14 +0100 |
| Message-ID | <n2tb42$6ml$1@dont-email.me> |
| In reply to | #76780 |
On 21/11/15 17:58, supercat@casperkitty.com wrote: > On Saturday, November 21, 2015 at 8:53:51 AM UTC-6, David Brown wrote: >> If the code requires -fno-strict-alias, then it will behave incorrectly >> when that flag is not used, or on compilers that don't support such a >> mode. So the code /is/ broken, at least in those circumstances. > > And code which requires CHAR_BITS==8 will behave incorrectly on DSPs where > CHAR_BITS==16, so such code would be broken, at least in those circumstances. > And code which is supposed to play audio won't work correctly on machines > which don't have any sound hardware, etc. The difference here is that you are relying on standards-determined implementation-dependent behaviour. It is perfectly reasonably to depend on implementation-dependent behaviour, though you would typically want to document the assumptions somewhere. The kindest thing you can say about code that needs -fno-strict-alias is that use of that flag turns certain undefined behaviour into implementation-dependent behaviour. I suppose if you want to do that, and make it absolutely clear in the code and documentation, then it is not too bad.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-23 03:39 -0800 |
| Message-ID | <kfntwod3py8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76772 |
David Brown <david.brown@hesbynett.no> writes: > On 21/11/15 01:02, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 17/11/15 19:24, Tim Rentsch wrote: >>>> 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. >>> >>> I use the term "broken code" in quite a wide sense - I mean code >>> that I would not consider as good enough quality, and which I >>> would reject during a code review. [...] >> >> Well then you should use a different term to describe it, like >> "personally unacceptable" or something along those lines. The >> phrase "broken code" is almost always taken to mean code that >> behaves incorrectly. > > If the code requires -fno-strict-alias, then it will behave > incorrectly when that flag is not used, or on compilers that don't > support such a mode. So the code /is/ broken, at least in those > circumstances. Any code that works as intended on the platforms it is intended to work on should not be called broken. It might be called non-portable, platform-specific, implementation-dependent, misusing of undefined behavior, an accident waiting to happen, insanely presumptuous, or any number of other descriptive terms. But not broken. The situation described above parallels the example given upthread regarding uint8_t; if we're going to call the type of code describe above broken then we would also have to call code that you write using uint8_t broken. Neither of these situations merits the term "broken code", since AFAIK that just isn't what most people take the term to mean.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-23 13:24 +0000 |
| Message-ID | <5653132f.9476906@news.xs4all.nl> |
| In reply to | #76980 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > David Brown <david.brown@hesbynett.no> writes: > > > If the code requires -fno-strict-alias, then it will behave > > incorrectly when that flag is not used, or on compilers that don't > > support such a mode. So the code /is/ broken, at least in those > > circumstances. > > Any code that works as intended on the platforms it is intended > to work on should not be called broken. It might be called > non-portable, platform-specific, implementation-dependent, > misusing of undefined behavior, an accident waiting to happen, > insanely presumptuous, or any number of other descriptive terms. > But not broken. Only if there is a good reason why it would require those restrictions, _and_ they're documented. -fno-strict-alias is self-documenting, but I have yet to find a _good_ reason why it should be needed. Lazy reasons, yes, aplenty. But not good ones. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-26 09:39 -0800 |
| Message-ID | <kfnvb8o1wzb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76987 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> David Brown <david.brown@hesbynett.no> writes: >> >>> If the code requires -fno-strict-alias, then it will behave >>> incorrectly when that flag is not used, or on compilers that don't >>> support such a mode. So the code /is/ broken, at least in those >>> circumstances. >> >> Any code that works as intended on the platforms it is intended >> to work on should not be called broken. It might be called >> non-portable, platform-specific, implementation-dependent, >> misusing of undefined behavior, an accident waiting to happen, >> insanely presumptuous, or any number of other descriptive terms. >> But not broken. > > Only if there is a good reason why it would require those > restrictions, _and_ they're documented. -fno-strict-alias is > self-documenting, but I have yet to find a _good_ reason why it > should be needed. Lazy reasons, yes, aplenty. But not good > ones. There are two distinct concerns involved here, and it's important to keep them separated. I might agree that code that relies on -fno-strict-alias has made a poor choice, or even an awful choice. Even so, that doesn't make the code broken. The word broken should be limited to cases where code objectively exhibits erroneous behavior; it should never rely on subjective assessment. To do otherwise starts down a slippery slope to a point of meaninglessness - someone might call code "broken" if it has an out-of-place semicolon. Or, what might be worse, the uncertainty ignites flame wars about where the boundary should be drawn (and whose subjective assessment defines it). To keep the meaning crisp, it is best to limit the use of "broken" - a hard-edged word - to cases that are similarly sharply delineated. There are plenty of other, fuzzier adjectives available for describing other, fuzzier kinds of non-goodness. If something is broken that means it doesn't work. That simple definition should be preserved when applying the word to software.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-11-26 13:16 -0600 |
| Message-ID | <7ole5bd5r441sv4ck5v3u4tpa7rr3n2npv@4ax.com> |
| In reply to | #77217 |
On Thu, 26 Nov 2015 09:39:20 -0800, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>raltbos@xs4all.nl (Richard Bos) writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> If the code requires -fno-strict-alias, then it will behave
>>>> incorrectly when that flag is not used, or on compilers that don't
>>>> support such a mode. So the code /is/ broken, at least in those
>>>> circumstances.
>>>
>>> Any code that works as intended on the platforms it is intended
>>> to work on should not be called broken. It might be called
>>> non-portable, platform-specific, implementation-dependent,
>>> misusing of undefined behavior, an accident waiting to happen,
>>> insanely presumptuous, or any number of other descriptive terms.
>>> But not broken.
>>
>> Only if there is a good reason why it would require those
>> restrictions, _and_ they're documented. -fno-strict-alias is
>> self-documenting, but I have yet to find a _good_ reason why it
>> should be needed. Lazy reasons, yes, aplenty. But not good
>> ones.
>
>There are two distinct concerns involved here, and it's important
>to keep them separated.
>
>I might agree that code that relies on -fno-strict-alias has made
>a poor choice, or even an awful choice. Even so, that doesn't
>make the code broken. The word broken should be limited to cases
>where code objectively exhibits erroneous behavior; it should
>never rely on subjective assessment. To do otherwise starts down
>a slippery slope to a point of meaninglessness - someone might
>call code "broken" if it has an out-of-place semicolon. Or, what
>might be worse, the uncertainty ignites flame wars about where
>the boundary should be drawn (and whose subjective assessment
>defines it). To keep the meaning crisp, it is best to limit the
>use of "broken" - a hard-edged word - to cases that are similarly
>sharply delineated. There are plenty of other, fuzzier adjectives
>available for describing other, fuzzier kinds of non-goodness.
>If something is broken that means it doesn't work. That simple
>definition should be preserved when applying the word to software.
That seems too strict. It would be similar to calling a (broken)
clock not broken at those two times each day it displays the right
time. Code that's working only because of an accident of the build
and environment would really be hard to consider working. Consider
the following:
void f()
{
int a=1, b=2, c=3, d=4;
...
}
void g()
{
int x;
... /* no assignment to x */
if (x < 10)
... /* we want to do this */
}
void h()
{
f();
g();
}
In many, perhaps most, implementations (and assuming the variables are
not optimized out) the condition in g() will be true then g() is
called from h() because of the particular stack "garbage" left by the
preceding call to f(). Presuming that the condition being true is the
desired/"correct" behavior, I'd still call the code in g() badly
broken, despite its high likelihood of actually working the way I
wanted. And like the broken clock, this can be changed to produce
actually incorrect results by action totally outside g() - changing
f() or putting code between the two calls in h(), for example.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-26 12:25 -0800 |
| Message-ID | <df203ffd-ad7c-406b-a010-91997677bafc@googlegroups.com> |
| In reply to | #77219 |
On Thursday, November 26, 2015 at 1:15:14 PM UTC-6, robert...@yahoo.com wrote:
> On Thu, 26 Nov 2015 09:39:20 -0800, Tim Rentsch
> >I might agree that code that relies on -fno-strict-alias has made
> >a poor choice, or even an awful choice. Even so, that doesn't
> >make the code broken.
>
> That seems too strict. It would be similar to calling a (broken)
> clock not broken at those two times each day it displays the right
> time. Code that's working only because of an accident of the build
> and environment would really be hard to consider working.
The use of -fno-strict-aliasing is not an "accident of the build
environment". Instead, it is a deliberate specification that the code
is written in a superset of C which is extended by allowing the bits
used to store objects of any type to be interpreted as bits representing
any other and applying memory ordering which is more precise than what
can be specified in C. For example, using -fno-strict-aliasing, the
following construct would be safe:
uint8_t dma_buffer[256];
while(DMA->BUSY)
; // Ensure that any previous operation is complete
memcpy(dma_buffer, src, size);
DMA->SRC = dma_buffer; // Hypothetical simplified DMA hardware
DMA->DEST = IO_DEVICE;
DMA->COUNT = size; // Start another DMA operation
When not using -fno-strict-aliasing, however, there is no ordering relation
between volatile and non-volatile writes, so the code would need to be
rewritten as something like:
unsigned char volatile dma_buffer[256];
while(DMA->BUSY)
; // Ensure that any previous operation is complete
for (int i=0; i<size; i++)
dma_buffer[i] = src[size]; // Can't use memcpy!
DMA->SRC = dma_buffer; // Hypothetical simplified DMA hardware
DMA->DEST = IO_DEVICE;
DMA->COUNT = size; // Start another DMA operation
Note that while memcpy could use any combination of byte, halfword, word,
or larger accesses, the compiler would be required to perform the accesses
to dma_buffer exactly as given.
> Consider the following:
[example of code using uninitialized variable]
Any code whose behavior would be affected by the content of an uninitialized
variable is broken. A more interesting scenario would be with a function
that returns an Indeterminate value in some cases where the value is going
to be ignored by the caller. Code to return a specific value could in many
cases not be eliminated by an optimizer even if callers didn't care what
value was returned. If there existed a standard means of explicitly
returning an indeterminate value, code using that directive could be just as
efficient as would be possible on compilers which allowed code to do so
implicitly; otherwise, requiring code to return an explicitly-specified
value even when the caller is known not to care would go against efforts to
improve efficiency.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 14:34 -0800 |
| Message-ID | <kfny4djxeaa.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77219 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Thu, 26 Nov 2015 09:39:20 -0800, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> raltbos@xs4all.nl (Richard Bos) writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> If the code requires -fno-strict-alias, then it will behave
>>>>> incorrectly when that flag is not used, or on compilers that don't
>>>>> support such a mode. So the code /is/ broken, at least in those
>>>>> circumstances.
>>>>
>>>> Any code that works as intended on the platforms it is intended
>>>> to work on should not be called broken. It might be called
>>>> non-portable, platform-specific, implementation-dependent,
>>>> misusing of undefined behavior, an accident waiting to happen,
>>>> insanely presumptuous, or any number of other descriptive terms.
>>>> But not broken.
>>>
>>> Only if there is a good reason why it would require those
>>> restrictions, _and_ they're documented. -fno-strict-alias is
>>> self-documenting, but I have yet to find a _good_ reason why it
>>> should be needed. Lazy reasons, yes, aplenty. But not good
>>> ones.
>>
>> There are two distinct concerns involved here, and it's important
>> to keep them separated.
>>
>> I might agree that code that relies on -fno-strict-alias has made
>> a poor choice, or even an awful choice. Even so, that doesn't
>> make the code broken. The word broken should be limited to cases
>> where code objectively exhibits erroneous behavior; it should
>> never rely on subjective assessment. To do otherwise starts down
>> a slippery slope to a point of meaninglessness - someone might
>> call code "broken" if it has an out-of-place semicolon. Or, what
>> might be worse, the uncertainty ignites flame wars about where
>> the boundary should be drawn (and whose subjective assessment
>> defines it). To keep the meaning crisp, it is best to limit the
>> use of "broken" - a hard-edged word - to cases that are similarly
>> sharply delineated. There are plenty of other, fuzzier adjectives
>> available for describing other, fuzzier kinds of non-goodness.
>> If something is broken that means it doesn't work. That simple
>> definition should be preserved when applying the word to software.
>
> That seems too strict. It would be similar to calling a (broken)
> clock not broken at those two times each day it displays the right
> time. Code that's working only because of an accident of the
> build and environment would really be hard to consider working.
> Consider the following:
>
>
> void f()
> {
> int a=1, b=2, c=3, d=4;
> ...
> }
>
> void g()
> {
> int x;
> ... /* no assignment to x */
> if (x < 10)
> ... /* we want to do this */
> }
>
> void h()
> {
> f();
> g();
> }
>
> In many, perhaps most, implementations (and assuming the variables
> are not optimized out) the condition in g() will be true then g()
> is called from h() because of the particular stack "garbage" left
> by the preceding call to f(). Presuming that the condition being
> true is the desired/"correct" behavior, I'd still call the code in
> g() badly broken, despite its high likelihood of actually working
> the way I wanted. And like the broken clock, this can be changed
> to produce actually incorrect results by action totally outside
> g() - changing f() or putting code between the two calls in h(),
> for example.
I understand your point, and I don't completely disagree with it.
In another response I used the phrase "reliably works correctly
on its intended targets", which does not apply to the situation
you describe above. I still think it is somewhat misleading to
call the program broken; off the top of my head I'd be inclined
to say "flawed" or "defective", probably something like that. I
think my key point here is that there are different levels and
different kinds of "bad" code, and we shouldn't use the same word
for all of them, or even most or many. Communication is improved
by choosing an adjective that more closely and more precisely
matches the situation it is meant to characterize.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-26 12:39 -0800 |
| Message-ID | <8daca748-4bf8-4aea-a80f-f169a56a3049@googlegroups.com> |
| In reply to | #77217 |
On Thursday, November 26, 2015 at 5:39:42 PM UTC, Tim Rentsch wrote: > > I might agree that code that relies on -fno-strict-alias has made > a poor choice, or even an awful choice. Even so, that doesn't > make the code broken. The word broken should be limited to cases > where code objectively exhibits erroneous behavior; it should > never rely on subjective assessment. #> Code is broken if something breaks it. Code that is guaranteed to execute correctly on a conforming C.xx implementation might break under C.yy. For example any code that uses the standard string library will break under Microsoft with default deprecation. It's usually conforming code, but Microsoft have said it is too dangerous. But if nothing breaks it, it's not broken. It might be undefined behaviour, but if all compilers for platforms where the code might have a practical use define the UB to "do the right thing", it won't break.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-27 16:43 +0000 |
| Message-ID | <565887f0.14082140@news.xs4all.nl> |
| In reply to | #77217 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > > Only if there is a good reason why it would require those > > restrictions, _and_ they're documented. -fno-strict-alias is > > self-documenting, but I have yet to find a _good_ reason why it > > should be needed. Lazy reasons, yes, aplenty. But not good > > ones. > > There are two distinct concerns involved here, and it's important > to keep them separated. > > I might agree that code that relies on -fno-strict-alias has made > a poor choice, or even an awful choice. Even so, that doesn't > make the code broken. The word broken should be limited to cases > where code objectively exhibits erroneous behavior; it should > never rely on subjective assessment. To do otherwise starts down > a slippery slope to a point of meaninglessness - someone might > call code "broken" if it has an out-of-place semicolon. Or, what > might be worse, the uncertainty ignites flame wars about where > the boundary should be drawn (and whose subjective assessment > defines it). To keep the meaning crisp, it is best to limit the > use of "broken" - a hard-edged word - to cases that are similarly > sharply delineated. There are plenty of other, fuzzier adjectives > available for describing other, fuzzier kinds of non-goodness. > If something is broken that means it doesn't work. That simple > definition should be preserved when applying the word to software. Call it Broken As Designed, then. Or "not fit for general purpose". Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-27 09:29 -0800 |
| Message-ID | <375a8be9-279c-4b97-9573-d22801e48db5@googlegroups.com> |
| In reply to | #77255 |
On Friday, November 27, 2015 at 4:43:16 PM UTC, Richard Bos wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > Call it Broken As Designed, then. Or "not fit for general purpose". > It's broken when something break it. But only under those circumstances. And it's nothing much to do with what the C standard says. Code breaks for lots of reasons.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 14:18 -0800 |
| Message-ID | <kfn37vrytl3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77255 |
raltbos@xs4all.nl (Richard Bos) writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> raltbos@xs4all.nl (Richard Bos) writes: >> >>> Only if there is a good reason why it would require those >>> restrictions, _and_ they're documented. -fno-strict-alias is >>> self-documenting, but I have yet to find a _good_ reason why it >>> should be needed. Lazy reasons, yes, aplenty. But not good >>> ones. >> >> There are two distinct concerns involved here, and it's important >> to keep them separated. >> >> I might agree that code that relies on -fno-strict-alias has made >> a poor choice, or even an awful choice. Even so, that doesn't >> make the code broken. The word broken should be limited to cases >> where code objectively exhibits erroneous behavior; it should >> never rely on subjective assessment. To do otherwise starts down >> a slippery slope to a point of meaninglessness - someone might >> call code "broken" if it has an out-of-place semicolon. Or, what >> might be worse, the uncertainty ignites flame wars about where >> the boundary should be drawn (and whose subjective assessment >> defines it). To keep the meaning crisp, it is best to limit the >> use of "broken" - a hard-edged word - to cases that are similarly >> sharply delineated. There are plenty of other, fuzzier adjectives >> available for describing other, fuzzier kinds of non-goodness. >> If something is broken that means it doesn't work. That simple >> definition should be preserved when applying the word to software. > > Call it Broken As Designed, then. Or "not fit for general purpose". It's funny: as I was reading your first sentence, the phrase "unsuitable for general use" popped into my head. When I got to the second sentence it was deja vu all over again. :)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-23 22:35 +0000 |
| Message-ID | <n304bu$8gj$1@speranza.aioe.org> |
| In reply to | #76980 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: (snip) > Any code that works as intended on the platforms it is intended > to work on should not be called broken. It might be called > non-portable, platform-specific, implementation-dependent, > misusing of undefined behavior, an accident waiting to happen, > insanely presumptuous, or any number of other descriptive terms. > But not broken. The situation described above parallels the > example given upthread regarding uint8_t; if we're going to call > the type of code describe above broken then we would also have to > call code that you write using uint8_t broken. Neither of these > situations merits the term "broken code", since AFAIK that just > isn't what most people take the term to mean. I would call code that depends on compiler bugs, or even hardware bugs, broken, but agree for all the other ones mentioned. More specifically, depending on code that doesn't do anything non-portable doing something else. For example, say you had a compiler where applying ++ to a float happened to double the value. (That is, apply ++ to the exponent.) Using that in actual code, to me, is broken. (I did once use a compiler with broken ++, but don't remember what it did with it. I believe the Borland compiler.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-23 17:40 -0500 |
| Message-ID | <565395EB.8050803@verizon.net> |
| In reply to | #77035 |
On 11/23/2015 05:35 PM, glen herrmannsfeldt wrote: ... > For example, say you had a compiler where applying ++ to a float > happened to double the value. (That is, apply ++ to the exponent.) > > Using that in actual code, to me, is broken. Was this behavior of ++ intentional and documented? Was it's use by this code intentional? Is this code never intended to be compiled by any compiler that fails to support this behavior? If the answer to all three question is "Yes", I can't accept "broken" as a term for code that reliably, in the context it's intended to be used, works precisely as it was intended to work.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-24 05:35 +0000 |
| Message-ID | <n30svi$nav$1@speranza.aioe.org> |
| In reply to | #77036 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip regarding broken code) (then I wrote) >> For example, say you had a compiler where applying ++ to a float >> happened to double the value. (That is, apply ++ to the exponent.) >> Using that in actual code, to me, is broken. > Was this behavior of ++ intentional and documented? Was it's use by this > code intentional? Is this code never intended to be compiled by any > compiler that fails to support this behavior? If the answer to all three > question is "Yes", I can't accept "broken" as a term for code that > reliably, in the context it's intended to be used, works precisely as it > was intended to work. Well, it was a hypothetical example, so it is hard to say. There have, over the years, been programs that depended on mistakes or undocumented instructions in hardware processors. If popular enough, later versions and emulators need to follow them. A favorite example is the original Microsoft BASIC interpreter that used undocumented flag bits in the 8080. The Z80 defined those bits in a different way, such that MS BASIC won't run. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-25 12:15 -0800 |
| Message-ID | <kfnziy125uu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77035 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > (snip) > >> Any code that works as intended on the platforms it is intended >> to work on should not be called broken. It might be called >> non-portable, platform-specific, implementation-dependent, >> misusing of undefined behavior, an accident waiting to happen, >> insanely presumptuous, or any number of other descriptive terms. >> But not broken. The situation described above parallels the >> example given upthread regarding uint8_t; if we're going to call >> the type of code describe above broken then we would also have to >> call code that you write using uint8_t broken. Neither of these >> situations merits the term "broken code", since AFAIK that just >> isn't what most people take the term to mean. > > I would call code that depends on compiler bugs, or even hardware > bugs, broken, but agree for all the other ones mentioned. > > More specifically, depending on code that doesn't do anything > non-portable doing something else. > > For example, say you had a compiler where applying ++ to a float > happened to double the value. (That is, apply ++ to the exponent.) > > Using that in actual code, to me, is broken. I understand your point, and I share your reaction that such things should be avoided. In most cases I still wouldn't use "broken" to describe it, at least not without some sort of additional phrase or explanation, so as not to unintentionally mislead people about what is meant. Until I think of something better, I propose "corrupt" as an appropriate label for code that intentionally exploits buggy implementations and/or platforms.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-25 22:49 +0000 |
| Message-ID | <n35dtm$3co$1@speranza.aioe.org> |
| In reply to | #77184 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: (snip, I wrote) >> I would call code that depends on compiler bugs, or even hardware >> bugs, broken, but agree for all the other ones mentioned. >> More specifically, depending on code that doesn't do anything >> non-portable doing something else. (snip of example) > I understand your point, and I share your reaction that such > things should be avoided. In most cases I still wouldn't use > "broken" to describe it, at least not without some sort of > additional phrase or explanation, so as not to unintentionally > mislead people about what is meant. Until I think of something > better, I propose "corrupt" as an appropriate label for code that > intentionally exploits buggy implementations and/or platforms. But corrupt reminds me too much of politicians, and I like to keep politics away from programming, and especially C. -- glen
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web