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 5 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-18 17:21 +0000 |
| Message-ID | <87k31oyity.fsf@bsb.me.uk> |
| In reply to | #54909 |
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> >>>>> I have a device in my possession that measures the precise distance >>>>> between itself and three fixed points in the room. Please show me a >>>>> well-defined C program that can read the data from my device correctly. >>>>> I will test your program and let you know whether it works. If you can >>>>> do it, I agree that I'm wrong. If you can't, I shan't. >>>> >>>> This, I think, is at the heart of any apparent disagreement about terms >>>> like "powerful". You like C because it is powerful and easy to add >>>> functionality to, and you think that these properties originate in the >>>> fact C is, in some sense, less rigorously defined than some other >>>> languages (again, I don't think exactly what the means really matters to >>>> the argument). >>> >>> Almost. I wasn't thinking of it in comparison to other languages, >>> actually, but purely in its own terms. >> >> Ah, we now be talking about different things. My comment relates to >> statements like this: >> >> | 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. >> >> That seems to be contrasting C with other languages (even if >> hypothetical ones). > > I'll hope you'll forgive me for being a pain, but if there was a comparison > going on in my head at the time of writing it would have been a comparison > between C-locked-down and C-free-to-be-cool. Well that was not clear. What does C-locked-down look like? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-18 18:15 +0000 |
| Message-ID | <LQEkw.189425$RM2.49981@fx43.am4> |
| In reply to | #54971 |
Ben Bacarisse wrote: > 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> >>>>>> I have a device in my possession that measures the precise distance >>>>>> between itself and three fixed points in the room. Please show me a >>>>>> well-defined C program that can read the data from my device >>>>>> correctly. I will test your program and let you know whether it >>>>>> works. If you can do it, I agree that I'm wrong. If you can't, I >>>>>> shan't. >>>>> >>>>> This, I think, is at the heart of any apparent disagreement about >>>>> terms >>>>> like "powerful". You like C because it is powerful and easy to add >>>>> functionality to, and you think that these properties originate in the >>>>> fact C is, in some sense, less rigorously defined than some other >>>>> languages (again, I don't think exactly what the means really matters >>>>> to the argument). >>>> >>>> Almost. I wasn't thinking of it in comparison to other languages, >>>> actually, but purely in its own terms. >>> >>> Ah, we now be talking about different things. My comment relates to >>> statements like this: >>> >>> | 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. >>> >>> That seems to be contrasting C with other languages (even if >>> hypothetical ones). >> >> I'll hope you'll forgive me for being a pain, but if there was a >> comparison going on in my head at the time of writing it would have been >> a comparison between C-locked-down and C-free-to-be-cool. > > Well that was not clear. Sorry. > 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!). > > <snip> -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-19 01:20 +0000 |
| Message-ID | <874msswi3g.fsf@bsb.me.uk> |
| In reply to | #54981 |
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: >>>> >>>>> Ben Bacarisse wrote: >>>>> >>>>>> Richard Heathfield <invalid@see.sig.invalid> writes: >>>> <snip> >>>>>>> I have a device in my possession that measures the precise distance >>>>>>> between itself and three fixed points in the room. Please show me a >>>>>>> well-defined C program that can read the data from my device >>>>>>> correctly. I will test your program and let you know whether it >>>>>>> works. If you can do it, I agree that I'm wrong. If you can't, I >>>>>>> shan't. >>>>>> >>>>>> This, I think, is at the heart of any apparent disagreement about >>>>>> terms >>>>>> like "powerful". You like C because it is powerful and easy to add >>>>>> functionality to, and you think that these properties originate in the >>>>>> fact C is, in some sense, less rigorously defined than some other >>>>>> languages (again, I don't think exactly what the means really matters >>>>>> to the argument). >>>>> >>>>> Almost. I wasn't thinking of it in comparison to other languages, >>>>> actually, but purely in its own terms. >>>> >>>> Ah, we now be talking about different things. My comment relates to >>>> statements like this: >>>> >>>> | 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. >>>> >>>> That seems to be contrasting C with other languages (even if >>>> hypothetical ones). >>> >>> I'll hope you'll forgive me for being a pain, but if there was a >>> comparison going on in my head at the time of writing it would have been >>> a comparison between C-locked-down and C-free-to-be-cool. >> >> Well that was not clear. > > Sorry. > >> 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... <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 07:48 +0000 |
| Message-ID | <ALQkw.114331$Cy6.90924@fx23.am4> |
| In reply to | #55025 |
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. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 07:40 -0500 |
| Message-ID | <m716bq$i5$1@dont-email.me> |
| In reply to | #55038 |
On 12/19/2014 02:48 AM, Richard Heathfield wrote: > 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. Why not? What prevents the implementation-defined behavior of a given construct from having the effect of giving access to that device? Until you define "locked-down C" sufficiently tightly to rule out that possibility, it's not clear that there's any problem. Why do you think that undefined behavior is necessary for this purpose? Why isn't implementation-defined behavior sufficient? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 12:54 +0000 |
| Message-ID | <jeVkw.179964$or5.57791@fx11.am4> |
| In reply to | #55060 |
James Kuyper wrote: > On 12/19/2014 02:48 AM, Richard Heathfield wrote: >> 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. > > Why not? What prevents the implementation-defined behavior of a given > construct from having the effect of giving access to that device? Until > you define "locked-down C" sufficiently tightly to rule out that > possibility, it's not clear that there's any problem. Why do you think > that undefined behavior is necessary for this purpose? Why isn't > implementation-defined behavior sufficient? Let's try it. Implementation-defined behaviour is unspecified behaviour where each implementation documents how the choice is made. Unspecified behaviour is behaviour where the Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance. The Standard does not require any implementation to support my position- sensing device. The closest it comes is in 7.19.2 Streams, but it does not define or specify how to map a device to a stream, and it does not require implementations to provide such a mapping to my specific device. Since the Standard doesn't require any implementation to support this device, it will be necessary to implement it oneself on systems where the implementation doesn't support it. How, without UB? -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 09:54 -0500 |
| Message-ID | <54943C24.4040407@verizon.net> |
| In reply to | #55061 |
On 12/19/2014 07:54 AM, Richard Heathfield wrote: > James Kuyper wrote: ... >> Why not? What prevents the implementation-defined behavior of a given >> construct from having the effect of giving access to that device? Until >> you define "locked-down C" sufficiently tightly to rule out that >> possibility, it's not clear that there's any problem. Why do you think >> that undefined behavior is necessary for this purpose? Why isn't >> implementation-defined behavior sufficient? > > Let's try it. Implementation-defined behaviour is unspecified behaviour > where each implementation documents how the choice is made. Unspecified > behaviour is behaviour where the Standard provides two or more possibilities > and imposes no further requirements on which is chosen in any instance. > > The Standard does not require any implementation to support my position- > sensing device. The closest it comes is in 7.19.2 Streams, but it does not > define or specify how to map a device to a stream, and it does not require > implementations to provide such a mapping to my specific device. > > Since the Standard doesn't require any implementation to support this > device, it will be necessary to implement it oneself on systems where the > implementation doesn't support it. How, without UB? Again, I can't see the problem. If it's possible to connect your device to a given platform, an implementor of C for that platform can provide features with the implementation-defined behavior of causing user-specified I/O to be performed through those connections. The implementor need not define what happens when that I/O is received through those connections by your device, that's the responsibility of the device designer, but you don't have to call the behavior "undefined" to make that work - it is defined, up to the system interface with external devices.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 15:19 +0000 |
| Message-ID | <OlXkw.483574$CW3.306863@fx07.am4> |
| In reply to | #55071 |
James Kuyper wrote: > On 12/19/2014 07:54 AM, Richard Heathfield wrote: <snip> >> Since the Standard doesn't require any implementation to support this >> device, it will be necessary to implement it oneself on systems where the >> implementation doesn't support it. How, without UB? > > Again, I can't see the problem. If it's possible to connect your device > to a given platform, an implementor of C for that platform can provide > features with the implementation-defined behavior of causing > user-specified I/O to be performed through those connections. Is it turtles all the way down? By which I mean, how does the *implementor* write the code to interface with that device, without UB? And what if the implementor doesn't support that device (perhaps because they've never heard of it)? How does one write the code oneself without UB? -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 11:00 -0500 |
| Message-ID | <54944BB2.4080700@verizon.net> |
| In reply to | #55073 |
On 12/19/2014 10:19 AM, Richard Heathfield wrote: > James Kuyper wrote: > >> On 12/19/2014 07:54 AM, Richard Heathfield wrote: > > <snip> > >>> Since the Standard doesn't require any implementation to support this >>> device, it will be necessary to implement it oneself on systems where the >>> implementation doesn't support it. How, without UB? >> >> Again, I can't see the problem. If it's possible to connect your device >> to a given platform, an implementor of C for that platform can provide >> features with the implementation-defined behavior of causing >> user-specified I/O to be performed through those connections. > > Is it turtles all the way down? > > By which I mean, how does the *implementor* write the code to interface with > that device, without UB? The same way it writes code to implement addition of two int values without undefined behavior. In either case, the implementation will be in a platform-specific assembler or machine language, with behavior that is well-defined by that language. > And what if the implementor doesn't support that device (perhaps because > they've never heard of it)? How does one write the code oneself without UB? They don't need to support the device; all they need to do is support the connection to the device. Knowing how to access all of the available connections provided by a given platform strikes me as a very ordinary thing I'd expect any implementor targeting that platform to be able to do. The user code needs to understand the device, but implementation's code need merely provide the tools for communicating with the device. As long as the use of the connection is well-defined, the fact that what happens on the other end of connection is outside the scope of the documentation is not sufficient to require the behavior to be described as "undefined". If you hadn't allowed for the possibility of implementation-defined behavior, or if you'd inserted even a single word suggesting that the solution needs to be portable, this would be a far more difficult challenge. However, as it stands, it seems trivial to meet this challenge. I can't provide example code, because it relies upon implementation-defined support. If you would care to provide a list of C features with implmentation-defined behavior, and to provide definitions for that behavior which provide adequate input and output access to the relevant connections on the relevant platform, and if you provide a description of the hardware interface to your device, I could, in principle, write appropriate user code to use those connections to interface with that device. In practice, I would expect creation of such a device driver to require a major commitment of time, far too large for me to tackle without being paid; and my lack of experience with this particular kind of programming suggests you wouldn't be getting good value for your money if you did pay me enough to justify spending my time to write it. But I don't see how it is necessary for C to have undefined behavior in order to make it work.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 16:13 +0000 |
| Message-ID | <b9Ykw.192687$Ea7.56636@fx16.am4> |
| In reply to | #55075 |
James Kuyper wrote: > On 12/19/2014 10:19 AM, Richard Heathfield wrote: >> James Kuyper wrote: >> >>> On 12/19/2014 07:54 AM, Richard Heathfield wrote: >> >> <snip> >> >>>> Since the Standard doesn't require any implementation to support this >>>> device, it will be necessary to implement it oneself on systems where >>>> the implementation doesn't support it. How, without UB? >>> >>> Again, I can't see the problem. If it's possible to connect your device >>> to a given platform, an implementor of C for that platform can provide >>> features with the implementation-defined behavior of causing >>> user-specified I/O to be performed through those connections. >> >> Is it turtles all the way down? >> >> By which I mean, how does the *implementor* write the code to interface >> with that device, without UB? > > The same way it writes code to implement addition of two int values > without undefined behavior. In either case, the implementation will be > in a platform-specific assembler or machine language, with behavior that > is well-defined by that language. So not in C, then. Kind of my point, James. <snip> -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 11:27 -0500 |
| Message-ID | <549451D5.1040000@verizon.net> |
| In reply to | #55077 |
On 12/19/2014 11:13 AM, Richard Heathfield wrote: > James Kuyper wrote: > >> On 12/19/2014 10:19 AM, Richard Heathfield wrote: >>> James Kuyper wrote: >>> >>>> On 12/19/2014 07:54 AM, Richard Heathfield wrote: >>> >>> <snip> >>> >>>>> Since the Standard doesn't require any implementation to support this >>>>> device, it will be necessary to implement it oneself on systems where >>>>> the implementation doesn't support it. How, without UB? >>>> >>>> Again, I can't see the problem. If it's possible to connect your device >>>> to a given platform, an implementor of C for that platform can provide >>>> features with the implementation-defined behavior of causing >>>> user-specified I/O to be performed through those connections. >>> >>> Is it turtles all the way down? >>> >>> By which I mean, how does the *implementor* write the code to interface >>> with that device, without UB? >> >> The same way it writes code to implement addition of two int values >> without undefined behavior. In either case, the implementation will be >> in a platform-specific assembler or machine language, with behavior that >> is well-defined by that language. > > So not in C, then. Kind of my point, James. Your point appeared to be about the necessity of having undefined behavior for some C code; what does the fact that C is, ultimately, always implemented in some lower-level platform-specific language have to do with that? It would still have to be implemented in a lower-level platform-specific language even if everything were well-defined, and I don't see how making it well-defined would prevent code with implementation-defined behavior from giving full access to all of the platform-specific connections to external devices.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 16:45 +0000 |
| Message-ID | <LCYkw.98512$AC.28334@fx29.am4> |
| In reply to | #55079 |
James Kuyper wrote: > On 12/19/2014 11:13 AM, Richard Heathfield wrote: >> James Kuyper wrote: >> >>> On 12/19/2014 10:19 AM, Richard Heathfield wrote: >>>> James Kuyper wrote: >>>> >>>>> On 12/19/2014 07:54 AM, Richard Heathfield wrote: >>>> >>>> <snip> >>>> >>>>>> Since the Standard doesn't require any implementation to support this >>>>>> device, it will be necessary to implement it oneself on systems where >>>>>> the implementation doesn't support it. How, without UB? >>>>> >>>>> Again, I can't see the problem. If it's possible to connect your >>>>> device to a given platform, an implementor of C for that platform can >>>>> provide features with the implementation-defined behavior of causing >>>>> user-specified I/O to be performed through those connections. >>>> >>>> Is it turtles all the way down? >>>> >>>> By which I mean, how does the *implementor* write the code to interface >>>> with that device, without UB? >>> >>> The same way it writes code to implement addition of two int values >>> without undefined behavior. In either case, the implementation will be >>> in a platform-specific assembler or machine language, with behavior that >>> is well-defined by that language. >> >> So not in C, then. Kind of my point, James. > > Your point appeared to be about the necessity of having undefined > behavior for some C code; My point is that there are some outcomes that cannot be achieved in ISO C (well-defined + IDB + USB + LSB). > what does the fact that C is, ultimately, > always implemented in some lower-level platform-specific language have > to do with that? Nothing, so why bring it up? > It would still have to be implemented in a lower-level > platform-specific language even if everything were well-defined, Especially if everything were well-defined. That's what I'm getting at. > and I > don't see how making it well-defined would prevent code with > implementation-defined behavior from giving full access to all of the > platform-specific connections to external devices. At some point, someone has to write the code that talks to the device hardware. Someone has to write the code that gets the bits (or analogue measurements, or whatever) off the pins and into a place where the data can be shoved into a stream (or whatever). I don't think it is possible to write that code in ISO C (WellDef+IDB+USB+LSB), in the general case. If it were, someone in this long thread would have demonstrated it by now. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 13:48 -0500 |
| Message-ID | <549472EB.8070200@verizon.net> |
| In reply to | #55086 |
On 12/19/2014 11:45 AM, Richard Heathfield wrote: > James Kuyper wrote: ... >> and I >> don't see how making it well-defined would prevent code with >> implementation-defined behavior from giving full access to all of the >> platform-specific connections to external devices. > > At some point, someone has to write the code that talks to the device > hardware. Someone has to write the code that gets the bits (or analogue > measurements, or whatever) off the pins and into a place where the data can > be shoved into a stream (or whatever). I don't think it is possible to write > that code in ISO C (WellDef+IDB+USB+LSB), in the general case. If it were, > someone in this long thread would have demonstrated it by now. What do you mean by "in the general case"? If, by that, you mean portable code, then you're rendering the inclusion of IDB, USB, and LSB meaningless, since portable code cannot rely upon IDB or USB, and since the set of supported locales is implementation-defined (7.11.1.1p3), there's not a lot that portable code can do with LSB, either You can write non-portable ISO C with implementation-defined behavior, which, could be defined by the implementation as causing the generation of the appropriate machine code needed to get those bits off of those pins and into a user-defined variable. For example, a non-STDC #pragma could have the implementation-defined behavior (6.10.6p1) of causing a specified machine port to become associated with a named volatile-qualified object, such that data read/written to that object is sent/received through that port. I'll grant you that only #pragma's implementation-defined behavior is sufficiently unrestricted to do anything this complicated. However, the fact that "What constitutes access an object that has a volatile-qualified type" is implementation-defined (6.7.3p7) opens up quite a few opportunities, too. I'll further grant you that implementation-specific function calls would be a better way to do something like this. But I think that a suitably defined #pragma would be sufficient to allow ISO C code to be used to cover just about any issue you might otherwise claim can only be handled by allowing the behavior to be undefined.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 19:10 +0000 |
| Message-ID | <hL_kw.76979$6Q5.74309@fx41.am4> |
| In reply to | #55099 |
James Kuyper wrote: <snip> > I'll further grant you that implementation-specific function calls would > be a better way to do something like this. But I think that a suitably > defined #pragma would be sufficient to allow ISO C code to be used to > cover just about any issue you might otherwise claim can only be handled > by allowing the behavior to be undefined. You make a good case. I would very much like to leave it at that, if I may. -- 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 | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2014-12-19 21:17 -0600 |
| Message-ID | <m72po9$9c9$1@speranza.aioe.org> |
| In reply to | #55086 |
On 12/19/14 10:45 AM, Richard Heathfield wrote:
> At some point, someone has to write the code that talks to the device
> hardware. Someone has to write the code that gets the bits (or analogue
> measurements, or whatever) off the pins and into a place where the data can
> be shoved into a stream (or whatever). I don't think it is possible to write
> that code in ISO C (WellDef+IDB+USB+LSB), in the general case. If it were,
> someone in this long thread would have demonstrated it by now.
Sigh. Near the top of http://www.iedu.com/Solar/LENR/Code.html is a
function time.c which returns a 64-bit date/time for a non-hosted
application.
The target hardware contains a clock divider circuit which causes a
32-bit ('long' in this toolchain) counter to be incremented once each
usec, and there is circuitry which causes a fetch from a specific memory
address (let’s say 0x00000001 for sake of discussion) to place the
content of the counter on the data bus (instead of the content of any
memory location).
The interface routine looks something like:
#define CLOCK_ADDR 1 /* memory-mapped 1 MHz clock address */
long micros(void)
{ return *((long *)CLOCK_ADDR);
}
Is this demonstration sufficient?
--
Morris Dovey
http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2014-12-19 21:32 -0600 |
| Message-ID | <m72qk9$bns$1@speranza.aioe.org> |
| In reply to | #55086 |
[ Corrects typo x3 in my previous post ]
On 12/19/14 10:45 AM, Richard Heathfield wrote:
> At some point, someone has to write the code that talks to the device
> hardware. Someone has to write the code that gets the bits (or analogue
> measurements, or whatever) off the pins and into a place where the data can
> be shoved into a stream (or whatever). I don't think it is possible to write
> that code in ISO C (WellDef+IDB+USB+LSB), in the general case. If it were,
> someone in this long thread would have demonstrated it by now.
Sigh. Near the top of http://www.iedu.com/Solar/LENR/Code.html is a
function time.c which returns a 64-bit date/time for a non-hosted
application.
The target hardware contains a clock divider circuit which causes a
32-bit ('unsigned long' in this toolchain) counter to be incremented
once each usec, and there is circuitry which causes a fetch from a
specific memory address (let’s say 0x00000001 for sake of discussion) to
place the content of the counter on the data bus (instead of the content
of any memory location).
The interface routine looks something like:
#define CLOCK_ADDR 1 /* memory-mapped 1 MHz clock address */
unsigned long micros(void)
{ return *((unsigned long *)CLOCK_ADDR);
}
Is this demonstration sufficient?
--
Morris Dovey
http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-12-19 16:49 +0000 |
| Message-ID | <87r3vvtwjl.fsf@bsb.me.uk> |
| In reply to | #55038 |
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.
(1) #include "tripos.h"
...
struct 3D_pos p = tripos_get_cur_pos();
(2) FILE *dev = fopen("dev://tri-position-finder", "rb");
...
struct 3D_pos p;
fread(&p, sizeof p, 1, dev);
(3) #include "tripos.h"
...
volatile struct tripos_control tpc;
tpc.command = TRIPOS_GET_CUR_POS;
if (tpc.position.x > 1.3) // and so on...
(4) void get_pos(void *vp)
{
_Pragma("DEVCTRL tipos load-position-via-praram #1");
}
...
struct 3D_pos p;
get_pos(&p);
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-19 17:00 +0000 |
| Message-ID | <1RYkw.92715$0o3.69735@fx45.am4> |
| In reply to | #55087 |
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...
>
> (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()?
(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.
And much the same objections can be made to all your examples. Do I need to
keep going? Okay, I'll keep going.
> ...
> struct 3D_pos p;
> fread(&p, sizeof p, 1, dev);
>
>
> (3) #include "tripos.h"
Again, the compilation fails at this point...
> ...
> 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.
>
> (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.
> }
> ...
> struct 3D_pos p;
> get_pos(&p);
>
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-12-19 13:57 -0500 |
| Message-ID | <5494752E.9000007@verizon.net> |
| In reply to | #55089 |
On 12/19/2014 12:00 PM, Richard Heathfield wrote: > Ben Bacarisse wrote: ... > 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. ... > ...and once we sort that out, we are faced with the problem that this code > doesn't work on the DS9000. You've been claiming that the problem is due to the locked-down nature of a hypothetically-modified version of the C standard. If the C standard were so modified, then the fact that the DS9000 doesn't provide any method of accessing your devices is nothing more than a choice made by the designers of the DS9000. They could have chosen, despite the hypothetically locked-down version of C, to provide access by any one of those methods, and many others, as well. The locking-down does not, itself, prevent the DS9000 from providing such access.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-12-19 14:31 -0800 |
| Message-ID | <51ed2a5b-e54b-46ad-8816-66a03127765f@googlegroups.com> |
| In reply to | #55100 |
On Friday, December 19, 2014 6:57:58 PM UTC, James Kuyper wrote: > > You've been claiming that the problem is due to the locked-down nature > of a hypothetically-modified version of the C standard. > If the C standard were so modified, then the fact that the DS9000 > doesn't provide any method of accessing your devices is nothing more > than a choice made by the designers of the DS9000. They could have > chosen, despite the hypothetically locked-down version of C, to provide > access by any one of those methods, and many others, as well. The > locking-down does not, itself, prevent the DS9000 from providing such > access. > Many moons ago, a weird DS9000-like architecture with segmented memory and other horrors had a character-mapped screen. The architects thoughtfully provided a header called conio.h that contained functions that would write a string to a given position on screen, in the set color. Great, except that if you tried to write a text editor, or a game of Space Invaders, and scroll the screen, it wouldn't have it. The primitive chips of the day just wouldn't do the calculations fast enough. By fiddling about a bit, you could write directly to screen memory. Then you got nice smooth scrolling Space Invaders.
[toc] | [prev] | [next] | [standalone]
Page 5 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