Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #53464 > unrolled thread
| Started by | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| First post | 2014-11-26 21:54 +0100 |
| Last post | 2014-12-19 02:34 +0100 |
| Articles | 20 on this page of 177 — 31 participants |
Back to article view | Back to comp.lang.c
the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:54 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:56 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:45 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:52 +0100
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-01 23:25 -0500
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-02 00:56 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-04 14:52 +0100
Re: the language "Osmium" <r124c4u102@comcast.net> - 2014-12-04 08:07 -0600
Re: the language Geoff <geoff@invalid.invalid> - 2014-12-04 10:20 -0800
Re: the language Mark Storkamp <mstorkamp@yahoo.com> - 2014-11-26 15:11 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:16 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:18 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:12 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-27 00:37 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-27 01:13 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-11-26 22:45 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 07:41 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 08:12 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-27 01:43 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:56 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 09:08 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 20:58 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 19:22 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-02 02:59 +0100
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 02:53 +0000
Re: the language Les Cargill <lcargill99@comcast.com> - 2014-12-01 21:25 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 06:22 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-27 08:37 +0000
Re: the language Reinhardt Behm <rbehm@hushmail.com> - 2014-11-27 16:44 +0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-27 15:35 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-27 11:58 -0500
Re: the language jt@toerring.de (Jens Thoms Toerring) - 2014-11-27 22:44 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 09:52 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 12:53 -0800
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 10:07 +0100
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 14:57 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:09 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:01 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 14:46 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:16 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 22:09 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:40 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 14:42 -0800
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:22 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 23:09 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 16:14 -0800
Re: the language BartC <bc@freeuk.com> - 2014-11-29 01:42 +0000
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 01:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 04:03 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-01 00:55 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-02 05:42 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-28 19:25 -0500
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-01 14:02 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-05 10:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 08:25 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 10:44 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 19:17 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 15:48 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 05:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:27 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-08 06:00 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 06:17 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:37 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 12:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 12:43 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 14:46 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 00:23 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-17 07:01 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 07:22 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-17 11:56 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-17 05:43 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:30 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:41 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 14:34 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 02:15 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:31 -0500
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:19 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 07:52 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:21 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:15 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 07:48 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 07:40 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 12:54 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 09:54 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 15:19 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:00 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:13 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:27 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:45 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:48 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 19:10 +0000
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:17 -0600
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:32 -0600
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 16:49 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:00 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:57 -0500
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 14:31 -0800
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 20:29 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 20:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 15:45 +0000
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 16:50 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:24 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:07 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:04 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-18 08:06 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-18 08:30 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 00:11 -0500
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-19 07:00 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-19 08:43 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 23:29 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 00:37 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-20 08:45 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-20 09:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-20 03:17 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 06:09 -0800
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:30 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:23 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-18 08:18 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-20 12:22 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-20 13:36 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:43 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:37 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:10 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:02 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-21 22:02 +0000
Re: the language Stephen Sprunk <stephen@sprunk.org> - 2014-12-21 23:49 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-21 17:45 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:29 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-20 05:29 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:32 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:23 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-22 23:39 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:22 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-19 09:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:48 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 02:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 08:31 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 09:31 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 10:10 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 07:08 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-20 06:39 +0000
Re: the language John Forkosh <forkosh@panix.com> - 2014-12-20 07:32 +0000
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 17:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-04 12:40 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 18:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 09:47 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-05 15:14 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-05 08:42 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-06 00:14 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:19 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2015-01-04 15:59 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-04 14:30 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:44 -0800
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:36 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:07 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-02 23:16 +0100
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-03 02:23 -0800
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-03 15:55 +0100
Re: the language Nobody <nobody@nowhere.invalid> - 2014-12-03 15:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 04:49 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 09:07 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 10:08 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 11:49 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-05 12:32 +0100
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-04 22:17 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:17 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:12 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:15 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:50 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-19 02:34 +0100
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-19 20:29 +0000 |
| Message-ID | <87lhm3tmc5.fsf@bsb.me.uk> |
| In reply to | #55089 |
Richard Heathfield <invalid@see.sig.invalid> writes:
> Ben Bacarisse wrote:
>
>> Richard Heathfield <invalid@see.sig.invalid> writes:
>>
>>> Ben Bacarisse wrote:
>>>
>>>> Richard Heathfield <invalid@see.sig.invalid> writes:
>>>>
>>> <snip>
>>>
>>>>>> What does C-locked-down look like?
>>>>>
>>>>> Exactly like C, except that every single possible undefined behaviour
>>>>> is removed from the language, either by making the construct illegal or
>>>>> defining exactly what must happen (or, perhaps, by making it
>>>>> unspecified or implementation-defined or locale-specific). How,
>>>>> exactly, that would work out in practice is left as an exercise for the
>>>>> reader (which, in this case, means that I have no idea!).
>>>>
>>>> How will this necessarily prevent you from adding "functionality
>>>> unanticipated by the language designers"? I am really at a loss seeing
>>>> the problem that you apparently see. Maybe an example with your
>>>> position-measuring device would help...
>>>
>>> You're right. But someone else needs to come up with the code for it,
>>> because I don't see any way to write that code except by relying on
>>> undefined behaviour. It simply can't be done in standard, locked-down,
>>> no-UB C.
>>
>> Let me propose a few methods to get the position from your hypothetical
>> new position detector. You can then say why a locked-down C *must*
>> prohibit all of them.
>
> Knowing you as I do (i.e. enough to know that you're nobody's fool), I
> suspect that a locked-down C needn't prohibit any of
> them. Nevertheless...
I am puzzled, then, why you answered in the way you did. It seems rude
to ignore your reply, but if you suspect none of them need be prohibited
in your re-imagined C, I may just be wasting my time...
>> (1) #include "tripos.h"
>> ...
>> struct 3D_pos p = tripos_get_cur_pos();
>
> Doesn't compile here. Can you please show tripos.h and the code for
> tripos_get_cur_pos()?
I did not intend to use a bad struct tag, if that's the point you are
making. It was just a typo.
And of course I can show you the contents of tripos.h and the code for
tripos_get_cur_pos but that's just busy work for me if you won't start
to make your point. Is it your contention that an ordinary external
function declaration and a call to a function written in, say, DS9000
assembler can not possibly be given a meaning in your new C?
> (BTW "tripos" is an *excellent* name for the device! All we have to do now
> is build one...)
>
>> (2) FILE *dev = fopen("dev://tri-position-finder", "rb");
>
> Nice try, but my DeathStation 9000 doesn't have a dev://tri-position-finder
> file, so this code isn't going to achieve its objective.
This is not portable code.
> And much the same objections can be made to all your examples. Do I need to
> keep going? Okay, I'll keep going.
No, please don't keep going. At least not unless you are going to make
a point that I feel you will be prepared to stand by.
>> ...
>> struct 3D_pos p;
>> fread(&p, sizeof p, 1, dev);
>>
>>
>> (3) #include "tripos.h"
>
> Again, the compilation fails at this point...
This is not the level of debate I was hoping for. The point was to
avoid writing irrelevant details not to hide some magic in a header.
The device comes with a header file that defines the structure that is
used to drive it.
>> ...
>> volatile struct tripos_control tpc;
>> tpc.command = TRIPOS_GET_CUR_POS;
>> if (tpc.position.x > 1.3) // and so on...
>
> ...and once we sort that out, we are faced with the problem that this code
> doesn't work on the DS9000.
This is not portable code.
>> (4) void get_pos(void *vp)
>> {
>> _Pragma("DEVCTRL tipos load-position-via-praram #1");
>
> Another good attempt, but my implementation doesn't support that
> pragma.
This is... Oh, you get the idea.
>> }
>> ...
>> struct 3D_pos p;
>> get_pos(&p);
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 20:36 +0000 |
| Message-ID | <m%%kw.123300$W43.38895@fx04.am4> |
| In reply to | #55106 |
Ben Bacarisse wrote: > Richard Heathfield <invalid@see.sig.invalid> writes: > >> Ben Bacarisse wrote: >> <snip> >>> >>> Let me propose a few methods to get the position from your hypothetical >>> new position detector. You can then say why a locked-down C *must* >>> prohibit all of them. >> >> Knowing you as I do (i.e. enough to know that you're nobody's fool), I >> suspect that a locked-down C needn't prohibit any of >> them. Nevertheless... > > I am puzzled, then, why you answered in the way you did. Because "suspect" != "know". I wanted to take a look. > It seems rude > to ignore your reply, but if you suspect none of them need be prohibited > in your re-imagined C, I may just be wasting my time... I think we both might be wasting our time, actually. But for form's sake, I'll take one more trawl through this morasse... > >>> (1) #include "tripos.h" >>> ... >>> struct 3D_pos p = tripos_get_cur_pos(); >> >> Doesn't compile here. Can you please show tripos.h and the code for >> tripos_get_cur_pos()? > > I did not intend to use a bad struct tag, if that's the point you are > making. It was just a typo. It wasn't my point. Typos are typos. > > And of course I can show you the contents of tripos.h and the code for > tripos_get_cur_pos but that's just busy work for me if you won't start > to make your point. I thought I'd made my point already, months ago, near the beginning of the thread. Are we both tiring of this thread? I know I am. > Is it your contention that an ordinary external > function declaration and a call to a function written in, say, DS9000 > assembler can not possibly be given a meaning in your new C? Sure it can, but DS9000 assembly language isn't C. I don't know how much more clearly I can say that. <snip - I infer from the rest of the article that you are in fact as tired of this debate as I am, and I don't wish for the whole thing to descend any more into farce than it already has.> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-17 07:18 -0800 |
| Message-ID | <kfnbnn28ful.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #54805 |
JohnF <john@please.see.sig.for.email.com> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: >> Richard Heathfield <invalid@see.sig.invalid> writes: >>> <<snip>> >>> A language in which every possible construct is either >>> well-defined or illegal makes it very difficult for programmers >>> to add kinds of functionality unanticipated by the language >>> designers. >> >> I have a suspicion that we are getting close to a philosophical >> question <<snip>> > > I'd just say RH's remark is plain wrong. [snip elaboration] To be fair, I wouldn't say either that his comment is right or wrong, because I don't know how to assign a meaning to it that agrees with his. It's like he is saying "A language in which every possible construct is either forta-magnus or cetcil makes it very difficult for programmers to add kinds of melnics unanticipated by the language designers." I don't know what he means by the words he is using (as he is using them), so it's not possible to evaluate whether the underlying proposition is true or false, or indeed if it is even sensible to ask whether it is true or false. On the other hand, he refuses to be pinned down about what he does mean, so further discussion seems rather pointless.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-17 15:45 +0000 |
| Message-ID | <5yhkw.397413$il4.43434@fx06.am4> |
| In reply to | #54848 |
Tim Rentsch wrote: > JohnF <john@please.see.sig.for.email.com> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> wrote: >>> Richard Heathfield <invalid@see.sig.invalid> writes: >>>> <<snip>> >>>> A language in which every possible construct is either >>>> well-defined or illegal makes it very difficult for programmers >>>> to add kinds of functionality unanticipated by the language >>>> designers. >>> >>> I have a suspicion that we are getting close to a philosophical >>> question <<snip>> >> >> I'd just say RH's remark is plain wrong. [snip elaboration] > > To be fair, I wouldn't say either that his comment is right or > wrong, because I don't know how to assign a meaning to it that > agrees with his. It's like he is saying "A language in which > every possible construct is either forta-magnus or cetcil makes > it very difficult for programmers to add kinds of melnics > unanticipated by the language designers." I don't know what he > means by the words he is using (as he is using them), so it's not > possible to evaluate whether the underlying proposition is true > or false, or indeed if it is even sensible to ask whether it is > true or false. > > On the other hand, he refuses to be pinned down about what he > does mean, so further discussion seems rather pointless. I've tried as best I can to explain what I mean, but English lacks the precision of C. Let me try again. Who knows? It might even help. Definitions of terms: illegal: code that violates a constraint or a syntax rule; legal: not illegal; undefined behaviour: see the C definition; unspecified behaviour: see the C definition; implementation-defined behaviour: see the C definition; locale-specific behaviour: see the C definition; well-defined behaviour: behaviour (of legal code) that is not undefined, unspecified, implementation-defined, or locale-specific; bad undefined behaviour: undefined behaviour that arises through ignorance or wilfulness; good undefined behaviour: undefined behaviour that allows a programmer to solve a problem that could not be solved effectively without it. It is my contention that 'good undefined behaviour' can exist, and that a programming language that prevents this is a hindrance to the solving of some real-world problems. I gave an example upthread (poking values into specific memory locations). That's the whole thing. Does it help at all? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-17 16:50 +0000 |
| Message-ID | <m6sc87$hmj$1@speranza.aioe.org> |
| In reply to | #54852 |
Richard Heathfield <invalid@see.sig.invalid> wrote: > Tim Rentsch wrote: (snip) >> To be fair, I wouldn't say either that his comment is right or >> wrong, because I don't know how to assign a meaning to it that >> agrees with his. (snip) > I've tried as best I can to explain what I mean, but English lacks the > precision of C. > Let me try again. Who knows? It might even help. > Definitions of terms: > illegal: code that violates a constraint or a syntax rule; > legal: not illegal; > undefined behaviour: see the C definition; > unspecified behaviour: see the C definition; > implementation-defined behaviour: see the C definition; > locale-specific behaviour: see the C definition; > well-defined behaviour: behaviour (of legal code) that is not undefined, > unspecified, implementation-defined, or locale-specific; > bad undefined behaviour: undefined behaviour that arises through ignorance > or wilfulness; > good undefined behaviour: undefined behaviour that allows a programmer to > solve a problem that could not be solved effectively without it. > It is my contention that 'good undefined behaviour' can exist, and that a > programming language that prevents this is a hindrance to the solving of > some real-world problems. I gave an example upthread (poking values into > specific memory locations). A fair number of programs assume twos complement. While there are ones complement machines around with C compilers, they are rare enough that I can't complain too much if someone doesn't program for them. I would be disappointed if an optimizer made assumptions based on the standard allowing for ones complement. Also, if I knew the overflow character of the processor I was using, again I would be disappointed if a compiler made assumptions based on overflow being undefined (or unspecified, or implementation defined). -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-17 17:24 +0000 |
| Message-ID | <5491ba31.2943531@news.xs4all.nl> |
| In reply to | #54860 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > Richard Heathfield <invalid@see.sig.invalid> wrote: > > It is my contention that 'good undefined behaviour' can exist, and that a > > programming language that prevents this is a hindrance to the solving of > > some real-world problems. I gave an example upthread (poking values into > > specific memory locations). > > A fair number of programs assume twos complement. While there are > ones complement machines around with C compilers, they are rare > enough that I can't complain too much if someone doesn't program > for them. Which is exactly the kind of "good undefined behaviour" Richard is talking about, and which the Standard now allows but _doesn't_ require. If it did, either such programs would be illegal, or C programs would not be allowed to run on one's complement machines. As it is, with a Standard that doesn't tie down every last detail, both are allowed. Of course, this does mean that those programs are not portable to those systems. That, I think, is the great nightmare of the people who argue against UB: that they might one day be expected to port a two's complement program to a one's complement machine. They forget that programs intended to be ported _always_ require extra care with not making assumptions, with or without UB. > I would be disappointed if an optimizer made assumptions based on > the standard allowing for ones complement. So would I - _if_ that optimiser targets a two's complement machine. On the other hand, I would be equally disappointed if an optimiser targeting a one's complement machine didn't make assumptions which are useful for optimising for that encoding. And I'd be disappointed, too, if a program written _not_ to use UB involving integer encoding weren't properly optimised by both optimisers. Richard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2014-12-18 02:07 -0600 |
| Message-ID | <ek259a5e27tr5bel88c6o07qah84o349v1@4ax.com> |
| In reply to | #54860 |
On Wed, 17 Dec 2014 16:50:15 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Richard Heathfield <invalid@see.sig.invalid> wrote: >> Tim Rentsch wrote: > >(snip) >>> To be fair, I wouldn't say either that his comment is right or >>> wrong, because I don't know how to assign a meaning to it that >>> agrees with his. > >(snip) > >> I've tried as best I can to explain what I mean, but English lacks the >> precision of C. > >> Let me try again. Who knows? It might even help. > >> Definitions of terms: > >> illegal: code that violates a constraint or a syntax rule; >> legal: not illegal; >> undefined behaviour: see the C definition; >> unspecified behaviour: see the C definition; >> implementation-defined behaviour: see the C definition; >> locale-specific behaviour: see the C definition; >> well-defined behaviour: behaviour (of legal code) that is not undefined, >> unspecified, implementation-defined, or locale-specific; >> bad undefined behaviour: undefined behaviour that arises through ignorance >> or wilfulness; >> good undefined behaviour: undefined behaviour that allows a programmer to >> solve a problem that could not be solved effectively without it. > >> It is my contention that 'good undefined behaviour' can exist, and that a >> programming language that prevents this is a hindrance to the solving of >> some real-world problems. I gave an example upthread (poking values into >> specific memory locations). > >A fair number of programs assume twos complement. While there are >ones complement machines around with C compilers, they are rare >enough that I can't complain too much if someone doesn't program >for them. > >I would be disappointed if an optimizer made assumptions based on >the standard allowing for ones complement. > >Also, if I knew the overflow character of the processor I was using, >again I would be disappointed if a compiler made assumptions based >on overflow being undefined (or unspecified, or implementation defined). In fact there's a lively discussion going on about compilers doing just that. Mike Stump (who's a GCC developer) has been arguing here in c.l.c that compiler *are* allowed to make assumptions based on what is technically undefined behavior when optimizing code. A number of other folks are unhappy with that.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-18 12:04 +0000 |
| Message-ID | <5492c298.300765@news.xs4all.nl> |
| In reply to | #54910 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > In fact there's a lively discussion going on about compilers doing > just that. Mike Stump (who's a GCC developer) has been arguing here > in c.l.c that compiler *are* allowed to make assumptions based on what > is technically undefined behavior when optimizing code. A number of > other folks are unhappy with that. They may be unhappy with that, but I can't see what arguments they can bring against it. Undefined behaviour is _undefined_, so if an optimiser wants to make use of it, it's free to do so. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-18 08:06 -0500 |
| Message-ID | <LjAkw.152595$Sn4.106292@fx10.iad> |
| In reply to | #54930 |
On 12/18/14, 7:04 AM, Richard Bos wrote: > Robert Wessel <robertwessel2@yahoo.com> wrote: > >> In fact there's a lively discussion going on about compilers doing >> just that. Mike Stump (who's a GCC developer) has been arguing here >> in c.l.c that compiler *are* allowed to make assumptions based on what >> is technically undefined behavior when optimizing code. A number of >> other folks are unhappy with that. > > They may be unhappy with that, but I can't see what arguments they can > bring against it. Undefined behaviour is _undefined_, so if an optimiser > wants to make use of it, it's free to do so. > > Richard > Just because the C standard says something is undefined, doesn't mean that the compiler is free to do anything in that case. There may be a second document defining that condition, and if the compiler claims compliance to that document, it should follow that too. A very common case is POSIX, which defines a number of things that would be undefined in plain C. It isn't that far of a reach to say that if a compiler claims that it generates code for processor X, that this means that if the manufacturer of that processor defines the behavior of a certain operation that C leaves as undefined, then that definition would apply to the C program apparently doing that operation. To be fair, GCC isn't a "conforming" compiler out of the box, you need to use certain options to put it into conforming mode. Similarly, they provide options to make the code "conform" to the processor specifications.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-18 08:30 -0500 |
| Message-ID | <m6uksd$7t3$1@dont-email.me> |
| In reply to | #54940 |
On 12/18/2014 08:06 AM, Richard Damon wrote: > On 12/18/14, 7:04 AM, Richard Bos wrote: >> Robert Wessel <robertwessel2@yahoo.com> wrote: >> >>> In fact there's a lively discussion going on about compilers doing >>> just that. Mike Stump (who's a GCC developer) has been arguing here >>> in c.l.c that compiler *are* allowed to make assumptions based on what >>> is technically undefined behavior when optimizing code. A number of >>> other folks are unhappy with that. >> >> They may be unhappy with that, but I can't see what arguments they can >> bring against it. Undefined behaviour is _undefined_, so if an optimiser >> wants to make use of it, it's free to do so. >> >> Richard >> > > Just because the C standard says something is undefined, doesn't mean > that the compiler is free to do anything in that case. There may be a > second document defining that condition, and if the compiler claims > compliance to that document, it should follow that too. A very common > case is POSIX, which defines a number of things that would be undefined > in plain C. That is quite true. > It isn't that far of a reach to say that if a compiler claims that it > generates code for processor X, that this means that if the manufacturer > of that processor defines the behavior of a certain operation that C > leaves as undefined, then that definition would apply to the C program > apparently doing that operation. Could you please specify a particular processor, and provide a piece of code with behavior undefined by the C standard which, in your opinion, mandates the use of a particular machine operation if compiled by an implementation that claims to target that processor? The concept that such code can even exist is fundamentally flawed. C doesn't provide any way of specifying that a particular machine operation be used (though it does mention the existence of an asm() construct which would have that affect, as a common extension). It just defines what the effects are when C code is translated and executed. The compiler is free to choose any desired combination of the machine operations provided by a given processor, so long as the net result of the operations chosen produces the behavior required by the C standard. When the C standard leaves the behavior undefined, there is no behavior that is not permitted, so the implementation is free to use any machine operations it wishes, including ones that behave quite differently from the one you mistakenly thought it was required to use. That's what "undefined" means: "this international standard imposes no restrictions" - including, as a special case, the fact that it doesn't impose any restrictions on which machine operations can be executed. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-19 00:11 -0500 |
| Message-ID | <rsOkw.818947$DX.276445@fx06.iad> |
| In reply to | #54945 |
On 12/18/14, 8:30 AM, James Kuyper wrote: > On 12/18/2014 08:06 AM, Richard Damon wrote: >> On 12/18/14, 7:04 AM, Richard Bos wrote: >>> Robert Wessel <robertwessel2@yahoo.com> wrote: >>> >>>> In fact there's a lively discussion going on about compilers doing >>>> just that. Mike Stump (who's a GCC developer) has been arguing here >>>> in c.l.c that compiler *are* allowed to make assumptions based on what >>>> is technically undefined behavior when optimizing code. A number of >>>> other folks are unhappy with that. >>> >>> They may be unhappy with that, but I can't see what arguments they can >>> bring against it. Undefined behaviour is _undefined_, so if an optimiser >>> wants to make use of it, it's free to do so. >>> >>> Richard >>> >> >> Just because the C standard says something is undefined, doesn't mean >> that the compiler is free to do anything in that case. There may be a >> second document defining that condition, and if the compiler claims >> compliance to that document, it should follow that too. A very common >> case is POSIX, which defines a number of things that would be undefined >> in plain C. > > That is quite true. > >> It isn't that far of a reach to say that if a compiler claims that it >> generates code for processor X, that this means that if the manufacturer >> of that processor defines the behavior of a certain operation that C >> leaves as undefined, then that definition would apply to the C program >> apparently doing that operation. > > Could you please specify a particular processor, and provide a piece of > code with behavior undefined by the C standard which, in your opinion, > mandates the use of a particular machine operation if compiled by an > implementation that claims to target that processor? Note, I didn't say "Mandated", but defined how that machine performed certain operations. Take almost ANY normal 2's complement machine (like x86) int i = INT_MAX; int j = 1; int k = i+j; Under the assumption that + means use the processors addition instruction, and not some horrible concoction that acts like the addition instruction most of the time, but in certain conditions defined by the standard, because there have at one time existed that did something diffent, the the only reasonable value for k int INT_MIN. The hardware definition has defined that the way arithmetic works on this machine is a benign wrap around. The compiler, in exploiting that the formal definition in C doesn't require the program to use the defined capabilities of the machine has inserts many landmines into the program design. It has gone out of its way to do something (technically allowed, but largely unexpected) surprising and counter intuitive. By the same logic, the compiler is allowed to insert code into a program so if ever the program does something undefined (like compute INT_MAX+1) it automatically emails the contents of the users computer to their competitor and then reformat the hard disk. > > The concept that such code can even exist is fundamentally flawed. C > doesn't provide any way of specifying that a particular machine > operation be used (though it does mention the existence of an asm() > construct which would have that affect, as a common extension). It just > defines what the effects are when C code is translated and executed. The > compiler is free to choose any desired combination of the machine > operations provided by a given processor, so long as the net result of > the operations chosen produces the behavior required by the C standard. > When the C standard leaves the behavior undefined, there is no behavior > that is not permitted, so the implementation is free to use any machine > operations it wishes, including ones that behave quite differently from > the one you mistakenly thought it was required to use. That's what > "undefined" means: "this international standard imposes no restrictions" > - including, as a special case, the fact that it doesn't impose any > restrictions on which machine operations can be executed. > Yes, C doesn't require that the compiler "do the expected thing" in the face of undefined behavior. I would contend that the fact the compiler goes out of its way to detect that the only way a path can happen is the result of undefined behavior and using that fact quietly optimize it away indicates that creating correct programs is not high on the list of results. The fact that the compiler has detected a path that can only be executed after undefined behavior says that the compiler should have warned of the case, as it is almost certainly a bug in the code.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-19 07:00 +0000 |
| Message-ID | <m70if7$llm$1@speranza.aioe.org> |
| In reply to | #55034 |
Richard Damon <Richard@damon-family.org> wrote: > On 12/18/14, 8:30 AM, James Kuyper wrote: (snip, someone wrote) >>> It isn't that far of a reach to say that if a compiler claims that it >>> generates code for processor X, that this means that if the manufacturer >>> of that processor defines the behavior of a certain operation that C >>> leaves as undefined, then that definition would apply to the C program >>> apparently doing that operation. >> Could you please specify a particular processor, and provide a piece of >> code with behavior undefined by the C standard which, in your opinion, >> mandates the use of a particular machine operation if compiled by an >> implementation that claims to target that processor? > Note, I didn't say "Mandated", but defined how that machine performed > certain operations. OK, but some machines give you a choice. > Take almost ANY normal 2's complement machine (like x86) > int i = INT_MAX; > int j = 1; > int k = i+j; > Under the assumption that + means use the processors addition > instruction, and not some horrible concoction that acts like the > addition instruction most of the time, but in certain conditions defined > by the standard, because there have at one time existed that did > something diffent, the the only reasonable value for k int INT_MIN. Some processors have a user settable PSW mask bit to turn on or off the interrupt for overflow. Now, presumably the C standard doesn't specify a way to turn it on or off, but a user could change it and then expect C code to run on it. > The hardware definition has defined that the way arithmetic works on > this machine is a benign wrap around. The compiler, in exploiting that > the formal definition in C doesn't require the program to use the > defined capabilities of the machine has inserts many landmines into the > program design. It has gone out of its way to do something (technically > allowed, but largely unexpected) surprising and counter intuitive. Yes. > By the same logic, the compiler is allowed to insert code into a program > so if ever the program does something undefined (like compute INT_MAX+1) > it automatically emails the contents of the users computer to their > competitor and then reformat the hard disk. x86 has the INTO instruction. If put after an instruction that can overflow, it generates interrupt 4. The compiler does have to generate them, though. Not like a PSW bit that can be set. >> The concept that such code can even exist is fundamentally flawed. C >> doesn't provide any way of specifying that a particular machine >> operation be used (though it does mention the existence of an asm() >> construct which would have that affect, as a common extension). It just >> defines what the effects are when C code is translated and executed. The >> compiler is free to choose any desired combination of the machine >> operations provided by a given processor, so long as the net result of >> the operations chosen produces the behavior required by the C standard. (snip) > Yes, C doesn't require that the compiler "do the expected thing" in the > face of undefined behavior. I would contend that the fact the compiler > goes out of its way to detect that the only way a path can happen is the > result of undefined behavior and using that fact quietly optimize it > away indicates that creating correct programs is not high on the list of > results. The fact that the compiler has detected a path that can only be > executed after undefined behavior says that the compiler should have > warned of the case, as it is almost certainly a bug in the code. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-19 08:43 -0800 |
| Message-ID | <lnppbfbneg.fsf@nuthaus.mib.org> |
| In reply to | #55034 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> Note, I didn't say "Mandated", but defined how that machine performed
> certain operations.
>
> Take almost ANY normal 2's complement machine (like x86)
>
> int i = INT_MAX;
> int j = 1;
> int k = i+j;
>
> Under the assumption that + means use the processors addition
> instruction, and not some horrible concoction that acts like the
> addition instruction most of the time, but in certain conditions defined
> by the standard, because there have at one time existed that did
> something diffent, the the only reasonable value for k int INT_MIN.
And that assumption is where you go astray. There is no
requirement, or even a vague implication, in the C standard that
the C "+" operator maps to any particular hardware instruction.
The target system might not even *have* an addition instruction --
implausible for int, but quite possible for some extended integer
or floating-point type.
C code does not specify CPU instructions. It specifies behavior.
CPU instructions are a tool used by the compiler to implement that
behavior. And in this case, neither the C standard nor this C code
specifies even the behavior of the "+" operator when the operands
have the values INT_MAX and 1.
A benign example:
int i = 2;
int j = 3;
printf("%d\n", i + j);
A decent optimizing compiler will not generate an ADD instruction to
compute the value of i + j. Instead, it will generate code equivalent
to printf("%d\n", 5), or even puts("5"), because it's able to prove that
that has the same behavior.
> The hardware definition has defined that the way arithmetic works on
> this machine is a benign wrap around. The compiler, in exploiting that
> the formal definition in C doesn't require the program to use the
> defined capabilities of the machine has inserts many landmines into the
> program design. It has gone out of its way to do something (technically
> allowed, but largely unexpected) surprising and counter intuitive.
>
> By the same logic, the compiler is allowed to insert code into a program
> so if ever the program does something undefined (like compute INT_MAX+1)
> it automatically emails the contents of the users computer to their
> competitor and then reformat the hard disk.
Compilers do not go out of their way to exploit undefined behavior for
the sake of generating surprising results. (Well, one could, but I
doubt that any actually do so.)
An optimizing compiler analyzes C code and its own generated
intermediate code in great detail, rearranging it for better
performance. This analysis and rearrangement are constrained by the
required behavior of the code as defined by the standard. The goal is
to maximize performance for code whose behavior is defined.
As a side effect, the analysis might reveal that a particular chunk of
code has undefined behavior, and compilers often warn about that (which
is why, in some cases, you can get better warnings by compiling with
optimization enabled).
[...]
> Yes, C doesn't require that the compiler "do the expected thing" in the
> face of undefined behavior. I would contend that the fact the compiler
> goes out of its way to detect that the only way a path can happen is the
> result of undefined behavior and using that fact quietly optimize it
> away indicates that creating correct programs is not high on the list of
> results. The fact that the compiler has detected a path that can only be
> executed after undefined behavior says that the compiler should have
> warned of the case, as it is almost certainly a bug in the code.
In some cases, a compiler can generate code that behaves differently in
the presence of undefined behavior even if it doesn't *know* that the
behavior is necessarily undefined.
A hypothetical example:
char arr[16];
int i = some_value();
arr[i] = '?';
Suppose the target CPU has an addressing mode that makes offsets smaller
than 16 bytes more efficient. If i is in the range 0..15, then using
that addressing mode will result in better code with the same behavior.
If i is outside that range, then that mode (which we'll assume ignores
all but the low-order 4 bits) will clobber some element of arr *instead
of* clobbering some byte outside arr. The compiler might not have been
able to determine whether the run-time value of i is in the range 0..15
or not, so it has no basis for printing a warning.
Small optimizations like this add up, and are why code compiled with
"-O3" (or equivalent) can be substantially faster than the same code
compiled with "-O0".
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-12-19 23:29 -0500 |
| Message-ID | <gW6lw.1032051$412.1025840@fx30.iad> |
| In reply to | #55084 |
Keith,
I kind of feel you are being a bit deliberately obtuse, but let me give
an alternate simple case and you can tell me where there is a
significant difference.
A compiler claims to be a "Windows" compiler.
A program that is run through it that includes "windows.h" and calls a
function defined therein.
By the C standard, this is "undefined behavior", as the C standard does
not define this behavior, and if windows.h were to be considered as
"user code" it contains elements that are reserved for the
implementation. (And there is no formal standard that can be appealed to
which requires the specified behavior)
If the compiler generated code that did anything different than to call
the name function, it would be considered a defect in the compiler.
Second case,
The compiler claims to be a compiler targeting the 80386 (going back old
school so I can get 16 bit ints for simplisity).
The code computes the value of 32767 + 1
Intel, in the documentation for the machine, defines that on a 80386,
the signed addition of the two 16 bit signed numbers 32767 and 1 will
yield the signed value -32768 when taken as a 16 bit signed value
(irrespective of the exact operation code used).
Any other result could be seen as a lack of conformance to the
specification of targeting an 80386.
Yes, the C standard, BY ITSELF, doesn't define the behavior, but the C
standard isn't by itself here, it has claimed a target processor, and
not acted like that target processor.
Other cases mentioned talk about "what if the processor has an
instruction that does X", well, if the processor has such an
instruction, then doing X in that situation conforms to the processors
definition.
The x86 family has NO instruction (that I know of) that would process a
sequence like:
if (i+1 > i) {
j = 5;
} else {
j = 4;
}
and execute the assignment of j=5 when i has the value of INT_MAX. Thus
to do so, "because the program has engaged undefined behavior" has
violated the promise of acting like an x86 processor.
Note, that "undefined behavior" by the C standard does NOT remove the
requirement to follow other defined behavior (like the windows.h case
showed).
The biggest part of my complaint is that by the time the compiler has
gone through enough work to determine that by using freedom in the
presence of undefined behavior it can remove the comparison and "unused"
code branch, it also has enough data to issue a warning that the code
seems to be expecting undefined behavior (or has dead code), but it
appears that it doesn't (at least by default).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-20 00:37 -0800 |
| Message-ID | <lntx0qaf9m.fsf@nuthaus.mib.org> |
| In reply to | #55115 |
Richard Damon <Richard@Damon-Family.org> writes:
> Keith,
> I kind of feel you are being a bit deliberately obtuse,
No, not at all.
> but let me give
> an alternate simple case and you can tell me where there is a
> significant difference.
>
> A compiler claims to be a "Windows" compiler.
> A program that is run through it that includes "windows.h" and calls a
> function defined therein.
>
> By the C standard, this is "undefined behavior", as the C standard does
> not define this behavior, and if windows.h were to be considered as
> "user code" it contains elements that are reserved for the
> implementation. (And there is no formal standard that can be appealed to
> which requires the specified behavior)
I'd say that <windows.h> is probably part of the implementation.
> If the compiler generated code that did anything different than to call
> the name function, it would be considered a defect in the compiler.
The semantics of a function call are defined by the C standard. But it
doesn't matter whether the compiler emits a CALL instruction (or
whatever it's called), as long as the behavior is consistent with an
actual call. For example, the call could be inlined, even if it
isn't marked as inline.
> Second case,
> The compiler claims to be a compiler targeting the 80386 (going back old
> school so I can get 16 bit ints for simplisity).
>
> The code computes the value of 32767 + 1
>
> Intel, in the documentation for the machine, defines that on a 80386,
> the signed addition of the two 16 bit signed numbers 32767 and 1 will
> yield the signed value -32768 when taken as a 16 bit signed value
> (irrespective of the exact operation code used).
I presume Intel's documentation describes the behavior of the ADD
instruction.
> Any other result could be seen as a lack of conformance to the
> specification of targeting an 80386.
>
> Yes, the C standard, BY ITSELF, doesn't define the behavior, but the C
> standard isn't by itself here, it has claimed a target processor, and
> not acted like that target processor.
>
> Other cases mentioned talk about "what if the processor has an
> instruction that does X", well, if the processor has such an
> instruction, then doing X in that situation conforms to the processors
> definition.
>
> The x86 family has NO instruction (that I know of) that would process a
> sequence like:
>
> if (i+1 > i) {
> j = 5;
> } else {
> j = 4;
> }
>
> and execute the assignment of j=5 when i has the value of INT_MAX. Thus
> to do so, "because the program has engaged undefined behavior" has
> violated the promise of acting like an x86 processor.
A C compiler is not required implement the "+" operator in a manner
that's consistent with the ADD instruction for the target processor,
and actual C compilers do not behave that way in all cases.
If you think they should, that's a perfectly valid opinion, though not
one that I share. But neither the C standard nor typical C compilers
work that way.
If you want your program to conform to the behavior specified for the
ADD instruction, you'll just have to write in assembly language, or in
some non-C language that makes the guarantees you want. (Or find a C
compiler that operates the way you want.)
> Note, that "undefined behavior" by the C standard does NOT remove the
> requirement to follow other defined behavior (like the windows.h case
> showed).
Agreed -- and a compiler can implement that behavior any way it likes.
> The biggest part of my complaint is that by the time the compiler has
> gone through enough work to determine that by using freedom in the
> presence of undefined behavior it can remove the comparison and "unused"
> code branch, it also has enough data to issue a warning that the code
> seems to be expecting undefined behavior (or has dead code), but it
> appears that it doesn't (at least by default).
Most compilers have options to increase the number of warnings they
issue. Sometimes excessive warnings can be distracting. And yes,
sometimes compilers fail to issue warnings when they should.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-12-20 08:45 +0000 |
| Message-ID | <m73cv6$pfn$1@news.xmission.com> |
| In reply to | #55121 |
In article <lntx0qaf9m.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: >Richard Damon <Richard@Damon-Family.org> writes: >> Keith, >> I kind of feel you are being a bit deliberately obtuse, > >No, not at all. Indeed. For Keith, it comes naturally. No effort needed. -- About that whole "sent His Son to die for us thing", I've never been able to understand that one. It's not like Jesus isn't going back to Heaven after his Earthly self dies, right? So, having him be executed, and resurrect a few days later strikes me as being more akin to spending the weekend at the non-custodial parent's house than "dying", doesn't it?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-20 09:45 +0000 |
| Message-ID | <5495448a.510656@news.xs4all.nl> |
| In reply to | #55121 |
Keith Thompson <kst-u@mib.org> wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > Keith, > > I kind of feel you are being a bit deliberately obtuse, > > No, not at all. No, but unless I am very much mistaken, you - both of you - _are_ arguing at cross-purposes. You're both arguing _for_ the continued existence of undefined behaviour, you're just doing it from different ends. One is arguing as a programmer, the other as an implementor, but both of you want to keep UB, because it makes both your jobs easier. The counter-arguments are all coming from academic language lawyers and would-be writers of "improved" versions of C, not from actual users. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-20 03:17 -0800 |
| Message-ID | <1ed24736-2bdd-4bfe-b18d-b8cdd96f0eee@googlegroups.com> |
| In reply to | #55125 |
On Saturday, December 20, 2014 9:45:27 AM UTC, Richard Bos wrote: > > No, but unless I am very much mistaken, you - both of you - _are_ > arguing at cross-purposes. You're both arguing _for_ the continued > existence of undefined behaviour, you're just doing it from different > ends. One is arguing as a programmer, the other as an implementor, but > both of you want to keep UB, because it makes both your jobs easier. The > counter-arguments are all coming from academic language lawyers and > would-be writers of "improved" versions of C, not from actual users. > I comes down to being able to write to absolute memory addresses, and force reads / writes even if, were the memory location private, it would have no effect. The fact that C makes this easy means that if you have a memory-mapped device interface, most or all of the code can be in C. Of course the code is inherently nonportable.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-18 06:09 -0800 |
| Message-ID | <2ea98619-63fc-4ab6-b7cc-40e0d292726f@googlegroups.com> |
| In reply to | #54940 |
On Thursday, December 18, 2014 1:07:00 PM UTC, Richard Damon wrote: > > It isn't that far of a reach to say that if a compiler claims that it > generates code for processor X, that this means that if the manufacturer > of that processor defines the behavior of a certain operation that C > leaves as undefined, then that definition would apply to the C program > apparently doing that operation. > Let's say a chip designer, reasonably, provides an assembly instruction shift accumulator right by value in register x. let's say he also, reasonably, defines, if x = 32, the accumulator shall be cleared to 0 (its a 32 bit system). Someone writes in C /* x = 32; */ a <<= x; a could be cleared. Or the compiler writer could, quite reasonably, say "undefined behaviour, best catch it by terminating the program with an error message".
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2014-12-18 14:30 +0000 |
| Message-ID | <5492e381.575484@news.xs4all.nl> |
| In reply to | #54950 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Thursday, December 18, 2014 1:07:00 PM UTC, Richard Damon wrote: > > > > It isn't that far of a reach to say that if a compiler claims that it > > generates code for processor X, that this means that if the manufacturer > > of that processor defines the behavior of a certain operation that C > > leaves as undefined, then that definition would apply to the C program > > apparently doing that operation. > > > Let's say a chip designer, reasonably, provides an assembly instruction > > shift accumulator right by value in register x. > > let's say he also, reasonably, defines, if x = 32, the accumulator shall > be cleared to 0 (its a 32 bit system). > > Someone writes in C > > /* x = 32; */ > a <<= x; That's left, not right, but let's assume a >>= x; . > a could be cleared. Or the compiler writer could, quite reasonably, say > "undefined behaviour, best catch it by terminating the program with > an error message". He could indeed, from a C POV, quite reasonably do both. And in fact I would expect a debugging compiler (or GCC invoked in a special debugging mode for that chip) to take the latter tack; while still expecting an optimising compiler, or GCC invoked with -O3, to take the first approach. The horror, for some people, of undefined behaviour is that both of those are allowed and you don't know which you're going to get if you write hacky code and someone else compiles it[42]. The beauty of undefined behaviour, for others is that both of those are allowed, and you can get the one which is optimal for your circumstances depending on how you choose to compile your code - and you can still avoid it by not writing hacky code! Richard [42] So we say, like the doctor whose patient told him that it hurt when he pinched the bit between his fingers: "Don't Do That, Then."
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web