Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60126 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2015-04-16 13:08 +0200 |
| Last post | 2015-04-18 08:11 -0700 |
| Articles | 20 on this page of 192 — 30 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Problems with va_list & friends... Philipp Klaus Krause <pkk@spth.de> - 2015-04-16 13:08 +0200
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-16 12:14 -0500
Re: Problems with va_list & friends... gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-16 17:18 +0000
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 18:43 +0100
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-16 21:03 -0500
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-16 23:38 -0400
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-17 07:39 +0100
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 13:31 -0500
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-17 14:46 -0400
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 11:46 -0700
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-18 15:35 -0700
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:57 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-19 11:58 +0100
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-20 10:50 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 17:55 +0100
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-17 23:01 -0500
Re: Problems with va_list & friends... Robert Wessel <robertwessel2@yahoo.com> - 2015-04-18 00:24 -0500
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-18 07:50 -0400
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 11:56 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-19 14:59 +0100
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-19 11:47 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-19 18:44 +0100
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-19 18:34 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 01:42 -0700
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 08:14 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 10:30 -0700
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 13:56 -0400
Re: Problems with va_list & friends... Ian Pilcher <arequipeno@gmail.com> - 2015-04-20 18:39 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-23 12:37 -0700
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-23 20:25 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:58 -0700
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-24 12:58 -0500
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-24 22:13 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-28 13:05 -0700
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-30 08:40 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 08:40 -0700
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-05-03 11:42 -0500
Re: Problems with va_list & friends... Ian Collins <ian-news@hotmail.com> - 2015-05-04 17:43 +1200
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-05-04 07:34 -0500
Re: Problems with va_list & friends... Phil Carmody <pc+usenet@asdf.org> - 2015-05-08 17:12 +0300
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 07:40 -0700
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-05-04 08:49 -0700
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-05-04 12:23 -0500
Re: Problems with va_list & friends... Les Cargill <lcargill99@comcast.com> - 2015-04-20 07:49 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 14:27 +0100
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-20 09:39 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 17:48 +0100
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-20 15:58 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 22:25 +0100
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 13:22 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 11:15 -0700
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 15:02 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 12:51 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 21:17 +0100
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-20 16:09 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 00:33 +0100
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 16:26 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 15:46 -0700
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-20 16:17 -0700
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-21 07:43 -0700
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-21 08:06 -0700
Re: Problems with va_list & friends... Philip Lantz <prl@canterey.us> - 2015-04-22 21:55 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 20:04 +0100
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 13:22 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 21:42 +0100
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 16:58 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 01:16 +0100
Re: Problems with va_list & friends... Melzzzzz <mel@zzzzz.com> - 2015-04-21 02:19 +0200
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-20 23:14 -0700
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-21 11:47 -0400
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-22 00:13 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 08:36 +0100
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-22 03:15 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 11:52 +0100
Re: Problems with va_list & friends... Öö Tiib <ootiib@hot.ee> - 2015-04-22 09:04 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 17:14 +0100
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-20 15:24 -0700
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-21 00:24 -0500
Re: Problems with va_list & friends... raltbos@xs4all.nl (Richard Bos) - 2015-04-21 09:33 +0000
Re: Problems with va_list & friends... gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-21 11:57 +0000
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-21 10:22 -0500
The Metric system (Was: Problems with va_list & friends...) gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-21 15:38 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-21 15:58 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-21 18:09 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-21 17:42 +0000
Re: The Metric system (Was: Problems with va_list & friends...) David Brown <david.brown@hesbynett.no> - 2015-04-22 10:47 +0200
Re: The Metric system (Was: Problems with va_list & friends...) Ian Collins <ian-news@hotmail.com> - 2015-04-22 20:56 +1200
Re: The Metric system (Was: Problems with va_list & friends...) guinness.tony@gmail.com - 2015-04-22 03:53 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-22 11:01 -0500
Re: The Metric system (Was: Problems with va_list & friends...) gwowen <gwowen@gmail.com> - 2015-04-23 08:17 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 10:21 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-22 11:17 -0500
Re: The Metric system (Was: Problems with va_list & friends...) David Kleinecke <dkleinecke@gmail.com> - 2015-04-22 09:59 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-22 18:48 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-22 14:35 -0500
Re: The Metric system Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-22 21:22 +0100
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-25 09:58 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-25 12:33 +0100
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-25 12:18 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-25 13:51 +0100
Re: The Metric system (Was: Problems with va_list & friends...) David Brown <david.brown@hesbynett.no> - 2015-04-25 16:34 +0200
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-25 17:00 +0100
Re: The Metric system (Was: Problems with va_list & friends...) gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-25 16:59 +0000
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-28 16:04 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 04:22 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Martin Shobe <martin.shobe@yahoo.com> - 2015-04-30 09:27 -0500
Re: The Metric system (Was: Problems with va_list & friends...) Robert Wessel <robertwessel2@yahoo.com> - 2015-04-30 12:01 -0500
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-30 13:38 +0100
Re: The Metric system (Was: Problems with va_list & friends...) David Brown <david.brown@hesbynett.no> - 2015-04-25 16:36 +0200
Re: The Metric system (Was: Problems with va_list & friends...) Ian Collins <ian-news@hotmail.com> - 2015-04-26 08:20 +1200
Re: The Metric system (Was: Problems with va_list & friends...) "Bill Davy" <Bill@SynectixLtd.com> - 2015-04-25 21:33 +0100
Re: The Metric system (Was: Problems with va_list & friends...) David Brown <david.brown@hesbynett.no> - 2015-04-26 12:07 +0200
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-26 14:22 +0100
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-26 15:44 +0000
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-22 13:11 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Robert Wessel <robertwessel2@yahoo.com> - 2015-04-22 17:05 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-22 18:30 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-22 17:35 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-22 19:15 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-23 11:05 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-23 12:54 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-23 14:12 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-23 15:50 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-23 16:43 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-23 18:09 -0400
Re: The Metric system (Was: Problems with va_list & friends...) "Osmium" <r124c4u102@comcast.net> - 2015-04-22 13:15 -0500
Re: The Metric system (Was: Problems with va_list & friends...) gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-22 19:17 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 20:48 +0100
Re: The Metric system (Was: Problems with va_list & friends...) "Osmium" <r124c4u102@comcast.net> - 2015-04-23 08:11 -0500
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-23 12:58 -0400
Re: The Metric system (Was: Problems with va_list & friends...) Robert Wessel <robertwessel2@yahoo.com> - 2015-04-23 14:13 -0500
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:08 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-22 17:15 -0500
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-25 09:18 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-25 13:02 -0500
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-26 14:26 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Philip Lantz <prl@canterey.us> - 2015-05-03 11:48 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-05-05 18:20 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-05-05 12:43 -0500
Re: The Metric system (Was: Problems with va_list & friends...) Bartc <bc@freeuk.com> - 2015-04-22 11:32 +0100
Re: The Metric system (Was: Problems with va_list & friends...) "Bill Davy" <Bill@SynectixLtd.com> - 2015-04-22 14:31 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Ian Collins <ian-news@hotmail.com> - 2015-04-23 07:51 +1200
Re: The Metric system (Was: Problems with va_list & friends...) "Bill Davy" <Bill@SynectixLtd.com> - 2015-04-23 08:05 +0100
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:10 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-26 09:27 +0100
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-26 10:55 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Morris Dovey <mrdovey@iedu.com> - 2015-04-26 07:19 -0500
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-26 12:59 +0000
Re: The Metric system (Was: Problems with va_list & friends...) gwowen <gwowen@gmail.com> - 2015-04-28 07:07 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Morris Dovey <mrdovey@iedu.com> - 2015-04-28 09:51 -0500
Re: The Metric system (Was: Problems with va_list & friends...) guinness.tony@gmail.com - 2015-04-28 08:04 -0700
Re: The Metric system (Was: Problems with va_list & friends...) Richard Heathfield <rjh@cpax.org.uk> - 2015-04-28 16:19 +0100
Re: The Metric system (Was: Problems with va_list & friends...) Les Cargill <lcargill99@comcast.com> - 2015-04-28 19:15 -0500
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-28 16:06 +0000
Re: The Metric system (Was: Problems with va_list & friends...) guinness.tony@gmail.com - 2015-04-28 09:39 -0700
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-28 16:51 +0000
Re: The Metric system (Was: Problems with va_list & friends...) guinness.tony@gmail.com - 2015-04-29 05:08 -0700
Re: The Metric system (Was: Problems with va_list & friends...) raltbos@xs4all.nl (Richard Bos) - 2015-04-29 13:47 +0000
Re: The Metric system (Was: Problems with va_list & friends...) James Kuyper <jameskuyper@verizon.net> - 2015-04-28 13:03 -0400
Re: The Metric system (Was: Problems with va_list & friends...) David Thompson <dave.thompson2@verizon.net> - 2015-05-10 12:24 -0400
Re: The Metric system (Was: Problems with va_list & friends...) gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-21 18:12 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-21 19:34 +0000
Re: The Metric system (Was: Problems with va_list & friends...) Stephen Sprunk <stephen@sprunk.org> - 2015-04-21 12:46 -0500
Re: The Metric system (Was: Problems with va_list & friends...) Ian Collins <ian-news@hotmail.com> - 2015-04-22 07:42 +1200
Re: The Metric system (Was: Problems with va_list & friends...) Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-21 20:13 +0000
Re: The Metric system (Was: Problems with va_list & friends...) David Brown <david.brown@hesbynett.no> - 2015-04-22 10:52 +0200
Re: The Metric system (Was: Problems with va_list & friends...) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 09:18 -0700
Re: Problems with va_list & friends... raltbos@xs4all.nl (Richard Bos) - 2015-04-21 22:25 +0000
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-23 15:59 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-23 11:51 -0700
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-23 11:26 -0700
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-20 16:15 -0500
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 17:23 -0400
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 13:17 -0400
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-20 15:26 -0500
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-20 16:15 -0700
Re: Problems with va_list & friends... Stephen Sprunk <stephen@sprunk.org> - 2015-04-21 00:42 -0500
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 11:15 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 21:50 +0100
Re: Problems with va_list & friends... James Kuyper <jameskuyper@verizon.net> - 2015-04-20 17:04 -0400
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 08:22 -0700
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-19 18:23 +0100
Re: Problems with va_list & friends... Keith Thompson <kst-u@mib.org> - 2015-04-19 13:22 -0700
Re: Problems with va_list & friends... Robert Wessel <robertwessel2@yahoo.com> - 2015-04-19 21:51 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 10:01 +0100
Re: Problems with va_list & friends... Robert Wessel <robertwessel2@yahoo.com> - 2015-04-20 05:08 -0500
Re: Problems with va_list & friends... Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 11:37 +0100
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-23 20:13 -0700
Re: Problems with va_list & friends... Philipp Klaus Krause <pkk@spth.de> - 2015-04-18 09:15 +0200
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 12:13 -0700
Re: Problems with va_list & friends... Richard Damon <Richard@Damon-Family.org> - 2015-04-16 23:40 -0400
Re: Problems with va_list & friends... Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 08:11 -0700
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-04-21 18:12 +0000 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <mh63vb$d6s$3@news.xmission.com> |
| In reply to | #60655 |
In article <psuZw.31252$5b5.12618@fx02.iad>,
Greg Martin <greg.at.softsprocket@dot.com> wrote:
...
>We did switch and a long time ago. I can't think of any area where
>imperial measurements are used though some of us of a certain age may
>have mentally flip-flopped at times. If you are under 40 and Canadian I
>doubt you would have used imperial measure for anything.
I assume you are Canadian?
Anyway, I am basing my comments on three things:
1) https://en.wikipedia.org/wiki/Metrication_in_Canada
which starts out saying:
* Canada has converted to the metric system for many purposes but
* there is still significant use of non-metric units and standards in
* many sectors of the Canadian economy.
The article goes on to list many of the areas where Canadians use
imperial units, such as feet for altitude (in aviation) and
Fahrenheit for temperature in cooking.
2) The knowledge that the Canadian economy and the US economy are tightly
interwoven, and that, as a matter of practicality, concessions have
to be made.
3) A certain TV show that I watch, which is produced in Canada and is
about truck driving in Canada, always refers to truck weights in
pounds. I think they also sometimes use miles for distance,
although, of course, kilometers are usually used.
Also, as you say, it seems to be an age thing. Older people and rural
people (which ends up meaning, people in the western provinces) are more
likely to use the older units than are younger people in the more urban
areas.
--
Modern Conservative: Someone who can take time out from flashing her
wedding ring around and bragging about her honeymoon to complain that a
fellow secretary who keeps a picture of her girlfriend on her desk is
"flauting her sexuality" and "forcing her lifestyle down our throats".
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-04-21 19:34 +0000 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <MCxZw.265367$pp5.159443@fx29.iad> |
| In reply to | #60668 |
On 2015-04-21, Kenny McCormack <gazelle@shell.xmission.com> wrote: > In article <psuZw.31252$5b5.12618@fx02.iad>, > Greg Martin <greg.at.softsprocket@dot.com> wrote: > ... >>We did switch and a long time ago. I can't think of any area where >>imperial measurements are used though some of us of a certain age may >>have mentally flip-flopped at times. If you are under 40 and Canadian I >>doubt you would have used imperial measure for anything. > > I assume you are Canadian? > > Anyway, I am basing my comments on three things: > > 1) https://en.wikipedia.org/wiki/Metrication_in_Canada > which starts out saying: > > * Canada has converted to the metric system for many purposes but > * there is still significant use of non-metric units and standards in > * many sectors of the Canadian economy. > > The article goes on to list many of the areas where Canadians use > imperial units, such as feet for altitude (in aviation) and > Fahrenheit for temperature in cooking. > > 2) The knowledge that the Canadian economy and the US economy are tightly > interwoven, and that, as a matter of practicality, concessions have > to be made. > > 3) A certain TV show that I watch, which is produced in Canada and is > about truck driving in Canada, always refers to truck weights in > pounds. I think they also sometimes use miles for distance, > although, of course, kilometers are usually used. > > Also, as you say, it seems to be an age thing. Older people and rural > people (which ends up meaning, people in the western provinces) are more > likely to use the older units than are younger people in the more urban > areas. > It is very much an age thing but also a linguistic twist. I'd never heard of metric as a child and when we switched had to rethink the lot and it takes a while to stop converting in your head. Linguistically speaking I still go to the store for a quart of milk even though it's a litre. I might talk about having a pint of beer but it is unlikely to be 16oz. I remember buying apples by the bushel or peck but never see those measures in the stores anymore but I think that's a different change. We've gone from a largely rural to a largely urban population in my lifetime. The Canadian gallon was the imperial, not US, measure but I don't think people think in gallons at all anymore. Generally, I don't know how far things are from me in miles though I might say, 'a couple of miles down the road', out of habit. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-21 12:46 -0500 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <mh62bf$ima$1@dont-email.me> |
| In reply to | #60650 |
On 21-Apr-15 10:38, Kenny McCormack wrote: > In article <mh5pu1$el9$1@dont-email.me>, Stephen Sprunk > <stephen@sprunk.org> wrote: .... >>> For example, the US's insistence on not using the metric system. >> >> That's more legislative neglect than insistence: Congress feels >> such things are best left to industry to decide, and industry is >> (so far) unwilling to take the short-term hit in return for >> long-term gains. > > Kinda "You say tomaytoe, I say tomahtoe". My view is that industry > is by nature and certainly by recent (since Reagan) US practice so > short sighted that they simply don't see any reason to switch. Why > take the hit? > > Incidentally, Canada almost succeeded in switching, but failed > because of the great influence US practice has on their policies. > The result is an ugly mishmash, where some things are quoted in > metric and other things are quoted in US units. The US is undoubtedly the worst offender, but to be fair, we're not alone in our failure, e.g. the UK requiring selling beer in pints. The US govt actually established an agency to promote metrication back in the 1970s, but it now has only one employee due to budget cuts... NIST does publish guidance for other agencies on _how_ to metricate; they just don't have the authority to force them to do so. > It must be very confusing for them... That's what happens when your only neighbor and biggest trading partner is nearly ten times your size, especially when >90% of your population lives within an hour of that border and most speak the same language; under such conditions, it's difficult to remain culturally distinct, and that includes the weights and measures used in common speech. OTOH, if not for Canada, few Merkins would have any contact with the metric system at all. 77% of Merkins don't even have a passport, but we can go to/from Canada without one by land/water--though it's not as easy as it used to be. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-22 07:42 +1200 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <cpnng8FsioeU2@mid.individual.net> |
| In reply to | #60667 |
Stephen Sprunk wrote: > On 21-Apr-15 10:38, Kenny McCormack wrote: >> >> Incidentally, Canada almost succeeded in switching, but failed >> because of the great influence US practice has on their policies. >> The result is an ugly mishmash, where some things are quoted in >> metric and other things are quoted in US units. > > The US is undoubtedly the worst offender, but to be fair, we're not > alone in our failure, e.g. the UK requiring selling beer in pints. Pint is the standard beer drinker's unit. Metric beer doesn't taste the same! Even down here were the local gassy fizz is sold in 500ml glasses, the locals still cal them "pints". Very confusing for up poor poms. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-04-21 20:13 +0000 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <%byZw.84337$fV3.27602@fx25.iad> |
| In reply to | #60680 |
On 2015-04-21, Ian Collins <ian-news@hotmail.com> wrote: > Stephen Sprunk wrote: >> On 21-Apr-15 10:38, Kenny McCormack wrote: >>> >>> Incidentally, Canada almost succeeded in switching, but failed >>> because of the great influence US practice has on their policies. >>> The result is an ugly mishmash, where some things are quoted in >>> metric and other things are quoted in US units. >> >> The US is undoubtedly the worst offender, but to be fair, we're not >> alone in our failure, e.g. the UK requiring selling beer in pints. > > Pint is the standard beer drinker's unit. Metric beer doesn't taste the > same! Even down here were the local gassy fizz is sold in 500ml > glasses, the locals still cal them "pints". Very confusing for up poor > poms. > Here in Canada we now use the terms pint and pub but in true Canadianese it was mug and bar. I'm not sure but they may be falling from the mother tongue. I grew up with mug (16oz) and glass (12oz) as the measure of beer served in either a bar or a lounge. That was Ontario and it was likely different elsewhere in Canada. Those terms may have gone the way of the stubby - the 12 oz bottle ubiquous at the time. Here on the west coast it's pint or half or maybe sleeve but the actually measure of beer could be anything, or so it seems. Even bottles don't seemed completely standardized though most (maybe not all) cans seem to be 355ml. Oh well, 'do you want a beer', still gets it done. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-22 10:52 +0200 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <mh7nea$55l$2@dont-email.me> |
| In reply to | #60680 |
On 21/04/15 21:42, Ian Collins wrote: > Stephen Sprunk wrote: >> On 21-Apr-15 10:38, Kenny McCormack wrote: >>> >>> Incidentally, Canada almost succeeded in switching, but failed >>> because of the great influence US practice has on their policies. >>> The result is an ugly mishmash, where some things are quoted in >>> metric and other things are quoted in US units. >> >> The US is undoubtedly the worst offender, but to be fair, we're not >> alone in our failure, e.g. the UK requiring selling beer in pints. > > Pint is the standard beer drinker's unit. Metric beer doesn't taste the > same! Even down here were the local gassy fizz is sold in 500ml > glasses, the locals still cal them "pints". Very confusing for up poor > poms. > There is one big advantage of metric beer - a half-litre is the standard size (for draught), but there is no equivalent to a half-pint!
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 09:18 -0700 |
| Subject | Re: The Metric system (Was: Problems with va_list & friends...) |
| Message-ID | <61ee5ece-d60f-4e08-a946-e4d54245a205@googlegroups.com> |
| In reply to | #60650 |
On Tuesday, April 21, 2015 at 4:39:04 PM UTC+1, Kenny McCormack wrote: > In article <mh5pu1$el9$1@dont-email.me>, > > Kinda "You say tomaytoe, I say tomahtoe". My view is that industry is by > nature and certainly by recent (since Reagan) US practice so short sighted > that they simply don't see any reason to switch. Why take the hit? > > Incidentally, Canada almost succeeded in switching, but failed because of > the great influence US practice has on their policies. The result is an > ugly mishmash, where some things are quoted in metric and other things are > quoted in US units. It must be very confusing for them... > The metric system was designed during the French Revolution. It was regarded as Satanic, and with considerable justification, because there was also a proposal for a metric ten day week, designed to make Sabbath observance difficult. The ten day week never caught on, but the metric measures did. There was also a belief that the term "inch" was derived from "Enoch" and had been used in sacred architecture, and the pyramids. Remember the US was heavily influenced by Freemasonry.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-21 22:25 +0000 |
| Message-ID | <5536ce3d.254656@news.xs4all.nl> |
| In reply to | #60648 |
Stephen Sprunk <stephen@sprunk.org> wrote: > On 21-Apr-15 06:57, Kenny McCormack wrote: > > It's kinda the Microsoft (and, for that matter, that of the US of A) > > attitude; we're big enough that even though we're "wrong" about many > > things, we're big enough that people will follow and do things our > > way regardless. > > > > For example, the US's insistence on not using the metric system. > > That's more legislative neglect than insistence: No, it's parochialism on the part of the population. Richard
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-23 15:59 -0500 |
| Message-ID | <mhbme2$shb$1@dont-email.me> |
| In reply to | #60687 |
On 21-Apr-15 17:25, Richard Bos wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> On 21-Apr-15 06:57, Kenny McCormack wrote: >>> It's kinda the Microsoft (and, for that matter, that of the US of >>> A) attitude; we're big enough that even though we're "wrong" >>> about many things, we're big enough that people will follow and >>> do things our way regardless. >>> >>> For example, the US's insistence on not using the metric system. >> >> That's more legislative neglect than insistence: > > No, it's parochialism on the part of the population. If by "population" you mean the general public, no; they have no say in the matter. By far the most influential factor is federal product labeling law, which _requires_ marking in traditional units but _allows_ marking in metric units as well. Reversing that (as in the rest of the world) would allow businesses worldwide to start marking only in metric, if that's what customers want, i.e. the general public's opinion would actually matter. A sunset on the traditional units (as Europe has tried--but failed--to do) would finish the job. Congress won't do that because their campaign contributors don't want them to. All they see is that the short-term costs of changing are less than the short-term costs of not changing; the long-term savings are irrelevant because they don't care about anything beyond their next election--or their next quarterly earnings report. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-23 11:51 -0700 |
| Message-ID | <kfniocmsmp3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60618 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 20/04/15 19:15, <<C3>> ?@C3{B6} Tiib wrote:
>>>
>>>> Wasn't it purely hypothetical and especially constructed
>>>> example?
>>>
>>> It was indeed, but it could be in the next gcc release, for all
>>> we know. So it is not unreasonable to ask the -Werror camp how
>>> they would deal with it.
>>
>> And the -Werror camp could respond that they depend on the gcc
>> maintainers *not* to introduce such a warning in a new version
>> of gcc. In this specific case, I think that's a reasonable
>> assumption.
>
> In the general case, however, it isn't. That's the real
> problem: you don't know what the next compiler edition may
> bring, _and_ we're talking about Ganuck, who have historically
> had a rather self-serving attitude towards what is acceptable C
> (read: Ganuck is, ISO isn't always).
IMO this characterization paints an unfair picture. Using
options -ansi -pedantic or -std=c99 -pedantic, my experience with
gcc is that it is stable, predictable, and faithful to the ISO
standard (perhaps with some bugs, but these are all acknowledged
and fixed AFAICT). I do find it annoying that gcc's default
behavior is not ISO conformance and that -pedantic is needed to
request it, but I understand the reasons for that (flimsy though
they may be at this point, but history is like that sometimes).
If you use only options like -ansi and -pedantic, and do not use
options like -Wall/-Wextra which are well-understood to express
the compiler authors' opinions about what warnings should be
given, is your experience different than that? If the property
"you don't know what the next compiler edition may bring" is
predicated on using options like -Wall or -Wextra, or not using
the options that request ISO conformance, I submit that the
complaint should be directed towards the person(s) who decided
which options to use (or not), and not towards the people who
write gcc.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-23 11:26 -0700 |
| Message-ID | <kfnmw1ysnus.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60585 |
Keith Thompson <kst-u@mib.org> writes: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 20/04/15 19:15, Tiib wrote: >>> On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: >> >> <snip> >> >>>> The example he gave in the very same message you were >>>> responding to seems an excellent one. What re-write would >>>> you propose to the following line: >>>> >>>> c = a + b; >>>> >>>> in order to avoid the following warning?: >>>> >>>>> foo.c:248:18: warning: addition of unsigned integer types >>>>> can result in a value lower than either operand >>>>> (-Waddition-of-unsigned-integer-types) >>> >>> Wasn't it purely hypothetical and especially constructed >>> example? >> >> It was indeed, but it could be in the next gcc release, for >> all we know. So it is not unreasonable to ask the -Werror >> camp how they would deal with it. > > And the -Werror camp could respond that they depend on the gcc > maintainers *not* to introduce such a warning in a new version > of gcc. In this specific case, I think that's a reasonable > assumption. > > The disadvantage of -Werror is that it enforces an arbitrary set > of restrictions on your code, namely those restrictions chosen by > the authors of the compiler you're using. [snip] I have to disagree with this sentence as written. What -Werror enforces is not an arbitrary set of restrictions, but the set of restrictions asked for via compiler options (plus a standard default set which I think most would agree are desirable but in any case is not arbitrary). If one /asks/ for an arbitrary set of conditions by using -Wall and/or -Wextra, then those conditions are what is enforced; if one does not use such options then the set of restrictions enforced is not arbitrary. In any case the choice rests on the user, not gcc's authors (again, not counting the standard default conditions, which AFAIK no one has any problem with).
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-20 16:15 -0500 |
| Message-ID | <mh3q7v$4bv$1@dont-email.me> |
| In reply to | #60540 |
On 20-Apr-15 12:22, James Kuyper wrote: > On 04/20/2015 10:39 AM, Stephen Sprunk wrote: >> Also, IMHO the metric should be that the cost of changing the code >> is greater than the cost (to every person who builds the code for >> all eternity) of determining the warning is spurious, which is a >> rather high bar for long-lived projects with large teams. >> >> Do you have such an example? > > The example he gave in the very same message you were responding to > seems an excellent one. What re-write would you propose to the > following line: > > c = a + b; > > in order to avoid the following warning?: > >> foo.c:248:18: warning: addition of unsigned integer types can >> result in a value lower than either operand >> (-Waddition-of-unsigned-integer-types) That's a ridiculous and contrived example; it would instantly break thousands of projects--including the compiler itself, most likely. If such stupidity were common from our tools, we'd either switch to better tools or, at minimum, change the -Werror rule. But it's not. It seems like a good rule of thumb would be that any warning have a simple and obvious workaround in the case that it's spurious, as in the example of "if (x=y)". S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 17:23 -0400 |
| Message-ID | <55356E62.8060806@verizon.net> |
| In reply to | #60577 |
On 04/20/2015 05:15 PM, Stephen Sprunk wrote: > On 20-Apr-15 12:22, James Kuyper wrote: ... >> The example he gave in the very same message you were responding to >> seems an excellent one. What re-write would you propose to the >> following line: >> >> c = a + b; >> >> in order to avoid the following warning?: >> >>> foo.c:248:18: warning: addition of unsigned integer types can >>> result in a value lower than either operand >>> (-Waddition-of-unsigned-integer-types) > > That's a ridiculous and contrived example; it would instantly break > thousands of projects--including the compiler itself, most likely. It's a warning message, not an error message, and therefore would only break the ones using the -Werror rule. It may seem ridiculous to you, but I've seen equally [un]reasonable warnings in real life that would have been just as difficult to work around, so I consider that fact to be evidence that the -Werror rule is at fault, not the compiler warning itself.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 13:17 -0400 |
| Message-ID | <553534B5.8020907@verizon.net> |
| In reply to | #60518 |
On 04/20/2015 08:49 AM, Les Cargill wrote:
> James Kuyper wrote:
,,,
> The rule "your code should have no warnings" is a normative, process
> based one. If you have such a rule to work with, then it's not "bad
> code" to fix the warning.
We're discussing whether that's a reasonable rule to have in the first
place. By defining code which violates that rule as bad, for no better
reason than the fact that it violates that rule, you're avoiding the
discussion entirely - it's simply another way of asserting, without
justification, that the rule is in fact reasonable.
> If you make a change to fix a warning, it should not affect the object
> code output in any meaningful way.
It's probably trivial to come up with exceptions, but in general, if a
given change to the source code doesn't change the output code, then the
change to the source code wasn't really necessary.
> Here's the critical detail - if it *does* affect the generated code,
> then you have a deeper problem to deal with. ...
Yes, and it's that deeper problem which justifies making those changes.
Without that deeper problem, changing the code is optional, at the
developer's discretion. -Werror overrides that discretion.
...
>> He's making no such argument. He's saying that code which avoids
>> triggering a warning message can sometimes be worse than code which
>> doesn't.
>
> And I remain skeptical of that idea. That code may be "simpler" -
> lacking a cast or something - but I don't see how that's necessarily
> better.
I made no claim that it was necessarily better. The operative phrase was
"can sometimes be". Usually, code that avoids triggering a warning is
better than code which doesn't, and I have no problems with that. I only
have problems with the assertion that it is ALWAYS better. That flies in
the face of my own personal experience, which is that many compilers
generate warnings about code that is perfectly fine. I've frequently
seen warnings I could not avoid with any reasonable code, and even a few
that I couldn't figure out how to avoid at all.
>> That becomes a "worse is better" argument only if you take it
>> as a matter of dogma (or perhaps, as a matter of definition), that code
>> which triggers a warning message can always be made better by a re-write
>> which avoids the warning.
>
> But such dogma exists. It's used as an operating principle in places.
I'm debating the advisability of such dogma - so pointing out that it
exists is somewhat redundant. There would be no need for debate if no
one was promoting that dogma (though the impracticality of a debate
wouldn't necessarily stop me ;-).
...
> None of that is necessary. If there's a shop expectation that there
> won't be warnings, then it is what it is. It's more a sop to the
> expectation of team members than to anything else.
I'm debating the advisability of that shop expectation, so pointing out
that it is expected doesn't say anything useful, either.
> You're requiring everyone to know that this warning is a "good
> warning" from now until the code base falls out of use.
Your alternative sometimes requires writing odd code that serves only to
silence a particular compiler's odd ideas about what needs to be warned
about, and the corresponding need to remember not to change until that
compiler falls out of use.
Let me give two real world examples. One compiler I've used warned about
not using the value of an expression. Thus,
x + 3*y;
triggered an error message because the value of x+3*y was computed but
never used, and this is a very reasonable warning to issue. However, the
same warning would be issued by the following code:
function_with_side_effects_returning_a_value(log, "frame number is
negative");
I'm calling the function entirely for it's side-effects, and ignoring
it's return value because I happen not to care about that value. People
familiar with this compiler would get into the habit of adding a cast to
void to silence it:
(void)function_with_side_effects_returning_a_value(log, "new message);
I refused to do so, but if we had been using the equivalent, on that
compiler, of -Werror, I wouldn't have had a choice in the matter.
My memory of this issue is incomplete. In almost every C
expression-statement, the expression has a value which is ignored - very
few expression statements naturally have a type of 'void'. Therefore, as
I've described the warning above, it should be triggered by almost every
line of a typical C program. In reality, it was triggered much less
frequently than that, so the trigger must have been more complicated
than I've implied above. But I know for a fact that the message was
sometimes triggered by code similar to what I've given above.
I have also taken code where other people have inserted (void) as needed
to silence such warnings from the first compiler, and ported it to a
compiler where the "fixed" code now triggered a different warning: "cast
to void has no effect". Now, you can avoid triggering either warning by
using code like the following:
#ifdef SILLY_COMPILER
#define VOID_CAST (void)
#else
#define VOID_CAST
#endif
VOID_CAST function_with_side_effects_returning_a_value(log, "new message);
I never bothered catering to the idiosyncrasies of the first compiler,
so I never did anything of the kind. However, your rule would seem to
mandate use of some such construct. Do you still think your rule is a
good idea?
Another example: I've used a compiler which would issue a warning for
the following code:
void increment(int *pint)
{
*pint++;
}
The warning? "The value of pint never changes - consider declaring it
const". While I certainly could get rid of the message by declaring
"inst * const pint", I see no good reason to do so. I've often found it
convenient to modify the value of a function parameter. Declaring it to
be 'const' suggests that this is something that would be unsafe,
discouraging maintenance programmers from pursuing such possibilities.
I've written code where it was vital that the values of particular
parameters not be changed, and when that was the case, I would declare
them 'const', but this message was often triggered by code for which
that didn't apply.
Now, a message that told me that "Neither pint nor any pointer derived
from it is used to modify the value of the object pointed at - consider
declaring *pint to be 'const'" - that would be a very useful warning for
me. I'd like to see a compiler provide such a warning, and I would
generally follow the suggestion whenever the message was triggered. But
that same compiler only warned about 'pint' being unchanged, not '*pint'.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-20 15:26 -0500 |
| Message-ID | <mh3nbj$oed$1@dont-email.me> |
| In reply to | #60539 |
On 20-Apr-15 12:17, James Kuyper wrote: > On 04/20/2015 08:49 AM, Les Cargill wrote: >> If you make a change to fix a warning, it should not affect the >> object code output in any meaningful way. > > It's probably trivial to come up with exceptions, but in general, if > a given change to the source code doesn't change the output code, > then the change to the source code wasn't really necessary. Changing "if (x=y)" to "if ((x=y)!=0)" shouldn't have any effect on the output code, but the latter tells both the compiler and other humans that an assignment was actually intended, which IMHO is superior. No, it isn't strictly necessary, but the point of making the change is to avoid confusion, not just to silence the warning. >> Here's the critical detail - if it *does* affect the generated >> code, then you have a deeper problem to deal with. ... > > Yes, and it's that deeper problem which justifies making those > changes. Without that deeper problem, changing the code is optional, > at the developer's discretion. -Werror overrides that discretion. Yes, it does; that's the point. I have learned, through painful experience, not to trust others' (or even my own) discretion because it does not produce the best results, regardless of good intentions. Even rock stars have off days--and I'm no rock star. >> And I remain skeptical of that idea. That code may be "simpler" - >> lacking a cast or something - but I don't see how that's >> necessarily better. > > I made no claim that it was necessarily better. The operative phrase > was "can sometimes be". Usually, code that avoids triggering a > warning is better than code which doesn't, and I have no problems > with that. I only have problems with the assertion that it is ALWAYS > better. That flies in the face of my own personal experience, which > is that many compilers generate warnings about code that is perfectly > fine. I've frequently seen warnings I could not avoid with any > reasonable code, and even a few that I couldn't figure out how to > avoid at all. That's why I asked for examples, since I've never seen such cases. > Let me give two real world examples. One compiler I've used warned > about not using the value of an expression. Thus, > > x + 3*y; > > triggered an error message because the value of x+3*y was computed > but never used, and this is a very reasonable warning to issue. Indeed. > However, the same warning would be issued by the following code: > > function_with_side_effects_returning_a_value(log, "frame number is > negative"); > > I'm calling the function entirely for it's side-effects, and > ignoring it's return value because I happen not to care about that > value. People familiar with this compiler would get into the habit of > adding a cast to void to silence it: > > (void)function_with_side_effects_returning_a_value(log, "new > message); > > I refused to do so, but if we had been using the equivalent, on that > compiler, of -Werror, I wouldn't have had a choice in the matter. I've seen such code*, and I assumed that's why the (void) was there, but no compiler I've ever used has warned about such cases. Still, the cast _does_ serve a documentary purpose: acknowledging that we're throwing away a return value, and having to do so should make one consider if that's actually the right thing to be doing. For instance, it may signal that you forgot to check for an error condition. Granted, the -Werror dogma assumes that people only use workarounds to silence the warning after they've determined it's spurious. Like most dogma, it doesn't serve its intended purpose if people just go through the motions, which is a decent argument against the dogma itself, but still not a convincing one IMHO. * My (admittedly vague) memory is that most involved printf(), which almost nobody ever checks the return value of. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-20 16:15 -0700 |
| Message-ID | <871tjeo0hr.fsf@kst-u.example.com> |
| In reply to | #60566 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 20-Apr-15 12:17, James Kuyper wrote:
>> On 04/20/2015 08:49 AM, Les Cargill wrote:
>>> If you make a change to fix a warning, it should not affect the
>>> object code output in any meaningful way.
>>
>> It's probably trivial to come up with exceptions, but in general, if
>> a given change to the source code doesn't change the output code,
>> then the change to the source code wasn't really necessary.
>
> Changing "if (x=y)" to "if ((x=y)!=0)" shouldn't have any effect on the
> output code, but the latter tells both the compiler and other humans
> that an assignment was actually intended, which IMHO is superior. No,
> it isn't strictly necessary, but the point of making the change is to
> avoid confusion, not just to silence the warning.
[...]
Personally I'd write one of:
if ((x = y) != 0)
if ((x = y) != 0.0)
if ((x = y) != NULL)
depending on the type(s) of x and y. If x and y are of type bool /
_Bool, it's a bit trickier. I dislike comparing bool values for
equality to either `false` or `true`. It's not likely to come up very
often, but if it did I might write:
if ((x = y))
or, if that didn't silence the warning:
x = y;
if (x)
For that matter, lifting the assignment out of the condition might be an
improvement in any case. Replace "if" by "while" for a more plausible
case where it makes sense to embed the assignment in the condition.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-21 00:42 -0500 |
| Message-ID | <mh4nuf$nm4$1@dont-email.me> |
| In reply to | #60588 |
On 20-Apr-15 18:15, Keith Thompson wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> Changing "if (x=y)" to "if ((x=y)!=0)" shouldn't have any effect on >> the output code, but the latter tells both the compiler and other >> humans that an assignment was actually intended, which IMHO is >> superior. No, it isn't strictly necessary, but the point of making >> the change is to avoid confusion, not just to silence the warning. > > Personally I'd write one of: > > if ((x = y) != 0) > if ((x = y) != 0.0) > if ((x = y) != NULL) > > depending on the type(s) of x and y. Ditto, but probably only after seeing the warning. I'll write "if (x)" regardless of x's type, so the verbosity of "if (x!=0)" et al would be jarring. But I know some folks don't like "if (x)" if x is anything other than a bool, so perhaps the x=y versions aren't as jarring to others. > If x and y are of type bool / _Bool, it's a bit trickier. I dislike > comparing bool values for equality to either `false` or `true`. It's > not likely to come up very often, but if it did I might write: > > if ((x = y)) That construction will silence GCC's warning too; I suppose the extra parens were thought to be enough to indicate it wasn't a typo. > or, if that didn't silence the warning: > > x = y; > if (x) > > For that matter, lifting the assignment out of the condition might be > an improvement in any case. Replace "if" by "while" for a more > plausible case where it makes sense to embed the assignment in the > condition. I can't put into words why, but sometimes lifting it feels better, and sometimes not lifting it feels better, even with "if". S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 11:15 -0700 |
| Message-ID | <kfnfv7st4fn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60588 |
Keith Thompson <kst-u@mib.org> writes:
> Stephen Sprunk <stephen@sprunk.org> writes:
>> On 20-Apr-15 12:17, James Kuyper wrote:
>>> On 04/20/2015 08:49 AM, Les Cargill wrote:
>>>> If you make a change to fix a warning, it should not affect the
>>>> object code output in any meaningful way.
>>>
>>> It's probably trivial to come up with exceptions, but in general,
>>> if a given change to the source code doesn't change the output
>>> code, then the change to the source code wasn't really necessary.
>>
>> Changing "if (x=y)" to "if ((x=y)!=0)" shouldn't have any effect on
>> the output code, but the latter tells both the compiler and other
>> humans that an assignment was actually intended, which IMHO is
>> superior. No, it isn't strictly necessary, but the point of making
>> the change is to avoid confusion, not just to silence the warning.
>
> [...]
>
> Personally I'd write one of:
>
> if ((x = y) != 0)
> if ((x = y) != 0.0)
> if ((x = y) != NULL)
>
> depending on the type(s) of x and y. [snip]
Alternatively, writing
if ( x = y, x )
or
if ( x = y, x != 0 )
will get rid of the warning, and IMO makes the presence, and
intention, of using assignment stand out more.
(Style note: I don't favor either always using the first
form, or always using the second form, of the two listed
above; which one is better in different particular cases
depends on other factors. However that has no bearing on my
comments above, so I'm trying to sidestep that question.)
Of course, this suggestion is no good if 'x' is volatile,
but if 'x' is volatile then none of these should be used,
including the earlier ones, because of the ambiguity about
accessing volatiles when the value of a to-volatile
assignment expression is used.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 21:50 +0100 |
| Message-ID | <mh3opp$u8r$1@dont-email.me> |
| In reply to | #60539 |
On 20/04/15 18:17, James Kuyper wrote:
<snip>
>
> Another example: I've used a compiler which would issue a warning for
> the following code:
>
> void increment(int *pint)
> {
> *pint++;
> }
>
> The warning? "The value of pint never changes - consider declaring it
> const".
Could you please clarify whether that was the code you intended for us
to read? Or did you mean to write (*pint)++?
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 17:04 -0400 |
| Message-ID | <553569C2.8050101@verizon.net> |
| In reply to | #60539 |
On 04/20/2015 01:17 PM, James Kuyper wrote:
...
> Another example: I've used a compiler which would issue a warning for
> the following code:
>
> void increment(int *pint)
> {
> *pint++;
Correction:
(*pint)++;
Sorry - I've been tripping up over some fairly simple things lately -
lack of sleep due to having newborn twins in the NICU is the obvious
candidate.
> }
>
> The warning? "The value of pint never changes - consider declaring it
> const". While I certainly could get rid of the message by declaring
> "inst * const pint", I see no good reason to do so. I've often found it
> convenient to modify the value of a function parameter. Declaring it to
> be 'const' suggests that this is something that would be unsafe,
> discouraging maintenance programmers from pursuing such possibilities.
> I've written code where it was vital that the values of particular
> parameters not be changed, and when that was the case, I would declare
> them 'const', but this message was often triggered by code for which
> that didn't apply.
I appreciate the irony of the fact that my mistake would have triggered
an error message if I had followed the compiler's suggestion. However,
it would have been an error only because I declared that variable const,
not because there was anything inherently wrong with modifying the value
of 'pint'. The true problem is revealed by the warning message that gets
reported if I leave out the 'const':
increment.c:3: warning: value computed is not used
I didn't see that message only because the code sample was so simple I
didn't think I could mess it up, so I didn't bother trying to compile
it. In the future, I'll try harder not to underestimate my ability to
mess things up. :-(
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web