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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 17:53 +0000 |
| Message-ID | <6CZkw.196379$p95.137017@fx38.am4> |
| In reply to | #55091 |
Tim Rentsch wrote: > Richard Heathfield <invalid@see.sig.invalid> writes: > >> Tim Rentsch wrote: >> [snip] >> >>> Two, I think you've punted on the big issue, which is how much >>> (or what kinds of) capability is (are) needed to satisfy the >>> predicate criterion. >> >> I'm sorry you think that. I'm not sure that I agree, and (alas) I >> lack the time right now to do any more than acknowledge your >> response. If I can get back to it before the whole debate goes >> stale, I will, but I may not be able to. > > I await your further comments with great anticipation. I hope I may be forgiven for inferring just a hint of sarcasm in that response. I guess it's understandable. I think the whole debate (about whether C could be locked down without losing expressive power) has been blown up out of all proportion, and I'm puzzled because what seems self- evident to me is being opposed vigorously by a number of people whose opinions I respect (which group of course includes you). So I have to face the possibility that I'm wrong - that is, that *any* task we might wish a computer to perform can be done in C as it exists at present, without ever dipping into the reservoir of tricks that can be achieved via UB (such as peek and poke, for example). Unfortunately, I am struggling to come up with mechanisms that would make this possible. The only ones I can think of are tricks: (1) the C program writes an assembly language program (fprintf() will do for that), and then calls an assembler (system() will do for that) - or even writes the machine language program directly (fwrite()) - and then executes the program via system(). (2) We rely on the implementation providing a dwim() function (for certain values of wim). But it seems to me that these are just weaselly ways of saying that we can't do it in C. So, if I'm wrong, I can't see *how* I'm wrong. Perhaps you could enlighten me. -- 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-20 11:48 -0800 |
| Message-ID | <kfnk31m3xww.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #55097 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Tim Rentsch wrote: > >> Richard Heathfield <invalid@see.sig.invalid> writes: >> >>> Tim Rentsch wrote: >>> [snip] >>> >>>> Two, I think you've punted on the big issue, which is how much >>>> (or what kinds of) capability is (are) needed to satisfy the >>>> predicate criterion. >>> >>> I'm sorry you think that. I'm not sure that I agree, and (alas) >>> I lack the time right now to do any more than acknowledge your >>> response. If I can get back to it before the whole debate goes >>> stale, I will, but I may not be able to. >> >> I await your further comments with great anticipation. > > I hope I may be forgiven for inferring just a hint of sarcasm in > that response. No sarcasm was intended. > I guess it's understandable. I think the whole debate (about > whether C could be locked down without losing expressive power) > has been blown up out of all proportion, and I'm puzzled because > what seems self- evident to me is being opposed vigorously by a > number of people whose opinions I respect (which group of course > includes you). So I have to face the possibility that I'm wrong - > that is, that *any* task we might wish a computer to perform can > be done in C as it exists at present, without ever dipping into > the reservoir of tricks that can be achieved via UB (such as peek > and poke, for example). > > Unfortunately, I am struggling to come up with mechanisms that > would make this possible. The only ones I can think of are > tricks: > > (1) the C program writes an assembly language program (fprintf() > will do for that), and then calls an assembler (system() will do > for that) - or even writes the machine language program directly > (fwrite()) - and then executes the program via system(). > (2) We rely on the implementation providing a dwim() function (for > certain values of wim). > > But it seems to me that these are just weaselly ways of saying > that we can't do it in C. > > So, if I'm wrong, I can't see *how* I'm wrong. Perhaps you could > enlighten me. Seeing your response to James Kuyper's post mentioning #pragma, I assume you would now prefer to discontinue the discussion, so I won't say anything further.
[toc] | [prev] | [next] | [standalone]
| From | JohnF <john@please.see.sig.for.email.com> |
|---|---|
| Date | 2014-12-19 02:20 +0000 |
| Message-ID | <m7020g$nlm$1@reader1.panix.com> |
| In reply to | #54852 |
Richard Heathfield <invalid@see.sig.invalid> wrote: > 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. > > <<snip>> > 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. <<snip>> Okay, I now see your original remark said "...very difficult...", and now you're saying "...hindrance...", and I'd agree that C's easier to program in than the same problem solved by a Turing machine, or even by just about any assembly language. But I'd disagree that C's ease of use is in any way correlated with (and certainly not caused by) its occasional undefinedness (which is instead related to its translation to machine code on different hardware architectures, whereby a consistent operational semantics becomes difficult or not possible). And I'd agree with TR that you "refuse to be pinned down". I had (and still have) no idea whatsoever about what you were asking/challenging in your followup to my earlier post. -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 08:31 +0000 |
| Message-ID | <KnRkw.194492$6H3.93390@fx35.am4> |
| In reply to | #55029 |
JohnF wrote: > Richard Heathfield <invalid@see.sig.invalid> wrote: <snip> >> 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. <<snip>> > > Okay, I now see your original remark said "...very difficult...", > and now you're saying "...hindrance...", and I'd agree that C's > easier to program in than the same problem solved by a Turing machine, I'm sorry. I realise that my use of language is not as precise as either you or I would like it to be. I also realise that precision matters. I'm doing the best I can. It may not be good enough. I am certainly not trying to be evasive. At heart, my contention is simply that, without undefined behaviour, there are some things we can't do in C, Turing-complete or not. For example, it is simply not possible, in ISO C, to write, say, a device driver for my notional 3D-position-sensing device. It can't be done. > or even by just about any assembly language. But I'd disagree that > C's ease of use is in any way correlated with (and certainly not > caused by) its occasional undefinedness (which is instead related to > its translation to machine code on different hardware architectures, > whereby a consistent operational semantics becomes difficult > or not possible). > And I'd agree with TR that you "refuse to be pinned down". I don't recall refusing. That sounds terribly wilful. No, I'm just trying to make a point about UB, and obviously not doing it very well. > I had (and still have) no idea whatsoever about what you were > asking/challenging in your followup to my earlier post. If you have a message ID, I could have another crack at it if you care enough. But I can't guarantee to be any clearer second time around - not because I don't want to be, but because I'm struggling to identify what it is that's unclear about my writing. -- 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 | JohnF <john@please.see.sig.for.email.com> |
|---|---|
| Date | 2014-12-19 09:31 +0000 |
| Message-ID | <m70r8v$290$1@reader1.panix.com> |
| In reply to | #55041 |
Richard Heathfield <invalid@see.sig.invalid> wrote: > JohnF wrote: >> Richard Heathfield <invalid@see.sig.invalid> wrote: > <snip> >>> 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. <<snip>> >> >> Okay, I now see your original remark said "...very difficult...", >> and now you're saying "...hindrance...", and I'd agree that C's >> easier to program in than the same problem solved by a Turing machine, > > I'm sorry. I realise that my use of language is not as precise as either you > or I would like it to be. I also realise that precision matters. I'm doing > the best I can. It may not be good enough. I am certainly not trying to be > evasive. > > At heart, my contention is simply that, without undefined behaviour, there > are some things we can't do in C, Turing-complete or not. For example, it is > simply not possible, in ISO C, to write, say, a device driver for my > notional 3D-position-sensing device. It can't be done. > >> or even by just about any assembly language. But I'd disagree that >> C's ease of use is in any way correlated with (and certainly not >> caused by) its occasional undefinedness (which is instead related to >> its translation to machine code on different hardware architectures, >> whereby a consistent operational semantics becomes difficult >> or not possible). >> And I'd agree with TR that you "refuse to be pinned down". > > I don't recall refusing. That sounds terribly wilful. > No, I'm just trying to make a point about UB, and obviously > not doing it very well. I'm not precisely sure which of your remarks TR was referring to with his phrase I quoted. But my agreement was, as stated below, based on your programming "challenge" in reply to my earlier post. I see above it's referring to your "notional 3D-position-sensing device". And I recall seeing you discuss this in some other posts I haven't read. Maybe it's described more clearly there (continued below)... >> I had (and still have) no idea whatsoever about what you were >> asking/challenging in your followup to my earlier post. > > If you have a message ID, I could have another crack at it if you care > enough. But I can't guarantee to be any clearer second time around - not > because I don't want to be, but because I'm struggling to identify what it > is that's unclear about my writing. ...No, don't bother. Let me just quote and comment on two of your above remarks: > my contention is simply that, without undefined behaviour, there > are some things we can't do in C, Turing-complete or not. > For example, it is simply not possible, in ISO C, to write, > say, a device driver for my notional 3D-position-sensing device. > It can't be done. I guarantee you you're wrong, Wrong, WRONG!!! I guarantee it!!! More accurately, it's the last 75 years or so of the entire planet's population of computer scientists that guarantees it. Every last one of them. You obviously haven't taken any computer science courses, or independently studied computability and the ideas around Turing completeness. (And, just in case your "undefined behavior" corresponds to what's more usually called non-deterministic finite automata, let me point out that every such nfa is provably reducible to a corresponding deterministic finite automaton.) Now, I'm making some pretty pointed remarks above, without knowing you at all. But, no problem! I'd love, Love, LOVE to be proven wrong, and for you to rigorously demonstrate a function that's computable in "C with undefined behavior" (unless your "undefined behavior" corresponds to what's called an Oracle, but then it wouldn't really be "undefined") but not computable in C. You do that, and you'll create a worldwide sensation. It'll be a small price for me to pay to look like an idiot. Go ahead -- make me look like an idiot. I double-dare you! And I'll be double-sure to listen to your Turing Award Lecture. But until then, I'm not really interested in poring over your code or your functional specifications, etc, to find where you tripped up over something or other. -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 10:10 +0000 |
| Message-ID | <BQSkw.737894$u67.536023@fx08.am4> |
| In reply to | #55045 |
JohnF wrote: <snip> > ...No, don't bother. Let me just quote and comment on two of your above > remarks: > > my contention is simply that, without undefined behaviour, there > > are some things we can't do in C, Turing-complete or not. > > For example, it is simply not possible, in ISO C, to write, > > say, a device driver for my notional 3D-position-sensing device. > > It can't be done. > I guarantee you you're wrong, Wrong, WRONG!!! I guarantee it!!! Great! Then you'll have no problem in showing me the code. > More accurately, it's the last 75 years or so of the entire planet's > population of computer scientists that guarantees it. Every last one > of them. You obviously haven't taken any computer science courses, > or independently studied computability and the ideas around Turing > completeness. Show me. I don't mean "show me the theory". I know the theory. I mean, show me the ISO C code for reading data from my notional 3D-position-sensing device, without using any undefined behaviour at all. > (And, just in case your "undefined behavior" corresponds > to what's more usually called non-deterministic finite automata, let me > point out that every such nfa is provably reducible to a corresponding > deterministic finite automaton.) > Now, I'm making some pretty pointed remarks above, without knowing > you at all. Yes. That's okay - I have a Usenet-thick skin - but I want to make it very, very clear that I'm not claiming that I've broken Turing completeness. Of course I haven't done that. I haven't done anything. I'm just saying that we sometimes need to step outside the Standard if we're to get some kinds of programming done, and that the Standard is right to leave some aspects of C undefined so that we can do that. > But, no problem! I'd love, Love, LOVE to be proven wrong, So would I. So show me the code. > and for you to rigorously demonstrate a function that's computable > in "C with undefined behavior" (unless your "undefined behavior" > corresponds to what's called an Oracle, but then it wouldn't really > be "undefined") but not computable in C. You do that, and you'll > create a worldwide sensation. It'll be a small price for me to pay > to look like an idiot. Go ahead -- make me look like an idiot. I don't want to make you look like an idiot. I don't see any value in that, especially since you clearly are not one. Nor do I think I've made any great advances in computer science. I am well aware of Turing completeness, and I am not making any claims about it. What I am claiming is that it is not possible to write a function in ISO C to read data from my position-sensing device without relying at some point on undefined behaviour. > I double-dare you! And I'll be double-sure to listen to your > Turing Award Lecture. But until then, I'm not really interested > in poring over your code or your functional specifications, etc, > to find where you tripped up over something or other. I don't think I'll be giving any lectures any time soon. I think you may have misunderstood my point. I am not claiming to have broken Turing completeness. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-19 07:08 -0800 |
| Message-ID | <0a1e3047-4073-4ca6-bd52-deda24b870b3@googlegroups.com> |
| In reply to | #55045 |
On Friday, December 19, 2014 9:31:19 AM UTC, JohnF wrote: > Richard Heathfield <invalid@see.sig.invalid> wrote: > > ...No, don't bother. Let me just quote and comment on two of your above > remarks: > > my contention is simply that, without undefined behaviour, there > > are some things we can't do in C, Turing-complete or not. > > For example, it is simply not possible, in ISO C, to write, > > say, a device driver for my notional 3D-position-sensing device. > > It can't be done. > I guarantee you you're wrong, Wrong, WRONG!!! I guarantee it!!! > More accurately, it's the last 75 years or so of the entire planet's > population of computer scientists that guarantees it. > Computers don't just compute things, they do things. You can shuffle bits about in memory to your heart's content, but it's entirely useless unless, at some point, they interact with the real world. Which often has things like timing constraints. Let's say that a system has a memory buffer which contains rgba pixels. During screen trace, the buffer is read by the hardware to show pretty pictures on the screen. If you try to write to it during this time, you'll get contention and a nice white snow effect will appear - great for the Christmas level, otherwise not what you want. However you get an interrupt during the vertical blank, when the screen resets. So you need to write out your pixels to the screen during this period. You can't do that without some notion of hardware control, timings, and direct memory access.
[toc] | [prev] | [next] | [standalone]
| From | JohnF <john@please.see.sig.for.email.com> |
|---|---|
| Date | 2014-12-20 06:39 +0000 |
| Message-ID | <m735j6$5a$1@reader1.panix.com> |
| In reply to | #55072 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Friday, December 19, 2014 9:31:19 AM UTC, JohnF wrote: >> Richard Heathfield <invalid@see.sig.invalid> wrote: >> >> ...No, don't bother. Let me just quote and comment on two of your above >> remarks: >> > my contention is simply that, without undefined behaviour, there >> > are some things we can't do in C, Turing-complete or not. >> > For example, it is simply not possible, in ISO C, to write, >> > say, a device driver for my notional 3D-position-sensing device. >> > It can't be done. >> I guarantee you you're wrong, Wrong, WRONG!!! I guarantee it!!! >> More accurately, it's the last 75 years or so of the entire planet's >> population of computer scientists that guarantees it. >> > Computers don't just compute things, they do things. > You can shuffle bits about in memory to your heart's content, but > it's entirely useless unless, at some point, they interact with > the real world. Which often has things like timing constraints. > > Let's say that a system has a memory buffer which contains rgba > pixels. During screen trace, the buffer is read by the hardware > to show pretty pictures on the screen. If you try to write to it > during this time, you'll get contention and a nice white snow > effect will appear - great for the Christmas level, otherwise not > what you want. However you get an interrupt during the vertical > blank, when the screen resets. So you need to write out your pixels > to the screen during this period. > > You can't do that without some notion of hardware control, > timings, and direct memory access. All this stuff can, one way or another, be encoded as integers, and composite types built up from N as NxN, N-->N, etc, in the usual type-theoretic way. And once you've constructed such a representation, you're back to discussing computable functions. Now, such a representation can be crazy stupid complicated. And you'll note my preceding post where I wholeheartedly agreed with RH's comments when they included qualifiers like "...very difficult..." and "...hindrance..". But when he just says "...can't...", then that's just wrong. And you're wrong for thinking that the complexities you mention introduce a regime of computation beyond computable function theory. Consider your resource contention example. Locks, semaphores, etc can be represented computably, so resolving contention can be represented computably (though, okay, I'm having trouble googling a reference). -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2014-12-20 07:32 +0000 |
| Message-ID | <m738lv$k1l$1@reader1.panix.com> |
| In reply to | #55117 |
JohnF <john@please.see.sig.for.email.com> wrote: > <<snip>> so resolving contention can be > represented computably (though, okay, I'm having trouble googling > a reference). I actually have been interested in the domain-theoretic formalism for this kind of stuff, but for totally different reasons than the current discussion, and know there's a reference bouncing around somewhere in my head. I think there's a 50-50 chance it's in http://mitpress.mit.edu/books/control-flow-semantics But I'm paging through my own copy, and failing to find it exactly. There's a lesser chance it's in http://mitpress.mit.edu/books/concurrent-constraint-programming or maybe amazon.com/Algebraic-Theory-Processes-Matthew-Hennessy/dp/0262580934 But I'm still failing to find it. Anybody have a reference for what I was claiming? -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-01-04 17:02 +0000 |
| Message-ID | <Vmeqw.180819$5r4.102802@fx31.iad> |
| In reply to | #55045 |
On 2014-12-19, JohnF <john@please.see.sig.for.email.com> wrote: > Richard Heathfield <invalid@see.sig.invalid> wrote: >> JohnF wrote: >>> Richard Heathfield <invalid@see.sig.invalid> wrote: >> <snip> >>>> 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. <<snip>> > > my contention is simply that, without undefined behaviour, there > > are some things we can't do in C, Turing-complete or not. > > For example, it is simply not possible, in ISO C, to write, > > say, a device driver for my notional 3D-position-sensing device. > > It can't be done. > I guarantee you you're wrong, Wrong, WRONG!!! I guarantee it!!! > More accurately, it's the last 75 years or so of the entire planet's > population of computer scientists that guarantees it. Every last one > of them. You obviously haven't taken any computer science courses, > or independently studied computability and the ideas around Turing > completeness. (And, just in case your "undefined behavior" corresponds > to what's more usually called non-deterministic finite automata, let me > point out that every such nfa is provably reducible to a corresponding > deterministic finite automaton.) I'm pretty sure that were I a wiser man I wouldn't throw any change this way, let alone my 2 cents but here it is. Is it not the case that C doesn't say anything about what form memory management on the host platform platform will take? It says nothing about paging, or page faults, doesn't require a heap and doesn't suggest or enforce a calling convention? Therefore when I write: mlockall (MCL_CURRENT | MCL_FUTURE ); mallopt (M_TRIM_THRESHOLD, -1); mallopt (M_MMAP_MAX, 0); int page_size = sysconf (_SC_PAGESIZE); size_t membuf_size = MIN_CHUNK_SIZE * page_size; as a prelude to setting up my own memory manager have I not (invoked|created|established) undefined behavior WRT C? I am expecting that following those lines of code the buffer I create will by available to my process without requiring a major page fault and will be reserved for my process alone until it exits. Since the C programming language says nothing about this, the behavior is undefined and if I run this code on an OS that doesn't map memory or have paging I shouldn't have expectations WRT to its behavior. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-01-04 12:40 -0500 |
| Message-ID | <m8btua$d8v$1@dont-email.me> |
| In reply to | #55823 |
On 01/04/2015 12:02 PM, Greg Martin wrote: ... > Is it not the case that C doesn't say anything about what form memory > management on the host platform platform will take? It says nothing > about paging, or page faults, doesn't require a heap and doesn't suggest > or enforce a calling convention? > > Therefore when I write: > > mlockall (MCL_CURRENT | MCL_FUTURE ); > mallopt (M_TRIM_THRESHOLD, -1); > mallopt (M_MMAP_MAX, 0); > int page_size = sysconf (_SC_PAGESIZE); > size_t membuf_size = MIN_CHUNK_SIZE * page_size; > > as a prelude to setting up my own memory manager have I not > (invoked|created|established) undefined behavior WRT C? Yes - but allowing such things to happen would also be permitted if the behavior were merely implementation-defined, rather than undefined. The existence of constructs with undefined behavior is not necessary to enable such uses of C. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-01-04 18:02 +0000 |
| Message-ID | <hffqw.1189226$Y4.451905@fx24.iad> |
| In reply to | #55826 |
On 2015-01-04, James Kuyper <jameskuyper@verizon.net> wrote: > On 01/04/2015 12:02 PM, Greg Martin wrote: > ... >> Is it not the case that C doesn't say anything about what form memory >> management on the host platform platform will take? It says nothing >> about paging, or page faults, doesn't require a heap and doesn't suggest >> or enforce a calling convention? >> >> Therefore when I write: >> >> mlockall (MCL_CURRENT | MCL_FUTURE ); >> mallopt (M_TRIM_THRESHOLD, -1); >> mallopt (M_MMAP_MAX, 0); >> int page_size = sysconf (_SC_PAGESIZE); >> size_t membuf_size = MIN_CHUNK_SIZE * page_size; >> >> as a prelude to setting up my own memory manager have I not >> (invoked|created|established) undefined behavior WRT C? > > Yes - but allowing such things to happen would also be permitted if the > behavior were merely implementation-defined, rather than undefined. The > existence of constructs with undefined behavior is not necessary to > enable such uses of C. Ah, implementation defined if the tool chain can find an implementation of the functions being called (on an appropriate platform) verses: a++ = ++a - f(a--); where the compiler has no idea what I mean but will do it anyway? -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-01-05 09:47 -0500 |
| Message-ID | <m8e85l$9f3$1@dont-email.me> |
| In reply to | #55828 |
On 01/04/2015 01:02 PM, Greg Martin wrote: > On 2015-01-04, James Kuyper <jameskuyper@verizon.net> wrote: >> On 01/04/2015 12:02 PM, Greg Martin wrote: >> ... >>> Is it not the case that C doesn't say anything about what form memory >>> management on the host platform platform will take? It says nothing >>> about paging, or page faults, doesn't require a heap and doesn't suggest >>> or enforce a calling convention? >>> >>> Therefore when I write: >>> >>> mlockall (MCL_CURRENT | MCL_FUTURE ); >>> mallopt (M_TRIM_THRESHOLD, -1); >>> mallopt (M_MMAP_MAX, 0); >>> int page_size = sysconf (_SC_PAGESIZE); >>> size_t membuf_size = MIN_CHUNK_SIZE * page_size; >>> >>> as a prelude to setting up my own memory manager have I not >>> (invoked|created|established) undefined behavior WRT C? >> >> Yes - but allowing such things to happen would also be permitted if the >> behavior were merely implementation-defined, rather than undefined. The >> existence of constructs with undefined behavior is not necessary to >> enable such uses of C. > > Ah, implementation defined if the tool chain can find an implementation > of the functions being called (on an appropriate platform) verses: ' No, it's your responsibility to find an implementation that defines the behavior of those function calls in the way that you'd like it to be defined - with no guarantee that any such implementation exists. It's not the responsibility of the tool-chain to guess what you want, and find such an implementation. A tool chain which provided you a way of specifying the desired behavior, and would search for an appropriate implementation, wouldn't be a bad thing - but whether such a tool chain even exists is irrelevant to the point I was making. > a++ = ++a - f(a--); > > where the compiler has no idea what I mean but will do it anyway? The behavior of that construct is undefined, but it could have been implementation-defined. If it were, what you meant would be irrelevant - the only thing that would be relevant is what the implementation-provided definition of the behavior is. If that definition meets your needs, use it. If not, rewrite your code to explicitly evaluate the expressions with side effects in the order that you desire. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-01-05 15:14 +0000 |
| Message-ID | <uTxqw.1059179$Fo3.656156@fx09.iad> |
| In reply to | #55898 |
On 2015-01-05, James Kuyper <jameskuyper@verizon.net> wrote: > On 01/04/2015 01:02 PM, Greg Martin wrote: > >> a++ = ++a - f(a--); >> >> where the compiler has no idea what I mean but will do it anyway? > > The behavior of that construct is undefined, but it could have been > implementation-defined. If it were, what you meant would be irrelevant - > the only thing that would be relevant is what the > implementation-provided definition of the behavior is. If that > definition meets your needs, use it. If not, rewrite your code to > explicitly evaluate the expressions with side effects in the order that > you desire. If a compiler allows a construct, and converts it into machine code, it "becomes" implementation defined anyways. I guess the difference is, calling it undefined behavior suggests that the compiler doesn't need to accept it but it may, calling it implementation defined means, there isn't a standardized meaning for this but the implementation is required to do something with it. It seems to me this largely only affects whether a compiler can be said to be compliant or not but perhaps that's the point. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-01-05 08:42 -0800 |
| Message-ID | <ln8uhhw54t.fsf@nuthaus.mib.org> |
| In reply to | #55905 |
Greg Martin <greg.at.softsprocket@dot.com> writes:
> On 2015-01-05, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 01/04/2015 01:02 PM, Greg Martin wrote:
>>
>>> a++ = ++a - f(a--);
>>>
>>> where the compiler has no idea what I mean but will do it anyway?
>>
>> The behavior of that construct is undefined, but it could have been
>> implementation-defined. If it were, what you meant would be irrelevant -
>> the only thing that would be relevant is what the
>> implementation-provided definition of the behavior is. If that
>> definition meets your needs, use it. If not, rewrite your code to
>> explicitly evaluate the expressions with side effects in the order that
>> you desire.
>
> If a compiler allows a construct, and converts it into machine code,
> it "becomes" implementation defined anyways.
Not quite. For implementation defined behavior (as the standard defines
that term), the implementation is required to document the behavior.
A compiler might generate machine code for `i = i++;`, but there's no
requirement to document the chosen behavior or for the behavior to be
consistent.
[...]
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-06 00:14 +0000 |
| Message-ID | <m8f9c7$e8e$1@speranza.aioe.org> |
| In reply to | #55916 |
Keith Thompson <kst-u@mib.org> wrote: > Greg Martin <greg.at.softsprocket@dot.com> writes: (snip) >> If a compiler allows a construct, and converts it into machine code, >> it "becomes" implementation defined anyways. I usually think of "implementation defined" for cases such as integer representation, where twos complement, ones complement, and sign magnitude are allowed. The implementation has to use one of them, and the result may depend on that choice. Also, for big-endian vs. little-endian. > Not quite. For implementation defined behavior (as the standard defines > that term), the implementation is required to document the behavior. Reminds me of the old story: Q: "What is the difference between a bug and a feature?" A: "A feature is documented." > A compiler might generate machine code for `i = i++;`, but there's no > requirement to document the chosen behavior or for the behavior to be > consistent. Some might expect it to be consistent once compiled, but even that might not be true on all systems now. There could be hardware which allows parallel operations with indeterminate ordering, and compilers could compile for that. > [...] -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-01-05 13:19 -0500 |
| Message-ID | <54AAD5B2.9090409@verizon.net> |
| In reply to | #55905 |
On 01/05/2015 10:14 AM, Greg Martin wrote: > On 2015-01-05, James Kuyper <jameskuyper@verizon.net> wrote: >> On 01/04/2015 01:02 PM, Greg Martin wrote: >> >>> a++ = ++a - f(a--); >>> >>> where the compiler has no idea what I mean but will do it anyway? >> >> The behavior of that construct is undefined, but it could have been >> implementation-defined. If it were, what you meant would be irrelevant - >> the only thing that would be relevant is what the >> implementation-provided definition of the behavior is. If that >> definition meets your needs, use it. If not, rewrite your code to >> explicitly evaluate the expressions with side effects in the order that >> you desire. > > If a compiler allows a construct, and converts it into machine code, > it "becomes" implementation defined anyways. No - in the C context, "implementation-defined" is a term with a meaning defined by the C standard - treating the term as if it were simply made up of two words interpreted according to the rules of ordinary English doesn't work. The relevant definition is: "unspecified behavior where each implementation documents how the choice is made". (3.4.1) That definition, in turn, depends upon the definition of "unspecified behavior": "use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance" (3.4.4) The behavior of a construct in a C program is implementation-defined only if the standard says so explicitly, and if it does, an implementation can only conform to the standard if it actually documents the behavior. Generating machine instructions that have a particular behavior doesn't qualify as documenting the behavior. The documentation has to specify what the behavior is in general, not just what it is when compiling a particular program. > ... I guess the difference is, > calling it undefined behavior suggests that the compiler doesn't need > to accept it but it may, ... Not quite. Undefined behavior means that the standard imposes no requirements on the behavior. Not requiring that it be accepted is only one small part of the implications. A conforming hosted implementation is required to accept any strictly conforming programs. There's lots of things that can render a program not strictly conforming; having undefined behavior is just one of those things. > calling it implementation defined means, there > isn't a standardized meaning for this but the implementation is > required to do something with it. No, it means the implementation is required to document it. > It seems to me this largely only affects whether a compiler can be > said to be compliant or not but perhaps that's the point. Well, yes - ultimately, everything the C standard says boils down to specifying what you need to know to determine a) whether a given implementation is conforming b) how well a given program conforms (there's a whole bunch of different terms that could apply: conforming, strictly conforming, unspecified behavior, implementation-defined behavior, undefined behavior, exceeds minimum implmentation limits).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-01-04 15:59 -0500 |
| Message-ID | <yQhqw.536793$O76.17348@fx15.iad> |
| In reply to | #55826 |
On 1/4/15 12:40 PM, James Kuyper wrote: > On 01/04/2015 12:02 PM, Greg Martin wrote: > ... >> Is it not the case that C doesn't say anything about what form memory >> management on the host platform platform will take? It says nothing >> about paging, or page faults, doesn't require a heap and doesn't suggest >> or enforce a calling convention? >> >> Therefore when I write: >> >> mlockall (MCL_CURRENT | MCL_FUTURE ); >> mallopt (M_TRIM_THRESHOLD, -1); >> mallopt (M_MMAP_MAX, 0); >> int page_size = sysconf (_SC_PAGESIZE); >> size_t membuf_size = MIN_CHUNK_SIZE * page_size; >> >> as a prelude to setting up my own memory manager have I not >> (invoked|created|established) undefined behavior WRT C? > > Yes - but allowing such things to happen would also be permitted if the > behavior were merely implementation-defined, rather than undefined. The > existence of constructs with undefined behavior is not necessary to > enable such uses of C. > By the standard, "Implementation Defined Behavior" is behavior where the standard put a requirement on the implementation to choose from a small list of possible behaviors, and document that decision. Undefined behavior means that the standard provides no limitations on what the implementation might do. This doesn't mean that literally anything thing can happen, just that the standard doesn't provide any limitations. The implementation is still limited by the law of physics and the ability of the processor the program is run on. Most undefined behavior actually have very predictable behavior given a bit of study, and knowledge of the system being used (at least on a micro scale). Some of it might be documented by the implementation, and some might not be. Using this sort of knowledge is going to make your program "non-portable", but this is often acceptable.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-01-04 14:30 -0800 |
| Message-ID | <lnd26uw54e.fsf@nuthaus.mib.org> |
| In reply to | #55837 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> Undefined behavior means that the standard provides no limitations on
> what the implementation might do. This doesn't mean that literally
> anything thing can happen, just that the standard doesn't provide any
> limitations. The implementation is still limited by the law of physics
> and the ability of the processor the program is run on.
True. But it does mean that if dereferencing a null pointer literally
causes demons to fly out of your nose, the implementation might be
violating the laws of physics, but it doesn't violate the C standard.
> Most undefined behavior actually have very predictable behavior given a
> bit of study, and knowledge of the system being used (at least on a
> micro scale). Some of it might be documented by the implementation, and
> some might not be. Using this sort of knowledge is going to make your
> program "non-portable", but this is often acceptable.
I'm not sure about "most". Accessing an out-of-bounds array element,
for example, will *probably* access memory at a particular location
-- but what's at that location is up to the whim of the compiler.
And in many cases, optimizing compilers will *assume* that a
program's behavior is defined.
Assuming that a null pointer is represented as all bits zero,
it's easy to assume that this:
char *ptr = NULL;
*ptr = '?';
means something like "attempt to store the character '?' at
memory location zero". But in fact, as far as the C standard is
concerned, *it doesn't mean anything at all*, and a compiler will
not necessarily assign any meaning to it. A sufficiently naive
non-optimizing compiler will likely generate code that attempts
to store '?' at location zero, but compilers are not required to
be naive.
--
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-01-04 15:44 -0800 |
| Message-ID | <403e4de2-151e-4e63-81f0-6bf334e0f266@googlegroups.com> |
| In reply to | #55837 |
On Sunday, January 4, 2015 8:59:17 PM UTC, Richard Damon wrote: > > Most undefined behavior actually have very predictable behavior given a > bit of study, and knowledge of the system being used (at least on a > micro scale). Some of it might be documented by the implementation, and > some might not be. Using this sort of knowledge is going to make your > program "non-portable", but this is often acceptable. > Not really. The understanding is that undefined behaviour makes a program an incorrect C program. Of course most program have to do things that C doesn't define, like open windows or list the files in a directory. The correct approach is to provide functions with C linkage, written in assembly, which implement the behaviour C doesn't define. The C is then well defined, in terms of the C standard and the assembly interface. The assembly can be as simple as "load accumulator with address of screen buffer and return it", or, "multiply two 32 bit numbers putting the high 32 bits at one address and the low 32 bits at the following address".
[toc] | [prev] | [next] | [standalone]
Page 8 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