Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #75341 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-11-08 16:49 +0100 |
| Last post | 2015-11-12 14:39 +0100 |
| Articles | 20 on this page of 181 — 23 participants |
Back to article view | Back to comp.lang.c
Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 16:49 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 19:29 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 11:46 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:03 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 21:14 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:25 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:06 -0800
Re: Right C version for GCC Philip Lantz <prl@canterey.us> - 2015-11-08 14:52 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 15:12 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 09:38 +0100
Re: Right C version for GCC Nick Bowler <nbowler@draconx.ca> - 2015-11-09 19:04 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 00:00 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 16:35 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 12:37 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:58 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:19 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-08 21:49 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 14:14 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 01:02 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 02:26 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 15:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 08:55 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 17:07 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 09:51 -0800
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 19:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:16 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:30 +0100
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 20:40 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 08:56 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 09:41 -0800
Re: Right C version for GCC gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-09 17:44 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 18:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 18:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 10:27 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:17 -0800
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 22:59 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:15 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-12 16:47 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-12 09:24 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-13 12:54 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 12:01 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-14 10:47 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-14 21:32 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 16:57 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:18 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:27 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:41 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:12 +0100
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 23:13 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 19:02 -0500
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:52 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-10 21:34 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:28 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 00:51 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-17 22:26 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:06 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:37 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 12:54 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:14 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:37 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:56 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 17:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:37 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 18:06 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 18:51 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:40 -0800
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:55 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:50 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:32 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:35 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-08 23:57 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:47 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 13:18 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 14:01 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 00:55 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:42 +0000
Re: Right C version for GCC Chad <cdalten@gmail.com> - 2015-11-09 03:03 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 03:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 12:28 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 09:07 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 07:37 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 16:57 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:39 +0100
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 13:18 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:49 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-10 19:33 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:34 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-11 06:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:00 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:37 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 13:53 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:54 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:45 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:14 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 10:53 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 03:14 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 13:00 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 12:39 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 15:11 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 16:16 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:35 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:54 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 18:56 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 23:27 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:32 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-18 08:44 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:43 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-19 12:29 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:01 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-21 15:50 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:13 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 07:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:42 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:48 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-11 01:08 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:43 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:27 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 16:27 +0100
Re: Right C version for GCC David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:57 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-06 22:34 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 22:41 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 09:47 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 07:30 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 17:30 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 10:17 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:29 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 13:16 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 23:35 +0100
Re: Right C version for GCC jadill33@gmail.com - 2015-12-07 10:41 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:35 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:11 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 09:57 +1300
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 13:06 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 10:16 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 22:59 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 12:13 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:43 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 13:00 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 12:02 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 09:00 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 07:25 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:35 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 08:55 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:00 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:04 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:11 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 20:18 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:21 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:30 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:30 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 13:02 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:35 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 14:41 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 23:31 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:33 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:16 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:04 +1300
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:04 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:03 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:23 +1300
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:41 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 23:00 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 15:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:35 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:03 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 12:42 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:51 -0800
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-09 12:20 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:36 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 18:47 +0000
Re: Right C version for GCC Stephen Sprunk <stephen@sprunk.org> - 2015-11-11 00:55 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:39 +0100
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-09 01:02 +0000 |
| Message-ID | <87egg0q91s.fsf@bsb.me.uk> |
| In reply to | #75389 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, November 8, 2015 at 9:49:25 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> >> > no nested structure definitions, >> >> Do you know any compiler at all that does not support nested structure >> definitions? Even the V7 Unix compiler of 1978 did, and there's no >> mention of this restriction in any of the old C manuals that I can find. >> > I; trying to future-proof the code. It's not so important to support > obsolete compilers. What makes you think a compiler will one day reject nested struct definitions but not some other language feature? Why did you pick that one? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 02:26 -0800 |
| Message-ID | <d7e68532-eaa3-443e-a40e-c843c0e51c4e@googlegroups.com> |
| In reply to | #75412 |
On Monday, November 9, 2015 at 1:02:47 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Sunday, November 8, 2015 at 9:49:25 PM UTC, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
> >> > no nested structure definitions,
> >>
> >> Do you know any compiler at all that does not support nested structure
> >> definitions? Even the V7 Unix compiler of 1978 did, and there's no
> >> mention of this restriction in any of the old C manuals that I can find.
> >>
> > I; trying to future-proof the code. It's not so important to support
> > obsolete compilers.
>
> What makes you think a compiler will one day reject nested struct
> definitions but not some other language feature? Why did you pick that
> one?
>
From stackoverflow:
"What you can do is this:
struct mystruct
{
int x;
struct myinnerstruct
{
int y;
} m;
};
The declaration of m is a member declaration, so it's ok; it also declares the type struct
myinnerstruct. But in my opinion, it's poor style. gcc seems to think that the type struct
myinnerstruct remains visible after the declaration of struct mystruct is completed. It's
probably right (I'd have to check the standard), but it's counterintuitive; it's reasonable
to expect that its visibility ends at the enclosing }."
The poster is one Keith Thompson. It might be a different Keith to the one we know
and love, but that's unlikely.
He's a highly experienced C programmer, and he's by his own admission getting into
a bit of a mess.
So it's not unlikely that a future compiler writer will change the semantics so that
myinnerstruct has the scope you would expect. Or deprecate nested structures
to avoid the confusion. Or simply say that because they aren't used much, they're
not worth supporting.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 12:53 +0100 |
| Message-ID | <n1q1b5$ifq$1@dont-email.me> |
| In reply to | #75425 |
On 09/11/15 11:26, Malcolm McLean wrote:
> On Monday, November 9, 2015 at 1:02:47 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Sunday, November 8, 2015 at 9:49:25 PM UTC, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>>>>> no nested structure definitions,
>>>>
>>>> Do you know any compiler at all that does not support nested structure
>>>> definitions? Even the V7 Unix compiler of 1978 did, and there's no
>>>> mention of this restriction in any of the old C manuals that I can find.
>>>>
>>> I; trying to future-proof the code. It's not so important to support
>>> obsolete compilers.
>>
>> What makes you think a compiler will one day reject nested struct
>> definitions but not some other language feature? Why did you pick that
>> one?
>>
> From stackoverflow:
>
> "What you can do is this:
>
> struct mystruct
> {
> int x;
> struct myinnerstruct
> {
> int y;
> } m;
> };
>
> The declaration of m is a member declaration, so it's ok; it also declares the type struct
> myinnerstruct. But in my opinion, it's poor style. gcc seems to think that the type struct
> myinnerstruct remains visible after the declaration of struct mystruct is completed. It's
> probably right (I'd have to check the standard), but it's counterintuitive; it's reasonable
> to expect that its visibility ends at the enclosing }."
>
> The poster is one Keith Thompson. It might be a different Keith to the one we know
> and love, but that's unlikely.
> He's a highly experienced C programmer, and he's by his own admission getting into
> a bit of a mess.
>
> So it's not unlikely that a future compiler writer will change the semantics so that
> myinnerstruct has the scope you would expect. Or deprecate nested structures
> to avoid the confusion. Or simply say that because they aren't used much, they're
> not worth supporting.
>
It is highly unlikely that someone will change the semantics here,
because the semantics of such nested structs are well known (I'm sure
someone can quote the correct part of the standards). C has a single
global struct tag namespace - "struct myinnerstruct" is visible
everywhere after its definition.
What is interesting here is that C++ takes a different view, because in
C++ the "struct mystruct" creates a new scope. Thus "struct
myinnerstruct" is not visible without qualification outside of "mystruct".
You can certainly say that it is poor style, especially for people who
work with both C and C++, but it is not counterintuitive (it follows the
scoping rules in both C and C++), and it is not going to be changed in
the future.
It is also only one of three ways to make nested structs - and arguably
the worst of the three. If you want "struct myinnerstruct" to be
visible later, write:
struct myinnerstruct { int y; };
struct mystruct {
int x;
struct myinnerstruct m;
};
If you don't want to use it later, write:
struct mystruct {
int x;
struct { int y; } m;
};
Clear, consistent, works on virtually every C and C++ compiler past,
present and future.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-09 15:00 +0000 |
| Message-ID | <878u67p68w.fsf@bsb.me.uk> |
| In reply to | #75425 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, November 9, 2015 at 1:02:47 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Sunday, November 8, 2015 at 9:49:25 PM UTC, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> <snip>
>> >> > no nested structure definitions,
>> >>
>> >> Do you know any compiler at all that does not support nested structure
>> >> definitions? Even the V7 Unix compiler of 1978 did, and there's no
>> >> mention of this restriction in any of the old C manuals that I can find.
>> >>
>> > I; trying to future-proof the code. It's not so important to support
>> > obsolete compilers.
>>
>> What makes you think a compiler will one day reject nested struct
>> definitions but not some other language feature? Why did you pick that
>> one?
>>
> From stackoverflow:
>
> "What you can do is this:
>
> struct mystruct
> {
> int x;
> struct myinnerstruct
> {
> int y;
> } m;
> };
>
> The declaration of m is a member declaration, so it's ok; it also
> declares the type struct myinnerstruct. But in my opinion, it's poor
> style. gcc seems to think that the type struct myinnerstruct remains
> visible after the declaration of struct mystruct is completed. It's
> probably right (I'd have to check the standard), but it's
> counterintuitive; it's reasonable to expect that its visibility ends
> at the enclosing }."
>
> The poster is one Keith Thompson. It might be a different Keith to the
> one we know and love, but that's unlikely. He's a highly experienced
> C programmer, and he's by his own admission getting into a bit of a
> mess.
>
> So it's not unlikely that a future compiler writer will change the
> semantics so that myinnerstruct has the scope you would expect. Or
> deprecate nested structures to avoid the confusion.
The committee doesn't work like that. They don't break existing code to
avoid confusions on web forums. To fear that a feature will vanish from
the language because you saw someone comment about it being not entirely
clear is, frankly, daft.
By all means say it's bad style (it surely it) but I can't imagine that
it's not going to be changed by the committee. After all, it's survived
decades of opportunities for that.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 08:55 -0800 |
| Message-ID | <930d0544-5ea9-4b5a-b1f2-20d2f710ffc7@googlegroups.com> |
| In reply to | #75454 |
On Monday, November 9, 2015 at 3:01:00 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > The committee doesn't work like that. They don't break existing code to > avoid confusions on web forums. To fear that a feature will vanish from > the language because you saw someone comment about it being not entirely > clear is, frankly, daft. > > By all means say it's bad style (it surely it) but I can't imagine that > it's not going to be changed by the committee. After all, it's survived > decades of opportunities for that. > The committee don't have the final say. Implementors of C compilers do. Some of them might implement compilers which support a subset of C, others a superset. The so-called superset might actually be sloppily defined, such that the code is effectively a superset of commonly used C features, but will break if passed peculiar C. (The 11["Isn't this fun"] == 'f' syntax might have been hijacked for a hash table / associative array for instance. By sticking to the conservative core, you do as much as you can to protect against such problems.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-09 17:07 +0000 |
| Message-ID | <87ziynnlt7.fsf@bsb.me.uk> |
| In reply to | #75461 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, November 9, 2015 at 3:01:00 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The committee doesn't work like that. They don't break existing code to >> avoid confusions on web forums. To fear that a feature will vanish from >> the language because you saw someone comment about it being not entirely >> clear is, frankly, daft. >> >> By all means say it's bad style (it surely it) but I can't imagine that >> it's not going to be changed by the committee. After all, it's survived >> decades of opportunities for that. >> > The committee don't have the final say. Implementors of C compilers do. > Some of them might implement compilers which support a subset of C, > others a superset. The so-called superset might actually be sloppily defined, > such that the code is effectively a superset of commonly used C features, > but will break if passed peculiar C. (The 11["Isn't this fun"] == 'f' syntax might > have been hijacked for a hash table / associative array for instance. > > By sticking to the conservative core, you do as much as you can to protect > against such problems. Yes, I don't have a problem with the concept, only the specific advice and your evidence for it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 09:51 -0800 |
| Message-ID | <c9eb123f-2b98-4178-a50d-293bfbdfeddf@googlegroups.com> |
| In reply to | #75461 |
On Monday, November 9, 2015 at 10:55:57 AM UTC-6, Malcolm McLean wrote: > The committee don't have the final say. Implementors of C compilers do. It's a collaborative effort between implementers and users, since someone who implements a C compiler that nobody ever uses won't really control much of anything. Unfortunately, some compiler writers seem to be more interested in whether or not the Standard requires them to do something than in whether or not their users do. GCC used to be a source of good innovations, providing users with features they need, but the attitude of some of the people maintaining it seems to have shifted. Unfortunately, programmers seem to be acquiescing to such an attitude shift, and started accepting the idea that they should serve compilers, rather than demanding that compilers should serve them.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-11-09 19:01 +0100 |
| Message-ID | <n1qmsn$923$1@dont-email.me> |
| In reply to | #75468 |
Le 09/11/2015 18:51, supercat@casperkitty.com a écrit : > On Monday, November 9, 2015 at 10:55:57 AM UTC-6, Malcolm McLean wrote: >> The committee don't have the final say. Implementors of C compilers do. > > It's a collaborative effort between implementers and users, since someone who > implements a C compiler that nobody ever uses won't really control much of > anything. > > Unfortunately, some compiler writers seem to be more interested in whether or > not the Standard requires them to do something than in whether or not their > users do. GCC used to be a source of good innovations, providing users with > features they need, but the attitude of some of the people maintaining it > seems to have shifted. Unfortunately, programmers seem to be acquiescing to > such an attitude shift, and started accepting the idea that they should serve > compilers, rather than demanding that compilers should serve them. > I couldn't agree more. Each time I have proposed a new feature in this group the answer of the "regs" was the same: not standard, not standard, bla bla bla Each time I present something like the CCL, that would be an enormous step forward for C (as it was for C++) the answer is always the same: not standard, not standard, roll your own single linked list, etc Innovation is concentrated into the C Committee, that took years of discussions with people like P.J. Plaugher to get the C standard take away gets() or the bugs of asctime in their own code. In this group support for innovation is NULL except if you are a religious bigot.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 19:16 +0100 |
| Message-ID | <n1qns6$ahg$1@speranza.aioe.org> |
| In reply to | #75471 |
On 09.11.2015 19:01, jacobnavia wrote: > Le 09/11/2015 18:51, supercat@casperkitty.com a écrit : >> On Monday, November 9, 2015 at 10:55:57 AM UTC-6, Malcolm McLean wrote: >>> The committee don't have the final say. Implementors of C compilers do. >> >> It's a collaborative effort between implementers and users, since >> someone who >> implements a C compiler that nobody ever uses won't really control >> much of >> anything. >> >> Unfortunately, some compiler writers seem to be more interested in >> whether or >> not the Standard requires them to do something than in whether or not >> their >> users do. GCC used to be a source of good innovations, providing >> users with >> features they need, but the attitude of some of the people maintaining it >> seems to have shifted. Unfortunately, programmers seem to be >> acquiescing to >> such an attitude shift, and started accepting the idea that they >> should serve >> compilers, rather than demanding that compilers should serve them. >> > > I couldn't agree more. Each time I have proposed a new feature in this > group the answer of the "regs" was the same: > > not standard, not standard, bla bla bla > > > Each time I present something like the CCL, that would be an enormous > step forward for C (as it was for C++) the answer is always the same: > > not standard, not standard, roll your own single linked list, etc > > Innovation is concentrated into the C Committee, that took years of > discussions with people like P.J. Plaugher to get the C standard take > away gets() or the bugs of asctime in their own code. Well, my thinking is that it is OK to try new things. I don't know how many users your compiler has, but it might be an easier sell if you can make new, non-standard functionality something that can be used on other compilers as well. Either as a macro, as a well-defined feature which is easy to implement or something along those lines. If a user doesn't risk being locked in, it is easier to try out new features. -Morten
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 11:24 -0800 |
| Message-ID | <5e669ac8-5e77-4bf9-8d61-6ab7157f126a@googlegroups.com> |
| In reply to | #75471 |
On Monday, November 9, 2015 at 12:01:11 PM UTC-6, jacobnavia wrote: > Each time I present something like the CCL, that would be an enormous > step forward for C (as it was for C++) the answer is always the same: One of the major obstacles to adding new features is avoiding making code that uses the features incompatible with existing compilers which could otherwise support the necessary semantics. The approach I'd like to see the language take would be to add standardized macros which could be mapped to compiler intrinsics on new compilers, or could be defined using header files to enable compatibility with existing compilers that "naturally" support the required semantics. The reason C has thrived is that it has historically allowed programmers targeting platforms with features beyond the Standard's minimum requirements to take advantage of those features, while allowing C to be used on platforms that lack such features to run programs that don't require them. To my mind, it should be possible to formulate a standard for "universal extended C" and a standard of strictly-UXC-conforming programs such that 1. Most practical C programs could be turned into strictly-UXC-conforming programs merely by the addition of suitable compiler directives or the substitutions of certain types. 2. Feeding a strictly-UXC-conforming program to a strictly-conforming implementation will result in that program either running with the intended behavior or identifying a requirement the implementation cannot meet. Adopting that sort of philosophy would make the Standard meaningful in ways which it presently is not (one could have a conforming compiler which would be incapable of compiling any useful programs, or a strictly-conforming program which would die with a stack overflow on any compiler other than the one above). The range of platforms that could accommodate C implementations meeting a defined standard would be increased somewhat, and the fraction of useful programs which could be practically implemented to a meaningful conformance standard would be increased enormously. How would you rate such a philosophy from a standpoint of desirability, technical feasibility, and political feasibility?
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 20:30 +0100 |
| Message-ID | <n1qs77$kkh$1@speranza.aioe.org> |
| In reply to | #75493 |
On 09.11.2015 20:24, supercat@casperkitty.com wrote: > On Monday, November 9, 2015 at 12:01:11 PM UTC-6, jacobnavia wrote: >> Each time I present something like the CCL, that would be an enormous >> step forward for C (as it was for C++) the answer is always the same: > > One of the major obstacles to adding new features is avoiding making code > that uses the features incompatible with existing compilers which could > otherwise support the necessary semantics. The approach I'd like to see > the language take would be to add standardized macros which could be mapped > to compiler intrinsics on new compilers, or could be defined using header > files to enable compatibility with existing compilers that "naturally" > support the required semantics. Yeah that's pretty much what I said earlier. -Morten
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-11-09 20:40 +0100 |
| Message-ID | <n1qso0$26m$1@dont-email.me> |
| In reply to | #75493 |
Le 09/11/2015 20:24, supercat@casperkitty.com a écrit : > One of the major obstacles to adding new features is avoiding making code > that uses the features incompatible with existing compilers which could > otherwise support the necessary semantics. Note that the code of the CCL does not use any feature not present in C-89. The container library is not a language extension but a library extension. It compiles in all compilers that support C-89 and above.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 08:56 -0800 |
| Message-ID | <ln8u67yuv9.fsf@kst-u.example.com> |
| In reply to | #75425 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, November 9, 2015 at 1:02:47 AM UTC, Ben Bacarisse wrote:
[...]
>> What makes you think a compiler will one day reject nested struct
>> definitions but not some other language feature? Why did you pick that
>> one?
>>
> From stackoverflow:
>
> "What you can do is this:
>
> struct mystruct
> {
> int x;
> struct myinnerstruct
> {
> int y;
> } m;
> };
>
> The declaration of m is a member declaration, so it's ok; it also
> declares the type struct myinnerstruct. But in my opinion, it's poor
> style. gcc seems to think that the type struct myinnerstruct remains
> visible after the declaration of struct mystruct is completed. It's
> probably right (I'd have to check the standard), but it's
> counterintuitive; it's reasonable to expect that its visibility ends
> at the enclosing }."
>
> The poster is one Keith Thompson. It might be a different Keith to the
> one we know and love, but that's unlikely. He's a highly experienced
> C programmer, and he's by his own admission getting into a bit of a
> mess.
I'm sure that was me. I don't know what question I was answering; can
you post a link? I'd like to update it.
C's scoping rules are quite clearly defined. N1570 6.1.2p2 says:
There are four kinds of scopes: function, file, block, and
function prototype.
This is exactly the same wording that appears in the C90 and C90
standards. A struct specifier does not create a scope, therefore
the name "struct myinnerstruct" is visible from the point of its
declaration to the end of the enclosing block (or to the end of
the translation unit if it's at file scope); it does not become
invisible at the closing "}" of the enclosing structure definition.
> So it's not unlikely that a future compiler writer will change the
> semantics so that myinnerstruct has the scope you would expect. Or
> deprecate nested structures to avoid the confusion. Or simply say
> that because they aren't used much, they're not worth supporting.
No competent C compiler writer would make such a change, and I can't
think of any good reason that a future C standard committee would
introduce a new kind of scope that could break existing code.
If you don't want to use nested structs, by all means don't.
But please don't try to justify your dislike of a well defined
standard feature by pretending that it might vanish.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 09:41 -0800 |
| Message-ID | <0c1e3897-c195-48ef-b143-2eed578dc744@googlegroups.com> |
| In reply to | #75462 |
On Monday, November 9, 2015 at 4:56:35 PM UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Monday, November 9, 2015 at 1:02:47 AM UTC, Ben Bacarisse wrote:
> [...]
> >> What makes you think a compiler will one day reject nested struct
> >> definitions but not some other language feature? Why did you pick that
> >> one?
> >>
> > From stackoverflow:
> >
> > "What you can do is this:
> >
> > struct mystruct
> > {
> > int x;
> > struct myinnerstruct
> > {
> > int y;
> > } m;
> > };
> >
> > The declaration of m is a member declaration, so it's ok; it also
> > declares the type struct myinnerstruct. But in my opinion, it's poor
> > style. gcc seems to think that the type struct myinnerstruct remains
> > visible after the declaration of struct mystruct is completed. It's
> > probably right (I'd have to check the standard), but it's
> > counterintuitive; it's reasonable to expect that its visibility ends
> > at the enclosing }."
> >
> > The poster is one Keith Thompson. It might be a different Keith to the
> > one we know and love, but that's unlikely. He's a highly experienced
> > C programmer, and he's by his own admission getting into a bit of a
> > mess.
>
> I'm sure that was me. I don't know what question I was answering; can
> you post a link? I'd like to update it.
>
Here you are:
http://stackoverflow.com/questions/7341123/nested-structure-syntax
>
> If you don't want to use nested structs, by all means don't.
> But please don't try to justify your dislike of a well defined
> standard feature by pretending that it might vanish.
>
We've already had a case. SDCC does not support nested structs. I wasn't
aware of that, but I was right, the future-proofing turned out to be
well advised.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-11-09 17:44 +0000 |
| Message-ID | <n1qm2o$457$1@news.xmission.com> |
| In reply to | #75466 |
In article <0c1e3897-c195-48ef-b143-2eed578dc744@googlegroups.com>,
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
...
>> > The poster is one Keith Thompson. It might be a different Keith to the
>> > one we know and love, but that's unlikely. He's a highly experienced
>> > C programmer, and he's by his own admission getting into a bit of a
>> > mess.
>>
>> I'm sure that was me. I don't know what question I was answering; can
>> you post a link? I'd like to update it.
>>
>Here you are:
>http://stackoverflow.com/questions/7341123/nested-structure-syntax
>>
>> If you don't want to use nested structs, by all means don't.
>> But please don't try to justify your dislike of a well defined
>> standard feature by pretending that it might vanish.
>>
>We've already had a case. SDCC does not support nested structs. I wasn't
>aware of that, but I was right, the future-proofing turned out to be
>well advised.
The rules of CLC:
1) Keith "Kiki" Thompson is never wrong.
2) When he is wrong, see rule 1).
--
"This ain't my first time at the rodeo"
is a line from the movie, Mommie Dearest, said by Joan Crawford at a board meeting.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-09 18:53 +0100 |
| Message-ID | <n1qmjm$p4f$1@solani.org> |
| In reply to | #75466 |
On 09.11.2015 18:41, Malcolm McLean wrote: >> > We've already had a case. SDCC does not support nested structs. I wasn't > aware of that, but I was right, the future-proofing turned out to be > well advised. > SDCC supports nested structs. AFAIK, SDCC is currently missing only three bits of the C90 standard: * Data type double. * Structures and unions can not be assigned, passed as function parameters or return values. * K & R style function declarations. http://sdcc.sourceforge.net/mediawiki/index.php/Standard_compliance#ISO_C11 Philipp
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-09 18:00 +0000 |
| Message-ID | <87twovnjdm.fsf@bsb.me.uk> |
| In reply to | #75466 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, November 9, 2015 at 4:56:35 PM UTC, Keith Thompson wrote: <snip> >> If you don't want to use nested structs, by all means don't. >> But please don't try to justify your dislike of a well defined >> standard feature by pretending that it might vanish. >> > We've already had a case. Not yet, no. > SDCC does not support nested structs. I wasn't > aware of that, but I was right, the future-proofing turned out to be > well advised. As far as I know it does. It but it does support double so you should add that to your list of things to avoid in portable programs. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 10:27 -0800 |
| Message-ID | <1ae49c07-2763-4ef5-ad97-ca00834f8db8@googlegroups.com> |
| In reply to | #75470 |
On Monday, November 9, 2015 at 6:00:13 PM UTC, Ben Bacarisse wrote: > > As far as I know it does. It but it does support double so you should > add that to your list of things to avoid in portable programs. > C compilers often don't support floating point arithmetic. But it's not practical to write some functions without. Sometimes double is provided and sometimes float is. Sometimes the missing type is supported, but with software emulation so slow that it's effectively unusable. Unfortunately I don't have a good system for protecting against that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 11:17 -0800 |
| Message-ID | <lnh9kvx9rd.fsf@kst-u.example.com> |
| In reply to | #75479 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, November 9, 2015 at 6:00:13 PM UTC, Ben Bacarisse wrote:
>>
>> As far as I know it does. It but it does support double so you should
>> add that to your list of things to avoid in portable programs.
>>
> C compilers often don't support floating point arithmetic. But it's
> not practical to write some functions without. Sometimes double is
> provided and sometimes float is. Sometimes the missing type is
> supported, but with software emulation so slow that it's effectively
> unusable.
>
> Unfortunately I don't have a good system for protecting against that.
Floating pointer arithmetic is not an optional feature. Strictly
speaking, a compiler that doesn't support it is not a C compiler.
Which is not to say that I object to calling something a "C compiler"
if it's not 100% compliant, but it's a good idea to qualify it.
It would probably be reasonable to make floating point optional
for freestanding implementations, but there's a question of how
far the standard should go to cater to tiny systems.
--
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-11-09 22:59 +0000 |
| Message-ID | <n1r8g8$gro$1@speranza.aioe.org> |
| In reply to | #75491 |
Keith Thompson <kst-u@mib.org> wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: (snip) >> C compilers often don't support floating point arithmetic. But it's >> not practical to write some functions without. Sometimes double is >> provided and sometimes float is. Sometimes the missing type is >> supported, but with software emulation so slow that it's effectively >> unusable. (snip) > Floating pointer arithmetic is not an optional feature. Strictly > speaking, a compiler that doesn't support it is not a C compiler. For a processor with an address space smaller than the routines to do software floating point, there doesn't seem much reason to try to write the routines. > Which is not to say that I object to calling something a "C compiler" > if it's not 100% compliant, but it's a good idea to qualify it. There are some that have names with a C in them, but hopefully don't claim to conform to the standard. > It would probably be reasonable to make floating point optional > for freestanding implementations, but there's a question of how > far the standard should go to cater to tiny systems. Some time ago, there was discussion of the 4004. In that case, even char isn't easy. -- glen
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web