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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-27 16:44 +0000 |
| Message-ID | <5658881d.14127062@news.xs4all.nl> |
| In reply to | #77191 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > 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. Too late. Politics have been involved in C ever since the final clause was added to 5.1.2.2.1#1. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 14:03 -0800 |
| Message-ID | <kfnbnafyu9x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77191 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 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.
If "corrupt" bothers you, there are plenty of other plausible
adjectives to choose from:
crooked
shady
rotten
fraudulent
untrustworthy
reprobate
bent
foul
fast and loose
iniquitous
knavish
perfidious
snide
treacherous
underhanded
unprincipled
exploiting
profiteering
suborned
And those were just on the first synonyms page I looked at.
Surely you could find something suitable. Of these, "bent"
seems fairly appropriate to the case under discussion.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-29 09:29 +0000 |
| Message-ID | <slrnn5lhb3.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77191 |
On Wed, 2015-11-25, glen herrmannsfeldt wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: ... >> 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. Corruption is just a term for agreeing not to do your job properly. It's not endemic to politics. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-22 19:01 +0000 |
| Message-ID | <slrnn5448o.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #76698 |
On Sat, 2015-11-21, 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.
The way I use the term, it includes code that "happens to work" and
may stop working at a compiler/OS upgrade.
I mean, isn't this broken code, even if the stack/register state
accidentally makes it work correctly?
int return_42(void)
{
int a;
return a + 42;
}
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-23 07:31 -0800 |
| Message-ID | <kfnio4s4ts0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76902 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Sat, 2015-11-21, 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.
>
> The way I use the term, it includes code that "happens to work"
> and may stop working at a compiler/OS upgrade.
The way I take your meaning is that, if the implementation does
not explicitly guarantee (as opposed to only implicitly or
accidentally guarantees) the desired behavior, then "broken" is
appropriate. I don't really disagree but I think I still would
prefer a different word in some circumstances. To some extent
it depends on the nature of the transgression.
> I mean, isn't this broken code, even if the stack/register state
> accidentally makes it work correctly?
>
> int return_42(void)
> {
> int a;
> return a + 42;
> }
I understand the sentiment, and agree with it, but still I am
loath to use the term "broken" for code that never exhibits
incorrect behavior. Adjectives that come to mind here, ie, for
this example, are defective, fragile, or unreliable; depending
on circumstances I might use any of those. For me the key point
is not to get hung up on just what word means what, but to choose
a word that has the best chance of conveying the intended meaning
to the listeners. In this particular case I think "defective"
does a better job of that than "broken" (but I hasten to add
that sometimes the choice may depend on the audience being
addressed).
In short - I understand the point you're making (and agree that
it is worth making), even if in some cases I might prefer a
different word choice.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-23 07:43 -0800 |
| Message-ID | <c4af8977-3b45-42a2-ace9-64ac3f915e51@googlegroups.com> |
| In reply to | #76993 |
On Monday, November 23, 2015 at 3:31:26 PM UTC, Tim Rentsch wrote: > > The way I take your meaning is that, if the implementation does > not explicitly guarantee (as opposed to only implicitly or > accidentally guarantees) the desired behavior, then "broken" is > appropriate. I don't really disagree but I think I still would > prefer a different word in some circumstances. To some extent > it depends on the nature of the transgression. > Code is broken by something. The construct char *new = malloc(10); is broken by C++. It's perfectly well formed, standards compliant C. But it breaks when run through a C++ compiler, and so in many contexts it's unacceptable. The construct char name[1204]; strcpy(name, "Fred"); breaks under Microsoft with deprecation on. Again, it's compliant with the standard. The code unsigned char *screen= 0x80000000; breaks under anything except some compiler / platform combinations that character map a screen at 0x80000000, so it can be broken by standards conforming C compilers. But code that functions as wanted isn't broken. It's only broken when it fails to function.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-23 08:17 -0800 |
| Message-ID | <lnsi3w3d28.fsf@kst-u.example.com> |
| In reply to | #76995 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> The code
>
> unsigned char *screen= 0x80000000;
>
> breaks under anything except some compiler / platform combinations that
> character map a screen at 0x80000000, so it can be broken by standards
> conforming C compilers.
Did you mean to write:
unsigned char *screen = (unsigned char*)0x80000000;
? Initializing a pointer with an integer constant (other than a null
pointer constant) is a constraint violation.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-23 17:34 +0100 |
| Message-ID | <n2vf1p$bja$1@dont-email.me> |
| In reply to | #76993 |
On 23/11/15 16:31, Tim Rentsch wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Sat, 2015-11-21, 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.
>>
>> The way I use the term, it includes code that "happens to work"
>> and may stop working at a compiler/OS upgrade.
>
> The way I take your meaning is that, if the implementation does
> not explicitly guarantee (as opposed to only implicitly or
> accidentally guarantees) the desired behavior, then "broken" is
> appropriate. I don't really disagree but I think I still would
> prefer a different word in some circumstances. To some extent
> it depends on the nature of the transgression.
>
>> I mean, isn't this broken code, even if the stack/register state
>> accidentally makes it work correctly?
>>
>> int return_42(void)
>> {
>> int a;
>> return a + 42;
>> }
>
> I understand the sentiment, and agree with it, but still I am
> loath to use the term "broken" for code that never exhibits
> incorrect behavior. Adjectives that come to mind here, ie, for
> this example, are defective, fragile, or unreliable; depending
> on circumstances I might use any of those. For me the key point
> is not to get hung up on just what word means what, but to choose
> a word that has the best chance of conveying the intended meaning
> to the listeners. In this particular case I think "defective"
> does a better job of that than "broken" (but I hasten to add
> that sometimes the choice may depend on the audience being
> addressed).
>
> In short - I understand the point you're making (and agree that
> it is worth making), even if in some cases I might prefer a
> different word choice.
>
I accept your points here - but for some audiences the word choice
"broken" would be appropriate IMHO. In particular, when doing code
reviews with colleagues I would not hesitate to call code that depended
on "-fno-strict-alias" "broken code". But I can agree that in other
circumstances, "broken" is perhaps not the best choice of words, and in
exceptional circumstances such code may even be acceptable as the least
bad option.
(And yes, I know the Linux kernel relies on -fno-strict-alias, and it
works perfectly well. If I were ever to see kernel-style coding for the
types of projects I write, or Linus Torvalds were ever to see my style
of code in the Linux kernel, then "broken" is probably the politest
adjective that we would use! That would, of course, be highly
audience-dependent and non-portable :-) )
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-23 22:02 +0000 |
| Message-ID | <slrnn5737v.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #77004 |
On Mon, 2015-11-23, David Brown wrote: > On 23/11/15 16:31, Tim Rentsch wrote: ["broken code"] >> In short - I understand the point you're making (and agree that >> it is worth making), even if in some cases I might prefer a >> different word choice. > > I accept your points here - but for some audiences the word choice > "broken" would be appropriate IMHO. In particular, when doing code > reviews with colleagues I would not hesitate to call code that depended > on "-fno-strict-alias" "broken code". But I can agree that in other > circumstances, "broken" is perhaps not the best choice of words, and in > exceptional circumstances such code may even be acceptable as the least > bad option. It's a good word IMO because it's slightly provocative and aggressive: it stresses the need to have code not just /accidentally/ work, but work for a /reason/. Of course, it's not always nice to be provocative and aggressive. Also, my "reason" may not be a good enough reason for someone else: -fno-strict-alias above is one example, me writing code some years ago which assumed certain operations were atomic because I was on x86_64, that's another example. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-24 10:12 +0100 |
| Message-ID | <n319hp$a9f$1@dont-email.me> |
| In reply to | #77029 |
On 23/11/15 23:02, Jorgen Grahn wrote: > On Mon, 2015-11-23, David Brown wrote: >> On 23/11/15 16:31, Tim Rentsch wrote: > > ["broken code"] > >>> In short - I understand the point you're making (and agree that >>> it is worth making), even if in some cases I might prefer a >>> different word choice. >> >> I accept your points here - but for some audiences the word choice >> "broken" would be appropriate IMHO. In particular, when doing code >> reviews with colleagues I would not hesitate to call code that depended >> on "-fno-strict-alias" "broken code". But I can agree that in other >> circumstances, "broken" is perhaps not the best choice of words, and in >> exceptional circumstances such code may even be acceptable as the least >> bad option. > > It's a good word IMO because it's slightly provocative and aggressive: > it stresses the need to have code not just /accidentally/ work, but > work for a /reason/. > > Of course, it's not always nice to be provocative and aggressive. > Agreed. Being British, I might actually say "perhaps that code is not structured in quite the ideal way". Translating into American, that would mean "Your code is broken. Redo it from scratch". > Also, my "reason" may not be a good enough reason for someone else: > -fno-strict-alias above is one example, me writing code some years ago > which assumed certain operations were atomic because I was on x86_64, > that's another example. > Yes, things change - as do people, requirements, tools, etc. Last year I was making some changes to a project I wrote nearly 20 years ago, and if I could time-travel I would have had a few serious words to say to my younger self. It is good that the compiler I used at that time was rather limited (and that I almost never change tools in a project) - a modern compiler would tear it apart for its abuses of undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-27 08:39 -0800 |
| Message-ID | <kfnr3jb1jo6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #77004 |
David Brown <david.brown@hesbynett.no> writes:
> On 23/11/15 16:31, Tim Rentsch wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Sat, 2015-11-21, 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.
>>>
>>> The way I use the term, it includes code that "happens to work"
>>> and may stop working at a compiler/OS upgrade.
>>
>> The way I take your meaning is that, if the implementation does
>> not explicitly guarantee (as opposed to only implicitly or
>> accidentally guarantees) the desired behavior, then "broken" is
>> appropriate. I don't really disagree but I think I still would
>> prefer a different word in some circumstances. To some extent
>> it depends on the nature of the transgression.
>>
>>> I mean, isn't this broken code, even if the stack/register state
>>> accidentally makes it work correctly?
>>>
>>> int return_42(void)
>>> {
>>> int a;
>>> return a + 42;
>>> }
>>
>> I understand the sentiment, and agree with it, but still I am
>> loath to use the term "broken" for code that never exhibits
>> incorrect behavior. Adjectives that come to mind here, ie, for
>> this example, are defective, fragile, or unreliable; depending
>> on circumstances I might use any of those. For me the key point
>> is not to get hung up on just what word means what, but to choose
>> a word that has the best chance of conveying the intended meaning
>> to the listeners. In this particular case I think "defective"
>> does a better job of that than "broken" (but I hasten to add
>> that sometimes the choice may depend on the audience being
>> addressed).
>>
>> In short - I understand the point you're making (and agree that
>> it is worth making), even if in some cases I might prefer a
>> different word choice.
>
> I accept your points here - but for some audiences the word choice
> "broken" would be appropriate IMHO. In particular, when doing code
> reviews with colleagues I would not hesitate to call code that depended
> on "-fno-strict-alias" "broken code". But I can agree that in other
> circumstances, "broken" is perhaps not the best choice of words, and in
> exceptional circumstances such code may even be acceptable as the least
> bad option.
Any code that reliably works correctly on its intended targets
should not be described as broken, no matter what audience is
being addressed. I don't think -fno-strict-alias should be
treated differently than any other platform-specific requirement.
I suggest it would help both the discussions and the work if
an effort were made to find a more specific term in the
circumstances you mention.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-14 18:24 +0000 |
| Message-ID | <slrnn4ev21.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75995 |
On Sat, 2015-11-14, Ben Bacarisse wrote: > supercat@casperkitty.com writes: > >> On Tuesday, November 10, 2015 at 1:15:24 PM UTC-6, Alla _ wrote: >>> About C - I am not giving it up. I love it, the more I learn >>> the more I like it. >> >> Make sure you don't look too deeply into anything having to do with strict >> aliasing and GCC if you want to keep loving C. > > How you imagine that someone just learning to program will conclude that > not being able to breaking the type rules of C is to be regretted? Thank you. My more blunt take on this: "supercat" hijacks all kinds of threads to broadcast his message, and that doesn't help me, or newbies like Alla, or himself. IMHO, he should spend that energy and knowledge on helping create free static analysis tools or something. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 12:23 -0800 |
| Message-ID | <lnlha0nxd2.fsf@kst-u.example.com> |
| In reply to | #75991 |
supercat@casperkitty.com writes:
[...]
> Make sure you don't look too deeply into anything having to do with strict
> aliasing and GCC if you want to keep loving C. The authors of C99 included
> some weird restrictions on what programs can do which would have made many
> kinds of useful programs nearly impossible to write except that compilers
> enforced them only narrowly, if at all.
[...]
These restrictions become relevant only when you write code that treats
an object of one type as if it were of a different type, something that
a novice C programmer can safely ignore.
Incidentally, what that a typo, or are there restrictions in C99 that
were not also in C90? As far as know the effective type rules did not
change.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-14 12:36 -0800 |
| Message-ID | <663e513b-b739-4e17-a175-642a3bd49283@googlegroups.com> |
| In reply to | #76013 |
On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote: > > These restrictions become relevant only when you write code that treats > an object of one type as if it were of a different type, something that > a novice C programmer can safely ignore. > Though if you say there is a complete ban on conversion from one type to another, that does raise the question of how to output a floating point number in human-readable form.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 13:13 -0800 |
| Message-ID | <ln6114nv2q.fsf@kst-u.example.com> |
| In reply to | #76019 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote:
>> These restrictions become relevant only when you write code that treats
>> an object of one type as if it were of a different type, something that
>> a novice C programmer can safely ignore.
>>
> Though if you say there is a complete ban on conversion from one
> type to another, that does raise the question of how to output
> a floating point number in human-readable form.
What???
Where in what I wrote did I imply a complete ban on conversion from one
type to another?
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-14 14:04 -0800 |
| Message-ID | <49e74554-a5a2-4441-9676-2e59118b1079@googlegroups.com> |
| In reply to | #76029 |
On Saturday, November 14, 2015 at 9:13:24 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote: > >> These restrictions become relevant only when you write code that treats > >> an object of one type as if it were of a different type, something that > >> a novice C programmer can safely ignore. > >> > > Though if you say there is a complete ban on conversion from one > > type to another, that does raise the question of how to output > > a floating point number in human-readable form. > > What??? > > Where in what I wrote did I imply a complete ban on conversion from one > type to another? > How do you implement the casts if, at some level, you don't treat an object of one type as though it were an object of a different type? Surely, somewhere and somehow, there has to be a re-interpretation of bits?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 14:15 -0800 |
| Message-ID | <ln1tbsns69.fsf@kst-u.example.com> |
| In reply to | #76032 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, November 14, 2015 at 9:13:24 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote:
>> >> These restrictions become relevant only when you write code that treats
>> >> an object of one type as if it were of a different type, something that
>> >> a novice C programmer can safely ignore.
>> >>
>> > Though if you say there is a complete ban on conversion from one
>> > type to another, that does raise the question of how to output
>> > a floating point number in human-readable form.
>>
>> What???
>>
>> Where in what I wrote did I imply a complete ban on conversion from one
>> type to another?
>>
> How do you implement the casts if, at some level, you don't treat an
> object of one type as though it were an object of a different type?
> Surely, somewhere and somehow, there has to be a re-interpretation of
> bits?
It seems likely I'm misunderstanding your point.
A conversion from float to int, for example, can be done either
explicitly with a cast, or implicitly via an implicit conversion. This
does not treat a float object as if it were an int object. As far as a
C programmer is concerned, the conversion just works (it's a fundamental
feature of the language); it doesn't require any reintrepretation, and
you don't have to care how float is represented. And it's not affected
by the effective type rules (or by what are sometimes called strict
aliasing rules).
Output of a floating-point number in human-readable form isn't even a
"conversion" in that sense. It could be done entirely using type-safe
arithmetic operations -- or it might involve some type conversions, none
of which require interpreting an object as if it were of a different
type.
Reinterpreting the representation of an object of one type as if it were
of another type is a completely different operation. It can be done via
a union, using pointer tricks, using memcpy, etc., and it can have
undefined behavior if the effective type rules (N1570 6.5p6-7) are
violated.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-14 14:29 -0800 |
| Message-ID | <40031c30-7a37-495b-990c-af271a82aa2d@googlegroups.com> |
| In reply to | #76035 |
On Saturday, November 14, 2015 at 10:16:07 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Saturday, November 14, 2015 at 9:13:24 PM UTC, Keith Thompson wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote: > >> >> These restrictions become relevant only when you write code that treats > >> >> an object of one type as if it were of a different type, something that > >> >> a novice C programmer can safely ignore. > >> >> > >> > Though if you say there is a complete ban on conversion from one > >> > type to another, that does raise the question of how to output > >> > a floating point number in human-readable form. > >> > >> What??? > >> > >> Where in what I wrote did I imply a complete ban on conversion from one > >> type to another? > >> > > How do you implement the casts if, at some level, you don't treat an > > object of one type as though it were an object of a different type? > > Surely, somewhere and somehow, there has to be a re-interpretation of > > bits? > > It seems likely I'm misunderstanding your point. > > A conversion from float to int, for example, can be done either > explicitly with a cast, or implicitly via an implicit conversion. This > does not treat a float object as if it were an int object. As far as a > C programmer is concerned, the conversion just works (it's a fundamental > feature of the language); it doesn't require any reintrepretation, and > you don't have to care how float is represented. And it's not affected > by the effective type rules (or by what are sometimes called strict > aliasing rules). > > Output of a floating-point number in human-readable form isn't even a > "conversion" in that sense. It could be done entirely using type-safe > arithmetic operations -- or it might involve some type conversions, none > of which require interpreting an object as if it were of a different > type. > > Reinterpreting the representation of an object of one type as if it were > of another type is a completely different operation. It can be done via > a union, using pointer tricks, using memcpy, etc., and it can have > undefined behavior if the effective type rules (N1570 6.5p6-7) are > violated. > OK, so let's imagine a processor with software floating point. So a float is 32 bit type with the following pattern 1 bit 8 bits 23 bits sign | exponent | mantissa The value equals (1 - (2 * sign)) * 2 ^(exponent-127) * 1 + mantissa/(2^23), treating all fields as unsigned binary integers, with a special rule for 0 (all bits zero). We'll say the software implementation doesn't bother with denormals or infinity or NaN. So how to we implement the cast of a float to an int?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 15:39 -0800 |
| Message-ID | <lnwptkm9q3.fsf@kst-u.example.com> |
| In reply to | #76038 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, November 14, 2015 at 10:16:07 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Saturday, November 14, 2015 at 9:13:24 PM UTC, Keith Thompson wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >> > On Saturday, November 14, 2015 at 8:24:01 PM UTC, Keith Thompson wrote:
>> >> >> These restrictions become relevant only when you write code that treats
>> >> >> an object of one type as if it were of a different type, something that
>> >> >> a novice C programmer can safely ignore.
>> >> >>
>> >> > Though if you say there is a complete ban on conversion from one
>> >> > type to another, that does raise the question of how to output
>> >> > a floating point number in human-readable form.
>> >>
>> >> What???
>> >>
>> >> Where in what I wrote did I imply a complete ban on conversion from one
>> >> type to another?
>> >>
>> > How do you implement the casts if, at some level, you don't treat an
>> > object of one type as though it were an object of a different type?
>> > Surely, somewhere and somehow, there has to be a re-interpretation of
>> > bits?
>>
>> It seems likely I'm misunderstanding your point.
>>
>> A conversion from float to int, for example, can be done either
>> explicitly with a cast, or implicitly via an implicit conversion. This
>> does not treat a float object as if it were an int object. As far as a
>> C programmer is concerned, the conversion just works (it's a fundamental
>> feature of the language); it doesn't require any reintrepretation, and
>> you don't have to care how float is represented. And it's not affected
>> by the effective type rules (or by what are sometimes called strict
>> aliasing rules).
>>
>> Output of a floating-point number in human-readable form isn't even a
>> "conversion" in that sense. It could be done entirely using type-safe
>> arithmetic operations -- or it might involve some type conversions, none
>> of which require interpreting an object as if it were of a different
>> type.
>>
>> Reinterpreting the representation of an object of one type as if it were
>> of another type is a completely different operation. It can be done via
>> a union, using pointer tricks, using memcpy, etc., and it can have
>> undefined behavior if the effective type rules (N1570 6.5p6-7) are
>> violated.
>>
> OK, so let's imagine a processor with software floating point.
>
> So a float is 32 bit type with the following pattern
>
> 1 bit 8 bits 23 bits
> sign | exponent | mantissa
>
> The value equals (1 - (2 * sign)) * 2 ^(exponent-127) * 1 + mantissa/(2^23),
>
> treating all fields as unsigned binary integers, with a special
> rule for 0 (all bits zero). We'll say the software implementation
> doesn't bother with denormals or infinity or NaN.
>
> So how to we implement the cast of a float to an int?
Sure, there's a lower level that has to deal with the bits. What does
that have to do with the point being discussed?
supercat warned Alla that the restrictions on "strict aliasing" are a
problem. I pointed out the restrictions do not apply in any code she's
likely to be concerned with any time soon.
How do you convert a float to int?
float f = 42.0;
int i = f;
How do you print a human-readable representation of a float value?
printf("%f\n", f);
How are strict aliasing / effective type rules relevant to any of this?
My point is that Alla, and other novice C programmers, don't need to
worry about any of that. (I rarely worry about it myself.)
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-14 16:37 -0800 |
| Message-ID | <55613c36-e3f3-4b26-b654-4b543e1acfdb@googlegroups.com> |
| In reply to | #76047 |
On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> How do you convert a float to int?
>
> float f = 42.0;
> int i = f;
>
> How do you print a human-readable representation of a float value?
>
> printf("%f\n", f);
>
> How are strict aliasing / effective type rules relevant to any of this?
> My point is that Alla, and other novice C programmers, don't need to
> worry about any of that. (I rarely worry about it myself.)
>
If you're content to say they work by magic, then fair enough.
But if you want to understand what's going on, you have to
explain it in terms of reinterpretation of bits, or aliasing.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web