Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #102431 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-01-25 14:30 +0000 |
| Last post | 2017-02-04 10:13 -0800 |
| Articles | 20 on this page of 206 — 18 participants |
Back to article view | Back to comp.lang.c
Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-25 14:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-27 15:18 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 11:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-01 21:35 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 21:02 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 00:35 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 09:00 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:41 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 00:11 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 00:56 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 20:49 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 00:43 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-01 17:36 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 17:50 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 18:09 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 10:30 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 12:13 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 13:53 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 13:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 14:42 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 15:25 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:19 -0800
Re: Preprocessor Overheads Noob <root@127.0.0.1> - 2017-02-02 22:59 +0100
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 06:02 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 14:29 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:00 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 08:54 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:03 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:15 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 19:29 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 08:32 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 20:44 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 13:06 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 21:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:17 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 00:16 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 01:09 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 01:04 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:34 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 14:54 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 15:31 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 19:32 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 20:28 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 12:44 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 21:33 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:19 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 22:46 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 17:47 -0600
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:26 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:08 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 18:09 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-04 17:01 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 18:20 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 20:40 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:08 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 21:10 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:21 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 11:51 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 09:26 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:02 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 22:39 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 00:21 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:10 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 01:55 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 00:57 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 14:08 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 09:32 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 12:22 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 04:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:04 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:42 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 08:10 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-07 09:57 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-07 11:26 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:36 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-07 07:27 +1300
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 20:35 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:16 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 00:51 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:20 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 01:48 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 02:10 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 02:56 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 01:56 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 11:14 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:00 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:16 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 13:41 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 14:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 07:55 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 18:15 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:41 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 16:36 +0000
Re: Preprocessor Overheads bart4858@gmail.com - 2017-02-04 11:24 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 21:08 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 13:41 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 14:26 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 23:27 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 00:18 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 19:56 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 11:01 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:04 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 14:03 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 06:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 09:01 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 20:53 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:15 +1300
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:30 -0800
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:39 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 14:58 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:23 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 15:40 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:05 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:22 +1300
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 07:48 -0800
Re: Preprocessor Overheads Thiago Adams <thiago.adams@gmail.com> - 2017-02-09 09:15 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:05 +1300
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 00:08 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:20 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 04:08 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 02:40 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:27 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-09 18:04 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 18:07 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 21:55 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 23:07 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 01:02 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 22:07 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:25 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:26 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 12:36 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:09 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:41 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 08:29 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 17:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 09:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 18:31 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:55 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 03:02 -0800
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:55 +0000
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:11 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 17:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 18:00 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:27 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 21:35 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:53 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:06 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:22 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:49 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-06 14:12 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:13 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:22 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 15:27 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 15:10 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 14:55 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 16:57 +0100
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:17 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:20 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:29 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 21:03 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 22:33 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:29 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 04:19 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 15:18 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 21:17 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 13:39 -0800
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 23:38 +0000
Re: printing int64_t objects Noob <root@127.0.0.1> - 2017-02-02 23:40 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 20:20 +1300
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:52 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 14:03 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-02 14:13 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 12:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 21:45 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 15:35 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:23 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 12:23 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 14:16 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 22:47 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 16:38 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-04 00:47 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 18:34 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 11:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-04 13:18 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 21:27 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:04 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 12:46 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:12 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:21 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 16:13 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:03 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:41 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 16:15 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:13 -0800
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 15:25 +0000 |
| Message-ID | <o6vita$n59$1@dont-email.me> |
| In reply to | #102960 |
On 02/02/2017 13:42, David Brown wrote: > On 02/02/17 14:14, BartC wrote: >> Huh? I compiled gcc.c with gcc. If there's work to do to make this >> compile clean, it's not me that has to do it! >> > > Sorry, I misunderstood which file you were compiling. > > > Having a quick look at gcc 4.9 (which I happen to have on my system at > the moment), it is built with "-W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Wold-style-definition -Wc++-compat" > > "-W" is the old name for "-Wextra". > > I would not be surprised if there were the occasional warning message > printed while compiling, but 33,000 warnings from a 8711 line file > /would/ surprise me. The "gcc.c" I'm talking about is an amalgamation of multiple source files (not done by me), and is a 753Kloc file. I think it corresponds to the "cc1" part of gcc. The 33000 /lines/ of warnings probably amount to 8000 warnings and notes. That's why I suggested it was small in comparison. http://people.csail.mit.edu/smcc/projects/single-file-programs/gcc.c.bz2 -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 10:19 -0800 |
| Message-ID | <lna8a478wz.fsf@kst-u.example.com> |
| In reply to | #102957 |
BartC <bc@freeuk.com> writes:
> On 02/02/2017 09:30, David Brown wrote:
[...]
>> zero-length arrays are not valid in C, so don't try to make them. You
>> can't declare an array of one length (zero or anything else) and then
>> "set it up" later with a different size.
>
> Yes you can. First declare this:
>
> int array[] = {};
The empty initializer is invalid (it's actually a syntax error, see the
syntax in 6.7.9), and any conforming compiler must at least warn about
it. Some compilers may support it as an extension. You're free to
depend on that extension if you choose to do so, but you should be clear
(to yourself and to the rest of us) that you're doing something outside
standard C.
[...]
--
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 | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-02-02 22:59 +0100 |
| Message-ID | <o70a06$71t$1@dont-email.me> |
| In reply to | #102969 |
On 02/02/2017 19:19, Keith Thompson wrote: > The empty initializer is invalid (it's actually a syntax error, see the > syntax in 6.7.9), and any conforming compiler must at least warn about > it. Some compilers may support it as an extension. You're free to > depend on that extension if you choose to do so, but you should be clear > (to yourself and to the rest of us) that you're doing something outside > standard C. I find it amazing that you're still trying to teach him C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-03 06:02 -0800 |
| Message-ID | <kfn7f57bcec.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102957 |
BartC <bc@freeuk.com> writes:
> On 02/02/2017 09:30, David Brown wrote:
>> On 02/02/17 01:43, BartC wrote:
>>
>>> Is it any wonder that I usually suppress warnings so that I
>>> don't see them? Anyway, there will be a few less now.
>>
>> [...]
>
> Out of the 900 lines of warnings [...] Most of them were pedantic
> quibbles, [...]
>
> The thing is, when people talk here about code compiling 'cleanly'
> with 'no warnings', that depends on what combinations of compile
> options /they/ prefer to use. I can't force them to use /my/
> combination of options which I find works.
>
> Or even to force them to use a particular compiler. Sometimes, I can
> do something to shut up one compiler, only to trigger a warning in
> another [...]
I wanted to follow up on this line. As you have seen different
people have different ideas about what warning options should be
used. IMO many people go overboard here, turning on every
warning under the sun. To me this seems counterproductive. For
what you are doing I think a good minimal base level is this set
(disclaimer: tested only with gcc 5.4.0):
gcc -std=c11 -pedantic -Wno-format -Werror
These options show which version of C is required, ensure that
there are no dependencies on non-standard extensions, and ignore
the annoying cases related to printf() etc. (The printf() ones
may be a problem in some systems but you think they aren't on
the ones you are targeting so they are suppressed.) Moreover
using -pedantic should make it easier if/when you add another
system to your set of targets.
Under these options, here are diffs for getting clex64.c to
compile without complaint. Notice, the number of changes
is small - six changes, only 29 lines affected.
404a405
> typedef void (*VOIDF)();
407c408
< void * addr;
---
> VOIDF addr;
676c677
< void * os_getdllprocaddr (int64,char *);
---
> VOIDF os_getdllprocaddr (int64,char *);
1774,1797c1775,1798
< void * os_getdllprocaddr (int64 hinst,char * name) {
< static rec table[23]={{"malloc",&malloc},
< {"realloc",&realloc},
< {"free",&free},
< {"printf",&printf},
< {"puts",&puts},
< {"fgetc",&fgetc},
< {"fputc",&fputc},
< {"getchar",&getchar},
< {"fopen",&fopen},
< {"fclose",&fclose},
< {"fseek",&fseek},
< {"ftell",&ftell},
< {"fread",&fread},
< {"fwrite",&fwrite},
< {"clock",&clock},
< {"isalpha",&isalpha},
< {"tolower",&tolower},
< {"feof",&feof},
< {"memset",&memset},
< {"memcpy",&memcpy},
< {"ungetc",&ungetc},
< {"remove",&remove},
< {"system",&system}
---
> VOIDF os_getdllprocaddr (int64 hinst,char * name) {
> static rec table[23]={{"malloc",(VOIDF)&malloc},
> {"realloc",(VOIDF)&realloc},
> {"free",(VOIDF)&free},
> {"printf",(VOIDF)&printf},
> {"puts",(VOIDF)&puts},
> {"fgetc",(VOIDF)&fgetc},
> {"fputc",(VOIDF)&fputc},
> {"getchar",(VOIDF)&getchar},
> {"fopen",(VOIDF)&fopen},
> {"fclose",(VOIDF)&fclose},
> {"fseek",(VOIDF)&fseek},
> {"ftell",(VOIDF)&ftell},
> {"fread",(VOIDF)&fread},
> {"fwrite",(VOIDF)&fwrite},
> {"clock",(VOIDF)&clock},
> {"isalpha",(VOIDF)&isalpha},
> {"tolower",(VOIDF)&tolower},
> {"feof",(VOIDF)&feof},
> {"memset",(VOIDF)&memset},
> {"memcpy",(VOIDF)&memcpy},
> {"ungetc",(VOIDF)&ungetc},
> {"remove",(VOIDF)&remove},
> {"system",(VOIDF)&system}
7958c7959
< static char * gcclinstdheaders[]={};
---
> static char * gcclinstdheaders[]={""};
8042c8043
< static char * customstdheaders[]={};
---
> static char * customstdheaders[]={""};
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 14:29 +0000 |
| Message-ID | <o7240o$b2i$1@dont-email.me> |
| In reply to | #103031 |
On 03/02/2017 14:02, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:
>> Or even to force them to use a particular compiler. Sometimes, I can
>> do something to shut up one compiler, only to trigger a warning in
>> another [...]
>
> I wanted to follow up on this line. As you have seen different
> people have different ideas about what warning options should be
> used. IMO many people go overboard here, turning on every
> warning under the sun. To me this seems counterproductive. For
> what you are doing I think a good minimal base level is this set
> (disclaimer: tested only with gcc 5.4.0):
>
> gcc -std=c11 -pedantic -Wno-format -Werror
>
OK, I've put that into my IDE. (And suggested those options in the build
instructions that go at the start of some of my distributed source code.
However, such code would normally be expected to be free of compilation
errors, so it should be a choice how people compile it.)
> Under these options, here are diffs for getting clex64.c to
> compile without complaint. Notice, the number of changes
> is small - six changes, only 29 lines affected.
>> VOIDF os_getdllprocaddr (int64,char *);
> 1774,1797c1775,1798
> < void * os_getdllprocaddr (int64 hinst,char * name) {
> < static rec table[23]={{"malloc",&malloc},
> < {"realloc",&realloc},
> < {"free",&free},
>> VOIDF os_getdllprocaddr (int64 hinst,char * name) {
>> static rec table[23]={{"malloc",(VOIDF)&malloc},
>> {"realloc",(VOIDF)&realloc},
>> {"free",(VOIDF)&free},
That's not too onerous. But since they appear to force an error it means
I have to fix it now!
(Actually I don't need this routine at the minute. For this project it
will be needed, in expanded form, if and when I try and execute the
input program, and then only for an OS-neutral version as this is.
OS-specific versions will use different methods such as dlopen/dlsym.)
> < static char * gcclinstdheaders[]={};
> ---
>> static char * gcclinstdheaders[]={""};
> 8042c8043
> < static char * customstdheaders[]={};
> ---
>> static char * customstdheaders[]={""};
This also has to change because an empty array is an error on most C
compilers (in gcc it had been a warning).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-04 10:00 -0800 |
| Message-ID | <kfnvasp96q3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103033 |
BartC <bc@freeuk.com> writes: > On 03/02/2017 14:02, Tim Rentsch wrote: >> BartC <bc@freeuk.com> writes: >> >>> Or even to force them to use a particular compiler. Sometimes, I can >>> do something to shut up one compiler, only to trigger a warning in >>> another [...] >> >> I wanted to follow up on this line. As you have seen different >> people have different ideas about what warning options should be >> used. IMO many people go overboard here, turning on every >> warning under the sun. To me this seems counterproductive. For >> what you are doing I think a good minimal base level is this set >> (disclaimer: tested only with gcc 5.4.0): >> >> gcc -std=c11 -pedantic -Wno-format -Werror > > OK, I've put that into my IDE. (And suggested those options in the > build instructions that go at the start of some of my distributed > source code. However, such code would normally be expected to be free > of compilation errors, so it should be a choice how people compile > it.) Right. The point of using (and documenting) a particular set of options is not to force other people to use them but to set expectations -- if they compile with the same set of options that you use and still see diagnostics, they know there is some fundamental problem with what they are doing rather than what set of options they may have chosen. They can still choose another set of options if they want to do so. Also, including -pedantic shows you are deliberately sticking to conforming C, which is greatly reassuring. Having spent no small amount of time looking at code that relies on any number of the myriad extensions that gcc provides, I can say confidently that your readers will thank you.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-03 08:54 -0800 |
| Message-ID | <lnzii343ly.fsf@kst-u.example.com> |
| In reply to | #103031 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> I wanted to follow up on this line. As you have seen different
> people have different ideas about what warning options should be
> used. IMO many people go overboard here, turning on every
> warning under the sun. To me this seems counterproductive. For
> what you are doing I think a good minimal base level is this set
> (disclaimer: tested only with gcc 5.4.0):
>
> gcc -std=c11 -pedantic -Wno-format -Werror
BartC seems to be using a particular version of gcc on Windows
that incorrectly complains about a "%lld" format.
"gcc --version" reports "gcc (tdm64-1) 5.1.0". tdm-gcc is
"A compiler suite for 32- and 64-bit Windows based on the GNU
toolchain". My unfounded speculation is that its maintainers
hacked the gcc sources to complain about "%lld" at a time
when the Microsoft C library didn't support it, and didn't
back out the change when later versions of the C library added
support. BartC, I suggest you submit a bug report via
<http://tdm-gcc.tdragon.net/bugs>.
Until it's fixed, I suggest using "-Wno-format* *only* for that
compiler, as a workaround for a bug that seems to occur only in
that implementation.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-04 10:03 -0800 |
| Message-ID | <kfnr33d96kc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103047 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> I wanted to follow up on this line. As you have seen different >> people have different ideas about what warning options should be >> used. IMO many people go overboard here, turning on every >> warning under the sun. To me this seems counterproductive. For >> what you are doing I think a good minimal base level is this set >> (disclaimer: tested only with gcc 5.4.0): >> >> gcc -std=c11 -pedantic -Wno-format -Werror > > BartC seems to be using a particular version of gcc on Windows > that incorrectly complains about a "%lld" format. > > "gcc --version" reports "gcc (tdm64-1) 5.1.0". tdm-gcc is > "A compiler suite for 32- and 64-bit Windows based on the GNU > toolchain". My unfounded speculation is that its maintainers > hacked the gcc sources to complain about "%lld" at a time > when the Microsoft C library didn't support it, and didn't > back out the change when later versions of the C library added > support. BartC, I suggest you submit a bug report via > <http://tdm-gcc.tdragon.net/bugs>. > > Until it's fixed, I suggest using "-Wno-format* *only* for that > compiler, as a workaround for a bug that seems to occur only in > that implementation. My goal was to offer a suggestion that Bart would find useful for what he wants to do. It does no good to offer a more elaborate suggestion, even if it is one I would make in different circumstances, if the result is that my suggestion is rejected entirely.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 10:15 -0800 |
| Message-ID | <lnefzg792t.fsf@kst-u.example.com> |
| In reply to | #102952 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/02/17 01:43, BartC wrote:
[...]
>> (3) Printing 64-bit values.
>>
>> This one I don't understand:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>> ...
>> int64_t aa = 0;
>> printf("%lld\n", aa);
>>
>> gcc gives me: "warning: unknown conversion type character 'l' in
>> format".
>
> Either you are requesting a standard older than C99, or you are using a
> Windows gcc build that uses MSVC's C runtime library (with older C90
> printf) rather than a build that uses a more modern runtime library, and
> gcc is smart enough to know this. I suspect the former - gcc prior to
> version 5 (IIRC) used -std=gnu90 as the default if you had not specified
> a standard.
I just tried compiling some similar code with gcc 2.8.1, which was released in
1998.
long long n = 42;
printf("%lld\n", n);
By default, it doesn't complain about the "%lld" format. If I use
"-ansi -pedantic -Wformat", it warns:
c.c:3: warning: ANSI C does not support `long long'
c.c:4: warning: ANSI C does not support the `ll' length modifier
BartC: Exactly what version of gcc are you using that prints "warning:
unknown conversion type character 'l' in format"? What is the output of
"gcc --version"?
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 19:29 +0000 |
| Message-ID | <o70186$tl2$1@dont-email.me> |
| In reply to | #102968 |
On 02/02/2017 18:15, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 02/02/17 01:43, BartC wrote:
> [...]
>>> (3) Printing 64-bit values.
>>>
>>> This one I don't understand:
>>>
>>> #include <stdio.h>
>>> #include <stdint.h>
>>> ...
>>> int64_t aa = 0;
>>> printf("%lld\n", aa);
>>>
>>> gcc gives me: "warning: unknown conversion type character 'l' in
>>> format".
>>
>> Either you are requesting a standard older than C99, or you are using a
>> Windows gcc build that uses MSVC's C runtime library (with older C90
>> printf) rather than a build that uses a more modern runtime library, and
>> gcc is smart enough to know this. I suspect the former - gcc prior to
>> version 5 (IIRC) used -std=gnu90 as the default if you had not specified
>> a standard.
>
> I just tried compiling some similar code with gcc 2.8.1, which was released in
> 1998.
>
> long long n = 42;
> printf("%lld\n", n);
>
> By default, it doesn't complain about the "%lld" format. If I use
> "-ansi -pedantic -Wformat", it warns:
>
> c.c:3: warning: ANSI C does not support `long long'
> c.c:4: warning: ANSI C does not support the `ll' length modifier
>
> BartC: Exactly what version of gcc are you using that prints "warning:
> unknown conversion type character 'l' in format"? What is the output of
> "gcc --version"?
gcc (tdm64-1) 5.1.0
But the resulting program works with "%lld" so the library supports it.
I've always had misgivings about C's format specifiers, when they have
to be used to impart type information, and this shows some of the
problems that come up.
I'm writing a 20-40Kloc application, but the most pressing portability
issue is going to be being able to print a number to the console? That
is probably the next beginner program after Hello World!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-03 08:32 +1300 |
| Message-ID | <efhfqfFhgsiU4@mid.individual.net> |
| In reply to | #102974 |
On 02/ 3/17 08:29 AM, BartC wrote:
> On 02/02/2017 18:15, Keith Thompson wrote:
>>
>> I just tried compiling some similar code with gcc 2.8.1, which was released in
>> 1998.
>>
>> long long n = 42;
>> printf("%lld\n", n);
>>
>> By default, it doesn't complain about the "%lld" format. If I use
>> "-ansi -pedantic -Wformat", it warns:
>>
>> c.c:3: warning: ANSI C does not support `long long'
>> c.c:4: warning: ANSI C does not support the `ll' length modifier
>>
>> BartC: Exactly what version of gcc are you using that prints "warning:
>> unknown conversion type character 'l' in format"? What is the output of
>> "gcc --version"?
>
> gcc (tdm64-1) 5.1.0
>
> But the resulting program works with "%lld" so the library supports it.
>
> I've always had misgivings about C's format specifiers, when they have
> to be used to impart type information, and this shows some of the
> problems that come up.
If you want C++, you know where to find it...
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 20:44 +0000 |
| Message-ID | <o705ji$j97$1@dont-email.me> |
| In reply to | #102975 |
On 02/02/2017 19:32, Ian Collins wrote:
> On 02/ 3/17 08:29 AM, BartC wrote:
>> On 02/02/2017 18:15, Keith Thompson wrote:
>>>
>>> I just tried compiling some similar code with gcc 2.8.1, which was
>>> released in
>>> 1998.
>>>
>>> long long n = 42;
>>> printf("%lld\n", n);
>>>
>>> By default, it doesn't complain about the "%lld" format. If I use
>>> "-ansi -pedantic -Wformat", it warns:
>>>
>>> c.c:3: warning: ANSI C does not support `long long'
>>> c.c:4: warning: ANSI C does not support the `ll' length modifier
>>>
>>> BartC: Exactly what version of gcc are you using that prints "warning:
>>> unknown conversion type character 'l' in format"? What is the output of
>>> "gcc --version"?
>>
>> gcc (tdm64-1) 5.1.0
>>
>> But the resulting program works with "%lld" so the library supports it.
>>
>> I've always had misgivings about C's format specifiers, when they have
>> to be used to impart type information, and this shows some of the
>> problems that come up.
>
> If you want C++, you know where to find it...
I don't understand; how would C++ help here?
I can already write in original source:
int64 a
print a
which I can translate, when I need portable output, to:
int64_t a;
printf("%lld", a)'
Except that that "ll" causes problems on gcc on Windows, with the
warning level high enough, and on the Linux, because there are too many
l's. (The code however will still run. The capabilities of a printf
function ought to be outside the remit of a compiler.)
Are you suggesting that I should instead generate C++ and use 'cout'? My
experience is that even if that solves one problem, it introduces dozens
more. I also have far less choice of compilers, and code will take
longer to compile.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 13:06 -0800 |
| Message-ID | <lnshnw5mmc.fsf@kst-u.example.com> |
| In reply to | #102978 |
BartC <bc@freeuk.com> writes:
[...]
> I can already write in original source:
>
> int64 a
> print a
>
> which I can translate, when I need portable output, to:
>
> int64_t a;
> printf("%lld", a)'
That's not portable output.
> Except that that "ll" causes problems on gcc on Windows, with the
> warning level high enough, and on the Linux, because there are too many
> l's. (The code however will still run. The capabilities of a printf
> function ought to be outside the remit of a compiler.)
I'm surprised that you're getting the particular warnings you report
from gcc, but the fact that you're getting *some* warnings shouldn't be
a problem, since the code is non-portable. (BTW, what compiler options
are you using?)
"%lld" is for type long long int. int64_t may or may not be the same
type. Either convert to long long int and use "%lld" (and figure out
how to get your gcc to suppress its incorrect warning), or use the
PRId64 macro. Those are your options if you want to write or generate
correct and portable C. You have other options if you don't.
If you have other questions that haven't already been asked and
answered, feel free to ask.
> Are you suggesting that I should instead generate C++ and use 'cout'? My
> experience is that even if that solves one problem, it introduces dozens
> more. I also have far less choice of compilers, and code will take
> longer to compile.
Using `std::cout << a` would certainly solve the problem of picking the
right format string (which isn't really much of a problem). No doubt it
would introduce other problems.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 21:51 +0000 |
| Message-ID | <o709ht$5be$1@dont-email.me> |
| In reply to | #102981 |
On 02/02/2017 21:06, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> I can already write in original source:
>>
>> int64 a
>> print a
>>
>> which I can translate, when I need portable output, to:
>>
>> int64_t a;
>> printf("%lld", a)'
>
> That's not portable output.
Well, that's the reason I'm generating C code. Otherwise I would just go
the extra mile and generate native code for all my targets (there's only
two or three). Using C as an intermediate language is supposed to make
life easier not harder.
>> Except that that "ll" causes problems on gcc on Windows, with the
>> warning level high enough, and on the Linux, because there are too many
>> l's. (The code however will still run. The capabilities of a printf
>> function ought to be outside the remit of a compiler.)
> "%lld" is for type long long int. int64_t may or may not be the same
> type.
In that case I might as well just use long long instead of int64_t. I
think long long will be 64 bits on all the targets I'm interested in.
'long' seems to jump about between 32 and 64.
'int' should be 32 bits until I start thinking about a 16-bit target.
It's a mess isn't it; I thought stdint.h was supposed to fix all this?
> how to get your gcc to suppress its incorrect warning), or use the
> PRId64 macro.
Suppose someone is calling printf as a foreign function from another
language. The want to print an integer known to be 64 bits. They don't
know what system they're using as /they/ want to keep things portable too.
Which print format should they use? PRId64 is not an option as there is
no C compiler involved.
> Using `std::cout << a` would certainly solve the problem of picking the
> right format string (which isn't really much of a problem). No doubt it
> would introduce other problems.
There will be problems in the rest of the language not just printing.
But the idea of a dependency on a C++ compile is not very enticing.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 14:16 -0800 |
| Message-ID | <2ed6d67b-1d0a-4601-b618-e42a8bbb914c@googlegroups.com> |
| In reply to | #102982 |
On Thursday, February 2, 2017 at 3:51:41 PM UTC-6, Bart wrote: > In that case I might as well just use long long instead of int64_t. I > think long long will be 64 bits on all the targets I'm interested in. Beware of compilers that will assume that a "long long*" won't be used to access an "int64_t", even if both have the same representation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 15:17 -0800 |
| Message-ID | <lno9yk5gix.fsf@kst-u.example.com> |
| In reply to | #102982 |
BartC <bc@freeuk.com> writes:
> On 02/02/2017 21:06, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> I can already write in original source:
>>>
>>> int64 a
>>> print a
>>>
>>> which I can translate, when I need portable output, to:
>>>
>>> int64_t a;
>>> printf("%lld", a)'
>>
>> That's not portable output.
>
> Well, that's the reason I'm generating C code. Otherwise I would just go
> the extra mile and generate native code for all my targets (there's only
> two or three). Using C as an intermediate language is supposed to make
> life easier not harder.
Great. Using "%lld" to print an int64_t value still isn't portable.
>>> Except that that "ll" causes problems on gcc on Windows, with the
>>> warning level high enough, and on the Linux, because there are too many
>>> l's. (The code however will still run. The capabilities of a printf
>>> function ought to be outside the remit of a compiler.)
>
>> "%lld" is for type long long int. int64_t may or may not be the same
>> type.
>
> In that case I might as well just use long long instead of int64_t. I
> think long long will be 64 bits on all the targets I'm interested in.
It's guaranteed to be at least 64 bits. I've never heard of a system
where it's more than 64 bits. If there's a tradeoff between convenience
and portability, you'll have to decide how to resolve it.
> 'long' seems to jump about between 32 and 64.
It's at least 32 bits; 32 and 64 are both common.
> 'int' should be 32 bits until I start thinking about a 16-bit target.
C requires int to be at least 16 bits. POSIX requires it to be at least
32 (Win32 probably does too).
> It's a mess isn't it; I thought stdint.h was supposed to fix all this?
Yes, it pretty much does, if you use it properly. (No doubt supercat
will jump in and repeat his earlier remarks about not knowing which
intN_t types are promoted to int in expressions.)
>> how to get your gcc to suppress its incorrect warning), or use the
>> PRId64 macro.
>
> Suppose someone is calling printf as a foreign function from another
> language. The want to print an integer known to be 64 bits. They don't
> know what system they're using as /they/ want to keep things portable too.
>
> Which print format should they use? PRId64 is not an option as there is
> no C compiler involved.
If you want to call printf from some non-C language, the calling code
will have to have some awareness of the characteristics of the relevant
types as used by the C compiler that compiled the printf implementation.
If your foreign code uses a "%lld" format, it will have to figure out
how to pass something equivalent to a long long int argument. It will
also have to deal with the parameter passing convention for variadic
functions if it differs from non-variadic functions. If there's an ABI
for the platform it might provide some guidance. I can think of ways to
approach the problem, but I won't go into detail without some concrete
information.
printf() is a standard C function, designed to be called from C code
compiled with a C compiler. Calling it from another language is going
to be difficult. If you want to ask how to do that, we'll need more
information than you've given us so far. (You might consider setting up
some C wrappers.)
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-03 00:16 +0000 |
| Message-ID | <87o9ykjfhr.fsf@bsb.me.uk> |
| In reply to | #102982 |
BartC <bc@freeuk.com> writes:
> On 02/02/2017 21:06, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> I can already write in original source:
>>>
>>> int64 a
>>> print a
>>>
>>> which I can translate, when I need portable output, to:
>>>
>>> int64_t a;
>>> printf("%lld", a)'
>>
>> That's not portable output.
>
> Well, that's the reason I'm generating C code. Otherwise I would just
> go the extra mile and generate native code for all my targets (there's
> only two or three). Using C as an intermediate language is supposed to
> make life easier not harder.
Why do you say that? What evidence is there that the designers of C
thought it was supposed to be used as an intermediate language? Do you
know of any evidence that the C committee made any decisions because it
supposed C would be used like that?
If not, it is possible that a whole slew of your complaints about C are
rooted in your bad experience of C not doing what the people involved in
its design never thought it was supposed to do.
<snip>
> Suppose someone is calling printf as a foreign function from another
> language. The want to print an integer known to be 64 bits. They don't
> know what system they're using as /they/ want to keep things portable
> too.
>
> Which print format should they use? PRId64 is not an option as there
> is no C compiler involved.
Since they know the integer is 64 bits a format of "%lld" and a cast to
(long long int) will be safe. Of course if they don't know what systems
is being used this is likely to the least of the problems.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 01:09 +0000 |
| Message-ID | <o70l4l$llq$1@dont-email.me> |
| In reply to | #102998 |
On 03/02/2017 00:16, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 02/02/2017 21:06, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>> [...]
>>>> I can already write in original source:
>>>>
>>>> int64 a
>>>> print a
>>>>
>>>> which I can translate, when I need portable output, to:
>>>>
>>>> int64_t a;
>>>> printf("%lld", a)'
>>>
>>> That's not portable output.
>>
>> Well, that's the reason I'm generating C code. Otherwise I would just
>> go the extra mile and generate native code for all my targets (there's
>> only two or three). Using C as an intermediate language is supposed to
>> make life easier not harder.
>
> Why do you say that? What evidence is there that the designers of C
> thought it was supposed to be used as an intermediate language? Do you
> know of any evidence that the C committee made any decisions because it
> supposed C would be used like that?
I didn't say it was designed that way. But that's how it seems to be
used. (I know Seed7 generates C; didn't early C++ do so as well?)
While it can work to get more or less portable code with less effort
(and to take advantage of better code generators), the language does
like to get in your way, and then there are some things that are not so
easy to do.
> If not, it is possible that a whole slew of your complaints about C are
> rooted in your bad experience of C not doing what the people involved in
> its design never thought it was supposed to do.
If I think something is a bad idea then I will say so. (Including a
bunch of my stuff too.)
I think needing %d %ld %ldd etc just to print a number is bad idea. You
don't always know the type of the value you want to print (buried
typedef, opaque type etc). Even if you did, it could change and the
format is out of date. Etc.
You have to resort to techniques such as making a broad guess to the
type, then apply a cast, which will shut up a compiler, but now a wrong
guess, or a change of type, might not be detected.
> <snip>
>> Suppose someone is calling printf as a foreign function from another
>> language. The want to print an integer known to be 64 bits. They don't
>> know what system they're using as /they/ want to keep things portable
>> too.
>>
>> Which print format should they use? PRId64 is not an option as there
>> is no C compiler involved.
>
> Since they know the integer is 64 bits a format of "%lld" and a cast to
> (long long int) will be safe.
Exactly. But I can't do that because between my code and the library,
might be a C compiler claiming it doesn't understand "%lld". Or, if I've
chosen to use [u]int64_t to represent my 64-bit types, some compilers
will squawk because that type needs a "%ld" not "%lld".
So now I have to uglify my code (after efforts to make it look more like
natural C) by using PRIdi32 and PRIdi64 everywhere I print a number. You
must admit this is not an elegant part of the language.
Or I could forget about using printf and output my numbers from first
principles just like I /had/ to do years ago. But that would be
ridiculous considering how sophisticated machines are now.
In the meantime, my code actually still works despite the warnings.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-03 01:04 -0600 |
| Message-ID | <6ja89ctcfsnjn6ld20pqmk8ec4th05e116@4ax.com> |
| In reply to | #103001 |
On Fri, 3 Feb 2017 01:09:15 +0000, BartC <bc@freeuk.com> wrote: > >I think needing %d %ld %ldd etc just to print a number is bad idea. You >don't always know the type of the value you want to print (buried >typedef, opaque type etc). Even if you did, it could change and the >format is out of date. Etc. cout << SomeTypeOfInt; But yes, printf is not well typed. We've known that for 40 years.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 11:34 +0100 |
| Message-ID | <o71m88$nh7$1@dont-email.me> |
| In reply to | #103001 |
On 03/02/17 02:09, BartC wrote:
> On 03/02/2017 00:16, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 02/02/2017 21:06, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>> [...]
>>>>> I can already write in original source:
>>>>>
>>>>> int64 a
>>>>> print a
>>>>>
>>>>> which I can translate, when I need portable output, to:
>>>>>
>>>>> int64_t a;
>>>>> printf("%lld", a)'
>>>>
>>>> That's not portable output.
>>>
>>> Well, that's the reason I'm generating C code. Otherwise I would just
>>> go the extra mile and generate native code for all my targets (there's
>>> only two or three). Using C as an intermediate language is supposed to
>>> make life easier not harder.
>>
>> Why do you say that? What evidence is there that the designers of C
>> thought it was supposed to be used as an intermediate language? Do you
>> know of any evidence that the C committee made any decisions because it
>> supposed C would be used like that?
>
> I didn't say it was designed that way. But that's how it seems to be
> used. (I know Seed7 generates C; didn't early C++ do so as well?)
>
Lots of "little languages" generate C, as have a number of "big"
languages during early development. Sometimes they try to generate
readable C code, but mostly they don't - they generate labels and gotos
that would make a C code reviewer cry, and use the basic C types
directly. Often they use extensions and compiler-specific features.
They do this because they C as an intermediary language - not as the end
product. For the programming language Mercury, you compile your Mercury
code and run the executable. It doesn't matter to the (normal) user
that this is done via C and gcc, any more than it matters to the
(normal) C programmer that your C compiler actually generates assembly
code, and it is the assembler that generates the object code.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web