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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 12:08 -0800 |
| Message-ID | <6f4a3c6f-a81e-4b75-9be6-67e07f6584af@googlegroups.com> |
| In reply to | #102952 |
On Thursday, February 2, 2017 at 3:31:14 AM UTC-6, David Brown wrote: > Those pesky rules of C, eh? Who would have thought you needed a cast to > void* just because the standards say so? When the Standard was written, a few implementations used different representations for pointers to different types, but many implementations used the same representation for void* as for pointers to all kinds of object. Passing a pointer to a function required casting it to a pointer type whose passed representation would be compatible with the function was expecting, *if the existing type's passed representation was already compatible*. Code which passed an int* to code that expected a char* without a cast could be expected to work on platforms where the passed representations of both types were compatible, but potentially fail in arbitrary fashion on platforms where they were not. If the authors of the Standard had intended to preserve that status quo, would they have written anything other than what they actually wrote? If not, what reason would there be for not interpreting the Standard as extending the existing state of affairs?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-02 21:45 +0100 |
| Message-ID | <o705mv$ird$1@dont-email.me> |
| In reply to | #102976 |
On 02/02/17 21:08, supercat@casperkitty.com wrote: > On Thursday, February 2, 2017 at 3:31:14 AM UTC-6, David Brown wrote: >> Those pesky rules of C, eh? Who would have thought you needed a cast to >> void* just because the standards say so? > > When the Standard was written, a few implementations used different > representations for pointers to different types, but many implementations > used the same representation for void* as for pointers to all kinds of > object. Passing a pointer to a function required casting it to a pointer > type whose passed representation would be compatible with the function was > expecting, *if the existing type's passed representation was already > compatible*. Code which passed an int* to code that expected a char* > without a cast could be expected to work on platforms where the passed > representations of both types were compatible, but potentially fail in > arbitrary fashion on platforms where they were not. > > If the authors of the Standard had intended to preserve that status quo, > would they have written anything other than what they actually wrote? If > not, what reason would there be for not interpreting the Standard as > extending the existing state of affairs? > Repeating your myths, imaginings and misunderstandings does not make them true, no matter how often you try. The possibility of different pointer types having different representations is only one minor reason why different pointer types are incompatible and you need casts in cases like this. Mostly it is about type safety - if you have a pointer to one type of object, and try to use it to access a different kind of object, your code probably has a bug. You can use a cast to tell the compiler that you know what you are doing.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 15:35 -0800 |
| Message-ID | <f9e8a928-46db-4c68-aef5-0dea5872f2e2@googlegroups.com> |
| In reply to | #102979 |
On Thursday, February 2, 2017 at 2:46:07 PM UTC-6, David Brown wrote: > On 02/02/17 21:08, supercat wrote: > > On Thursday, February 2, 2017 at 3:31:14 AM UTC-6, David Brown wrote: > >> Those pesky rules of C, eh? Who would have thought you needed a cast to > >> void* just because the standards say so? > > > > When the Standard was written, a few implementations used different > > representations for pointers to different types, but many implementations > > used the same representation for void* as for pointers to all kinds of > > object.... > > Repeating your myths, imaginings and misunderstandings does not make > them true, no matter how often you try. Your question was "Who would have thought...", so perhaps I should have said "People who took up C programming at a time where many programmers lacked the creativity to imagine why a decent compiler for a hardware platform where a pointer type has the same representation as void* would not behave in predictable fashion if a pointer of that type were passed to code expecting a void*." > The possibility of different pointer types having different > representations is only one minor reason why different pointer types are > incompatible and you need casts in cases like this. Mostly it is about > type safety - if you have a pointer to one type of object, and try to > use it to access a different kind of object, your code probably has a > bug. You can use a cast to tell the compiler that you know what you are > doing. The purpose of a "void*" is to be a "pointer to any type". Passing a pointer to a specific type to code which expects a "pointer to any type" is a normal state of affairs. The fact that a few platforms might in a some circumstances require a void* to be treated differently from other pointer types would be a fair reason not to require that all programmers *who want their code to run on those platforms* must include some casts to void*, but not to require that all programmers must include casts when coding for platforms which would naturally treat the pointers interchangeably.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 15:56 -0800 |
| Message-ID | <lnfujw5eqc.fsf@kst-u.example.com> |
| In reply to | #102994 |
supercat@casperkitty.com writes:
[...]
> The purpose of a "void*" is to be a "pointer to any type".
Do you have a citation for that assertion?
The purpose of void* is to permit a round-trip *conversion* from
foo* to void* and back to yield the original pointer value, for an
object type foo.
That's why assigning a foo* to a void* (or any equivalent operation:
argument passing, initialization, return) *converts* the foo* value to
void*. That code that implements that conversion may or may not be
trivial.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 16:23 -0800 |
| Message-ID | <4062958e-6c63-41f6-90ab-a02063a18a4c@googlegroups.com> |
| In reply to | #102995 |
On Thursday, February 2, 2017 at 5:55:22 PM UTC-6, Keith Thompson wrote: > supercat writes: > [...] > > The purpose of a "void*" is to be a "pointer to any type". > > Do you have a citation for that assertion? The fact that the authors of the Standard allow pointers of other types to be converted to/from void* without a cast, and the fact that the resulting void* can be given to things like memcpy, would tend to suggest that void* was intended to point to things of arbitrary type. > The purpose of void* is to permit a round-trip *conversion* from > foo* to void* and back to yield the original pointer value, for an > object type foo. The behavior of memcpy when given a void* would imply that the void* is not just a container for some bits that will have no meaning until they are converted back to their original type. > That's why assigning a foo* to a void* (or any equivalent operation: > argument passing, initialization, return) *converts* the foo* value to > void*. That code that implements that conversion may or may not be > trivial. It makes sense that bypassing a non-trivial conversion may cause bad things to happen. The question is whether it makes sense to treat trivial conversions likewise.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-03 12:23 -0800 |
| Message-ID | <7e401214-44c8-4003-850c-857c3e2b8c03@googlegroups.com> |
| In reply to | #102995 |
On Thursday, February 2, 2017 at 5:55:22 PM UTC-6, Keith Thompson wrote: > supercat writes: > [...] > > The purpose of a "void*" is to be a "pointer to any type". > > Do you have a citation for that assertion? > > The purpose of void* is to permit a round-trip *conversion* from > foo* to void* and back to yield the original pointer value, for an > object type foo. The qsort() function accepts an argument of type "void*". If the purpose of void* were as you say, that would imply that if I take the address of the first element of a "struct foo[]", convert it to void* and pass that to qsort(), the function would need to somehow convert the pointer back to a "struct foo*" before it could do anything else with it. Can you suggest any plausible means by which qsort() would know that the pointer would need to be converted to a "struct foo*"? Given that N1570 7.22.5.2 says that it sorts an array whose first element is "pointed to by base" [a void*], I'd say that pretty strongly suggests that void pointers "point to" things. Since qsort() would have no way of knowing the type of object to which "base" points, that would suggest that a void* can point to objects of unknown type.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 20:51 +0000 |
| Message-ID | <o72qdm$24m$1@dont-email.me> |
| In reply to | #103075 |
On 03/02/17 20:23, supercat@casperkitty.com wrote: > On Thursday, February 2, 2017 at 5:55:22 PM UTC-6, Keith Thompson wrote: >> supercat writes: >> [...] >>> The purpose of a "void*" is to be a "pointer to any type". >> >> Do you have a citation for that assertion? >> >> The purpose of void* is to permit a round-trip *conversion* from >> foo* to void* and back to yield the original pointer value, for an >> object type foo. > > The qsort() function accepts an argument of type "void*". If the purpose > of void* were as you say, that would imply that if I take the address of > the first element of a "struct foo[]", convert it to void* and pass that > to qsort(), the function would need to somehow convert the pointer back > to a "struct foo*" before it could do anything else with it. No, it can pass it unmodified to another function (and in fact that's precisely what it /does/ do). > Can you > suggest any plausible means by which qsort() would know that the pointer > would need to be converted to a "struct foo*"? Can you suggest any plausible reason why it would need to know? > Given that N1570 7.22.5.2 says that it sorts an array whose first element > is "pointed to by base" [a void*], I'd say that pretty strongly suggests > that void pointers "point to" things. Since qsort() would have no way of > knowing the type of object to which "base" points, that would suggest that > a void* can point to objects of unknown type. Yes, it can. But the /purpose/ is as Keith suggests. Think about qsort a bit harder. What does it do with the void *? It passes it straight to the comparator function, and it is /that/ function that knows that it needs to convert the void * to a struct foo * (or rather, the const void * to a const struct foo *). The qsort function does one other thing with the pointer - it uses the result of the comparator function call to determine whether stuff needs to be swapped around. If so, it either converts the void * to an unsigned char * (which is specifically permitted by the Standard) or, which amounts to the same thing, passes the void * to a function that can do the swapping on its behalf. It seems to me that there are two things that you can do with void * that might reasonably be called its "purpose": 1) make it possible to store pointers to arbitrary objects without having to know their type, *so that* they can later be converted back to the proper pointer type by a function that knows what that pointer type should be; 2) enable a function to access individual bytes of an arbitrary block of memory. These are two uses of void * that are explicitly permitted by the Standard. I don't think there are more (although I could of course be mistaken - I haven't conducted an exhaustive search). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-03 14:16 -0800 |
| Message-ID | <846577bb-c24e-43bc-89b3-3028b9007355@googlegroups.com> |
| In reply to | #103080 |
On Friday, February 3, 2017 at 2:51:49 PM UTC-6, Richard Heathfield wrote: > On 03/02/17 20:23, supercat wrote: > > The qsort() function accepts an argument of type "void*". If the purpose > > of void* were as you say, that would imply that if I take the address of > > the first element of a "struct foo[]", convert it to void* and pass that > > to qsort(), the function would need to somehow convert the pointer back > > to a "struct foo*" before it could do anything else with it. > > No, it can pass it unmodified to another function (and in fact that's > precisely what it /does/ do). Oh really? > The qsort function does one other thing with the pointer - it uses the > result of the comparator function call to determine whether stuff needs > to be swapped around. If so, it either converts the void * to an > unsigned char * (which is specifically permitted by the Standard) or, > which amounts to the same thing, passes the void * to a function that > can do the swapping on its behalf. So it doesn't just pass it to a function that knows the original type, nor convert the pointer to its original type. It relies upon the fact that a pointer to an object of any type can be converted to void* and then to char*, yielding the same result as if the original pointer had been converted directly to char*. > It seems to me that there are two things that you can do with void * > that might reasonably be called its "purpose": > > 1) make it possible to store pointers to arbitrary objects without > having to know their type, *so that* they can later be converted back to > the proper pointer type by a function that knows what that pointer type > should be; > 2) enable a function to access individual bytes of an arbitrary block of > memory. > > These are two uses of void * that are explicitly permitted by the > Standard. I don't think there are more (although I could of course be > mistaken - I haven't conducted an exhaustive search). Is the behavior of qsort() described as acting upon bytes within arbitrary blocks of memory, or as acting upon items within an array?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 22:47 +0000 |
| Message-ID | <o7316h$pdl$1@dont-email.me> |
| In reply to | #103087 |
On 03/02/17 22:16, supercat@casperkitty.com wrote: > On Friday, February 3, 2017 at 2:51:49 PM UTC-6, Richard Heathfield wrote: >> On 03/02/17 20:23, supercat wrote: >>> The qsort() function accepts an argument of type "void*". If the purpose >>> of void* were as you say, that would imply that if I take the address of >>> the first element of a "struct foo[]", convert it to void* and pass that >>> to qsort(), the function would need to somehow convert the pointer back >>> to a "struct foo*" before it could do anything else with it. >> >> No, it can pass it unmodified to another function (and in fact that's >> precisely what it /does/ do). > > Oh really? Yes. >> The qsort function does one other thing with the pointer - it uses the >> result of the comparator function call to determine whether stuff needs >> to be swapped around. If so, it either converts the void * to an >> unsigned char * (which is specifically permitted by the Standard) or, >> which amounts to the same thing, passes the void * to a function that >> can do the swapping on its behalf. > > So it doesn't just pass it to a function that knows the original type, nor > convert the pointer to its original type. It relies upon the fact that a > pointer to an object of any type can be converted to void* and then to > char*, yielding the same result as if the original pointer had been converted > directly to char*. The Standard says (in 6.3.2.3(1)): A pointer to void may be converted to or from a pointer to any object type. A pointer to any object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer. It further says (in 6.3.2.3(7)): When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object. > >> It seems to me that there are two things that you can do with void * >> that might reasonably be called its "purpose": >> >> 1) make it possible to store pointers to arbitrary objects without >> having to know their type, *so that* they can later be converted back to >> the proper pointer type by a function that knows what that pointer type >> should be; (This opinion is based on 6.3.2.3(1).) >> 2) enable a function to access individual bytes of an arbitrary block of >> memory. (This opinion is based on 6.3.2.3(7).) >> >> These are two uses of void * that are explicitly permitted by the >> Standard. I don't think there are more (although I could of course be >> mistaken - I haven't conducted an exhaustive search). > > Is the behavior of qsort() described as acting upon bytes within arbitrary > blocks of memory, or as acting upon items within an array? Can you show me a strictly conforming program that can tell the difference? A pointer to a single object may be legitimately considered to be a pointer to the first and only element in an array of one object, and an array for which one lacks type information can (as long as you know the size, which qsort does) be considered an arbitrary block of memory. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-03 16:38 -0800 |
| Message-ID | <9d311cd1-7437-49cb-b308-f9ba2dff4808@googlegroups.com> |
| In reply to | #103091 |
On Friday, February 3, 2017 at 4:47:28 PM UTC-6, Richard Heathfield wrote: > On 03/02/17 22:16, supercat wrote: > > On Friday, February 3, 2017 at 2:51:49 PM UTC-6, Richard Heathfield wrote: > >> On 03/02/17 20:23, supercat wrote: > >>> The qsort() function accepts an argument of type "void*". If the purpose > >>> of void* were as you say, that would imply that if I take the address of > >>> the first element of a "struct foo[]", convert it to void* and pass that > >>> to qsort(), the function would need to somehow convert the pointer back > >>> to a "struct foo*" before it could do anything else with it. > >> > >> No, it can pass it unmodified to another function (and in fact that's > >> precisely what it /does/ do). > > > > Oh really? > > Yes. The supplied comparator function accepts two pointers of type void*. If the qsort function merely passes the original pointer unmodified (rather than, say, converting it to a char*, adding the offset to the desired element, and then converting that back to a void*), how is the comparator function supposed to know which parts of the array are supposed to be compared? Note that as with functions like atoi(), there's nothing "special" about qsort() which should preclude its implementation in "ordinary" C code. > >> The qsort function does one other thing with the pointer - it uses the > >> result of the comparator function call to determine whether stuff needs > >> to be swapped around. If so, it either converts the void * to an > >> unsigned char * (which is specifically permitted by the Standard) or, > >> which amounts to the same thing, passes the void * to a function that > >> can do the swapping on its behalf. > > So it doesn't just pass it to a function that knows the original type, nor > > convert the pointer to its original type. It relies upon the fact that a > > pointer to an object of any type can be converted to void* and then to > > char*, yielding the same result as if the original pointer had been converted > > directly to char*. > > The Standard says (in 6.3.2.3(1)): > > A pointer to void may be converted to or from a pointer to any object > type. A pointer to any object type may be converted to a pointer to void > and back again; the result shall compare equal to the original pointer. > > It further says (in 6.3.2.3(7)): > > When a pointer to an object is converted to a pointer to a character > type, the result points to the lowest addressed byte of the object. > Successive increments of the result, up to the size of the object, yield > pointers to the remaining bytes of the object. The Standard fails to explicitly mandate all of the behaviors that would be necessary to make void* useful. Whether that is a "defect" would depend upon whether any compiler writers would exploit such omissions either for reasons of optimization or obtuseness. Many useful kinds of code can only work if converting a pointer to void* and then to char* yields a pointer to the first character of the original object. That behavior was consistent among compilers that supported void* prior to the C89 Standard, and I see no reason to believe the Standard was intended to allow anything else. I've seen no indication that qsort() was not expected to be typical of what could be accomplished with user code. > >> These are two uses of void * that are explicitly permitted by the > >> Standard. I don't think there are more (although I could of course be > >> mistaken - I haven't conducted an exhaustive search). > > > > Is the behavior of qsort() described as acting upon bytes within arbitrary > > blocks of memory, or as acting upon items within an array? > > Can you show me a strictly conforming program that can tell the > difference? A pointer to a single object may be legitimately considered > to be a pointer to the first and only element in an array of one object, > and an array for which one lacks type information can (as long as you > know the size, which qsort does) be considered an arbitrary block of memory. The terminology used in the Standard's definition of qsort suggests that the "base" is a pointer to an array of objects of arbitrary type. While it might *also* be regarded as a pointer to a region of bytes, the fact that the Standard uses the former terminology would suggest that it can hardly be called "wrong".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-04 00:47 +0000 |
| Message-ID | <o73886$hfp$1@dont-email.me> |
| In reply to | #103101 |
On 04/02/17 00:38, supercat@casperkitty.com wrote: > On Friday, February 3, 2017 at 4:47:28 PM UTC-6, Richard Heathfield wrote: >> On 03/02/17 22:16, supercat wrote: >>> On Friday, February 3, 2017 at 2:51:49 PM UTC-6, Richard Heathfield wrote: >>>> On 03/02/17 20:23, supercat wrote: >>>>> The qsort() function accepts an argument of type "void*". If the purpose >>>>> of void* were as you say, that would imply that if I take the address of >>>>> the first element of a "struct foo[]", convert it to void* and pass that >>>>> to qsort(), the function would need to somehow convert the pointer back >>>>> to a "struct foo*" before it could do anything else with it. >>>> >>>> No, it can pass it unmodified to another function (and in fact that's >>>> precisely what it /does/ do). >>> >>> Oh really? >> >> Yes. > > The supplied comparator function accepts two pointers of type void*. If > the qsort function merely passes the original pointer unmodified (rather > than, say, converting it to a char*, adding the offset to the desired > element, and then converting that back to a void*), how is the comparator > function supposed to know which parts of the array are supposed to be > compared? Oh yes, of course. Pointer arithmetic. It can do this because of the explicit guarantee in 6.3.2.3(7), which I already discussed. In fact, I already mentioned this in the following paragraph: >>>> The qsort function does one other thing with the pointer - it uses the >>>> result of the comparator function call to determine whether stuff needs >>>> to be swapped around. If so, it either converts the void * to an >>>> unsigned char * (which is specifically permitted by the Standard) or, >>>> which amounts to the same thing, passes the void * to a function that >>>> can do the swapping on its behalf. See? >>> So it doesn't just pass it to a function that knows the original type, nor >>> convert the pointer to its original type. It relies upon the fact that a >>> pointer to an object of any type can be converted to void* and then to >>> char*, yielding the same result as if the original pointer had been converted >>> directly to char*. >> >> The Standard says (in 6.3.2.3(1)): >> >> A pointer to void may be converted to or from a pointer to any object >> type. A pointer to any object type may be converted to a pointer to void >> and back again; the result shall compare equal to the original pointer. >> >> It further says (in 6.3.2.3(7)): >> >> When a pointer to an object is converted to a pointer to a character >> type, the result points to the lowest addressed byte of the object. >> Successive increments of the result, up to the size of the object, yield >> pointers to the remaining bytes of the object. > > The Standard fails to explicitly mandate all of the behaviors that would be > necessary to make void* useful. Not convinced. > Whether that is a "defect" would depend upon > whether any compiler writers would exploit such omissions either for reasons > of optimization or obtuseness. > > Many useful kinds of code can only work if converting a pointer to void* > and then to char* yields a pointer to the first character of the original > object. 6.3.2.3(1) guarantees it. >>> Is the behavior of qsort() described as acting upon bytes within arbitrary >>> blocks of memory, or as acting upon items within an array? >> >> Can you show me a strictly conforming program that can tell the >> difference? A pointer to a single object may be legitimately considered >> to be a pointer to the first and only element in an array of one object, >> and an array for which one lacks type information can (as long as you >> know the size, which qsort does) be considered an arbitrary block of memory. > > The terminology used in the Standard's definition of qsort suggests that > the "base" is a pointer to an array of objects of arbitrary type. While > it might *also* be regarded as a pointer to a region of bytes, the fact > that the Standard uses the former terminology would suggest that it can > hardly be called "wrong". Neither explanation is wrong, because as far as C is concerned they're isomorphic. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-03 18:34 -0800 |
| Message-ID | <lnfuju4rba.fsf@kst-u.example.com> |
| In reply to | #103101 |
supercat@casperkitty.com writes:
> On Friday, February 3, 2017 at 4:47:28 PM UTC-6, Richard Heathfield wrote:
>> On 03/02/17 22:16, supercat wrote:
>> > On Friday, February 3, 2017 at 2:51:49 PM UTC-6, Richard Heathfield wrote:
>> >> On 03/02/17 20:23, supercat wrote:
>> >>> The qsort() function accepts an argument of type "void*". If the
>> >>> purpose of void* were as you say, that would imply that if I take
>> >>> the address of the first element of a "struct foo[]", convert it
>> >>> to void* and pass that to qsort(), the function would need to
>> >>> somehow convert the pointer back to a "struct foo*" before it
>> >>> could do anything else with it.
>> >>
>> >> No, it can pass it unmodified to another function (and in fact that's
>> >> precisely what it /does/ do).
>> >
>> > Oh really?
>>
>> Yes.
>
> The supplied comparator function accepts two pointers of type void*. If
> the qsort function merely passes the original pointer unmodified (rather
> than, say, converting it to a char*, adding the offset to the desired
> element, and then converting that back to a void*), how is the comparator
> function supposed to know which parts of the array are supposed to be
> compared?
You're pointing out that the void* pointers passed from qsort() to the
comparator function have to be computed from the array base pointer by
adding an offset.
You could have just said so without a long-winded rhetorical question.
In fact, perhaps you could just go ahead and make whatever point you're
trying to make.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-04 11:02 -0800 |
| Message-ID | <507fd86a-1749-4030-8a39-62f03858b5e1@googlegroups.com> |
| In reply to | #103115 |
On Friday, February 3, 2017 at 8:33:56 PM UTC-6, Keith Thompson wrote: > You're pointing out that the void* pointers passed from qsort() to the > comparator function have to be computed from the array base pointer by > adding an offset. You were adamant that the only operation supported with void pointers was round-tripping to the original type. I was hoping to nudge you in the direction of recognizing that the qsort() function would obviously have to do something that would require something other than a round-trip cast to the original type. My original point in any event was that the authors of the C Standard decided that void*, unlike unsigned char*, should be implicitly convertible to other pointer types without a need for a cast in cases where a such conversions could easily be handled on all platforms. This makes "void*" more usable than "unsigned char*" when using functions that need to accept a pointer to an object of arbitrary type. On a small number of C89 platforms, it would be almost impossible to maintain compatibility with existing code while allowing pointers of types other than void* to be passed to functions which expect void* but don't have a prototype saying so. The authors of the C89 Standard didn't want to mandate that compilers abandon compatibility with existing code, so they allow for the possibility that a conforming implementation may fail if a cast is not used. The inconsistency in the behavior of printf vs almost every other functiont that accepts pointers is not borne out of semantics, but technical necessity with a few C89 platforms. I would be interested to know if there are any C99 implementations for platforms that include the same technical limitations (and likewise if there are any C99 or C11 implementations for any systems whose integer sizes are not powers of two). I suspect most of the technical concessions that the Committee made in C89 have ceased to be relevant decades ago.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-04 13:18 -0800 |
| Message-ID | <lnwpd53b9s.fsf@kst-u.example.com> |
| In reply to | #103160 |
supercat@casperkitty.com writes:
> On Friday, February 3, 2017 at 8:33:56 PM UTC-6, Keith Thompson wrote:
>> You're pointing out that the void* pointers passed from qsort() to the
>> comparator function have to be computed from the array base pointer by
>> adding an offset.
>
> You were adamant that the only operation supported with void pointers was
> round-tripping to the original type. I was hoping to nudge you in the
> direction of recognizing that the qsort() function would obviously have to
> do something that would require something other than a round-trip cast to
> the original type.
I see. For future reference, if you have a point to make, just make it.
If I've missed something (and it happens), it's a lot easier just to
point it out rather than trying to nudge me in the right direction.
[...]
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-02-04 21:27 +0000 |
| Message-ID | <o75gvm$el1$1@news.xmission.com> |
| In reply to | #103168 |
In article <lnwpd53b9s.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: >supercat@casperkitty.com writes: >> On Friday, February 3, 2017 at 8:33:56 PM UTC-6, Keith Thompson wrote: >>> You're pointing out that the void* pointers passed from qsort() to the >>> comparator function have to be computed from the array base pointer by >>> adding an offset. >> >> You were adamant that the only operation supported with void pointers was >> round-tripping to the original type. I was hoping to nudge you in the >> direction of recognizing that the qsort() function would obviously have to >> do something that would require something other than a round-trip cast to >> the original type. > >I see. For future reference, if you have a point to make, just make it. >If I've missed something (and it happens), it's a lot easier just to >point it out rather than trying to nudge me in the right direction. Because, and don't you (*) ever forget it, I run this newsgroup. (*) Or anyone else... -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/EternalFlame
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-04 10:04 -0800 |
| Message-ID | <kfnmve196je.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #102995 |
Keith Thompson <kst-u@mib.org> writes: > supercat@casperkitty.com writes: > [...] >> The purpose of a "void*" is to be a "pointer to any type". > > Do you have a citation for that assertion? > > The purpose of void* is to permit a round-trip *conversion* from > foo* to void* and back to yield the original pointer value, for an > object type foo. That is a purpose. It is not the only purpose.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 12:46 -0800 |
| Message-ID | <lnwpd85nji.fsf@kst-u.example.com> |
| In reply to | #102976 |
supercat@casperkitty.com writes:
> On Thursday, February 2, 2017 at 3:31:14 AM UTC-6, David Brown wrote:
>> Those pesky rules of C, eh? Who would have thought you needed a cast to
>> void* just because the standards say so?
>
> When the Standard was written, a few implementations used different
> representations for pointers to different types, but many implementations
> used the same representation for void* as for pointers to all kinds of
> object. Passing a pointer to a function required casting it to a pointer
> type whose passed representation would be compatible with the function was
> expecting, *if the existing type's passed representation was already
> compatible*. Code which passed an int* to code that expected a char*
> without a cast could be expected to work on platforms where the passed
> representations of both types were compatible, but potentially fail in
> arbitrary fashion on platforms where they were not.
>
> If the authors of the Standard had intended to preserve that status quo,
> would they have written anything other than what they actually wrote? If
> not, what reason would there be for not interpreting the Standard as
> extending the existing state of affairs?
Currently, the standard says that passing a pointer of one type to a
function expecting a pointer of a different type has undefined behavior.
It could have said that such code has well defined behavior if the two
pointer types have the same representation, perhaps with some added
wording about alignment. This would relevant only in cases that aren't
constraint violations, such as where there's a visible non-variadic
prototype for the called function (unless you want to loosen those
rules).
Of course any implementation can make that guarantee if it chooses to
do so.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 14:12 -0800 |
| Message-ID | <dd875ad6-ecde-434a-a609-fea3239efa77@googlegroups.com> |
| In reply to | #102980 |
On Thursday, February 2, 2017 at 2:46:10 PM UTC-6, Keith Thompson wrote: > supercat writes: > > If the authors of the Standard had intended to preserve that status quo, > > would they have written anything other than what they actually wrote? If > > not, what reason would there be for not interpreting the Standard as > > extending the existing state of affairs? > > Currently, the standard says that passing a pointer of one type to a > function expecting a pointer of a different type has undefined behavior. > > It could have said that such code has well defined behavior if the two > pointer types have the same representation, perhaps with some added > wording about alignment. This would relevant only in cases that aren't > constraint violations, such as where there's a visible non-variadic > prototype for the called function (unless you want to loosen those > rules). The Standard could have specified that, but having rules which guaranteed behavior on some platforms but not others might have been seen as reflecting negatively on the platforms that worked differently--something the authors of the Standard seem to have bent over backward to avoid doing. The dominant case by far where code would rely upon such behavior would be when passing a pointer of a particular type to a function which expects a void*, which would be permissible without a cast in cases where the prototype is in scope. > Of course any implementation can make that guarantee if it chooses to > do so. Many platforms document how pointers are represented. In cases where all pointers share the same representation, this will naturally make it easier for a compiler to act in a way consistent with many useful behavioral guarantees, than for it to do anything else. For a long time after C89 was published, one could reasonably expect that when the characteristics of a system suggested useful natural behaviors, compiler writers would not go out of their way to break code that exploited them. There was no perceived need for compiler writers to explicitly promise not to do things that would have been recognized as silly.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-02 15:21 -0800 |
| Message-ID | <lnk2985gc8.fsf@kst-u.example.com> |
| In reply to | #102984 |
supercat@casperkitty.com writes:
[...]
> The Standard could have specified that, but having rules which
> guaranteed behavior on some platforms but not others might have been
> seen as reflecting negatively on the platforms that worked
> differently--something the authors of the Standard seem to have bent
> over backward to avoid doing. The dominant case by far where code
> would rely upon such behavior would be when passing a pointer of a
> particular type to a function which expects a void*, which would be
> permissible without a cast in cases where the prototype is in scope.
[...]
What? In such cases the pointer is converted.
void func(void *param);
int *p = NULL;
func(p);
The value of p is converted from int* to void*. On some systems, that
conversion is trivial; on others it might not be.
Are you talking about having such a call without a visible prototype?
In that case, there would still have to be a visible non-prototype
declaration -- and the behavior would be undefined. So don't do that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-02 16:02 -0800 |
| Message-ID | <acdc3cab-a5c4-466d-bf4a-bba66b0e417a@googlegroups.com> |
| In reply to | #102993 |
On Thursday, February 2, 2017 at 5:20:49 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> [...]
> > The Standard could have specified that, but having rules which
> > guaranteed behavior on some platforms but not others might have been
> > seen as reflecting negatively on the platforms that worked
> > differently--something the authors of the Standard seem to have bent
> > over backward to avoid doing. The dominant case by far where code
> > would rely upon such behavior would be when passing a pointer of a
> > particular type to a function which expects a void*, which would be
> > permissible without a cast in cases where the prototype is in scope.
> [...]
>
> What? In such cases the pointer is converted.
>
> void func(void *param);
>
> int *p = NULL;
> func(p);
>
> The value of p is converted from int* to void*. On some systems, that
> conversion is trivial; on others it might not be.
In the days before prototypes, some implementations would require that the
argument to functions like memcpy be converted to void* (or before that
type existed, to char*), but most implementations would work just fine
without the cast. If a cast between a T* and a void* doesn't generate
any code, having a system treat
void test();
void test2() { test(&someInteger); }
void test(p)
void *p;
{...}
as synonymous with:
void test2() { test((void*)&someInteger); } // All other lines equal
would have been regarded as a useful feature on platforms where it was
practical to provide it.
> Are you talking about having such a call without a visible prototype?
> In that case, there would still have to be a visible non-prototype
> declaration -- and the behavior would be undefined. So don't do that.
It would have failed with pointer types that required a non-trivial
conversion but been reliable on those that don't. I have no trouble with
saying that the cast is required in the 0.001% of code that will ever
be called to run on an implementation where the cast would require a
non-trivial conversion.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web