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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 14:01 +0100 |
| Message-ID | <n1q5ag$va$1@dont-email.me> |
| In reply to | #75440 |
On 09/11/15 13:18, Morten W. Petersen wrote: > 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. > The Arduino uses an AVR (newer Arduino boards use ARM Cortex). Although the AVR is 8-bit, it is fully supported by gcc - the Arduino project uses C++ with gcc rather than C. So no problem there. > 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. > Trust me, it is unthinkable. It is a /long/ time since 8-bit processors were used with anything "large address space". The only 8-bit processor for which you would even consider using large address space (meaning more than 64K flash and 4K ram) is the AVR - and that uses gcc.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-09 00:55 +0000 |
| Message-ID | <87k2psq9e1.fsf@bsb.me.uk> |
| In reply to | #75397 |
Philipp Klaus Krause <pkk@spth.de> writes: > 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). OK. I'm tempted to claim that it's not really a C compiler then since it was only in K&R1 that struct passing was not permitted (though even there it was marked as forthcoming). I.e. there's no "official" version of C with those properties (no struct passing and no K&R functions). But that would be churlish. It's an C compiler with a restriction. I applaud your work, but curse you for being a counter example to my point! I thought a language feature from the 70s would have made it into every compiler by now, but maybe there is no demand for this is small devices. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-09 10:42 +0000 |
| Message-ID | <slrnn40u5e.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75409 |
On Mon, 2015-11-09, Ben Bacarisse wrote: > Philipp Klaus Krause <pkk@spth.de> writes: > >> 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). > > OK. I'm tempted to claim that it's not really a C compiler then since > it was only in K&R1 that struct passing was not permitted (though even > there it was marked as forthcoming). I.e. there's no "official" version > of C with those properties (no struct passing and no K&R functions). > > But that would be churlish. It's an C compiler with a restriction. I > applaud your work, but curse you for being a counter example to my > point! I thought a language feature from the 70s would have made it > into every compiler by now, but maybe there is no demand for this is > small devices. Perhaps it's my C++ background, but I regularly store small things in structs to get the type safety, and expect a compiler to handle them as well as 'sizeof' would indicate. So the feature is useful on small devices, too. There's always the argument "this device is so rare and its use so specialized, that we can't motivate developing a full-fledged C compiler for it" though. I cannot tell if that is the case here. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2015-11-09 03:03 -0800 |
| Message-ID | <3de13faf-f113-4805-be3c-fb8f3b39a6aa@googlegroups.com> |
| In reply to | #75430 |
How can you get type safety by storing small things in a struct?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 03:27 -0800 |
| Message-ID | <da730764-0991-4d1f-8485-143bd5f9b606@googlegroups.com> |
| In reply to | #75433 |
On Monday, November 9, 2015 at 11:03:26 AM UTC, Chad wrote:
> How can you get type safety by storing small things in a struct?
>
typedef struct
{
int x; // integer scaled on 0 - 1023 == 0 to 1
} SCALEDINTEGER1;
typedef struct
{
int x; // integer scaled on 0 - 1023 = 0 to 1 - 1/1024
} SCALEDINTEGER2
We've got both swilling about in our hackky and badly designed system.
But at least the compiler will tell us if we try to use one when we mean the
other.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-09 12:28 +0000 |
| Message-ID | <n1q3co$pjh$1@dont-email.me> |
| In reply to | #75435 |
On 09/11/2015 11:27, Malcolm McLean wrote:
> On Monday, November 9, 2015 at 11:03:26 AM UTC, Chad wrote:
>> How can you get type safety by storing small things in a struct?
>>
> typedef struct
> {
> int x; // integer scaled on 0 - 1023 == 0 to 1
> } SCALEDINTEGER1;
>
> typedef struct
> {
> int x; // integer scaled on 0 - 1023 = 0 to 1 - 1/1024
> } SCALEDINTEGER2
>
> We've got both swilling about in our hackky and badly designed system.
> But at least the compiler will tell us if we try to use one when we mean the
> other.
Sometimes. Other times, you will need to extract x in order to do
anything with it, and that's still just an ordinary int. But it means a
lot of extra clutter too.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-10 09:07 +0000 |
| Message-ID | <slrnn43cub.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75441 |
On Mon, 2015-11-09, BartC wrote:
> On 09/11/2015 11:27, Malcolm McLean wrote:
>> On Monday, November 9, 2015 at 11:03:26 AM UTC, Chad wrote:
>>> How can you get type safety by storing small things in a struct?
>>>
>> typedef struct
>> {
>> int x; // integer scaled on 0 - 1023 == 0 to 1
>> } SCALEDINTEGER1;
>>
>> typedef struct
>> {
>> int x; // integer scaled on 0 - 1023 = 0 to 1 - 1/1024
>> } SCALEDINTEGER2
>>
>> We've got both swilling about in our hackky and badly designed system.
>> But at least the compiler will tell us if we try to use one when we mean the
>> other.
Good example -- thanks.
> Sometimes. Other times, you will need to extract x in order to do
> anything with it, and that's still just an ordinary int. But it means a
> lot of extra clutter too.
It's certainly less useful in C than in C++ due to the lack of
function and operator overloading. But I find that you often
overestimate the clutter -- there's a good chance you only need to
access 'scaled.x' in a few places in the program, and the rest of the
time you mostly store or pass around these structs.
But yes, there is clutter.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-09 07:37 -0500 |
| Message-ID | <n1q3u1$ril$1@dont-email.me> |
| In reply to | #75433 |
On 11/09/2015 06:03 AM, Chad wrote: > How can you get type safety by storing small things in a struct? Many different types of data can be stored in an 'int', and C allows those ints to be interchanged freely, which is often a mistake (passing the number of televisions in a house to a function that is looking for the number of lines in a file, for instance). A struct containing a single int, however, is only compatible with the same struct type, or with equivalent struct types declared in other translation units using the same tag, and containing a single object of int type with the same name. This increases the safety of the type, by restricting the places where it can be used. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-09 16:57 +0100 |
| Message-ID | <n1qfq5$ulj$1@solani.org> |
| In reply to | #75430 |
On 09.11.2015 11:42, Jorgen Grahn wrote: > > There's always the argument "this device is so rare and its use so > specialized, that we can't motivate developing a full-fledged C > compiler for it" though. I cannot tell if that is the case here. > > /Jorgen > I can see the point in diverging from the standard by default in some cases - e.g. renentrency on architectures where there is no efficient way to use variables on the stack. But it seems, unfortunately compilers for embedded targets also often do not follow the standard even theough they easily could, and IMO should. A typical example would be Dynamic C. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 12:39 +0100 |
| Message-ID | <n1q0hq$eh3$2@dont-email.me> |
| In reply to | #75380 |
On 08/11/15 22:49, 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. > > <snip> > I know of a at least two embedded C compilers that did not support nested structures, or mixes of array and struct, or passing or returning structs. But those were brain-dead compilers for brain-dead microcontrollers, and while they were marketed as "C compilers", they were certainly not compliant with any standard. And it is /highly/ unlikely that anyone will ever want to compile an XML parser with them.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-09 13:18 -0500 |
| Message-ID | <5640E35B.1050205@verizon.net> |
| In reply to | #75437 |
On 11/09/2015 06:39 AM, David Brown wrote:
...
> I know of a at least two embedded C compilers that did not support
> nested structures, or mixes of array and struct, or passing or returning
> structs.
Could you give an example of what you mean by "mixes of array and
struct"? My best guesses as to what you might mean are:
struct array_holder { char array[8]; };
struct tm tm_array[8];
> ... But those were brain-dead compilers for brain-dead
> microcontrollers, and while they were marketed as "C compilers", they
> were certainly not compliant with any standard. ...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-10 10:49 +0100 |
| Message-ID | <n1sefi$tje$1@dont-email.me> |
| In reply to | #75477 |
On 09/11/15 19:18, James Kuyper wrote:
> On 11/09/2015 06:39 AM, David Brown wrote:
> ...
>> I know of a at least two embedded C compilers that did not support
>> nested structures, or mixes of array and struct, or passing or returning
>> structs.
>
> Could you give an example of what you mean by "mixes of array and
> struct"? My best guesses as to what you might mean are:
>
> struct array_holder { char array[8]; };
> struct tm tm_array[8];
>
Yes, that is exactly what I mean.
As a "big system" programmer, you would probably be shocked by what
passes for "C compiler", and also C code, in some areas of embedded
development. These days ARM Cortex M devices are dominating and we can
use gcc, clang, or proprietary compilers for these solid 32-bit cores.
And of the few remaining popular 8-bit and 16-bit devices, both the AVR
and msp430 are well supported by gcc. But there are still many 8-bit
cores such as the 8051 and the PIC around, which are hopeless for
"normal" C. Going back further with a wider variety of 8-bit devices,
you had programs full of extensions to put data into different
discontinuous memory banks, "bit" variables, functions that need to be
specially annotated and modified to be re-entrant, etc. Compilers might
have 8-bit "int". The chip might have 512 bytes of ram, but no
structure can be bigger than 127 bytes. Pointers to const data might
not be compatible with pointers to non-const data, because const data
gets placed in flash and accessed with a different instruction from ram
data. The chip might not have any ram at all. The return stack can be
in hardware, limited to 3 entries. Great fun!
>> ... But those were brain-dead compilers for brain-dead
>> microcontrollers, and while they were marketed as "C compilers", they
>> were certainly not compliant with any standard. ...
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-11-10 19:33 -0600 |
| Message-ID | <n1u5ip$oso$2@dont-email.me> |
| In reply to | #75560 |
David Brown wrote:
> On 09/11/15 19:18, James Kuyper wrote:
>> On 11/09/2015 06:39 AM, David Brown wrote:
>> ...
>>> I know of a at least two embedded C compilers that did not support
>>> nested structures, or mixes of array and struct, or passing or returning
>>> structs.
>>
>> Could you give an example of what you mean by "mixes of array and
>> struct"? My best guesses as to what you might mean are:
>>
>> struct array_holder { char array[8]; };
>> struct tm tm_array[8];
>>
>
> Yes, that is exactly what I mean.
>
> As a "big system" programmer, you would probably be shocked by what
> passes for "C compiler", and also C code, in some areas of embedded
> development. These days ARM Cortex M devices are dominating and we can
> use gcc, clang, or proprietary compilers for these solid 32-bit cores.
> And of the few remaining popular 8-bit and 16-bit devices, both the AVR
> and msp430 are well supported by gcc. But there are still many 8-bit
> cores such as the 8051 and the PIC around, which are hopeless for
> "normal" C.
And that is fine. The process for development on those more or less
precludes porting anyhow.
> Going back further with a wider variety of 8-bit devices,
> you had programs full of extensions to put data into different
> discontinuous memory banks, "bit" variables, functions that need to be
> specially annotated and modified to be re-entrant, etc. Compilers might
> have 8-bit "int". The chip might have 512 bytes of ram, but no
> structure can be bigger than 127 bytes. Pointers to const data might
> not be compatible with pointers to non-const data, because const data
> gets placed in flash and accessed with a different instruction from ram
> data. The chip might not have any ram at all. The return stack can be
> in hardware, limited to 3 entries. Great fun!
>
>
>
>>> ... But those were brain-dead compilers for brain-dead
>>> microcontrollers, and while they were marketed as "C compilers", they
>>> were certainly not compliant with any standard. ...
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-11 13:34 +0100 |
| Message-ID | <n1vcge$7hn$1@dont-email.me> |
| In reply to | #75710 |
On 11/11/15 02:33, Les Cargill wrote:
> David Brown wrote:
>> On 09/11/15 19:18, James Kuyper wrote:
>>> On 11/09/2015 06:39 AM, David Brown wrote:
>>> ...
>>>> I know of a at least two embedded C compilers that did not support
>>>> nested structures, or mixes of array and struct, or passing or
>>>> returning
>>>> structs.
>>>
>>> Could you give an example of what you mean by "mixes of array and
>>> struct"? My best guesses as to what you might mean are:
>>>
>>> struct array_holder { char array[8]; };
>>> struct tm tm_array[8];
>>>
>>
>> Yes, that is exactly what I mean.
>>
>> As a "big system" programmer, you would probably be shocked by what
>> passes for "C compiler", and also C code, in some areas of embedded
>> development. These days ARM Cortex M devices are dominating and we can
>> use gcc, clang, or proprietary compilers for these solid 32-bit cores.
>> And of the few remaining popular 8-bit and 16-bit devices, both the AVR
>> and msp430 are well supported by gcc. But there are still many 8-bit
>> cores such as the 8051 and the PIC around, which are hopeless for
>> "normal" C.
>
>
> And that is fine. The process for development on those more or less
> precludes porting anyhow.
>
Yes indeed - as long as you understand what you are doing, it's fine.
The pain is when some half-educated programmer has learned his C on
Windows (often not learning C, but C++, C#, Java, or something else
C-like) and then tries to write code for an 8051 using double-precision
floating point...
>> Going back further with a wider variety of 8-bit devices,
>> you had programs full of extensions to put data into different
>> discontinuous memory banks, "bit" variables, functions that need to be
>> specially annotated and modified to be re-entrant, etc. Compilers might
>> have 8-bit "int". The chip might have 512 bytes of ram, but no
>> structure can be bigger than 127 bytes. Pointers to const data might
>> not be compatible with pointers to non-const data, because const data
>> gets placed in flash and accessed with a different instruction from ram
>> data. The chip might not have any ram at all. The return stack can be
>> in hardware, limited to 3 entries. Great fun!
>>
>>
>>
>>>> ... But those were brain-dead compilers for brain-dead
>>>> microcontrollers, and while they were marketed as "C compilers", they
>>>> were certainly not compliant with any standard. ...
>>
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-11 06:53 -0800 |
| Message-ID | <5e3c5e93-9e15-40b4-9dde-3064b4e47d61@googlegroups.com> |
| In reply to | #75732 |
On Wednesday, November 11, 2015 at 6:34:49 AM UTC-6, David Brown wrote: > Yes indeed - as long as you understand what you are doing, it's fine. > The pain is when some half-educated programmer has learned his C on > Windows (often not learning C, but C++, C#, Java, or something else > C-like) and then tries to write code for an 8051 using double-precision > floating point... I took over a fixed-point DSP project where everything was written in assembly language except the frequency-detection code which was written in C using floating-point. I ended up rewriting pretty much everything in C, except for I/O, which I did in interrupt-driven machine code, and about 10-lines of math in assembly language (using hardware multiply-accumulate).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-08 17:00 -0800 |
| Message-ID | <lntwowyojo.fsf@kst-u.example.com> |
| In reply to | #75355 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> 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).
C has permitted structure assignment, argument passing, and
returning as values from functions since the 1989 ANSI standard,
and several years before. K&R1, published in 1978, mentions it
as a feature that would be implemented soon. I challenge you to
find a C compiler in current use that does not support it.
If by "nested structure definitions" you mean using a structure as
a member of another structure, I have never heard of a C compiler
that did not fully support that. A C reference manual from 1975
includes structs and mentions no such restriction. If not, what
exactly do you mean by "nested structure definitions"? C11 supports
anonymous structures, but those are easily avoided.
If you want maximially portable C code, I suggest using C89 while
avoiding any features that are either obsolescent or incompatible
with later standards. Using C99 will only slightly reduce your
code's portability. Microsoft's c compiler is the one that's the
most notorious for its failure to support C99, but it does support
*some* C99 features.
There are some C (or C-like) compilers, particularly for embedded
systems, that don't fully support any C standard. You can't really
write portable C code to target such compilers, since the features
that are missing are going to vary from one compiler to another.
I suggest not worrying about that until and unless you actually
need to use such a compiler.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-09 13:37 +0100 |
| Message-ID | <n1q3uf$rka$1@dont-email.me> |
| In reply to | #75410 |
On 09/11/15 02:00, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >> 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). > > C has permitted structure assignment, argument passing, and > returning as values from functions since the 1989 ANSI standard, > and several years before. K&R1, published in 1978, mentions it > as a feature that would be implemented soon. I challenge you to > find a C compiler in current use that does not support it. > > If by "nested structure definitions" you mean using a structure as > a member of another structure, I have never heard of a C compiler > that did not fully support that. A C reference manual from 1975 > includes structs and mentions no such restriction. If not, what > exactly do you mean by "nested structure definitions"? C11 supports > anonymous structures, but those are easily avoided. > > If you want maximially portable C code, I suggest using C89 while > avoiding any features that are either obsolescent or incompatible > with later standards. Using C99 will only slightly reduce your > code's portability. Microsoft's c compiler is the one that's the > most notorious for its failure to support C99, but it does support > *some* C99 features. An alternative path here is to target the common subset of C99 and C++. Many people use MS's compiler in C++ mode to compile their C code, as it lets them use most of C99. > > There are some C (or C-like) compilers, particularly for embedded > systems, that don't fully support any C standard. You can't really > write portable C code to target such compilers, since the features > that are missing are going to vary from one compiler to another. > I suggest not worrying about that until and unless you actually > need to use such a compiler. >
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2015-11-09 13:53 +0100 |
| Message-ID | <n1q4vo$oa4$1@solani.org> |
| In reply to | #75410 |
On 09.11.2015 02:00, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >> 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). > > C has permitted structure assignment, argument passing, and > returning as values from functions since the 1989 ANSI standard, > and several years before. K&R1, published in 1978, mentions it > as a feature that would be implemented soon. I challenge you to > find a C compiler in current use that does not support it. > SDCC is in current use, and is a C compiler. > > There are some C (or C-like) compilers, particularly for embedded > systems, that don't fully support any C standard. You can't really > write portable C code to target such compilers, since the features > that are missing are going to vary from one compiler to another. > I suggest not worrying about that until and unless you actually > need to use such a compiler. > While SDCC targets embedded systems, it also aims for standard-compliance. Its support for the standard is not complete yet. In particular, structure assignment, passing and returning are still missing. This is one current C90 compliance issue in SDCC. The other two are missing support for K&R-style functions, and missing support for double (when encountering double, SDCC will emit a warning, and use a float instead). Philipp P.S.: http://sdcc.sourceforge.net/mediawiki/index.php/Standard_compliance
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-09 21:54 +0000 |
| Message-ID | <n1r4iv$3j0$1@dont-email.me> |
| In reply to | #75355 |
On 08/11/2015 19:46, Malcolm McLean wrote: > On Sunday, November 8, 2015 at 3:49:02 PM UTC, Morten W. Petersen wrote: >> 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, SDCC was mentioned later in the thread. From the latter's docs: "The preferred method of installation is to compile SDCC from source using GNU gcc and make." Which of course means using the usual array of Unix-specific tools. The sources of SDCC may or may not be portable C, but if you are expected to use gcc under Unix then that fact is irrelevant. The point is not many other projects are that bothered about portability if they recommend such a narrow tool set. (And that quote continues: "For Windows some pre-compiled binary distributions are available for your convenience." which is a hint that that any other method may not be as straightforward!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-09 15:45 -0800 |
| Message-ID | <d98173b9-804c-457c-87ec-9294f0490229@googlegroups.com> |
| In reply to | #75521 |
On Monday, November 9, 2015 at 9:54:55 PM UTC, Bart wrote: > On 08/11/2015 19:46, Malcolm McLean wrote: > > > If you want to write portable code, > > SDCC was mentioned later in the thread. From the latter's docs: > > "The preferred method of installation is to compile SDCC from source > using GNU gcc and make." > > Which of course means using the usual array of Unix-specific tools. > > The sources of SDCC may or may not be portable C, but if you are > expected to use gcc under Unix then that fact is irrelevant. > The embedded community traditionally uses Linux to host cross-compilers and other tools - usually a huge number even for a a little project. SDCC will only work under a unix-like system that supports gcc, but the code it compiles will be for a target, probably a smallish 8 or 16 bit processor. Since it is not fully feature complete, if you want to take a function or a C source file of related functions, and compile, those functions need to be written in a conservative subset of C.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web