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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 11:15 -0800 |
| Message-ID | <lnlha7x9vt.fsf@kst-u.example.com> |
| In reply to | #75470 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 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.
Not surprisingly, it doesn't support long double either.
<http://sdcc.sourceforge.net/mediawiki/index.php/Standard_compliance>
lists double under C90 and C95, and both double and long double
under C99 and C11. It looks like the authors are under the mistaken
impression that long double was introduced by C99. In fact, it
exists in C90 as well. (I've seen a gcc warning message that implies
a similar misconception.) I've sent an e-mail pointing this out.
--
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 | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-12 16:47 +0100 |
| Message-ID | <n22ccn$bjr$2@solani.org> |
| In reply to | #75490 |
On 09.11.2015 20:15, Keith Thompson wrote: > […]It looks like the authors are under the mistaken > impression that long double was introduced by C99. In fact, it > exists in C90 as well. (I've seen a gcc warning message that implies > a similar misconception.) I guess the very limited availability of the C90 and C95 standards conributes to such problems. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-12 09:24 -0800 |
| Message-ID | <lnfv0bqgf1.fsf@kst-u.example.com> |
| In reply to | #75832 |
Philipp Klaus Krause <pkk@spth.de> writes:
> On 09.11.2015 20:15, Keith Thompson wrote:
>> […]It looks like the authors are under the mistaken
>> impression that long double was introduced by C99. In fact, it
>> exists in C90 as well. (I've seen a gcc warning message that implies
>> a similar misconception.)
>
> I guess the very limited availability of the C90 and C95 standards
> conributes to such problems.
K&R2 mentions long double. I presume any other C89/C90 reference
would as well. Drafts of the C99 and C11 standards are freely
available (N1256 and N1570, respectively), and they don't mention
long double as a new feature.
<math.h> functions operating on long double (sqrtl() et al) are new
in C99, but the type itself is not. Functions operating on float
(sqrtf() et al) are also new in C99, but that presumably wouldn't
lead someone to think that float is a new type.
--
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 | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-13 12:54 +0100 |
| Message-ID | <n24j17$aoc$1@solani.org> |
| In reply to | #75845 |
On 12.11.2015 18:24, Keith Thompson wrote: > Philipp Klaus Krause <pkk@spth.de> writes: >> On 09.11.2015 20:15, Keith Thompson wrote: >>> […]It looks like the authors are under the mistaken >>> impression that long double was introduced by C99. In fact, it >>> exists in C90 as well. (I've seen a gcc warning message that implies >>> a similar misconception.) >> >> I guess the very limited availability of the C90 and C95 standards >> conributes to such problems. > > K&R2 mentions long double. I presume any other C89/C90 reference > would as well. Drafts of the C99 and C11 standards are freely > available (N1256 and N1570, respectively), and they don't mention > long double as a new feature. > > <math.h> functions operating on long double (sqrtl() et al) are new > in C99, but the type itself is not. Functions operating on float > (sqrtf() et al) are also new in C99, but that presumably wouldn't > lead someone to think that float is a new type. > How up to date is http://www.iso-9899.info/wiki/The_Standard? Through the links there, I was able to find one seller of AMD1 (the C90 vs C95 diff), but none for C90. Do you know of any place where the C90 standard is available? Philipp
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-13 12:01 -0800 |
| Message-ID | <kfna8qhr7mw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #75938 |
Philipp Klaus Krause <pkk@spth.de> writes:
> On 12.11.2015 18:24, Keith Thompson wrote:
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>> On 09.11.2015 20:15, Keith Thompson wrote:
>>>> [?]It looks like the authors are under the mistaken
>>>> impression that long double was introduced by C99. In fact, it
>>>> exists in C90 as well. (I've seen a gcc warning message that implies
>>>> a similar misconception.)
>>>
>>> I guess the very limited availability of the C90 and C95 standards
>>> conributes to such problems.
>>
>> K&R2 mentions long double. I presume any other C89/C90 reference
>> would as well. Drafts of the C99 and C11 standards are freely
>> available (N1256 and N1570, respectively), and they don't mention
>> long double as a new feature.
>>
>> <math.h> functions operating on long double (sqrtl() et al) are new
>> in C99, but the type itself is not. Functions operating on float
>> (sqrtf() et al) are also new in C99, but that presumably wouldn't
>> lead someone to think that float is a new type.
>
> How up to date is http://www.iso-9899.info/wiki/The_Standard?
> Through the links there, I was able to find one seller of AMD1 (the C90
> vs C95 diff), but none for C90. Do you know of any place where the C90
> standard is available?
I expect you will want to see this if you haven't
already:
http://flash-gordon.me.uk/ansi.c.txt
My understanding is the contents are the same as the C90 standard,
just with different section numbering.
Here are some other links you may find useful:
http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html
http://www.bsb.me.uk/ansi-c/ansi-c
http://www.bsb.me.uk/ansi-c/ansi-c-one-file
http://nepsweb.co.uk/langstand/isoC/gordon/ansi-c89w.txt
http://nepsweb.co.uk/langstand/isoC/gordon/ansi-c89u.txt
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 10:47 -0800 |
| Message-ID | <lntwooo1ts.fsf@kst-u.example.com> |
| In reply to | #75969 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Philipp Klaus Krause <pkk@spth.de> writes:
[...]
>> How up to date is http://www.iso-9899.info/wiki/The_Standard?
>> Through the links there, I was able to find one seller of AMD1 (the C90
>> vs C95 diff), but none for C90. Do you know of any place where the C90
>> standard is available?
>
> I expect you will want to see this if you haven't
> already:
>
> http://flash-gordon.me.uk/ansi.c.txt
>
> My understanding is the contents are the same as the C90 standard,
> just with different section numbering.
The 1989 ANSI and 1990 ISO C standard documents are essentially
identical, with ISO inserting some more or less boilerplate introductory
material and incrementing the section numbers by 3.
My understanding is that ansi.c.txt is a draft of the final 1989 ANSI C
standard. There were probably some changes between that draft and the
published standard, but I expect they'd be minor.
I have official PDF copies of the 1990, 1999, and 2011 ISO standards,
purchased from ANSI. The 1990 standard was digitized from a hard copy;
you can copy-and-paste the text, but you'll have to fix a lot of errors.
I don't know whether they still sell the older standards, or for how
much. Google "ANSI store" and search for 9899. The 1995 amendment was
available at no charge at one time, as were the 3 Technical Corrigenda
for C99 and the one for C11.
--
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 | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-14 21:32 +0100 |
| Message-ID | <n285pa$aca$1@solani.org> |
| In reply to | #76004 |
On 14.11.2015 19:47, Keith Thompson wrote: > I have official PDF copies of the 1990, 1999, and 2011 ISO standards, > purchased from ANSI. The 1990 standard was digitized from a hard copy; It seems no one is selling the 1990 standard anymore. However, I just found it on bittorrent. Looks like it is the one you have. > you can copy-and-paste the text, but you'll have to fix a lot of errors. > I don't know whether they still sell the older standards, or for how > much. Google "ANSI store" and search for 9899. They no longer have the older standards. > The 1995 amendment was > available at no charge at one time, as were the 3 Technical Corrigenda > for C99 and the one for C11. > Hmm, it seems there is exactly one place selling the 1995 amendment. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-14 16:57 -0800 |
| Message-ID | <kfnbnawoz8u.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76004 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Philipp Klaus Krause <pkk@spth.de> writes: > > [...] > >>> How up to date is http://www.iso-9899.info/wiki/The_Standard? >>> Through the links there, I was able to find one seller of AMD1 (the C90 >>> vs C95 diff), but none for C90. Do you know of any place where the C90 >>> standard is available? >> >> I expect you will want to see this if you haven't >> already: >> >> http://flash-gordon.me.uk/ansi.c.txt >> >> My understanding is the contents are the same as the C90 standard, >> just with different section numbering. > > The 1989 ANSI and 1990 ISO C standard documents are essentially > identical, with ISO inserting some more or less boilerplate > introductory material and incrementing the section numbers by 3. Right. My statement was about ansi.c.txt and C90, not about C89 and C90. > My understanding is that ansi.c.txt is a draft of the final 1989 > ANSI C standard. There were probably some changes between that > draft and the published standard, but I expect they'd be minor. Which is basically what I was trying to say (although your comments are more precise, so thank you for that).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 11:07 -0800 |
| Message-ID | <lnpozjxa93.fsf@kst-u.example.com> |
| 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:
[...]
>> 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
Thanks. I see you didn't quote the part of my answer where I cited the
wording in the C standard that says there are four kinds of scopes.
I've just cleaned up the answer a bit to make it clearer.
>> 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.
That's not what I'd call future-proofing. SDCC is an incomplete
compiler. As I understand it, its authors intend to implement
standard C (which of course includes nested structures) in the
future.
If I have a specific need for my code to work with SDCC, then
of course I'll avoid using any features that it doesn't support.
Otherwise, it is not reasonable to point to some unfinished partial
C compiler as a reason to avoid using features that it doesn't
yet support.
**That's the whole point of having a standard.**
Suppose I'm working on a C compiler that doesn't yet support lower case
letters. Should you write "Hello, world" as "HELLO, WORLD" just in case
you might need to use my compiler?
You can write portable C code *or* you can write code that targets
the C subset supported by SDCC (or by any other not-quite-C compiler
you choose). You cannot reasonably do both.
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 20:18 +0100 |
| Message-ID | <n1qri5$ivt$1@speranza.aioe.org> |
| In reply to | #75489 |
On 09.11.2015 20:07, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: [...] > Suppose I'm working on a C compiler that doesn't yet support lower case > letters. Should you write "Hello, world" as "HELLO, WORLD" just in case > you might need to use my compiler? I think that's a really bad comparison. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 11:27 -0800 |
| Message-ID | <lnd1vjx9av.fsf@kst-u.example.com> |
| In reply to | #75492 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 09.11.2015 20:07, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> Suppose I'm working on a C compiler that doesn't yet support lower case
>> letters. Should you write "Hello, world" as "HELLO, WORLD" just in case
>> you might need to use my compiler?
>
> I think that's a really bad comparison.
How so?
Both Malcolm's example of nested structs (which, as it turns out,
*are* supported by SDCC) and my example of uppercase letters are
features that are required by all versions of the C standard.
You can either assume that all features required by the standard
are implemented, or not.
Though it does depend on what exactly we mean by "nested structures".
Structures as members of structures are supported by all conforming
C compilers. Anonymous structures are supported as an extension by
some pre-C11 compilers, and are a standard feature starting with C11.
If you have to use a compiler that doesn't fully conform to the C
standard, then of course you have to avoid the features it doesn't
(yet?) support. But in the absence of any such specific requirement,
it is in my opinion foolish to worry about it.
Not supporting lowercase letters is probably not a plausible
restriction. Perhaps long int would be a better example. I can easily
imagine a small embedded compiler not supporting long int; that's not
going to make me hesitate to use long int in my code if I need it.
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 20:41 +0100 |
| Message-ID | <n1qst4$mfn$1@speranza.aioe.org> |
| In reply to | #75494 |
On 09.11.2015 20:27, Keith Thompson wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: >> On 09.11.2015 20:07, Keith Thompson wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> [...] >>> Suppose I'm working on a C compiler that doesn't yet support lower case >>> letters. Should you write "Hello, world" as "HELLO, WORLD" just in case >>> you might need to use my compiler? >> >> I think that's a really bad comparison. > > How so? > > Both Malcolm's example of nested structs (which, as it turns out, > *are* supported by SDCC) and my example of uppercase letters are > features that are required by all versions of the C standard. > You can either assume that all features required by the standard > are implemented, or not. Well, the English alphabet has 26 characters. Writing something in uppercase, when lowercase can be expected, is something like shouting, and talking normal and shouting are to completely different things. So what, you have to pass a pointer back or not have things nested in a pretty way, what's the big deal? I found your comparison overly dramatic and inaccurate. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 12:07 -0800 |
| Message-ID | <ln1tbzx7fy.fsf@kst-u.example.com> |
| In reply to | #75499 |
"Morten W. Petersen" <morphex@gmail.com> writes:
> On 09.11.2015 20:27, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> On 09.11.2015 20:07, Keith Thompson wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> [...]
>>>> Suppose I'm working on a C compiler that doesn't yet support lower case
>>>> letters. Should you write "Hello, world" as "HELLO, WORLD" just in case
>>>> you might need to use my compiler?
>>>
>>> I think that's a really bad comparison.
>>
>> How so?
>>
>> Both Malcolm's example of nested structs (which, as it turns out,
>> *are* supported by SDCC) and my example of uppercase letters are
>> features that are required by all versions of the C standard.
>> You can either assume that all features required by the standard
>> are implemented, or not.
>
> Well, the English alphabet has 26 characters. Writing something in
> uppercase, when lowercase can be expected, is something like shouting,
> and talking normal and shouting are to completely different things.
My example wasn't meant to suggest shouting. C has always supported
both upper and lower case letters, but some older programming languages
and systems have supported only upper case.
Don't read too much into the specific feature I chose. The point is
simply that a C compiler that hasn't yet been fully implemented might
omit some standard features, but that's not a good reason to avoid those
features when writing normal C code (*unless* you have a specific
requirement to use that particular compiler). As I wrote in my previous
followup, `long int` is probably a more plausible example.
> So what, you have to pass a pointer back or not have things nested
> in a pretty way, what's the big deal?
I think you're talking about nested structures. Structures as
members of structures are fully supported in all versions of the C
standard. Do you suggest avoiding nested structures? If so, why?
(Note that SDCC in particular *does* support nested structures.
It even supports anonymous structures that were introduced in C11.)
How do you decide which standard features to avoid because some
compiler somewhere *might* not support them? I suggest that using
the full C89/C90 standard, while avoiding any features that were
removed or made obselescent in C90 or in any later standard, can
give you C code that's *portable enough* for almost all purposes.
If you think it's necessary to use a smaller subset than that,
can you explain what features you would avoid and why?
> I found your comparison overly dramatic and inaccurate.
Overly dramatic? Sure. Inaccurate? I don't see how; please
enlighten me.
--
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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 21:12 +0100 |
| Message-ID | <n1qun9$qlk$2@speranza.aioe.org> |
| In reply to | #75505 |
On 09.11.2015 21:07, Keith Thompson wrote: [...] >> I found your comparison overly dramatic and inaccurate. > > Overly dramatic? Sure. Inaccurate? I don't see how; please > enlighten me. If you focused on understanding what I said, you would understand. I don't have anything else to add to this part of the thread. -Morten
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-09 23:13 +0000 |
| Message-ID | <n1r9b9$iqe$1@speranza.aioe.org> |
| In reply to | #75505 |
Keith Thompson <kst-u@mib.org> wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: (snip) >> Well, the English alphabet has 26 characters. Writing something in >> uppercase, when lowercase can be expected, is something like shouting, >> and talking normal and shouting are to completely different things. > My example wasn't meant to suggest shouting. C has always supported > both upper and lower case letters, but some older programming languages > and systems have supported only upper case. Most systems before IBM S/360 used 6 bit characters, so not enough for lower case. It would be interesting to have a C compiler for the IBM 7090, so we could test C with sign-magnitude integers. And even with 8 bits, lower case was rarely used for S/360 other than for word processing. The IBM train printers are much faster whan not using a train with lower case. All the OS/360 compilers that I know of completely ignore lower case. That is, all will be invalid characters outside of quoted strings. It is an interesting question of how much C code will fail if all the non-quoted characters are converted to a single case. > Don't read too much into the specific feature I chose. The point is > simply that a C compiler that hasn't yet been fully implemented might > omit some standard features, but that's not a good reason to avoid those > features when writing normal C code (*unless* you have a specific > requirement to use that particular compiler). As I wrote in my previous > followup, `long int` is probably a more plausible example. As above, you don't have to stop using upper and lower case, but it is a good idea to write programs that don't depend on case sensitivity. >> So what, you have to pass a pointer back or not have things nested >> in a pretty way, what's the big deal? > I think you're talking about nested structures. Structures as > members of structures are fully supported in all versions of the C > standard. Do you suggest avoiding nested structures? If so, why? > (Note that SDCC in particular *does* support nested structures. > It even supports anonymous structures that were introduced in C11.) > How do you decide which standard features to avoid because some > compiler somewhere *might* not support them? I suggest that using > the full C89/C90 standard, while avoiding any features that were > removed or made obselescent in C90 or in any later standard, can > give you C code that's *portable enough* for almost all purposes. > If you think it's necessary to use a smaller subset than that, > can you explain what features you would avoid and why? In my early programming days, and maybe still, I would sometimes use a feature just because I could. I do remember once using ++ on a double, and having it fail on one compiler. Not a compilation error, but the generated code was wrong. Seems that it wasn't tested enough. >> I found your comparison overly dramatic and inaccurate. > Overly dramatic? Sure. Inaccurate? I don't see how; please > enlighten me. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-09 19:02 -0500 |
| Message-ID | <56413406.4030308@verizon.net> |
| In reply to | #75529 |
On 11/09/2015 06:13 PM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: ... >> How do you decide which standard features to avoid because some >> compiler somewhere *might* not support them? I suggest that using >> the full C89/C90 standard, while avoiding any features that were >> removed or made obselescent in C90 or in any later standard, can >> give you C code that's *portable enough* for almost all purposes. >> If you think it's necessary to use a smaller subset than that, >> can you explain what features you would avoid and why? > > In my early programming days, and maybe still, I would sometimes > use a feature just because I could. I do remember once using ++ > on a double, and having it fail on one compiler. Not a compilation > error, but the generated code was wrong. Seems that it wasn't > tested enough. 35 years ago I had needed to calculate num % den, where num was too big to fit in an int, but small enough that it could fit in a long. I remember getting very weird results that were not at all what I needed, and concluding that the implementation of % for long integers was defective on that system. I tried using num - den *(num/den) instead, and got the same results, so the broken implementation of % was at least consistent with the implementation of integer division. I'm not sure how I worked around the problem - I may have used fmod(). I would not recommend avoiding use of % on long integers, just because of one such implementation (except, of course, when writing code that must be used on that implementation).
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 17:52 +0000 |
| Message-ID | <56422e98.11229531@news.xs4all.nl> |
| In reply to | #75529 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Keith Thompson <kst-u@mib.org> wrote:
> > Don't read too much into the specific feature I chose. The point is
> > simply that a C compiler that hasn't yet been fully implemented might
> > omit some standard features, but that's not a good reason to avoid those
> > features when writing normal C code (*unless* you have a specific
> > requirement to use that particular compiler). As I wrote in my previous
> > followup, `long int` is probably a more plausible example.
>
> As above, you don't have to stop using upper and lower case, but it
> is a good idea to write programs that don't depend on case
> sensitivity.
In C, it is _impossible_ to do so. The identifiers Foo and foo are
different, and strcmp("foo", "Foo") must never be zero. And this is
regardless of what your teletype can print.
Richard
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-10 21:34 +0000 |
| Message-ID | <n1tnt7$qrp$1@speranza.aioe.org> |
| In reply to | #75640 |
Richard Bos <raltbos@xs4all.nl> wrote:
(snip, I wrote)
>> As above, you don't have to stop using upper and lower case, but it
>> is a good idea to write programs that don't depend on case
>> sensitivity.
>
> In C, it is _impossible_ to do so. The identifiers Foo and foo are
> different, and strcmp("foo", "Foo") must never be zero. And this is
> regardless of what your teletype can print.
But you don't need to use foo and Foo as variable names in the same
program. It is likely more confusing, and so harder to read, if you do.
Though in some C programs that I translate from Fortran, I would
#define N (*n)
to avoid having to put the (*n) throughout, for subroutine arguments,
since Fortran doesn't use call by value.
(But only for arguments where the value changed.)
And also, for languages where identifiers are not case sensitive
one should avoid the confusion to the reader of using different case.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-17 22:28 +0000 |
| Message-ID | <564ba918.26552375@news.xs4all.nl> |
| In reply to | #75681 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Richard Bos <raltbos@xs4all.nl> wrote:
>
> (snip, I wrote)
>
> >> As above, you don't have to stop using upper and lower case, but it
> >> is a good idea to write programs that don't depend on case
> >> sensitivity.
> >
> > In C, it is _impossible_ to do so. The identifiers Foo and foo are
> > different, and strcmp("foo", "Foo") must never be zero. And this is
> > regardless of what your teletype can print.
>
> But you don't need to use foo and Foo as variable names in the same
> program. It is likely more confusing, and so harder to read, if you do.
True for object identifiers - though I like to use Foo as a typedef and
foo as the name of an object of type Foo.
Not true for strings. You don't know what your user will enter, and you
have to make a conscious decision whether the records "foo" and "Foo"
are the same or not.
Richard
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-18 00:51 +0000 |
| Message-ID | <n2gi2n$75l$1@speranza.aioe.org> |
| In reply to | #76307 |
Richard Bos <raltbos@xs4all.nl> wrote:
(snip, I wrote)
>> But you don't need to use foo and Foo as variable names in the same
>> program. It is likely more confusing, and so harder to read, if you do.
> True for object identifiers - though I like to use Foo as a typedef and
> foo as the name of an object of type Foo.
I don't use typedef so often. I forget if you can have the same name
for the typedef and the object. I am more sure you can have the same
name for a struct and the object.
struct s {int x} s;
In Java you can have a class name the same as an instance variable
and method. The compiler doesn't get confused, readers might.
-- glen
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web