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 1 of 10 [1] 2 3 … 10 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-08 16:49 +0100 |
| Subject | Right C version for GCC |
| Message-ID | <n1nqt1$f3m$1@speranza.aioe.org> |
Hi there. :) OK, so I'm inching along on my XML parser Smash XML, and thought I'd give developing on CentOS a go. I quickly ran into problems there though, as gcc wouldn't accept the -std=c90 command line argument. I glanced at the man page and found that -ansi could be an option. But when using -ansi, the compiler doesn't recognize the nested struct elements.. the man page says that turning on -ansi shuts down some GCC extensions that conflict with C90, so GCC has some non-standard ways of defining structs then I assume. How can I handle this? Project code, today's version, is here: https://github.com/morphex/smash_xml/tree/1fade93c3f69f14ef90860f88f99170bfc37bfb7 -Morten
[toc] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-08 19:29 +0100 |
| Message-ID | <n1o49d$4h1$1@speranza.aioe.org> |
| In reply to | #75341 |
On 08.11.2015 16:49, Morten W. Petersen wrote: > Hi there. :) > > OK, so I'm inching along on my XML parser Smash XML, and thought > I'd give developing on CentOS a go. > > I quickly ran into problems there though, as gcc wouldn't accept > the -std=c90 command line argument. I glanced at the man page and > found that -ansi could be an option. > > But when using -ansi, the compiler doesn't recognize the nested > struct elements.. the man page says that turning on -ansi shuts > down some GCC extensions that conflict with C90, so GCC has some > non-standard ways of defining structs then I assume. > > How can I handle this? > > Project code, today's version, is here: > > https://github.com/morphex/smash_xml/tree/1fade93c3f69f14ef90860f88f99170bfc37bfb7 I'll answer this myself. It can be fixed adding the command-line option -fms-extensions. I like the way of nested named unions, as it saves a lot of typing in debugging mode and also is easier on the eyes.. But I'll make things C90 before releasing the first release candidate or around that point in time. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 11:46 -0800 |
| Message-ID | <dcaff3d0-3feb-4343-bf7f-f5f87696da81@googlegroups.com> |
| In reply to | #75341 |
On Sunday, November 8, 2015 at 3:49:02 PM UTC, Morten W. Petersen wrote: > Hi there. :) > > OK, so I'm inching along on my XML parser Smash XML, and thought > I'd give developing on CentOS a go. > > I quickly ran into problems there though, as gcc wouldn't accept > the -std=c90 command line argument. I glanced at the man page and > found that -ansi could be an option. > > But when using -ansi, the compiler doesn't recognize the nested > struct elements.. the man page says that turning on -ansi shuts > down some GCC extensions that conflict with C90, so GCC has some > non-standard ways of defining structs then I assume. > > How can I handle this? > If you want to write portable code, I strongly recommend that you stick to a conservative subset of C89. No passing or returning of structures by value, no nested structure definitions, no non-basic types as members except for structures declared in your own program, especially wide character types (you can probably get away with size_t, but I'd also cut it out).
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-08 20:03 +0000 |
| Message-ID | <slrnn3vala.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75355 |
On Sun, 2015-11-08, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 3:49:02 PM UTC, Morten W. Petersen wrote: >> Hi there. :) >> >> OK, so I'm inching along on my XML parser Smash XML, and thought >> I'd give developing on CentOS a go. >> >> I quickly ran into problems there though, as gcc wouldn't accept >> the -std=c90 command line argument. I glanced at the man page and >> found that -ansi could be an option. >> >> But when using -ansi, the compiler doesn't recognize the nested >> struct elements.. the man page says that turning on -ansi shuts >> down some GCC extensions that conflict with C90, so GCC has some >> non-standard ways of defining structs then I assume. >> >> How can I handle this? >> > If you want to write portable code, I strongly recommend that you stick > to a conservative subset of C89. No passing or returning of structures > by value, Huh? What compiler would that make the code portable to? > no nested structure definitions, no non-basic types as > members except for structures declared in your own program, > especially wide character types (you can probably get away with > size_t, but I'd also cut it out). And in general, which compilers (that matter) don't implement C89? I know people here are conservative on average, and some don't like C99. But I don't think I've seen anyone claim a 27 years old standard is too new before. Or are you just pulling his leg? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 12:18 -0800 |
| Message-ID | <ce3c34e3-4104-49c2-83c9-79f47b71f8ce@googlegroups.com> |
| In reply to | #75358 |
On Sunday, November 8, 2015 at 8:04:05 PM UTC, Jorgen Grahn wrote: > On Sun, 2015-11-08, Malcolm McLean wrote: > > > If you want to write portable code, I strongly recommend that you stick > > to a conservative subset of C89. No passing or returning of structures > > by value, > > Huh? What compiler would that make the code portable to? > > > no nested structure definitions, no non-basic types as > > members except for structures declared in your own program, > > especially wide character types (you can probably get away with > > size_t, but I'd also cut it out). > > And in general, which compilers (that matter) don't implement C89? > > I know people here are conservative on average, and some don't like > C99. But I don't think I've seen anyone claim a 27 years old standard > is too new before. Or are you just pulling his leg? > Every time a new standard comes out, the set of C programs which work everywhere becomes narrower. However there's a core to the C language which is unlikely to change, and likely to be supported in any future revision. It's likely that you'll always have an "int", a "double" and a "char *". So that gives string data, real data, and indices into internal arrays, and that's really all you need for most programs. Build everything on top of that, using your own UTF-8 routines written in C89 if handling strings non-transparently, and you've got the best chance that everything will still be working many years down the line.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-11-08 21:14 +0100 |
| Message-ID | <n1oadv$lbh$1@speranza.aioe.org> |
| In reply to | #75355 |
On 08.11.2015 20:46, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 3:49:02 PM UTC, Morten W. Petersen wrote: >> Hi there. :) >> >> OK, so I'm inching along on my XML parser Smash XML, and thought >> I'd give developing on CentOS a go. >> >> I quickly ran into problems there though, as gcc wouldn't accept >> the -std=c90 command line argument. I glanced at the man page and >> found that -ansi could be an option. >> >> But when using -ansi, the compiler doesn't recognize the nested >> struct elements.. the man page says that turning on -ansi shuts >> down some GCC extensions that conflict with C90, so GCC has some >> non-standard ways of defining structs then I assume. >> >> How can I handle this? >> > If you want to write portable code, I strongly recommend that you stick > to a conservative subset of C89. No passing or returning of structures > by value, no nested structure definitions, no non-basic types as > members except for structures declared in your own program, > especially wide character types (you can probably get away with > size_t, but I'd also cut it out). Yep. But this article says size_t is better: http://www.embedded.com/electronics-blogs/programming-pointers/4026076/Why-size-t-matters Could you elaborate on why I should not use size_t? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 12:25 -0800 |
| Message-ID | <8b385e5f-c3de-46f7-87db-fc5d82eff491@googlegroups.com> |
| In reply to | #75361 |
On Sunday, November 8, 2015 at 8:14:10 PM UTC, Morten W. Petersen wrote: > On 08.11.2015 20:46, Malcolm McLean wrote: > > On Sunday, November 8, 2015 at 3:49:02 PM UTC, Morten W. Petersen wrote: > >> Hi there. :) > >> > >> OK, so I'm inching along on my XML parser Smash XML, and thought > >> I'd give developing on CentOS a go. > >> > >> I quickly ran into problems there though, as gcc wouldn't accept > >> the -std=c90 command line argument. I glanced at the man page and > >> found that -ansi could be an option. > >> > >> But when using -ansi, the compiler doesn't recognize the nested > >> struct elements.. the man page says that turning on -ansi shuts > >> down some GCC extensions that conflict with C90, so GCC has some > >> non-standard ways of defining structs then I assume. > >> > >> How can I handle this? > >> > > If you want to write portable code, I strongly recommend that you stick > > to a conservative subset of C89. No passing or returning of structures > > by value, no nested structure definitions, no non-basic types as > > members except for structures declared in your own program, > > especially wide character types (you can probably get away with > > size_t, but I'd also cut it out). > > Yep. But this article says size_t is better: > > http://www.embedded.com/electronics-blogs/programming-pointers/4026076/Why-size-t-matters > > Could you elaborate on why I should not use size_t? > From the article: In my experience, most C and C++ programmers are aware that the standard libraries use size_t, but they really don't know what size_t represents or why the libraries use size_t as they do. Moreover, they don't know if and when they should use size_t themselves. In this column, I'll explain what size_t is, why it exists, and how you should use it in your code. That explains it all. No one is going to use a language where the default basic integer type is called size_t, especially when it usually holds an index rather than a size. Then it's unsigned, which creates nasty problems when doing index calculations. because C defines behaviour on overflow as wrap-around, it's also impossible to build a conforming compiler that treats overflow safely, leading to potential exploits like feeding an image file with dimensions cooked to overflow to the value an attacker wants. Personally I want size_t deprecated. It should go. Eventually everyone else will come round to my way of thinking, but not until size_t has done an enormous amount of damage. it's not future-proof, though you'll have backwards compatibility for many many years, and you can probably get away with it as far as portability is concerned.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-08 13:06 -0800 |
| Message-ID | <68aa11fd-f737-4584-a888-fba3c933239c@googlegroups.com> |
| In reply to | #75364 |
On Sunday, November 8, 2015 at 2:25:58 PM UTC-6, Malcolm McLean wrote: > Personally I want size_t deprecated. It should go. Eventually everyone > else will come round to my way of thinking, but not until size_t has > done an enormous amount of damage. > it's not future-proof, though you'll have backwards compatibility for > many many years, and you can probably get away with it as far as > portability is concerned. Two things C lacks which have been needed for along time are: 1. A set of types, in all sizes, to represent unsigned *quantities*. 2. A set of types, in all sizes, to represent wrapping abstract algebriac rings of integers congruent mod 2^N. Instead of having either of the above, C has a partial family of "small" unsigned types which mostly have the former behavior, but with hints of the second, and a family of "large" unsigned types which mostly have the latter behavior, but with hints of the former. An operator like "sizeof" needs to yield a type large enough to hold it, which may or may not need to be larger than "int". Since the value that sizeof represents is a quantity, it should yield the first kind of unsigned value. Unfortunately, since it's generally larger than "int", it typically in practice implements the second. Short of adding a new operator to replace "sizeof", I don't see any way to fix the problems that result from size_t representing a quantity but behaving as an abstract algebraic ring member, since some code exists which relies upon such behavior. On the other hand, defining separate "unumN_t" and "uwrapN_t" types and then adding a new operator which is like sizeof but yields a unumN_t would solve a lot of problems.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-11-08 14:52 -0800 |
| Message-ID | <MPG.30a972206126b31292@news.eternal-september.org> |
| In reply to | #75373 |
supercat@casperkitty.com wrote: > > Malcolm McLean wrote: > > Personally I want size_t deprecated. It should go. Eventually everyone > > else will come round to my way of thinking, but not until size_t has > > done an enormous amount of damage. > > it's not future-proof, though you'll have backwards compatibility for > > many many years, and you can probably get away with it as far as > > portability is concerned. > > Two things C lacks which have been needed for along time are: > > 1. A set of types, in all sizes, to represent unsigned *quantities*. > > 2. A set of types, in all sizes, to represent wrapping abstract algebriac > rings of integers congruent mod 2^N. > > Instead of having either of the above, C has a partial family of "small" > unsigned types which mostly have the former behavior, but with hints of > the second, and a family of "large" unsigned types which mostly have the > latter behavior, but with hints of the former. > > An operator like "sizeof" needs to yield a type large enough to hold it, > which may or may not need to be larger than "int". Since the value that > sizeof represents is a quantity, it should yield the first kind of unsigned > value. Unfortunately, since it's generally larger than "int", it typically > in practice implements the second. > > Short of adding a new operator to replace "sizeof", I don't see any way to > fix the problems that result from size_t representing a quantity but > behaving as an abstract algebraic ring member, since some code exists which > relies upon such behavior. On the other hand, defining separate "unumN_t" > and "uwrapN_t" types and then adding a new operator which is like sizeof but > yields a unumN_t would solve a lot of problems. In Ada, the type of the result of the equivalent of the sizeof operator is "Universal Integer", which has no inherent signedness or size, and is converted as needed according to the context it is used in. I believe this could be made to work for sizeof, without needing a new operator, while retaining backward compatibility for correct programs. Obviously there are a lot of details that would need to be worked out. I doubt there is any motivation on the part of the committee, though, as they probably don't perceive the same problems that we do with the status quo. (Note that I am *not* saying that the type of the sizeof expression be dependent on the context. There is no place in C where that occurs (unless something has changed recently that I've overlooked), and I would never suggest changing that.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-08 15:12 -0800 |
| Message-ID | <4241d2be-dac9-4373-b292-a8fafb35ece5@googlegroups.com> |
| In reply to | #75396 |
On Sunday, November 8, 2015 at 4:53:08 PM UTC-6, Philip Lantz wrote: > I believe this could be made to work for sizeof, without needing a new > operator, while retaining backward compatibility for correct programs. > Obviously there are a lot of details that would need to be worked out. Presently, it would be legal for code to test whether the size of type1 is at least as large as type2, but does not exceed it by more than 60 bytes, using sizeof (type1) - sizeof (type2) <= 60 While such code might reasonably be considered "weird" that would change the fact that the code is guaranteed by the language spec to behave as described and is thus "correct". I know of no way to make sizeof behave more "normally" without changing the meaning of the above code.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 09:38 +0100 |
| Message-ID | <n1pltk$arg$1@dont-email.me> |
| In reply to | #75398 |
On 09/11/15 00:12, supercat@casperkitty.com wrote: > On Sunday, November 8, 2015 at 4:53:08 PM UTC-6, Philip Lantz wrote: >> I believe this could be made to work for sizeof, without needing a new >> operator, while retaining backward compatibility for correct programs. >> Obviously there are a lot of details that would need to be worked out. > > Presently, it would be legal for code to test whether the size of type1 > is at least as large as type2, but does not exceed it by more than 60 > bytes, using > > sizeof (type1) - sizeof (type2) <= 60 > Code like that should all be done with compile-time checks or comparisons (and if done with "run-time" code, it will be optimised to compile-time) - you can freely add as many comparisons and checks as you want in order to make your code clear and safe, at zero cost. > While such code might reasonably be considered "weird" that would change > the fact that the code is guaranteed by the language spec to behave as > described and is thus "correct". I know of no way to make sizeof behave > more "normally" without changing the meaning of the above code. >
[toc] | [prev] | [next] | [standalone]
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2015-11-09 19:04 +0000 |
| Message-ID | <n1qqn1$r1s$2@dont-email.me> |
| In reply to | #75398 |
On Sun, 08 Nov 2015 15:12:21 -0800, supercat wrote: > On Sunday, November 8, 2015 at 4:53:08 PM UTC-6, Philip Lantz wrote: >> I believe this could be made to work for sizeof, without needing a new >> operator, while retaining backward compatibility for correct programs. >> Obviously there are a lot of details that would need to be worked out. > > Presently, it would be legal for code to test whether the size of type1 > is at least as large as type2, but does not exceed it by more than 60 > bytes, using > > sizeof (type1) - sizeof (type2) <= 60 > > While such code might reasonably be considered "weird" that would change > the fact that the code is guaranteed by the language spec to behave as > described and is thus "correct". I know of no way to make sizeof behave > more "normally" without changing the meaning of the above code. Is not actually correct to say that this behaviour is guaranteed by the language spec. While not common in the wild, it is permitted for size_t to be a type smaller than int, which promotes to int in arithmetic. If that happens, the arithmetic above is done on signed types, and unsigned wraparound will not occur as intended. Thus, in this situation the comparison will be true even if sizeof (type1) is less than sizeof (type2).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-09 11:27 -0800 |
| Message-ID | <55fc01f9-8722-4726-a591-0b6883bf60cf@googlegroups.com> |
| In reply to | #75488 |
On Monday, November 9, 2015 at 1:06:28 PM UTC-6, Nick Bowler wrote: > While not common in the wild, it is permitted for size_t to be a type > smaller than int, which promotes to int in arithmetic. If that happens, > the arithmetic above is done on signed types, and unsigned wraparound > will not occur as intended. Thus, in this situation the comparison will > be true even if sizeof (type1) is less than sizeof (type2). Yeah, I knew that and even mentioned it, but failed to make my example take account of it. I think my point holds, though, which is that the behavior of arithmetic involving size_t is specified in ways which would make it impossible to apply semantics that would more typically be sensible without breaking existing code which is legal and correct.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-09 00:00 +0000 |
| Message-ID | <n1onig$th1$1@dont-email.me> |
| In reply to | #75396 |
On 08/11/2015 22:52, Philip Lantz wrote: > supercat@casperkitty.com wrote: >> Short of adding a new operator to replace "sizeof", I don't see any way to >> fix the problems that result from size_t representing a quantity but >> behaving as an abstract algebraic ring member, since some code exists which >> relies upon such behavior. On the other hand, defining separate "unumN_t" >> and "uwrapN_t" types and then adding a new operator which is like sizeof but >> yields a unumN_t would solve a lot of problems. > > In Ada, the type of the result of the equivalent of the sizeof operator > is "Universal Integer", which has no inherent signedness or size, and is > converted as needed according to the context it is used in. > > I believe this could be made to work for sizeof, without needing a new > operator, while retaining backward compatibility for correct programs. > Obviously there are a lot of details that would need to be worked out. sizeof could just generate a corresponding literal value, which would normally have int type, but I believe the type adjusts itself to the magnitude. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-08 16:35 -0800 |
| Message-ID | <lny4e8yppf.fsf@kst-u.example.com> |
| In reply to | #75364 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, November 8, 2015 at 8:14:10 PM UTC, Morten W. Petersen wrote:
[...]
>> Yep. But this article says size_t is better:
>>
>> http://www.embedded.com/electronics-blogs/programming-pointers/4026076/Why-size-t-matters
>>
>> Could you elaborate on why I should not use size_t?
>>
> From the article:
>
> In my experience, most C and C++ programmers are aware that the
> standard libraries use size_t, but they really don't know what size_t
> represents or why the libraries use size_t as they do. Moreover, they
> don't know if and when they should use size_t themselves.
>
> In this column, I'll explain what size_t is, why it exists, and how
> you should use it in your code.
>
> That explains it all. No one is going to use a language where the default
> basic integer type is called size_t, especially when it usually holds
> an index rather than a size.
size_t is not "the default basic integer type". Modern C has no
default integer type, though in older versions of C int was in a
sense the default, and some of that still shows through.
But even if your characterization is accurate, your statement is
manifestly false. Lots of people, including most or all participants
in this newsgroup, do in fact use such a language.
Morten, Malcolm's opinion is that size_t is a bad thing, and that
the language would be much better without it. He is, to the best
of my recollection, literally the only person who has expressed
that opinion. Of course that doesn't mean he's wrong, but you
should be aware that his is a minority view.
size_t is an unsigned integer type that can represent the size of any
object, measured in bytes [*]. Because it can represent the number
of bytes in any object, and array elements are at least one byte,
it can also represent the number of elements in any array object,
and can therefore be safely used as an array index.
Malcolm also seems to object to the name "size_t", for reasons I
frankly don't understand (something about the "_t" suffix, I think).
Most of us have no problem with size_t, and use it where it's
appropriate.
[...]
--
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-08 12:37 -0800 |
| Message-ID | <79f89f2e-e39f-484c-bd6b-df3571ff0118@googlegroups.com> |
| In reply to | #75355 |
On Sunday, November 8, 2015 at 1:46:44 PM UTC-6, Malcolm McLean wrote: > If you want to write portable code, I strongly recommend that you stick > to a conservative subset of C89. No passing or returning of structures > by value, no nested structure definitions, no non-basic types as > members except for structures declared in your own program, > especially wide character types (you can probably get away with > size_t, but I'd also cut it out). What type would you use to hold the result of "sizeof" if not "size_t"? Or differences between pointers if not "ptrdiff_t"? The existence of values of those types is unaffected by whether a program uses those identifiers.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 12:58 -0800 |
| Message-ID | <c430cf36-6b24-4990-a131-0aab821258b1@googlegroups.com> |
| In reply to | #75367 |
On Sunday, November 8, 2015 at 8:37:48 PM UTC, supe...@casperkitty.com wrote: > On Sunday, November 8, 2015 at 1:46:44 PM UTC-6, Malcolm McLean wrote: > > If you want to write portable code, I strongly recommend that you stick > > to a conservative subset of C89. No passing or returning of structures > > by value, no nested structure definitions, no non-basic types as > > members except for structures declared in your own program, > > especially wide character types (you can probably get away with > > size_t, but I'd also cut it out). > > What type would you use to hold the result of "sizeof" if not "size_t"? > Or differences between pointers if not "ptrdiff_t"? The existence of > values of those types is unaffected by whether a program uses those > identifiers. > You need a type which can index an arbitrary array. That's such a basic requirement that the logical name for that type is "integer" or some derivative. The same type can also hold the size of any object in memory. What about the difference between two pointers to the same addressable segment of memory? There's an annoying problem here, which is that differences can be negative. But intermediate results in index calculations are also often negative. So integers need to be signed, and you lose a bit. Annoying, but very seldom a practical problem. Certainly it doesn't justify the way size_t sweeps through the C language like a virus, transforming everything it touches into an unsigned type like itself.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-08 13:19 -0800 |
| Message-ID | <a8531a49-8d94-4bf5-bbb0-0b46a7c4f80e@googlegroups.com> |
| In reply to | #75370 |
On Sunday, November 8, 2015 at 2:58:33 PM UTC-6, Malcolm McLean wrote: > Certainly it doesn't justify the way size_t > sweeps through the C language like a virus, transforming everything > it touches into an unsigned type like itself. Unsigned values are often used to represent members of an abstract algebraic ring. Such a construct may be viewed like a utility meter that reads the last few digits of one's total utility usage. If the gas meter read 9957 last month and this month it reads 0009, one's energy usage will be +52 units, not -9948. Similarly if "unsigned" is 16 bits, subtracting 0xFFFA from 0x0012 will yield 0x0018. Mathematically, additions, subtractions, and multiplications involving a mod-based algebraic ring and an integer should yield a member of the same algebraic ring. When unsigned types are used to represent algebraic rings, it is thus appropriate that operations between signed types and unsigned types of the same size should yield the unsigned type; indeed, operations between an unsigned type and a signed type of *any* size should yield the unsigned type (e.g. if a meter read 0123 when first installed, and the total energy used since then is 570011 units, the meter will simply read 0134, not 570134), though C ignores the rules of ring types in those cases. The problem in C is that while algebraic ring types are useful in many cases (and are the reason the unsigned types which behave like rings don't overflow) the rules which are appropriate for them are not appropriate for types which represent cardinal numbers. C would be much more useful (and could allow much better optimizations) if it could distinguish between ring types and cardinal-number types.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-08 21:49 +0000 |
| Message-ID | <877flsrwkh.fsf@bsb.me.uk> |
| In reply to | #75355 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > If you want to write portable code, I strongly recommend that you stick > to a conservative subset of C89. No passing or returning of structures > by value, Seriously? I used a pre-ANSI compiler in 1978 that did not yet support structure passing, but it would throw out almost all of Morten's code for other reasons. Do you know any compiler that accepts prototypes but does not support passing and returning structures values? > 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. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 14:14 -0800 |
| Message-ID | <b0105612-45c6-408e-8db5-709a827aba77@googlegroups.com> |
| In reply to | #75380 |
On Sunday, November 8, 2015 at 9:49:25 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > <snip> > > If you want to write portable code, I strongly recommend that you stick > > to a conservative subset of C89. No passing or returning of structures > > by value, > > Seriously? I used a pre-ANSI compiler in 1978 that did not yet support > structure passing, but it would throw out almost all of Morten's code > for other reasons. Do you know any compiler that accepts prototypes but > does not support passing and returning structures values? > > > 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. With every new standard the set of programs which compile today and still compile becomes narrower. But we can't predict the future. Who would have guessed that Microsoft would deprecate the standard library, for example? But we can make some guesses about what is the "core" C language which is unlikely to break, or at least break trivially (C++ needs a cast from malloc(), but you can slot that in mechanically, it doesn't break code badly).
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web