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 1 of 11 [1] 2 3 … 11 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-25 14:30 +0000 |
| Subject | Preprocessor Overheads |
| Message-ID | <o6acmh$pcd$1@dont-email.me> |
I'm testing my preprocessor program (C source input, preprocessed tokens as output), and some of the results are interesting. On one very large input file, preprocessing reduces throughput by 70%, compared with ignoring #if and macro expansion. That is, it is only about as a third as fast. And this is not because macro expansion generates a lot more input than has been accounted for, as the preprocessed source (using gcc -E) is actually smaller than the original. I had expected a significant hit but not this much! My CPP program still needs to be optimised but clawing back that much (effectively getting a 200% increase) seems unlikely. I'm hoping that this is not typical of C code. The SQLite amalgamation only showed a 15% slowdown. The culprit is called gcc.c, and is an amalgamation of the files forming the 'cc1' component of gcc. Looking at the 750Kloc file, it is not good C code; it is an unreadable mishmash of CPP directives, macro calls, and bits of actual C. With another program, only 1000 lines this time, macro expansion slowed things down by nearly 2000 times (99.994%) compared with the expected throughput. But this was making extensive use of macros, and the output was 150 times bigger than the original. However some C compilers also had trouble with it, with two crashing. I've never had much of an opinion of C's macro system (the rest of the preprocessor is OK), but it's now sunk even lower. It's poorly specified, tricky to implement, can be slow to process, and people can make too much use of it to the extent that they are no longer coding in C. [Comparisons are made between tokenising source code with both #if and macro expansion enabled, or both disabled. #include has to be disabled for the comparison as it will not work without #if. Link to gcc.c at bottom of this page: http://people.csail.mit.edu/smcc/projects/single-file-programs/ ] -- Bartc
[toc] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-27 15:18 +0000 |
| Message-ID | <o6fo9r$i9v$1@dont-email.me> |
| In reply to | #102431 |
On 25/01/2017 14:30, BartC wrote: > I'm testing my preprocessor program (C source input, preprocessed tokens > as output), and some of the results are interesting. I've put a version of it here: https://github.com/bartg/langs/blob/master/clex/clex.c As usual, this is one C source file, which here only does the job of -E in C compilers. The code is for compiling and running, not perusing (it's full of other junk anyway). It sort of works, but there are bugs, omissions, and is at the point where the correctness of the output depends on my defining certain built-in macros that a specific compiler expects (if the output is to be compiled) and which I can't be bothered to deal with. (Eventually I will have my own standard headers.) At this point, my interest in this will move on to the next part of my compiler project. This C preprocessor has delayed me several weeks! And has caused (and will continue to cause) a lot of trouble. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-01 11:40 -0800 |
| Message-ID | <kfnmve5d7im.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102529 |
BartC <bc@freeuk.com> writes:
> On 25/01/2017 14:30, BartC wrote:
>> I'm testing my preprocessor program (C source input, preprocessed tokens
>> as output), and some of the results are interesting.
>
> I've put a version of it here:
>
> https://github.com/bartg/langs/blob/master/clex/clex.c
If anyone is interested, a few comments.
1. The code uses a new feature of C11, specifically anonymous
structs and/or unions. <editorial>It would be nice if that
dependency were removed, so it could be compiled with -std=c99
instead of -std=c11.</editorial>
2. The code is not standard C. Apparently it was compiled
without using the -pedantic option. Bart: I recommend using
the -pedantic-errors option. Also you might want to include the
appropriate language version option (ie, -std=c11 for the code
as it is now) in the lines that document how to compile it.
3. The dependency on -m32 caused me some problems when I
tried compiling it. I believe this dependency can be
removed fairly easily (see below), but I should add that
I have only gotten the revised code to compile, I haven't
tried running it. With the diffs below the code compiles
both with and without -m32 (on a 64 bit system).
4. If compiled with -Wuninitialized, roughly half a dozen
cases are detected.
All the rest below is generated output of diagnostics
and diffs, if that isn't of interest feel free to skip
out now. :)
The -Wuninitialized diagnostics:
fixed-up-clex.c: In function 'lexreadtoken':
fixed-up-clex.c:3401:22: error: 'c' may be used uninitialized in this function [-Werror=maybe-uninitialized]
fixed-up-clex.c: In function 'readimportlist':
fixed-up-clex.c:7246:12: error: 'n' is used uninitialized in this function [-Werror=uninitialized]
fixed-up-clex.c: In function 'do_parse':
fixed-up-clex.c:7539:12: error: 'status' is used uninitialized in this function [-Werror=uninitialized]
fixed-up-clex.c: In function 'do_codegen':
fixed-up-clex.c:7544:12: error: 'status' is used uninitialized in this function [-Werror=uninitialized]
fixed-up-clex.c: In function 'do_showprogdiags':
fixed-up-clex.c:7617:7: error: 'd' may be used uninitialized in this function [-Werror=maybe-uninitialized]
Here are diffs (diff old-file new-file) for what I did to get
the code to compile under -std=c11 -pedantic -Werror. The diff
lines are not indented, 192 lines long, and make up all the rest
of the posting.
53c53,61
< #pragma pack(1)
---
> // #pragma pack(1)
>
> typedef void (*VOIDF)();
> typedef struct {
> char * name;
> VOIDF addr;
> } F_WITH_NAME;
> typedef void *RAW_WORD;
>
58c66,67
< typedef int64_t int64;
---
> //typedef int64_t int64;
> typedef long long int int64; // to help with printf() calls
63c72,73
< typedef uint64_t uint64;
---
> //typedef uint64_t uint64;
> typedef unsigned long long uint64; // to help with printf() calls
628c638
< void * os_getdllprocaddr (int32,char *);
---
> VOIDF os_getdllprocaddr (int32,char *);
658c668
< void pcm_printfreelist (int32,uint32 *);
---
> void pcm_printfreelist (int32,RAW_WORD *);
944c954,955
< static uint32 * freelist[9];
---
> //static uint32 * freelist[9];
> static RAW_WORD *freelist[9];
1673c1684
< printf("%s %d\n","Time=",clock()-t);
---
> printf("%s %lld\n","Time=",(long long){ clock()-t } );
1778,1801c1789,1812
< void * os_getdllprocaddr (int32 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 (int32 hinst,char * name) {
> static F_WITH_NAME 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}
1914c1925,1926
< freelist[alloccode] = (uint32 *)*freelist[alloccode];
---
> //freelist[alloccode] = (uint32 *)*freelist[alloccode];
> freelist[alloccode] = *freelist[alloccode];
1935,1936c1947,1948
< *(uint32 *)p = (uint32)freelist[acode];
< freelist[acode] = (uint32 *)p;
---
> *(RAW_WORD *)p = freelist[acode];
> freelist[acode] = p;
2058c2070
< void pcm_printfreelist (int32 size,uint32 * p) {
---
> void pcm_printfreelist (int32 size,RAW_WORD * p) {
2061,2062c2073,2074
< printf(" %X",(uint32)p);
< p = (uint32 *)*p;
---
> printf(" %llX",(unsigned long long)(uintptr_t)p);
> p = (RAW_WORD *)*p;
2096c2108
< printf("%s %p %d\n","***************ADD TO ALLOC:",ptr,size);
---
> printf("%s %p %d\n","***************ADD TO ALLOC:",(void*){ptr},size);
2099c2111
< printf("%s %p %s\n","ALLOC ERROR:",ptr,"ALREADY ALLOCATED\n\n\n");
---
> printf("%s %p %s\n","ALLOC ERROR:",(void*){ptr},"ALREADY ALLOCATED\n\n\n");
2115c2127
< printf("%s %p %d\n","------------------************REMOVE FROM ALLOC:",ptr,size);
---
> printf("%s %p %d\n","------------------************REMOVE FROM ALLOC:",(void*){ptr},size);
2119c2131
< printf("%s %p %s %d %s %d\n","REMOVE:FOUND",ptr,"IN MEMALLOCTABLE, FREESIZE=",size,", BUT STORED AS BLOCK SIZE:",memallocsize[i-1]);
---
> printf("%s %p %s %d %s %d\n","REMOVE:FOUND",(void*){ptr},"IN MEMALLOCTABLE, FREESIZE=",size,", BUT STORED AS BLOCK SIZE:",memallocsize[i-1]);
2126c2138
< printf("%s %p %s %d\n","CAN'T FIND",ptr,"IN MEMALLOCTABLE",size);
---
> printf("%s %p %s %d\n","CAN'T FIND",(void*){ptr},"IN MEMALLOCTABLE",size);
2409,2410c2421,2422
< uint32 * p;
< uint32 * q;
---
> RAW_WORD * p;
> RAW_WORD * q;
2415c2427
< aa = (int64)(int32)p;
---
> aa = (int64)(uintptr_t)p;
2417c2429
< printf("%s %s %d %p %p\n",s,"FREE LIST ERROR",i,p,q);
---
> printf("%s %s %d %p %p\n",s,"FREE LIST ERROR",i,(void*){p},(void*){q});
2422c2434
< p = (uint32 *)*p;
---
> p = (RAW_WORD *)*p;
2432c2444
< freelist[2] = (uint32 *)*freelist[2];
---
> freelist[2] = (RAW_WORD *)*freelist[2];
2440,2441c2452,2453
< *(uint32 *)p = (uint32)freelist[2];
< freelist[2] = (uint32 *)p;
---
> *(RAW_WORD *)p = freelist[2];
> freelist[2] = (RAW_WORD *)p;
2850c2862
< printf("%s %s\n","Writing output to",&outfile);
---
> printf("%s %s\n","Writing output to",(char*){outfile});
3522c3534,3536
< printf("%s %lld %p","//",l.value,(void *)(int32)l.value);
---
> // What is point of printing l.value with %p????
> // printf("%s %lld %p","//",l.value,(void *)l.value);
> printf("%s %lld %p","//",l.value,(void *)(uintptr_t)l.value);
6098c6112
< sprintf((char *)&str,"%.*s",p->uflags.ulength,&(p->uflags).codes);
---
> sprintf((char *)&str,"%.*s",p->uflags.ulength,(char*){(void*){&(p->uflags).codes}});
6135c6149
< fprintf(f,"%d %p %s %s %s %s\n",i,p,":",p->name,symbolnames[p->symbol-1],namenames[p->nameid]);
---
> fprintf(f,"%d %p %s %s %s %s\n",i,(void*){p},":",p->name,symbolnames[p->symbol-1],namenames[p->nameid]);
6138c6152
< fprintf(f,"%s %p %s %s %s %p %s %s%s\n","\t",p,p->name,symbolnames[p->symbol-1],namenames[p->nameid],p->prevdupl,"(From",(!!p->owner?(p->owner)->name:"-"),")");
---
> fprintf(f,"%s %p %s %s %s %p %s %s%s\n","\t",(void*){p},p->name,symbolnames[p->symbol-1],namenames[p->nameid],(void*){p->prevdupl},"(From",(!!p->owner?(p->owner)->name:"-"),")");
6389c6403
< fprintf(dev,"%p %s",p,": ");
---
> fprintf(dev,"%p %s",(void*){p},": ");
6405c6419
< fprintf(dev,"%s %p"," Lastcall:",p->c);
---
> fprintf(dev,"%s %p"," Lastcall:",(void*){p->c});
7636c7650
< printf("%s %s %d %p\n",m.name,sourcefilepaths[fileno],sourcefilesizes[fileno],m.stmodule);
---
> printf("%s %s %d %p\n",m.name,sourcefilepaths[fileno],sourcefilesizes[fileno],(void*){m.stmodule});
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-01 21:35 +0100 |
| Message-ID | <o6tgmu$2sp$1@dont-email.me> |
| In reply to | #102922 |
On 01/02/17 20:40, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 25/01/2017 14:30, BartC wrote:
>>> I'm testing my preprocessor program (C source input, preprocessed tokens
>>> as output), and some of the results are interesting.
>>
>> I've put a version of it here:
>>
>> https://github.com/bartg/langs/blob/master/clex/clex.c
>
> If anyone is interested, a few comments.
I haven't read all of Bart's code - I don't have your patience. But a
few aspects of the points you make were interesting to me.
>
> 1. The code uses a new feature of C11, specifically anonymous
> structs and/or unions. <editorial>It would be nice if that
> dependency were removed, so it could be compiled with -std=c99
> instead of -std=c11.</editorial>
Anonymous unions and structs have been a common extension to C
compilers, so they are supported by many in non-strict C99 mode. That
may be good enough compatibility for some people (though clearly not all).
>
> 2. The code is not standard C. Apparently it was compiled
> without using the -pedantic option. Bart: I recommend using
> the -pedantic-errors option. Also you might want to include the
> appropriate language version option (ie, -std=c11 for the code
> as it is now) in the lines that document how to compile it.
>
> 3. The dependency on -m32 caused me some problems when I
> tried compiling it. I believe this dependency can be
> removed fairly easily (see below), but I should add that
> I have only gotten the revised code to compile, I haven't
> tried running it. With the diffs below the code compiles
> both with and without -m32 (on a 64 bit system).
What was the problem with the code? Had it assumed that pointers could
be stored in uint32_t types, instead of using uintptr_t ?
>
> 4. If compiled with -Wuninitialized, roughly half a dozen
> cases are detected.
What happens with -Wall, or even better, -Wall -Wextra ?
>
> All the rest below is generated output of diagnostics
> and diffs, if that isn't of interest feel free to skip
> out now. :)
>
> The -Wuninitialized diagnostics:
>
> fixed-up-clex.c: In function 'lexreadtoken':
> fixed-up-clex.c:3401:22: error: 'c' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> fixed-up-clex.c: In function 'readimportlist':
> fixed-up-clex.c:7246:12: error: 'n' is used uninitialized in this function [-Werror=uninitialized]
> fixed-up-clex.c: In function 'do_parse':
> fixed-up-clex.c:7539:12: error: 'status' is used uninitialized in this function [-Werror=uninitialized]
> fixed-up-clex.c: In function 'do_codegen':
> fixed-up-clex.c:7544:12: error: 'status' is used uninitialized in this function [-Werror=uninitialized]
> fixed-up-clex.c: In function 'do_showprogdiags':
> fixed-up-clex.c:7617:7: error: 'd' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> Here are diffs (diff old-file new-file) for what I did to get
> the code to compile under -std=c11 -pedantic -Werror. The diff
> lines are not indented, 192 lines long, and make up all the rest
> of the posting.
>
>
> 53c53,61
> < #pragma pack(1)
> ---
>> // #pragma pack(1)
Bart, why was there a "#pragma pack(1)" here? I thought you were
interested in making this run quickly, rather than finding the most
concise ways to make it slow.
>>
>> typedef void (*VOIDF)();
>> typedef struct {
>> char * name;
>> VOIDF addr;
>> } F_WITH_NAME;
>> typedef void *RAW_WORD;
>>
> 58c66,67
> < typedef int64_t int64;
> ---
>> //typedef int64_t int64;
>> typedef long long int int64; // to help with printf() calls
> 63c72,73
> < typedef uint64_t uint64;
> ---
>> //typedef uint64_t uint64;
>> typedef unsigned long long uint64; // to help with printf() calls
Surely it is better to use standard types int64_t, uint64_t, etc., if
that is the sizes he specifically wants in his code? Home-made names
like "int64" and "uint64" are, IMHO, worse than useless. But I don't
see how your "typedef long long int int64;" helps. Either the code is
to be portable to all practical and realistic compilers, in which case
"int64_t" is already a typedef for "long long int" and you should use
it, or it is to be portable to a wider range of hypothetical tools in
which case you can't assume that "long long int" really is 64 bits and
the names are wrong. By using "int64_t", you are making a compile-time
assumption that a type with the required properties exists - if it does
not, you'll get a compile-time error. If you use "long long int", you
really ought to check that the size is correct.
As for printf's, you can either use "%lld" with a cast to "long long
int" or PRId64 - whichever you find neatest.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-01 21:02 +0000 |
| Message-ID | <o6ti9r$94n$1@dont-email.me> |
| In reply to | #102926 |
On 01/02/2017 20:35, David Brown wrote: > On 01/02/17 20:40, Tim Rentsch wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 25/01/2017 14:30, BartC wrote: >>>> I'm testing my preprocessor program (C source input, preprocessed >>>> tokens >>>> as output), and some of the results are interesting. >>> >>> I've put a version of it here: >>> >>> https://github.com/bartg/langs/blob/master/clex/clex.c >> >> If anyone is interested, a few comments. > > I haven't read all of Bart's code - I don't have your patience. Neither have I! The C is intermediate code in this project. >> 3. The dependency on -m32 caused me some problems when I >> tried compiling it. I believe this dependency can be >> removed fairly easily (see below), but I should add that >> I have only gotten the revised code to compile, I haven't >> tried running it. With the diffs below the code compiles >> both with and without -m32 (on a 64 bit system). > > What was the problem with the code? Had it assumed that pointers could > be stored in uint32_t types, instead of using uintptr_t ? The problem is that anything that is different between 32- and 64-bit, such as pointer sizes, which makes it into compile-time expressions, or is used to calculate struct-member offsets, could result in hard-coded constants in this generated C code. >> < #pragma pack(1) >> --- >>> // #pragma pack(1) > > Bart, why was there a "#pragma pack(1)" here? I thought you were > interested in making this run quickly, rather than finding the most > concise ways to make it slow. Again, because this is a translator, it can't always be certain what arrangements for padding will be used for the eventual C compiler. It might put a 64-bit member at offset 4, or it might be 8. With pack(1), it will always know exactly, and be sure any offset calculations used, or struct sizes used in compile-time expressions (ie. /my/ compile-time, not C's) will be accurate. Most of the time, the offsets will be the same. But not always. (On ARM, I have to remove pack(1) as gcc there will do funny things, like assume a pointer to pack(1) is going to be unaligned, even though ARM can do unaligned access, and generate byte-at-a-time accesses.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-02 00:35 -0600 |
| Message-ID | <0jk59cla47uee9cpo3ldc94m2q11s05n9m@4ax.com> |
| In reply to | #102929 |
On Wed, 1 Feb 2017 21:02:25 +0000, BartC <bc@freeuk.com> wrote: >On 01/02/2017 20:35, David Brown wrote: >> On 01/02/17 20:40, Tim Rentsch wrote: >>> BartC <bc@freeuk.com> writes: > >>> < #pragma pack(1) >>> --- >>>> // #pragma pack(1) >> >> Bart, why was there a "#pragma pack(1)" here? I thought you were >> interested in making this run quickly, rather than finding the most >> concise ways to make it slow. > >Again, because this is a translator, it can't always be certain what >arrangements for padding will be used for the eventual C compiler. It >might put a 64-bit member at offset 4, or it might be 8. > >With pack(1), it will always know exactly, and be sure any offset >calculations used, or struct sizes used in compile-time expressions (ie. >/my/ compile-time, not C's) will be accurate. Two comments - while "#pragma pack(1)" is commonly supported, it's not universal. Second, you already have to do some amount of configuration for your language based on the target C implementation, why not just include the alignment rules that the target will be using? You could probably even compute many of those dynamically, assuming your compiler is running on the same platform as the target.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-02 09:00 +0100 |
| Message-ID | <o6uora$iej$1@dont-email.me> |
| In reply to | #102929 |
On 01/02/17 22:02, BartC wrote: > On 01/02/2017 20:35, David Brown wrote: >> On 01/02/17 20:40, Tim Rentsch wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 25/01/2017 14:30, BartC wrote: >>>>> I'm testing my preprocessor program (C source input, preprocessed >>>>> tokens >>>>> as output), and some of the results are interesting. >>>> >>>> I've put a version of it here: >>>> >>>> https://github.com/bartg/langs/blob/master/clex/clex.c >>> >>> If anyone is interested, a few comments. >> >> I haven't read all of Bart's code - I don't have your patience. > > Neither have I! The C is intermediate code in this project. That might explain some of the oddities, like using large numbers of separate enum types to define closely related concepts that would more logical in a single enum. > >>> 3. The dependency on -m32 caused me some problems when I >>> tried compiling it. I believe this dependency can be >>> removed fairly easily (see below), but I should add that >>> I have only gotten the revised code to compile, I haven't >>> tried running it. With the diffs below the code compiles >>> both with and without -m32 (on a 64 bit system). >> >> What was the problem with the code? Had it assumed that pointers could >> be stored in uint32_t types, instead of using uintptr_t ? > > The problem is that anything that is different between 32- and 64-bit, > such as pointer sizes, which makes it into compile-time expressions, or > is used to calculate struct-member offsets, could result in hard-coded > constants in this generated C code. I can't see how that would be the case. Use appropriate types, and use sizeof when you need to (wrapped in macros, consts, static-inline functions, conditional compilation, etc., as needed to make the code clear). There is very rarely good reason for making a PC program that will not compile correctly as both 32-bit and 64-bit. It's fine, IMHO, if it does not work with 16-bit int's or 64-bit int's - there is a limit to how much portability make sense. But if it doesn't work with -m32 and -m64, there is a design problem or serious programmer laziness. > >>> < #pragma pack(1) >>> --- >>>> // #pragma pack(1) >> >> Bart, why was there a "#pragma pack(1)" here? I thought you were >> interested in making this run quickly, rather than finding the most >> concise ways to make it slow. > > Again, because this is a translator, it can't always be certain what > arrangements for padding will be used for the eventual C compiler. It > might put a 64-bit member at offset 4, or it might be 8. That is why C has things like "offsetof", and newer C has _Alignof. But in most cases, it simply does not matter. It can make a difference for structs that are passed in and out of the program in binary form - these need to match a specific format. It is not unreasonable to have specific packing for these (though pack 4 makes far more sense than the highly inefficient pack 1). Personally, I prefer to make padding explicit and then use static assertions to double-check the sizes. > > With pack(1), it will always know exactly, and be sure any offset > calculations used, or struct sizes used in compile-time expressions (ie. > /my/ compile-time, not C's) will be accurate. They will all be correct anyway if you use the appropriate features of C - sizeof and offsetof. > > Most of the time, the offsets will be the same. But not always. > > (On ARM, I have to remove pack(1) as gcc there will do funny things, > like assume a pointer to pack(1) is going to be unaligned, even though > ARM can do unaligned access, and generate byte-at-a-time accesses.) > Some ARM targets cannot do unaligned access - if you are not accurate about specifying exactly /which/ ARM cpu you are targeting, then the compiler will be conservative in the code it generates. And in all cases, ARM and x86, unaligned access is significantly slower.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-02 16:41 -0600 |
| Message-ID | <84d79c9ig2qqfita6i8o49je35ge542e8h@4ax.com> |
| In reply to | #102949 |
On Thu, 02 Feb 2017 09:00:18 +0100, David Brown <david.brown@hesbynett.no> wrote: >Some ARM targets cannot do unaligned access - if you are not accurate >about specifying exactly /which/ ARM cpu you are targeting, then the >compiler will be conservative in the code it generates. And in all >cases, ARM and x86, unaligned access is significantly slower. On most modern x86s, unaligned accesses that do not cross a cache line boundary have little or no penalty. So if you had a an array of structures, reducing the number of cache lines each instance takes would probably be a good win so long as you avoid cache line crossings in any items. Of course you might be able to do the same thing by re-arranging the items in the structure (although there may be external constraint making that difficult). Similar rules hold for POWER and IPF.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 00:11 +0100 |
| Message-ID | <o70e7h$rpc$1@dont-email.me> |
| In reply to | #102989 |
On 02/02/17 23:41, Robert Wessel wrote: > On Thu, 02 Feb 2017 09:00:18 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> Some ARM targets cannot do unaligned access - if you are not accurate >> about specifying exactly /which/ ARM cpu you are targeting, then the >> compiler will be conservative in the code it generates. And in all >> cases, ARM and x86, unaligned access is significantly slower. > > > On most modern x86s, unaligned accesses that do not cross a cache line > boundary have little or no penalty. So if you had a an array of > structures, reducing the number of cache lines each instance takes > would probably be a good win so long as you avoid cache line crossings > in any items. Of course you might be able to do the same thing by > re-arranging the items in the structure (although there may be > external constraint making that difficult). > > Similar rules hold for POWER and IPF. > The nearest I have used to POWER is a couple of embedded PowerPC microcontrollers, and I don't think they supported unaligned access at all. Even if the cpu does not impose penalties for the unaligned access, you might have issues in software where code assumes that data follows alignment rules. Some cpu instructions (such as some SIMD instructions on the x86) only work with properly aligned data - code that uses these, such as optimised block copy loops, could have trouble. In general, it is a better idea to stick to the standard alignments for the target unless you have particularly good reason not to - even if the slow-down is not as bad as I thought.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-03 00:56 -0600 |
| Message-ID | <pc989ctoftgruk1l6ske2134isuhjon2r8@4ax.com> |
| In reply to | #102991 |
On Fri, 3 Feb 2017 00:11:21 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 02/02/17 23:41, Robert Wessel wrote: >> On Thu, 02 Feb 2017 09:00:18 +0100, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> Some ARM targets cannot do unaligned access - if you are not accurate >>> about specifying exactly /which/ ARM cpu you are targeting, then the >>> compiler will be conservative in the code it generates. And in all >>> cases, ARM and x86, unaligned access is significantly slower. >> >> >> On most modern x86s, unaligned accesses that do not cross a cache line >> boundary have little or no penalty. So if you had a an array of >> structures, reducing the number of cache lines each instance takes >> would probably be a good win so long as you avoid cache line crossings >> in any items. Of course you might be able to do the same thing by >> re-arranging the items in the structure (although there may be >> external constraint making that difficult). >> >> Similar rules hold for POWER and IPF. >> > >The nearest I have used to POWER is a couple of embedded PowerPC >microcontrollers, and I don't think they supported unaligned access at all. The "big" PPC devices are supposed to support unaligned accesses except when they cross page boundaries, and they *may* under some circumstances even if the do (basically if both translations are available, and the protections are identical, plus some weasel words to make it more or less completely optional). The small PPC devices may well not support all that. OTOH, the penalty for a (successful) unaligned access is not specified. >Even if the cpu does not impose penalties for the unaligned access, you >might have issues in software where code assumes that data follows >alignment rules. Some cpu instructions (such as some SIMD instructions >on the x86) only work with properly aligned data - code that uses these, >such as optimised block copy loops, could have trouble. > >In general, it is a better idea to stick to the standard alignments for >the target unless you have particularly good reason not to - even if the >slow-down is not as bad as I thought. While true, the problem is that there are cases where it's difficult to know ahead of time, which means that you either allow the horribly slow trap to fixup code, or perform an expensive test and select one of two code paths in what can be a rather inner bit of code, or generate the slower, unaligned tolerant code unconditionally. So unaligned access performance can matter. While it's clearly possible to build software systems that don't require unaligned accesses (although there may be considerable overhead in places because of that), it's also clearly possible to build hardware where many/most unaligned accesses can be performed with very little penalty (although there is clearly some overhead to that, possibly including an impact on clock rates).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-01 20:49 +0000 |
| Message-ID | <o6thh9$60m$1@dont-email.me> |
| In reply to | #102922 |
On 01/02/2017 19:40, Tim Rentsch wrote: > BartC <bc@freeuk.com> writes: > >> On 25/01/2017 14:30, BartC wrote: >>> I'm testing my preprocessor program (C source input, preprocessed tokens >>> as output), and some of the results are interesting. >> >> I've put a version of it here: >> >> https://github.com/bartg/langs/blob/master/clex/clex.c > 3. The dependency on -m32 caused me some problems when I > tried compiling it. I believe this dependency can be > removed fairly easily (see below), but I should add that > I have only gotten the revised code to compile, I haven't > tried running it. With the diffs below the code compiles > both with and without -m32 (on a 64 bit system). The 32-bit dependency was a minor detail. Perhaps I should have just provided both versions, eg. here is a version that compiles with -m64 (it's just an option on my translator): https://github.com/bartg/langs/blob/master/clex/clex64.c (Note quite the same version as before, as it's being developed.) > 4. If compiled with -Wuninitialized, roughly half a dozen > cases are detected. Thanks, I'll look at the warning from gcc later on. Note that all the code in clex.c is translated by a program so permanent fixes to remove warnings is not practical just by modifying the C source. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 00:43 +0000 |
| Message-ID | <o6tv8g$mb5$1@dont-email.me> |
| In reply to | #102922 |
On 01/02/2017 19:40, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:
>> https://github.com/bartg/langs/blob/master/clex/clex.c
> The -Wuninitialized diagnostics:
>
> fixed-up-clex.c: In function 'lexreadtoken':
> ...
OK, well maybe I should apologise for leaving so much junk in that
source code (but I did warn about it). Most of these functions are not
used in this app, and might be left over from previous bits of code that
are in the middle of being overhauled.
The one above /is/ used, although the code in question is for error
handling.
As for other warnings, I believe this code compiles clean using:
gcc -c clex.c
under Windows. (Under Linux, there are extra print format-mismatch
errors that I'll come to later.)
With gcc -Wall -Wextra -Wpedantic -c clex.c, I got 900 lines of
warnings. A few of these I've taken care of by putting extra casts via
the translator (I don't want to clutter the original source).
But many are proving difficult to eliminate:
(1) Unused variables, functions/labels defined but not used.
In development code, there are lots of bits of code that are temporarily
commented out, or are only there while debugging.
Commenting out some lines may mean there are apparently orphan functions
that aren't called or variables not used.
(2) Printing pointer values.
Presumably this is what "%p" is for. But apparently %p should only be
used for void* types, so requiring a cast in most cases. (I've got my
translator to add such a cast, but that won't work where I directly call
a printf-family function, so I have clutter my source code with
pointless casts.)
(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". If I change it to "%ld", I now get:
"format '%ld' expects argument of type 'long int', but argument 2 has
type 'int64_t {aka long long int}'"
"%d" doesn't work either. What the hell print format do you have to use
for int64_t?! Meanwhile, if I compile the %lld on Linux, I get:
"format ‘%lld’ expects argument of type ‘long long int’, but argument 2
has type ‘int64_t {aka long int}". (That is, one long not two.)
At least gcc on Linux can be shut up by using "%ld". But what format to
use that works on Windows, and works also on Linux for the same type,
int64_t?
(4) 'Too many arguments for format'
This one line:
printf("%lld%s",l.value," ");
generates 3 warnings:
"warning: unknown conversion type character 'l' in format"
"warning: format '%s' expects argument of type 'char *', but argument
2 has type 'int64 {aka long long int}"
"warning: too many arguments for format"
l.value has int64_t type. What's it moaning about here?
(5) Suggesting parentheses:
If I mix && and ||, I get this warning:
"warning: suggest parentheses around '&&' within '||'"
It's my translator that suppresses the parentheses because it
understands C precedences. So adding them in the original source
wouldn't work (and I don't want them as I understand 'and' and 'or'
precedences).
I also get it for:
"warning: suggest parentheses around '+' inside '<<'"
(6) Zero-length arrays
This is an error not a warning, but I think it came about while I was
trying to suppress a warning (to do with using {} for initialising I think):
int data[]; // or:
int data[] = {};
Apparently this is a no-no. But sometimes this is exactly what you want,
for example when you have a set of such arrays, some may be filled, some
could be empty waiting to be set up at some later date or by someone
else. But in the meantime, it won't compile.
(7) Converting between void* and function pointers.
This seems to be frowned upon. But it's difficult to add a cast, when
there are multiple pointers that must all be coerced to the same time,
where the functions are all mixed types. (I think Tim has done something
to fix that, but whatever it is, I don't think I can do the same. Nor do
I want the clutter.)
Is it any wonder that I usually suppress warnings so that I don't see
them? Anyway, there will be a few less now.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-01 17:36 -0800 |
| Message-ID | <lnmve574r4.fsf@kst-u.example.com> |
| In reply to | #102939 |
BartC <bc@freeuk.com> writes:
[...]
> (2) Printing pointer values.
>
> Presumably this is what "%p" is for.
Yes.
> But apparently %p should only be
> used for void* types, so requiring a cast in most cases.
Yes, using any other type (other than a character pointer type) has
undefined behavior.
The casts are hardly pointless. They're necessary if you want to write
(or generate) valid C.
> (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".
Are you using a very old version of gcc, or with some odd options? The
"%lld" format has been standard since C99. If you're using "-ansi" or
"-std=c90", then you're telling the compiler you don't want to use some
features that you're using.
[...]
> At least gcc on Linux can be shut up by using "%ld". But what format to
> use that works on Windows, and works also on Linux for the same type,
> int64_t?
int64_t might be defined as long or as long long (or, in principle, as
any of several other types). Either use the PRId64 macro from
<inttypes.h>, or convert to long long and use "%lld".
> (4) 'Too many arguments for format'
>
> This one line:
>
> printf("%lld%s",l.value," ");
>
> generates 3 warnings:
>
> "warning: unknown conversion type character 'l' in format"
> "warning: format '%s' expects argument of type 'char *', but argument
> 2 has type 'int64 {aka long long int}"
> "warning: too many arguments for format"
>
> l.value has int64_t type. What's it moaning about here?
That line doesn't appear in the clex.c file I thought we were
talking about. But again, any modern gcc will recognize "%lld" --
but see above for the corrct way to print an int64_t value.
[...]
> (6) Zero-length arrays
>
> This is an error not a warning, but I think it came about while I was
> trying to suppress a warning (to do with using {} for initialising I think):
>
> int data[]; // or:
> int data[] = {};
>
> Apparently this is a no-no. But sometimes this is exactly what you want,
> for example when you have a set of such arrays, some may be filled, some
> could be empty waiting to be set up at some later date or by someone
> else. But in the meantime, it won't compile.
Right, it won't compile, because zero-length arrays do not exist in C.
And you're complaining that your compiler tells you this?
> (7) Converting between void* and function pointers.
>
> This seems to be frowned upon. But it's difficult to add a cast, when
> there are multiple pointers that must all be coerced to the same time,
> where the functions are all mixed types. (I think Tim has done something
> to fix that, but whatever it is, I don't think I can do the same. Nor do
> I want the clutter.)
You can convert (using a cast) from any function pointer type to any
other function pointer type. If you need a generic function pointer
type, just pick one, such as `void(*)(void)`.
[...]
--
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-01 17:50 -0800 |
| Message-ID | <kfn60ktcqef.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102939 |
BartC <bc@freeuk.com> writes:
> On 01/02/2017 19:40, Tim Rentsch wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> https://github.com/bartg/langs/blob/master/clex/clex.c
>>
>> The -Wuninitialized diagnostics:
>>
>> fixed-up-clex.c: In function 'lexreadtoken':
>> ...
>
> OK, well maybe I should apologise for leaving so much junk [...]
No apology needed. I just figured you might want to know.
> With gcc -Wall -Wextra -Wpedantic -c clex.c, I got 900 lines of
> warnings. A few of these I've taken care of by putting extra
> casts via the translator (I don't want to clutter the original
> source).
I used (and recommend)
-std=c11 -pedantic -Wall -Wextra -Wno-parentheses -Wno-unused -Werror
which should take out a lot of the clutter.
> But many are proving difficult to eliminate:
>
> (1) Unused variables, functions/labels defined but not used.
That will be taken care of by the -Wno-unused option.
> (2) Printing pointer values.
>
> Presumably this is what "%p" is for. But apparently %p should only be
> used for void* types, so requiring a cast in most cases. (I've got my
> translator to add such a cast, but that won't work where I directly
> call a printf-family function, so I have clutter my source code with
> pointless casts.)
Yes, the (void*) casts in these cases are kind of a pain.
I live with them because I find the other printf() format
warnings so useful.
> (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". If I change it to "%ld", I now get: [...]
There is a standard way of handling this problem, using the
header <inttypes.h>, but that may not be supported on some
of the systems you use. I will post a separate message
about how this can be addressed.
> (4) 'Too many arguments for format'
>
> This one line:
>
> printf("%lld%s",l.value," ");
>
> generates 3 warnings:
>
> "warning: unknown conversion type character 'l' in format"
> "warning: format '%s' expects argument of type 'char *', but argument
> 2 has type 'int64 {aka long long int}"
> "warning: too many arguments for format"
>
> l.value has int64_t type. What's it moaning about here?
This looks like a bug in whatever is producing the warning
message. There is nothing wrong with %lld as a format
specifier, and the system knows about 'long long'. Which
compiler produces these messages?
> (5) Suggesting parentheses:
>
> If I mix && and ||, I get this warning: [...]
These will be taken care of by the -Wno-parentheses option.
> (6) Zero-length arrays
>
> This is an error not a warning, but I think it came about while I was
> trying to suppress a warning (to do with using {} for initialising I
> think):
>
> int data[]; // or:
> int data[] = {};
>
> Apparently this is a no-no. But sometimes this is exactly what you
> want, for example when you have a set of such arrays, some may be
> filled, some could be empty waiting to be set up at some later date or
> by someone else. But in the meantime, it won't compile.
I didn't see any problems like this in the source I looked
at. Could that have come up since the earlier version?
> (7) Converting between void* and function pointers.
>
> This seems to be frowned upon. But it's difficult to add a cast, when
> there are multiple pointers that must all be coerced to the same time,
> where the functions are all mixed types. (I think Tim has done
> something to fix that, but whatever it is, I don't think I can do the
> same. Nor do I want the clutter.)
This problem is important, because it's incompatible with
standard C. You should be able to use the same fix that I
did, and the changes are fairly small and pretty localized.
I will post a separate message about that.
> Is it any wonder that I usually suppress warnings so that I don't see
> them? Anyway, there will be a few less now.
I routinely suppress _some_ warnings, but basically always use
the -pedantic option, and usually enable other warnings. IME
enabling a small set of warnings almost always, and treating them
as errors with -Werror, has a fairly small cost and a fairly high
yield, in the sense that almost all the detected cases represent
bugs of one kind or another (unlike for example used variables,
which as often as not are irrelevant). At the very least use
the -pedantic option, which should make targeting multiple
environments easier by eliminating non-standard extensions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-01 18:09 -0800 |
| Message-ID | <kfn1svhcpi3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102939 |
BartC <bc@freeuk.com> writes:
> On 01/02/2017 19:40, Tim Rentsch wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> https://github.com/bartg/langs/blob/master/clex/clex.c
>>
> (7) Converting between void* and function pointers.
Fixing this in the code that I looked at needs changes in only
three places. Change this:
typedef struct _rec {
char * name;
void * addr;
} rec;
to this (a typedef is added, and the type of 'addr' is changed to
be of the new type):
typedef void (*VOIDF)();
typedef struct _rec {
char * name;
VOIDF addr;
} rec;
================================================================
Next, change this:
void * os_getdllprocaddr (int32,char *);
to this (the return type of the function is changed):
VOIDF os_getdllprocaddr (int32,char *);
================================================================
And last, change this:
void * os_getdllprocaddr (int32 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}
};
to this (the type of the function changes, and there are casts
in each initializer line):
VOIDF os_getdllprocaddr (int32 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}
};
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-02 10:30 +0100 |
| Message-ID | <o6uu5g$2ff$1@dont-email.me> |
| In reply to | #102939 |
On 02/02/17 01:43, BartC wrote:
> On 01/02/2017 19:40, Tim Rentsch wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> https://github.com/bartg/langs/blob/master/clex/clex.c
>
>> The -Wuninitialized diagnostics:
>>
>> fixed-up-clex.c: In function 'lexreadtoken':
>> ...
>
> OK, well maybe I should apologise for leaving so much junk in that
> source code (but I did warn about it). Most of these functions are not
> used in this app, and might be left over from previous bits of code that
> are in the middle of being overhauled.
>
> The one above /is/ used, although the code in question is for error
> handling.
>
> As for other warnings, I believe this code compiles clean using:
>
> gcc -c clex.c
>
> under Windows. (Under Linux, there are extra print format-mismatch
> errors that I'll come to later.)
>
> With gcc -Wall -Wextra -Wpedantic -c clex.c, I got 900 lines of
> warnings. A few of these I've taken care of by putting extra casts via
> the translator (I don't want to clutter the original source).
>
> But many are proving difficult to eliminate:
>
> (1) Unused variables, functions/labels defined but not used.
>
> In development code, there are lots of bits of code that are temporarily
> commented out, or are only there while debugging.
>
> Commenting out some lines may mean there are apparently orphan functions
> that aren't called or variables not used.
Since this C code is generated rather than hand-written, can't the
generator be improved to omit things that are never used? And if you
didn't have a habit of declaring all your variables at the start of
functions, you'd find far fewer of them being unused.
-Wunused is a useful warning for most people because normally people
only put useful things in their code - an unused variable or label is a
likely indication of an error. They do turn up a bit during
development, but not /that/ much IME.
However, if your code generator makes lots of unnecessary identifiers of
various sorts, use -Wno-unused to suppress the warning while keeping
-Wall -Wextra.
>
> (2) Printing pointer values.
>
> Presumably this is what "%p" is for. But apparently %p should only be
> used for void* types, so requiring a cast in most cases. (I've got my
> translator to add such a cast, but that won't work where I directly call
> a printf-family function, so I have clutter my source code with
> pointless casts.)
Those pesky rules of C, eh? Who would have thought you needed a cast to
void* just because the standards say so?
>
> (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.
So use -std=c99, -std=c11, -std=gnu99 or -std=gnu11 according to taste.
Note that "gnu90" standard allows some use of C99 features as an
extension, which is why you might not have noticed which standard you
had picked (or left as default). The default is designed to be
convenient rather than strict.
> If I change it to "%ld", I now get:
>
> "format '%ld' expects argument of type 'long int', but argument 2 has
> type 'int64_t {aka long long int}'"
That seems a perfectly reasonable warning, and states the situation
accurately.
>
> "%d" doesn't work either. What the hell print format do you have to use
> for int64_t?!
In C90, there is /no/ format specifier for long long int, as there is no
long long int. (But gcc might allow it as an extension in gnu90 mode.)
If size_t is 64 bits, then %z should work - but that will not be the
case with -m32.
> Meanwhile, if I compile the %lld on Linux, I get:
>
> "format ‘%lld’ expects argument of type ‘long long int’, but argument 2
> has type ‘int64_t {aka long int}". (That is, one long not two.)
"long long int" and "long int" are two different types, even when they
have the same size and representation. Whether you consider that a
"feature" of C, or a "quirk" of C, depends on your usage. <inttypes.h>
has macros such as PRId64 to deal with that - on Windows, it would
expand to "%lld" and on Linux it would be "%ld".
>
> At least gcc on Linux can be shut up by using "%ld". But what format to
> use that works on Windows, and works also on Linux for the same type,
> int64_t?
PRId64 - that's what that macro is for. (Section 7.8.1 in C11 standards.)
>
>
> (4) 'Too many arguments for format'
>
> This one line:
>
> printf("%lld%s",l.value," ");
>
> generates 3 warnings:
>
> "warning: unknown conversion type character 'l' in format"
> "warning: format '%s' expects argument of type 'char *', but argument
> 2 has type 'int64 {aka long long int}"
> "warning: too many arguments for format"
>
> l.value has int64_t type. What's it moaning about here?
The format specifier "%lld" is ignored (by the static error checker -
the actual run-time code will pass it on to the library printf function)
because it is invalid in your current compiler mode, generating the
first warning. So the format checker sees just one specifier "%s",
followed by two arguments of type int64 and then char*. Appropriate
warnings are then given.
>
>
> (5) Suggesting parentheses:
>
> If I mix && and ||, I get this warning:
>
> "warning: suggest parentheses around '&&' within '||'"
>
Yes, these are excellent warnings because it is very easy to get the
precedences wrong, either when writing the code, or when trying to
understand code written by other people. So for code you write
yourself, or code you expect other people to read, it is a good idea to
include the extra parentheses.
> It's my translator that suppresses the parentheses because it
> understands C precedences. So adding them in the original source
> wouldn't work (and I don't want them as I understand 'and' and 'or'
> precedences).
If you want people to read the generated code, put those parentheses in
the generated code.
If you don't want anyone to read it, use the -Wno-parentheses flag to
suppress that warning.
>
> I also get it for:
>
> "warning: suggest parentheses around '+' inside '<<'"
>
Same as above.
> (6) Zero-length arrays
>
> This is an error not a warning, but I think it came about while I was
> trying to suppress a warning (to do with using {} for initialising I
> think):
>
> int data[]; // or:
> int data[] = {};
>
> Apparently this is a no-no. But sometimes this is exactly what you want,
> for example when you have a set of such arrays, some may be filled, some
> could be empty waiting to be set up at some later date or by someone
> else. But in the meantime, it won't compile.
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. Whatever you think your code
is doing here, it is not doing it - it is broken.
>
> (7) Converting between void* and function pointers.
>
> This seems to be frowned upon. But it's difficult to add a cast, when
> there are multiple pointers that must all be coerced to the same time,
> where the functions are all mixed types. (I think Tim has done something
> to fix that, but whatever it is, I don't think I can do the same. Nor do
> I want the clutter.)
Again, if you want to use C, follow the rules of C. Tim gave a
suggestion - if you don't like it, find a different method.
And this is /generated/ code. It should not be difficult for the code
generator to add casts as necessary - there is no problem with "clutter"
in code that you are not writing by hand or expecting people to read.
>
> Is it any wonder that I usually suppress warnings so that I don't see
> them? Anyway, there will be a few less now.
>
Given that all these issues can be dealt with sensibly, and some of them
are clear indications of incorrect code and not just stylistic issues,
yes, it is a wonder. It is especially a "wonder" since many of these
are just simple standard C.
Is it a wonder that /you/ suppress warnings rather than trying to
understand what they mean and why they might be indications that there
are problems (or at least "opportunities for improvement") in your code?
No, it is par for the course for the way you code and the way you
assume that any issues in your programming are the result of bad design
of the C language rather than your own errors or misunderstandings.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 12:13 +0000 |
| Message-ID | <o6v7m8$56j$1@dont-email.me> |
| In reply to | #102952 |
On 02/02/2017 09:30, David Brown wrote:
> On 02/02/17 01:43, BartC wrote:
>> Commenting out some lines may mean there are apparently orphan functions
>> that aren't called or variables not used.
>
> Since this C code is generated rather than hand-written, can't the
> generator be improved to omit things that are never used? And if you
> didn't have a habit of declaring all your variables at the start of
> functions, you'd find far fewer of them being unused.
Sure, I forget about writing a new compiler so that I can perfect an old
one first!
> If you want people to read the generated code, put those parentheses in
> the generated code.
(Do you know how much effort it took to get rid of them? Now I have to
put them back in order to shut up a compiler!)
>> (6) Zero-length arrays
>> Apparently this is a no-no.
> 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[] = {};
In this form, the array can't be used, other than take its size. But
someone could later change it to:
int array[] = {10,20,30};
and /recompile/ it. Then it could be used.
(The original context was multiple string arrays giving 'include'
search-paths for different C compiler 'hosts'. One of them was a custom
host with an initially empty set of paths to be filled in by whoever
compiled the code.)
So there's nothing wrong with the idea (and with a native code target,
it works perfectly fine).
>> Is it any wonder that I usually suppress warnings so that I don't see
>> them? Anyway, there will be a few less now.
>>
>
> Given that all these issues can be dealt with sensibly, and some of them
> are clear indications of incorrect code and not just stylistic issues,
> yes, it is a wonder. It is especially a "wonder" since many of these
> are just simple standard C.
>
> Is it a wonder that /you/ suppress warnings rather than trying to
> understand what they mean and why they might be indications that there
> are problems (or at least "opportunities for improvement") in your code?
Out of the 900 lines of warnings in that source file when I used -Wextra
etc, I only identified one that I knew would give wrong results (but
would not cause a crash).
Most of them were pedantic quibbles, given that I knew which platforms
I'd intended this code to run on, so I wasn't particularly worried.
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 remember DMC battling it out with clang about "=" being used in an
expression.) The translator doesn't know which C compiler is to be used.
> No, it is par for the course for the way you code and the way you
> assume that any issues in your programming are the result of bad design
> of the C language rather than your own errors or misunderstandings.
Yes it is, because I also generate native code for x64 and have none of
these problems.
With the printf problem, originally I used to generate discrete
functions calls, so an original source of 'println a', where a is 64-bit
signed int, would result in:
print_i64(a);
print_newline();
Then I thought it would be neat if it could generate instead:
printf("%lld\n", a);
Because it would look great in the output. Now you say I should instead use:
printf(PRId64 "\n", a);
Just to suppress warnings in pedantic mode, which defeats the purpose of
my using printf in the first place. No thanks, I'd rather go back to my
discrete functions.
(And this is when I translate 'println a'; if instead I directly call
sprintf() for example from the other language, then PRId64 is not
available.)
(BTW I've just compiled gcc.c with -Wextra etc, and I get 33,000 lines
of warnings and notes. That's for a hefty input file, but still... it's
not exactly 'clean'.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-02 13:53 +0100 |
| Message-ID | <o6va19$f3l$1@dont-email.me> |
| In reply to | #102957 |
On 02/02/17 13:13, BartC wrote:
> On 02/02/2017 09:30, David Brown wrote:
>> On 02/02/17 01:43, BartC wrote:
>
>>> Commenting out some lines may mean there are apparently orphan functions
>>> that aren't called or variables not used.
>>
>> Since this C code is generated rather than hand-written, can't the
>> generator be improved to omit things that are never used? And if you
>> didn't have a habit of declaring all your variables at the start of
>> functions, you'd find far fewer of them being unused.
>
> Sure, I forget about writing a new compiler so that I can perfect an old
> one first!
>
>> If you want people to read the generated code, put those parentheses in
>> the generated code.
>
> (Do you know how much effort it took to get rid of them? Now I have to
> put them back in order to shut up a compiler!)
I have no idea how much effort it took - though it was wasted effort.
Why would you go to the bother of removing them in a code generator?
For a good generator, your main concern is that the generated code
should be unambiguously interpreted by the target compiler(s).
Secondary concerns are being readable by humans, and being conveniently
warning-free for compilers. Removing brackets around expressions that
form part of && and || expressions fulfils none of these goals - it
actively works against the two secondary goals.
>
>>> (6) Zero-length arrays
>
>>> Apparently this is a no-no.
>
>> 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[] = {};
Note that this actually reserves one char of space for array (objects
cannot have zero size, since different objects must have different
non-overlapping addresses). sizeof(array) is 0.
And anyway, this is an extension - standard C does not allow an empty
initialiser {}. (See the grammar in 6.7.9)
>
> In this form, the array can't be used, other than take its size. But
> someone could later change it to:
>
> int array[] = {10,20,30};
>
> and /recompile/ it. Then it could be used.
That is not "re-using it" - that is having one useless and illegal
declaration completely replaced by legal declaration.
>
> (The original context was multiple string arrays giving 'include'
> search-paths for different C compiler 'hosts'. One of them was a custom
> host with an initially empty set of paths to be filled in by whoever
> compiled the code.)
>
> So there's nothing wrong with the idea (and with a native code target,
> it works perfectly fine).
Yes there is, if you want to target C.
>
>>> Is it any wonder that I usually suppress warnings so that I don't see
>>> them? Anyway, there will be a few less now.
>>>
>>
>> Given that all these issues can be dealt with sensibly, and some of them
>> are clear indications of incorrect code and not just stylistic issues,
>> yes, it is a wonder. It is especially a "wonder" since many of these
>> are just simple standard C.
>>
>> Is it a wonder that /you/ suppress warnings rather than trying to
>> understand what they mean and why they might be indications that there
>> are problems (or at least "opportunities for improvement") in your code?
>
> Out of the 900 lines of warnings in that source file when I used -Wextra
> etc, I only identified one that I knew would give wrong results (but
> would not cause a crash).
I have already given you plenty of examples of incorrect code.
>
> Most of them were pedantic quibbles, given that I knew which platforms
> I'd intended this code to run on, so I wasn't particularly worried.
>
> 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.
When people talk about compiling "cleanly", they usually mean with at
least the common -Wall warnings (and equivalent flags on other
compilers). They will also often mean with the -pedantic flag for gcc
(and again, appropriate flags on other compilers). When they more
robust code, -Wall -Wextra is a common starting point but many of the
-Wextra warnings are liked by some and disliked by others (that's why
they are in -Wextra and not -Wall).
>
> 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 remember DMC battling it out with clang about "=" being used in an
> expression.) The translator doesn't know which C compiler is to be used.
>
>> No, it is par for the course for the way you code and the way you
>> assume that any issues in your programming are the result of bad design
>> of the C language rather than your own errors or misunderstandings.
>
> Yes it is, because I also generate native code for x64 and have none of
> these problems.
>
> With the printf problem, originally I used to generate discrete
> functions calls, so an original source of 'println a', where a is 64-bit
> signed int, would result in:
>
> print_i64(a);
> print_newline();
>
> Then I thought it would be neat if it could generate instead:
>
> printf("%lld\n", a);
>
> Because it would look great in the output. Now you say I should instead
> use:
>
> printf(PRId64 "\n", a);
>
> Just to suppress warnings in pedantic mode, which defeats the purpose of
> my using printf in the first place. No thanks, I'd rather go back to my
> discrete functions.
"Looks great" is not a substitute for "correct".
If you think your discrete functions are correct and look "better" than
correct printf code, then use your discrete functions. There's a fair
chance that they are more efficient too.
>
> (And this is when I translate 'println a'; if instead I directly call
> sprintf() for example from the other language, then PRId64 is not
> available.)
>
> (BTW I've just compiled gcc.c with -Wextra etc, and I get 33,000 lines
> of warnings and notes. That's for a hefty input file, but still... it's
> not exactly 'clean'.)
>
Then you have some work to do.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-02 13:14 +0000 |
| Message-ID | <o6vb7t$kcp$1@dont-email.me> |
| In reply to | #102958 |
On 02/02/2017 12:53, David Brown wrote: > On 02/02/17 13:13, BartC wrote: >> (BTW I've just compiled gcc.c with -Wextra etc, and I get 33,000 lines >> of warnings and notes. That's for a hefty input file, but still... it's >> not exactly 'clean'.) >> > > Then you have some work to do. 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!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-02 14:42 +0100 |
| Message-ID | <o6vcsd$rin$1@dont-email.me> |
| In reply to | #102959 |
On 02/02/17 14:14, BartC wrote: > On 02/02/2017 12:53, David Brown wrote: >> On 02/02/17 13:13, BartC wrote: > >>> (BTW I've just compiled gcc.c with -Wextra etc, and I get 33,000 lines >>> of warnings and notes. That's for a hefty input file, but still... it's >>> not exactly 'clean'.) >>> >> >> Then you have some work to do. > > 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. Of course, if you try to compile "gcc.c" without being part of the normal build process (using your old favourites, ./config and make) then it is unlikely that you will have things like the include directories for headers correct, or appropriate config.h files, or any other flags that might be needed.
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web