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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-17 22:26 -0500 |
| Message-ID | <n2hrhb$1kr$1@dont-email.me> |
| In reply to | #76338 |
On 11/17/2015 07:51 PM, glen herrmannsfeldt wrote: > 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. ... Only if they are indifferent scopes. If both names have the same scope, it's a constraint violation (6.7p3), because typedef names and object names are both from the "ordinary identifiers" name space (6.2.3p1). Name spaces should not be confused with C++ namespaces, which are a different concept entirely. > ... I am more sure you can have the same > name for a struct and the object. Yes, because struct tags are in the tag name space, while object names are in the ordinary identifiers name space, so there's no conflict. The reason for that distinction is simple: in C, you can never use a struct tag without also using the 'struct' keyword. This is a key difference between C and C++: since C++ allows use of a tag with no keyword, tags and object names can conflict with each other. As a result, while the C++ standard does in fact mention the concept of a "name space" in three different locations, it's much less important in C++; the standard doesn't even bother to define the term. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-18 11:06 +0100 |
| Message-ID | <n2hik1$tn6$1@solani.org> |
| In reply to | #76307 |
On 17.11.2015 23:28, Richard Bos wrote:
> 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.
And if you want them to be the same, how about fooß, fooss, foosz and
FOOSS, FOOSZ, FOOẞ?
Philipp
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 15:37 -0800 |
| Message-ID | <5929c2a2-9890-478c-b345-3b1b3d79de72@googlegroups.com> |
| In reply to | #75505 |
On Monday, November 9, 2015 at 8:07:53 PM UTC, Keith Thompson 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? > You restrict yourself to the "conservative core" of C89. Practically every C89 program uses lower case. So whilst you might well come across a compiler that only has upper-case output, you've just got to accept that, in that case, it will be necessary to transform the program. On the other hand, octal constants are little used, and best avoided.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-10 12:54 +1300 |
| Message-ID | <dacq15FebevU8@mid.individual.net> |
| In reply to | #75532 |
Malcolm McLean wrote: > On Monday, November 9, 2015 at 8:07:53 PM UTC, Keith Thompson 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? >> > You restrict yourself to the "conservative core" of C89. Where is that defined? > Practically every C89 program uses lower case. So whilst you might > well come across a compiler that only has upper-case output, > you've just got to accept that, in that case, it will be necessary > to transform the program. > On the other hand, octal constants are little used, and best avoided. On potability grounds? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 16:14 -0800 |
| Message-ID | <lna8qmww0h.fsf@kst-u.example.com> |
| In reply to | #75532 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, November 9, 2015 at 8:07:53 PM UTC, Keith Thompson 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?
>>
> You restrict yourself to the "conservative core" of C89.
That tells me nothing. What do you exclude from that "conservative
core"?
> Practically every C89 program uses lower case. So whilst you might
> well come across a compiler that only has upper-case output,
> you've just got to accept that, in that case, it will be necessary
> to transform the program.
> On the other hand, octal constants are little used, and best avoided.
Are you suggesting that avoiding octal constants improves
portability? If so, I'll just cut to the chase and say that
you're wrong. If you don't *like* octal constants that's fine
(I presume you don't object to 0), but I asked about features to
avoid because some compilers might not support them.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 16:37 -0800 |
| Message-ID | <c3bc8164-36f2-4e4e-ae7d-ea49911b203d@googlegroups.com> |
| In reply to | #75538 |
On Monday, November 9, 2015 at 6:14:44 PM UTC-6, Keith Thompson wrote: > Are you suggesting that avoiding octal constants improves > portability? If so, I'll just cut to the chase and say that > you're wrong. If you don't *like* octal constants that's fine > (I presume you don't object to 0), but I asked about features to > avoid because some compilers might not support them. Some compilers will issue warnings if any constant consists of a zero followed by one or more additional digits, since such things are more likely to have been written by people who don't realize that decimal constants can't have leading zeroes, than by people who want to write an octal constant. Personally, I think an alternative notation should be defined for octal constants so that the leading-zero form could be deprecated. It may be awhile before constants with leading zeroes could safely be treated as decimal, but I see no reason not to start the process.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 16:56 -0800 |
| Message-ID | <ln611awu1y.fsf@kst-u.example.com> |
| In reply to | #75540 |
supercat@casperkitty.com writes:
> On Monday, November 9, 2015 at 6:14:44 PM UTC-6, Keith Thompson wrote:
>> Are you suggesting that avoiding octal constants improves
>> portability? If so, I'll just cut to the chase and say that
>> you're wrong. If you don't *like* octal constants that's fine
>> (I presume you don't object to 0), but I asked about features to
>> avoid because some compilers might not support them.
>
> Some compilers will issue warnings if any constant consists of a zero
> followed by one or more additional digits, since such things are more
> likely to have been written by people who don't realize that decimal
> constants can't have leading zeroes, than by people who want to write
> an octal constant.
Compilers can warn about anything they like, but do you have an example
of a compiler that warns about octal constants?
> Personally, I think an alternative notation should be defined for
> octal constants so that the leading-zero form could be deprecated. It
> may be awhile before constants with leading zeroes could safely be
> treated as decimal, but I see no reason not to start the process.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 17:25 -0800 |
| Message-ID | <551b8153-e85e-4ab3-80e9-189dc03c4375@googlegroups.com> |
| In reply to | #75541 |
On Monday, November 9, 2015 at 6:57:07 PM UTC-6, Keith Thompson wrote: > > Some compilers will issue warnings if any constant consists of a zero > > followed by one or more additional digits, since such things are more > > likely to have been written by people who don't realize that decimal > > constants can't have leading zeroes, than by people who want to write > > an octal constant. > > Compilers can warn about anything they like, but do you have an example > of a compiler that warns about octal constants? I recall having used one with an option to warn about such things, though I don't remember which one it was. I agree that there's nothing necessarily non-portable about a compiler generating warnings, though the usefulness of warnings may be inversely proportional to the number of them a program produces.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-10 10:37 +0100 |
| Message-ID | <n1sdon$r96$1@dont-email.me> |
| In reply to | #75541 |
On 10/11/15 01:56, Keith Thompson wrote: > supercat@casperkitty.com writes: >> On Monday, November 9, 2015 at 6:14:44 PM UTC-6, Keith Thompson wrote: >>> Are you suggesting that avoiding octal constants improves >>> portability? If so, I'll just cut to the chase and say that >>> you're wrong. If you don't *like* octal constants that's fine >>> (I presume you don't object to 0), but I asked about features to >>> avoid because some compilers might not support them. >> >> Some compilers will issue warnings if any constant consists of a zero >> followed by one or more additional digits, since such things are more >> likely to have been written by people who don't realize that decimal >> constants can't have leading zeroes, than by people who want to write >> an octal constant. > > Compilers can warn about anything they like, but do you have an example > of a compiler that warns about octal constants? Any embedded compiler which supports MISRA warnings will be able to warn on non-zero octal constants. (The warnings will be option, of course.) Non-zero octal constants are banned by many coding standards, including MISRA (C and C++), PRQA High Integrity C++, and the JSF C++ standard. So any tools that check for these (MISRA checking is common on embedded compilers) will warn here. > >> Personally, I think an alternative notation should be defined for >> octal constants so that the leading-zero form could be deprecated. It >> may be awhile before constants with leading zeroes could safely be >> treated as decimal, but I see no reason not to start the process. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 18:06 -0800 |
| Message-ID | <b8ead28b-711c-4c4e-9e57-64c7bd89b199@googlegroups.com> |
| In reply to | #75538 |
On Tuesday, November 10, 2015 at 12:14:44 AM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You restrict yourself to the "conservative core" of C89. > > That tells me nothing. What do you exclude from that "conservative > core"? > It's a fuzzy set. If something is rarely used, not in the spirit of C, and likely to cause problems for a future implementer, then it's not in the "conservative core". setjmp and longjmp are clearly outside the conservative core, for example.few people use them, they work in totally different way to most C functions, they're something that a future implementer might well decide causes too many problems. "short" on the other hand, is a very marginal member of the set. It's not used much, but it's not exactly unusual. It fits in with the rest of the type system. It might go if someone decides that short has to be 16 bit and his processor doesn't support 16 bit accesses. It's not ridiculous to exclude it from the conservative core, but you are being very conservative indeed. int, structures, pointers, array / pointer equivalence, for, while, if, and passing of parameters to functions are all full members of the conservative core. char, break, continue, goto, switch, do while and return are nearly as core - you can write recognisable C programs without them (I'm not talking about a Turing equivalent unusable language that happens to be a subset of C, but something that would be accepted by most people as "C"). Then you've got floating point, long, short, most of the standard library, and a few quirks like function pointers, ? :, comma operators in for loop expressions, sizeof, and so on. That's usually where you would draw the line. That's the conservative core, roughly speaking. > > Are you suggesting that avoiding octal constants improves > portability? If so, I'll just cut to the chase and say that > you're wrong. If you don't *like* octal constants that's fine > (I presume you don't object to 0), but I asked about features to > avoid because some compilers might not support them. > We've got to consider the future. Octal might break 20 years down the line. I'm still compiling and running code I wrote 20 years ago. I've just had a complaint about the very first piece of code I wrote professionally. It produces an image which is too "soft" according to our graphics guru.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-09 18:51 -0800 |
| Message-ID | <ln1tbywoqq.fsf@kst-u.example.com> |
| In reply to | #75549 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, November 10, 2015 at 12:14:44 AM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > You restrict yourself to the "conservative core" of C89.
>>
>> That tells me nothing. What do you exclude from that "conservative
>> core"?
>>
> It's a fuzzy set. If something is rarely used, not in the spirit of C,
> and likely to cause problems for a future implementer, then it's
> not in the "conservative core".
> setjmp and longjmp are clearly outside the conservative core, for
> example.few people use them, they work in totally different way
> to most C functions, they're something that a future implementer
> might well decide causes too many problems.
What exactly is the point of this "conservative core"?
If you think that some future version of the C standard will drop
support for setjmp() and longjmp(), that's just ridiculous. Too much
code depends on it.
[List of things that are *in* the "conservative core" snipped; that's
not what I asked about, and I'm not going construct a list of all C89
features and subtrace your list from it to figure out what you'd
exclude.]
>> Are you suggesting that avoiding octal constants improves
>> portability? If so, I'll just cut to the chase and say that
>> you're wrong. If you don't *like* octal constants that's fine
>> (I presume you don't object to 0), but I asked about features to
>> avoid because some compilers might not support them.
>>
> We've got to consider the future. Octal might break 20 years down
> the line. I'm still compiling and running code I wrote 20 years
> ago. I've just had a complaint about the very first piece of code
> I wrote professionally. It produces an image which is too "soft"
> according to our graphics guru.
No, octal will not break 20 years from now. Sheesh!
And even if it did, a translator that replaces all octal constants by
their hexadecimal equivalents (or by the new octal constant syntax
if there is one) would be easy enough to implement. Or you could
just use an old C11 compiler, or a newer compiler with an option
to re-enable octal constants.
So you want to avoid setjmp(), longjmp(), and octal constants because
they might vanish from some future C standard or be omitted by some
C compiler that you might need to use some day. Anything else?
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-10 08:40 -0800 |
| Message-ID | <6d10ec2f-ba64-4ab5-ad23-0f0f58e9a6e0@googlegroups.com> |
| In reply to | #75549 |
On Monday, November 9, 2015 at 8:06:17 PM UTC-6, Malcolm McLean wrote: > It's a fuzzy set. If something is rarely used, not in the spirit of C, > and likely to cause problems for a future implementer, then it's > not in the "conservative core". I'd argue that the fuzzy set is what allowed C to thrive in the 1990s; code which could compile in Borland and Microsoft C on the PC, MPW C and Think C on the Macintosh, and some of the more popular C compilers on the Amiga, was considered portable, and any platform which couldn't handle code which could "naturally" handle those was considered "weird". I see no reason why modern platforms shouldn't be able to handle code which could run on those platforms with no changes beyond some typedefs, but for some reason it has become fashionable to regard constructs that would have worked on any non- weird compiler in the 1990s as "non-portable".
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 17:55 +0000 |
| Message-ID | <56422f5c.11425515@news.xs4all.nl> |
| In reply to | #75549 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Tuesday, November 10, 2015 at 12:14:44 AM UTC, Keith Thompson wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > > You restrict yourself to the "conservative core" of C89. > > > > That tells me nothing. What do you exclude from that "conservative > > core"? > > > It's a fuzzy set. Fuzzy, _and_ conservative. Sounds like Sarah Palin. Predictably, is useless. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 17:50 +0000 |
| Message-ID | <56422d49.10894328@news.xs4all.nl> |
| In reply to | #75499 |
"Morten W. Petersen" <morphex@gmail.com> wrote: > 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. That's 26. > Writing something in uppercase, when lowercase can be expected, That's 52. There have historically been computers (and not the least ones) which only used upper case. C does not support them (BASIC originally did). C also does not support computers which can't nest structs. Deal with it, or choose another language. Richard
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-12 14:32 +0100 |
| Message-ID | <n224dc$rhi$1@speranza.aioe.org> |
| In reply to | #75639 |
On 10.11.2015 18:50, Richard Bos wrote: > "Morten W. Petersen" <morphex@gmail.com> wrote: [...] >> Writing something in uppercase, when lowercase can be expected, > > That's 52. > > There have historically been computers (and not the least ones) which > only used upper case. C does not support them (BASIC originally did). > C also does not support computers which can't nest structs. Deal with > it, or choose another language. Hm, what? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-09 10:35 +0000 |
| Message-ID | <slrnn40tml.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75412 |
On Mon, 2015-11-09, 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? At that point I gave up, in the other similar subthread I was involved in. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-08 23:57 +0100 |
| Message-ID | <n1ok0b$bn4$1@solani.org> |
| In reply to | #75380 |
On 08.11.2015 22:49, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > […]Do you know any compiler that accepts prototypes but > does not support passing and returning structures values? > SDCC is free compiler with a small number of developers, so to get a feature implemented, some developer (from our team or someone writing a patch) has to be willing to spend time on it. SDCC does not yet support returning struct (nor K&R-style functions). It does not yet support VLAs either (thus C11 support in SDCC is more complete than C99). Philipp
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 00:47 +0100 |
| Message-ID | <n1omt4$jjc$1@speranza.aioe.org> |
| In reply to | #75397 |
On 08.11.2015 23:57, Philipp Klaus Krause wrote: > On 08.11.2015 22:49, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> […]Do you know any compiler that accepts prototypes but >> does not support passing and returning structures values? >> > > SDCC is free compiler with a small number of developers, so to get a > feature implemented, some developer (from our team or someone writing a > patch) has to be willing to spend time on it. > > SDCC does not yet support returning struct (nor K&R-style functions). It > does not yet support VLAs either (thus C11 support in SDCC is more > complete than C99). I'd like to support this compiler as well, but I can't easily tell why I or someone else should choose this over for example GCC on the webpage. -Morten
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 13:01 +0100 |
| Message-ID | <n1q1qe$k4p$1@dont-email.me> |
| In reply to | #75403 |
On 09/11/15 00:47, Morten W. Petersen wrote: > On 08.11.2015 23:57, Philipp Klaus Krause wrote: >> On 08.11.2015 22:49, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> […]Do you know any compiler that accepts prototypes but >>> does not support passing and returning structures values? >>> >> >> SDCC is free compiler with a small number of developers, so to get a >> feature implemented, some developer (from our team or someone writing a >> patch) has to be willing to spend time on it. >> >> SDCC does not yet support returning struct (nor K&R-style functions). It >> does not yet support VLAs either (thus C11 support in SDCC is more >> complete than C99). > > I'd like to support this compiler as well, but I can't easily tell why I > or someone else should choose this over for example GCC on the webpage. > SDCC targets very small processors, almost all 8-bit devices in microcontrollers. It works for processors that are too small for gcc to support. There is no sane set of circumstances where people will want to compile your XML parser with SDCC.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-09 13:18 +0100 |
| Message-ID | <n1q2t0$jka$1@speranza.aioe.org> |
| In reply to | #75439 |
On 09.11.2015 13:01, David Brown wrote: > On 09/11/15 00:47, Morten W. Petersen wrote: >> On 08.11.2015 23:57, Philipp Klaus Krause wrote: >>> On 08.11.2015 22:49, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> […]Do you know any compiler that accepts prototypes but >>>> does not support passing and returning structures values? >>>> >>> >>> SDCC is free compiler with a small number of developers, so to get a >>> feature implemented, some developer (from our team or someone writing a >>> patch) has to be willing to spend time on it. >>> >>> SDCC does not yet support returning struct (nor K&R-style functions). It >>> does not yet support VLAs either (thus C11 support in SDCC is more >>> complete than C99). >> >> I'd like to support this compiler as well, but I can't easily tell why I >> or someone else should choose this over for example GCC on the webpage. >> > > SDCC targets very small processors, almost all 8-bit devices in > microcontrollers. It works for processors that are too small for gcc to > support. > > There is no sane set of circumstances where people will want to compile > your XML parser with SDCC. Maybe not. But I was thinking of creating a simple Morse app that can run on for example the Arduino Nano and blink a large attached LED, and it could read from an XML file. Now that example maybe belongs more in the art category, but it isn't unthinkable that someone wants to use an 8-bit processor and some large address space to do something. -Morten
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web