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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-19 11:47 -0500 |
| Message-ID | <mh0lrf$s0$1@dont-email.me> |
| In reply to | #60399 |
Richard Heathfield wrote: > On 18/04/15 05:01, Les Cargill wrote: >> Richard Heathfield wrote: > > <snip> > >>> The gcc compiler, however, is a different kettle of bananas, and it does >>> sometimes issue warnings for code that /could/ be a problem in different >>> circumstances but which I happen to know is /not/ a problem in this >>> particular case, >> >> ... and so I think you maybe oughta buck up and fix it. > > Fix what? Fix the code? The warniong. > Not broken. If it has a warning, and "warnings mean it's broken" then it's broken. > Fix the comment? Done. Fix gcc? I > don't think that's broken either. It's giving a warning that is sensible > as a warning but not sensible as an error. The problem, if there is a > problem, is in the use of -Werror, so don't use that. > That's another fine solution, but shipping code with warnings isn't the best of all possible practice. >>> where I've seen the warning, where I've thought it >>> through all over again precisely /because/ of the warning (which is why >>> I want the warning!), and I've decided to press ahead anyway. >> >> Understood. But maybe you missed something. > > Sure, that's possible. But maybe you missed something when you were > 'fixing' the code to sidestep -Werror, something that meant you were no > longer coding the solution you were supposed to be coding. Of *course* > we might have missed something. That's why we do testing. > If fixing a warning breaks things, you have a much bigger problem. And your tests should show it up if you *do* break something. > <snip> > >> It is a really rich and interesting tradeoff. I come mainly from the >> perspective of "why your code got warnings", which I treat as a credible >> question. > > It is indeed a credible question, but sometimes the credible answer is > "the compiler is not magical - sometimes it is over-zealous in its > diagnostics, so check every diagnostic message and make sure you > understand every diagnostic message." Normally, this will result in a > code change, but sometimes it will result only in a comment in the > source, documenting the warning, why you got it, and why it isn't a > problem. > So you have a code base that compiles clean. NO warnings. If you manage to step on something and cause a warning, you'd fix it. Right? So now we have a legacy code base, with warnings-as-technical-debt. If there's anyway to do it in a reasonable fashion, it's nice to get rid of that technical debt. By the same reasoning above. If you can't, you just can't, but please accept that even though the compiler may be overzealous, this is dysfunctional behavior. >> >> What -Werror does is hijack your priorities, which I consider >> essentially valuable. I am more worried about being complacent >> than I am about being slightly grumpy from the compiler being >> unreasonable. > > Am I worried about complacency? Sure. Oh yes. > Am I worried about being slightly grumpy? Sure. > Am I worried about turning good code into worse code just as a sop to > the compiler? Sure. > I just don't buy the essential "worse is better" argument you're making ( or gently accusing me of making ). OF course you have local code standards and that decides. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-19 18:44 +0100 |
| Message-ID | <mh0ph1$fuv$1@dont-email.me> |
| In reply to | #60430 |
On 19/04/15 17:47, Les Cargill wrote: > Richard Heathfield wrote: >> On 18/04/15 05:01, Les Cargill wrote: >>> Richard Heathfield wrote: >> >> <snip> >> >>>> The gcc compiler, however, is a different kettle of bananas, and it does >>>> sometimes issue warnings for code that /could/ be a problem in different >>>> circumstances but which I happen to know is /not/ a problem in this >>>> particular case, >>> >>> ... and so I think you maybe oughta buck up and fix it. >> >> Fix what? Fix the code? > > The warniong. Why? (But we'll come on to that.) > >> Not broken. > > If it has a warning, and "warnings mean it's broken" then it's broken. But if it has a warning, and warnings don't mean it's broken, then it isn't necessarily broken, is it? >> Fix the comment? Done. Fix gcc? I >> don't think that's broken either. It's giving a warning that is sensible >> as a warning but not sensible as an error. The problem, if there is a >> problem, is in the use of -Werror, so don't use that. >> > > > That's another fine solution, but shipping code with warnings isn't the > best of all possible practice. > >>>> where I've seen the warning, where I've thought it >>>> through all over again precisely /because/ of the warning (which is why >>>> I want the warning!), and I've decided to press ahead anyway. >>> >>> Understood. But maybe you missed something. >> >> Sure, that's possible. But maybe you missed something when you were >> 'fixing' the code to sidestep -Werror, something that meant you were no >> longer coding the solution you were supposed to be coding. Of *course* >> we might have missed something. That's why we do testing. >> > > If fixing a warning breaks things, you have a much bigger problem. That's why I don't fix warnings if they are warning about something that isn't broken. > And your tests should show it up if you *do* break something. Agreed. > >> <snip> >> >>> It is a really rich and interesting tradeoff. I come mainly from the >>> perspective of "why your code got warnings", which I treat as a credible >>> question. >> >> It is indeed a credible question, but sometimes the credible answer is >> "the compiler is not magical - sometimes it is over-zealous in its >> diagnostics, so check every diagnostic message and make sure you >> understand every diagnostic message." Normally, this will result in a >> code change, but sometimes it will result only in a comment in the >> source, documenting the warning, why you got it, and why it isn't a >> problem. > > So you have a code base that compiles clean. NO warnings. If you > manage to step on something and cause a warning, you'd fix it. > > Right? It depends on whether the warning reflects a problem with the code. > So now we have a legacy code base, with warnings-as-technical-debt. Please explain what you mean by "warnings-as-technical-debt" because, if you mean what I think you mean, it's a poor description of warnings. > If there's anyway to do it in a reasonable fashion, it's nice > to get rid of that technical debt. By the same reasoning above. So far, you haven't presented very much reasoning with which I could unequivocally agree, so I don't think I'm yet in a position to accept your conclusion. > If you can't, you just can't, but please accept that even > though the compiler may be overzealous, this is dysfunctional behavior. Why? >>> What -Werror does is hijack your priorities, which I consider >>> essentially valuable. I am more worried about being complacent >>> than I am about being slightly grumpy from the compiler being >>> unreasonable. >> >> Am I worried about complacency? Sure. > > Oh yes. > >> Am I worried about being slightly grumpy? Sure. >> Am I worried about turning good code into worse code just as a sop to >> the compiler? Sure. >> > > I just don't buy the essential "worse is better" argument you're > making ( or gently accusing me of making ). I'm not trying to make any accusations, and I certainly don't think worse is better. I do think that we can't expect compilers correctly to diagnose every situation that they are required or expected to diagnose without /also/ occasionally diagnosing code that is perfectly fine as it is. That isn't "worse is better". It's the best of both worlds. > OF course you have local code standards and that decides. As do you. -- 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-19 18:34 -0400 |
| Message-ID | <mh1afq$kkl$1@dont-email.me> |
| In reply to | #60430 |
On 04/19/2015 12:47 PM, Les Cargill wrote: > Richard Heathfield wrote: >> On 18/04/15 05:01, Les Cargill wrote: >>> Richard Heathfield wrote: >> >> <snip> >> >>>> The gcc compiler, however, is a different kettle of bananas, and it does >>>> sometimes issue warnings for code that /could/ be a problem in different >>>> circumstances but which I happen to know is /not/ a problem in this >>>> particular case, >>> >>> ... and so I think you maybe oughta buck up and fix it. >> >> Fix what? Fix the code? > > The warniong. Why? It's correctly identifying a situation as justifying a closer look by the developer. If that closer look indicates that there's no actual problem, there doesn't have to be anything wrong with the warning message (thought there could be). If the existence of a problem that needs to be solved were certain, it should have been an error message, not a warning message. >> Not broken. > > If it has a warning, and "warnings mean it's broken" then it's broke. The logic is impeccable, but the conclusion is wrong because the second premise which is false. So th thing which needs fixing is the second premise. >> Fix the comment? Done. Fix gcc? I >> don't think that's broken either. It's giving a warning that is sensible >> as a warning but not sensible as an error. The problem, if there is a >> problem, is in the use of -Werror, so don't use that. >> > > > That's another fine solution, but shipping code with warnings isn't the > best of all possible practice. It's better practice than writing bad code to avoid a warning about good code. >>>> where I've seen the warning, where I've thought it >>>> through all over again precisely /because/ of the warning (which is why >>>> I want the warning!), and I've decided to press ahead anyway. >>> >>> Understood. But maybe you missed something. >> >> Sure, that's possible. But maybe you missed something when you were >> 'fixing' the code to sidestep -Werror, something that meant you were no >> longer coding the solution you were supposed to be coding. Of *course* >> we might have missed something. That's why we do testing. >> > > If fixing a warning breaks things, you have a much bigger problem. Being less than divinely infallible might be considered a big problem from some points of view, but to me it seems an ordinary fact of the human condition. And being divinely infallible is the only way I'm familiar with for avoiding all possibility of breaking one thing when you fix something else. It's also the only sense in which your comment "But maybe you missed something" is relevant. > And your tests should show it up if you *do* break something. Ideally, yes, but in the same sense that you said "you might have missed something while determining whether or not a given warning is applicable to a given piece of code, "you might have missed something" when putting together your tests. ... > manage to step on something and cause a warning, you'd fix it. > > Right? If, by "step on something" you mean "insert a defect" - sure. However, if by "step on something" you mean "write perfectly good code that happens to trigger a warning message", then the answer is "No".' > So now we have a legacy code base, with warnings-as-technical-debt. > If there's anyway to do it in a reasonable fashion, it's nice > to get rid of that technical debt. By the same reasoning above. > > If you can't, you just can't, but please accept that even > though the compiler may be overzealous, this is dysfunctional behavior. I consider it more dysfunctional to write bad code to avoid triggering a warning message. ... >> Am I worried about turning good code into worse code just as a sop to >> the compiler? Sure. >> > > I just don't buy the essential "worse is better" argument you're > making ( or gently accusing me of making ). 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. 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. Such a dogma (or definition) only makes sense if you have more faith in the infallibility of compiler warnings than I do, and if you also believe that the compiler writers who have managed to determine infallibly that a given piece of code is defective, might for some reason chose to issue a warning message rather than the error message that would seem more appropriate when such certainty is justified. It's hard for me to imagine that anyone who who could make such a stupid mistake in determining which type of message to issue, could be infallibly correct about he problem they think justifies issuing it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 01:42 -0700 |
| Message-ID | <e11b05ae-6415-4c43-af0f-2d83723957fb@googlegroups.com> |
| In reply to | #60472 |
On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote: > On 04/19/2015 12:47 PM, Les Cargill wrote: > > Richard Heathfield wrote: > > ... > >> Am I worried about turning good code into worse code just as a sop to > >> the compiler? Sure. > >> > > > > I just don't buy the essential "worse is better" argument you're > > making ( or gently accusing me of making ). > > 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. 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. Warning is a signal that a tool is not certain if piece of code is good or bad. It can be problem on its own if we write code for reading by tools and other programmers. Where one tool is uncertain there other tool may be confused and also programmer may misunderstand it. The code is not robust and clear enough for something; there is a cosmetic issue. In attempt to fix such a cosmetic issue we may introduce more serious defect or make the code to look even more unclear. It is certainly a risk (and so potential cost) but it feels low. Most of the ways to silence warnings are cheap, trivial and not too ugly. Usually it is minor annoyance. > Such a dogma (or definition) only makes sense if you have more faith in > the infallibility of compiler warnings than I do, and if you also > believe that the compiler writers who have managed to determine > infallibly that a given piece of code is defective, might for some > reason chose to issue a warning message rather than the error message > that would seem more appropriate when such certainty is justified. It's > hard for me to imagine that anyone who who could make such a stupid > mistake in determining which type of message to issue, could be > infallibly correct about he problem they think justifies issuing it. It may be about dogmas but it is not always about dogmas. There can be (and usually are) just choices between different risks (and potential costs). For example when warnings pile in large project then it becomes harder (more costly) to notice that compiler issued a new warning about some real defect. So programmers do not notice it. It also can slip past automatic tests in big project because corner cases are not always covered by such. The defect reaches testers, those discover it, reproduce and report, it will be assigned to someone who debugs it and finally finds that the problem is already warned about by compiler. The whole circle may take weeks. If that scenario tends to repeat then -Werror may be added not by dogmatic preference but by pragmatic cost analysis. Yes, reading the thread makes it indeed feel a bit like clash of dogmas but outside of these there can be rational and good reasons.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 08:14 -0400 |
| Message-ID | <mh2qh8$1s9$1@dont-email.me> |
| In reply to | #60497 |
On 04/20/2015 04:42 AM, Öö Tiib wrote: > On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote: >> On 04/19/2015 12:47 PM, Les Cargill wrote: ... >>> I just don't buy the essential "worse is better" argument you're >>> making ( or gently accusing me of making ). >> >> 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. 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. > > Warning is a signal that a tool is not certain if piece of code is good > or bad. It can be problem on its own if we write code for reading by > tools and other programmers. Where one tool is uncertain there other > tool may be confused and also programmer may misunderstand it. The > code is not robust and clear enough for something; there is a > cosmetic issue. No matter how bad the reason is for the warning? You have more faith in the infallibility of compiler writers than I do. > In attempt to fix such a cosmetic issue we may introduce more serious > defect or make the code to look even more unclear. It is certainly a > risk (and so potential cost) but it feels low. Most of the ways to > silence warnings are cheap, trivial and not too ugly. Usually it is > minor annoyance. I agree - "most" of the ways - my objection is the elevation of the entirely reasonable principle "avoid triggering warning messages" into a dogma "never trigger warning messages". That elevation is precisely what -Werror does. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 10:30 -0700 |
| Message-ID | <9b8eb622-5398-4da8-92c4-5d816e6fa603@googlegroups.com> |
| In reply to | #60516 |
On Monday, 20 April 2015 15:14:42 UTC+3, James Kuyper wrote:
> On 04/20/2015 04:42 AM, Öö Tiib wrote:
> > On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote:
> >> On 04/19/2015 12:47 PM, Les Cargill wrote:
> ...
> >>> I just don't buy the essential "worse is better" argument you're
> >>> making ( or gently accusing me of making ).
> >>
> >> 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. 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.
> >
> > Warning is a signal that a tool is not certain if piece of code is good
> > or bad. It can be problem on its own if we write code for reading by
> > tools and other programmers. Where one tool is uncertain there other
> > tool may be confused and also programmer may misunderstand it. The
> > code is not robust and clear enough for something; there is a
> > cosmetic issue.
>
> No matter how bad the reason is for the warning? You have more faith in
> the infallibility of compiler writers than I do.
Compiler writers are imperfect but still good specialists about language.
Compilers have given me odd and even humorously wrong warnings
but the diagnosed code has been always tricky too somehow.
For odd case when particular warning is outright silly there may be
possibilities to overrule command line in code. For example gcc has
such pragmas:
#pragma GCC diagnostic ignored "-Wformat"
#pragma GCC diagnostic warning "-Wformat"
It is up to team to decide if those (or similar) are good idea to use.
> > In attempt to fix such a cosmetic issue we may introduce more serious
> > defect or make the code to look even more unclear. It is certainly a
> > risk (and so potential cost) but it feels low. Most of the ways to
> > silence warnings are cheap, trivial and not too ugly. Usually it is
> > minor annoyance.
>
> I agree - "most" of the ways - my objection is the elevation of the
> entirely reasonable principle "avoid triggering warning messages" into a
> dogma "never trigger warning messages". That elevation is precisely what
> -Werror does.
I see the risk and cost of -Werror so it is not dogma for me. My points
are that:
* It is reasonable to take every diagnostic seriously.
* The person who made the change that was warned about is likely most
aware what is going on in diagnosed code.
* It is easier to miss new warnings when build log is littered with older
diagnostics.
Are there some better way than -Werror to make people to treat warnings
seriously, make author of diagnosed change to see it first and to reduce
annoyances about garbage? It certainly isn't as widely available or clear
given the popularity of -Werror.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 13:56 -0400 |
| Message-ID | <55353DBC.7070201@verizon.net> |
| In reply to | #60541 |
On 04/20/2015 01:30 PM, Öö Tiib wrote: > On Monday, 20 April 2015 15:14:42 UTC+3, James Kuyper wrote: ... >> I agree - "most" of the ways - my objection is the elevation of the >> entirely reasonable principle "avoid triggering warning messages" into a >> dogma "never trigger warning messages". That elevation is precisely what >> -Werror does. > > I see the risk and cost of -Werror so it is not dogma for me. My points > are that: > * It is reasonable to take every diagnostic seriously. I would disagree. I've seen too many diagnostics that need not be taken seriously. You should always give due consideration to the possibility that a diagnostic should be taken seriously - but "due consideration" does not include necessarily changing your code to avoid triggering the diagnostic. > * The person who made the change that was warned about is likely most > aware what is going on in diagnosed code. > * It is easier to miss new warnings when build log is littered with older > diagnostics. I'm not recommending writing code that generates so many warnings that it's hard to notice new ones. Only spurious warnings should be ignored, and when using any decent compiler, spurious warnings should be rare. A compiler that does generate large numbers of spurious warnings should be dropped in favor of one that's more reasonable. I admit, this isn't always feasible. > Are there some better way than -Werror to make people to treat warnings > seriously, make author of diagnosed change to see it first and to reduce > annoyances about garbage? It certainly isn't as widely available or clear > given the popularity of -Werror. I think a policy of evaluating all warnings, but changing the code only when the warning is justified, is the best approach. -Werror will help only if you've got developers who are unwilling to follow that policy, or not qualified to perform such evaluations. If that's the case, you should consider replacing those developers. Believe me, I'm quite familiar with the situation where you can't afford better developers, and can't afford to fire the poor ones you've already hired. Still, it is a situation to be avoided.
[toc] | [prev] | [next] | [standalone]
| From | Ian Pilcher <arequipeno@gmail.com> |
|---|---|
| Date | 2015-04-20 18:39 -0500 |
| Message-ID | <mh42lm$37j$1@dont-email.me> |
| In reply to | #60547 |
On 04/20/2015 12:56 PM, James Kuyper wrote: > I would disagree. I've seen too many diagnostics that need not be taken > seriously. You should always give due consideration to the possibility > that a diagnostic should be taken seriously - but "due consideration" > does not include necessarily changing your code to avoid triggering the > diagnostic. I can't help thinking of this ... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145 -- ======================================================================== Ian Pilcher arequipeno@gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ========================================================================
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-23 12:37 -0700 |
| Message-ID | <kfnegnaskj1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60516 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/20/2015 04:42 AM, Tiib wrote: >> On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote: >>> On 04/19/2015 12:47 PM, Les Cargill wrote: >>> [snip] >> >> In attempt to fix such a cosmetic issue we may introduce more >> serious defect or make the code to look even more unclear. It is >> certainly a risk (and so potential cost) but it feels low. Most >> of the ways to silence warnings are cheap, trivial and not too >> ugly. Usually it is minor annoyance. > > I agree - "most" of the ways - my objection is the elevation of > the entirely reasonable principle "avoid triggering warning > messages" into a dogma "never trigger warning messages". That > elevation is precisely what -Werror does. You're using the term "dogma" as more or less a synonym for strict, rigid, or inflexible. This isn't what dogma means. The recommendation to use -Werror (and to strictly insist that all requested diagnostics be address, so no diagnostics are generated) is not a dogmatic position but a reasoned position based on seeing how different policies play out in actual experience. Of course I am speaking for myself here, but I expect Stephen Sprunk (among others) would say much the same thing. (And I hope he will jump in if the matter needs correction, clarification or amplification.) In fact, ISTM that the more dogmatic position is the idea that compiles should _always_ be done using -Wall and -W (aka -Wextra). I have heard this policy suggestion many times, but have never heard anyone offer any real justification for it. AFAICT everyone does it mainly because they think everyone else thinks it's the right thing to do. And that is what makes it dogma.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-23 20:25 -0500 |
| Message-ID | <mhc5nb$e84$4@dont-email.me> |
| In reply to | #60935 |
Tim Rentsch wrote: > James Kuyper <jameskuyper@verizon.net> writes: > >> On 04/20/2015 04:42 AM, Tiib wrote: >>> On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote: >>>> On 04/19/2015 12:47 PM, Les Cargill wrote: >>>> [snip] >>> >>> In attempt to fix such a cosmetic issue we may introduce more >>> serious defect or make the code to look even more unclear. It is >>> certainly a risk (and so potential cost) but it feels low. Most >>> of the ways to silence warnings are cheap, trivial and not too >>> ugly. Usually it is minor annoyance. >> >> I agree - "most" of the ways - my objection is the elevation of >> the entirely reasonable principle "avoid triggering warning >> messages" into a dogma "never trigger warning messages". That >> elevation is precisely what -Werror does. > > You're using the term "dogma" as more or less a synonym for strict, > rigid, or inflexible. This isn't what dogma means. > > The recommendation to use -Werror (and to strictly insist that all > requested diagnostics be address, so no diagnostics are generated) > is not a dogmatic position but a reasoned position based on seeing > how different policies play out in actual experience. Of course I > am speaking for myself here, but I expect Stephen Sprunk (among > others) would say much the same thing. (And I hope he will jump > in if the matter needs correction, clarification or amplification.) > I am not Stephen, but I happen to agree. It's something that must be weighed pragmatically. > In fact, ISTM that the more dogmatic position is the idea that > compiles should _always_ be done using -Wall and -W (aka -Wextra). I think that's the same basic issue. > I have heard this policy suggestion many times, but have never > heard anyone offer any real justification for it. AFAICT everyone > does it mainly because they think everyone else thinks it's the > right thing to do. And that is what makes it dogma. > I do it because it exposed problem I don't see any other way, or that I only see when it's too late. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-24 07:58 -0700 |
| Message-ID | <kfnd22tr2sx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60967 |
Les Cargill <lcargill99@comcast.com> writes: > Tim Rentsch wrote: >> James Kuyper <jameskuyper@verizon.net> writes: >> >>> On 04/20/2015 04:42 AM, Tiib wrote: >>>> On Monday, 20 April 2015 01:34:37 UTC+3, James Kuyper wrote: >>>>> On 04/19/2015 12:47 PM, Les Cargill wrote: >>>>> [snip] >>>> >>>> In attempt to fix such a cosmetic issue we may introduce more >>>> serious defect or make the code to look even more unclear. It is >>>> certainly a risk (and so potential cost) but it feels low. Most >>>> of the ways to silence warnings are cheap, trivial and not too >>>> ugly. Usually it is minor annoyance. >>> >>> I agree - "most" of the ways - my objection is the elevation of >>> the entirely reasonable principle "avoid triggering warning >>> messages" into a dogma "never trigger warning messages". That >>> elevation is precisely what -Werror does. >> >> You're using the term "dogma" as more or less a synonym for strict, >> rigid, or inflexible. This isn't what dogma means. >> >> The recommendation to use -Werror (and to strictly insist that all >> requested diagnostics be address, so no diagnostics are generated) >> is not a dogmatic position but a reasoned position based on seeing >> how different policies play out in actual experience. Of course I >> am speaking for myself here, but I expect Stephen Sprunk (among >> others) would say much the same thing. (And I hope he will jump >> in if the matter needs correction, clarification or amplification.) > > I am not Stephen, but I happen to agree. It's something that must > be weighed pragmatically. > >> In fact, ISTM that the more dogmatic position is the idea that >> compiles should _always_ be done using -Wall and -W (aka -Wextra). > > I think that's the same basic issue. > >> I have heard this policy suggestion many times, but have never >> heard anyone offer any real justification for it. AFAICT everyone >> does it mainly because they think everyone else thinks it's the >> right thing to do. And that is what makes it dogma. > > I do it because it exposed problem I > don't see any other way, or that I only > see when it's too late. Clearly -Wall and -Wextra provide some value, and it's perfectly reasonable to use them to get that. What I think is dogmatic is the idea that -Wall and -Wextra should be used on /every/ compile. Some compiles, sure, and I've said so, but I haven't heard any rational basis for using them always.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-24 12:58 -0500 |
| Message-ID | <mhe077$b63$1@dont-email.me> |
| In reply to | #60967 |
On 23-Apr-15 20:25, Les Cargill wrote: > Tim Rentsch wrote: >> The recommendation to use -Werror (and to strictly insist that all >> requested diagnostics be address, so no diagnostics are generated) >> is not a dogmatic position but a reasoned position based on seeing >> how different policies play out in actual experience. Of course I >> am speaking for myself here, but I expect Stephen Sprunk (among >> others) would say much the same thing. (And I hope he will jump in >> if the matter needs correction, clarification or amplification.) > > I am not Stephen, but I happen to agree. It's something that must be > weighed pragmatically. I am Stephen, and I agree as well :) >> In fact, ISTM that the more dogmatic position is the idea that >> compiles should _always_ be done using -Wall and -W (aka -Wextra). > > I think that's the same basic issue. It's related, at least. Using -Werror is predicated on the warnings being reasonable, and there is such consensus for the warnings in -Wall, but I would suggest that some warnings are relegated to -Wextra because there _isn't_ consensus that they are reasonable. IOW, you can use -Wall with -Werror, but you probably shouldn't use -Wextra with -Werror. 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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-24 22:13 -0500 |
| Message-ID | <mhf0d8$l47$1@dont-email.me> |
| In reply to | #61026 |
Stephen Sprunk wrote: > On 23-Apr-15 20:25, Les Cargill wrote: >> Tim Rentsch wrote: >>> The recommendation to use -Werror (and to strictly insist that all >>> requested diagnostics be address, so no diagnostics are generated) >>> is not a dogmatic position but a reasoned position based on seeing >>> how different policies play out in actual experience. Of course I >>> am speaking for myself here, but I expect Stephen Sprunk (among >>> others) would say much the same thing. (And I hope he will jump in >>> if the matter needs correction, clarification or amplification.) >> >> I am not Stephen, but I happen to agree. It's something that must be >> weighed pragmatically. > > I am Stephen, and I agree as well :) > >>> In fact, ISTM that the more dogmatic position is the idea that >>> compiles should _always_ be done using -Wall and -W (aka -Wextra). >> >> I think that's the same basic issue. > > It's related, at least. Using -Werror is predicated on the warnings > being reasonable, and there is such consensus for the warnings in -Wall, > but I would suggest that some warnings are relegated to -Wextra because > there _isn't_ consensus that they are reasonable. IOW, you can use > -Wall with -Werror, but you probably shouldn't use -Wextra with -Werror. > I don't have any of the flavor of -Wextra. Looks like the use/dont use state space of all these options is on the order of 16, so it shouldn't take too much trying to find out. Every day past a commit to the repository, the memory of what was done decays, so a certain amount of tolerance of compiler diagnostics is in order. Taking time to ship it clean seems no real sacrifice. > S > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-28 13:05 -0700 |
| Message-ID | <kfnbni8c934.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61026 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 23-Apr-15 20:25, Les Cargill wrote: >> Tim Rentsch wrote: >>> >>> In fact, ISTM that the more dogmatic position is the idea that >>> compiles should _always_ be done using -Wall and -W (aka -Wextra). >> >> I think that's the same basic issue. > > It's related, at least. Using -Werror is predicated on the > warnings being reasonable, and there is such consensus for the > warnings in -Wall, but I would suggest that some warnings are > relegated to -Wextra because there _isn't_ consensus that they are > reasonable. IOW, you can use -Wall with -Werror, but you probably > shouldn't use -Wextra with -Werror. This made me wonder just what sets of conditions these two options include, some I did a man gcc and went through them. I would summarize my reactions as follows. (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio (+/- 15%, say). (B) IMO it is still not a good idea to use -Wall or -Wextra on a regular basis (as opposed to just now and then as spot checks). Better is to select explicitly just those options that are considered both reliable enough and also suitable to have be on for all compilations. (C) In any case, the deciding factor should not be community consensus (if such a thing can even be determined) but the intersection of condition sets of the relevant stakeholders. In other words the only options that should be turned on all the time are those where every (voting) stakeholder agrees it should be turned on. It always possible for individual compiles to use more stringent sets of options, but the baseline should include only those options that are /always/ right for all compiles.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-30 08:40 -0500 |
| Message-ID | <mhtba4$i92$1@dont-email.me> |
| In reply to | #61209 |
On 28-Apr-15 15:05, Tim Rentsch wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> It's related, at least. Using -Werror is predicated on the >> warnings being reasonable, and there is such consensus for the >> warnings in -Wall, but I would suggest that some warnings are >> relegated to -Wextra because there _isn't_ consensus that they are >> reasonable. IOW, you can use -Wall with -Werror, but you probably >> shouldn't use -Wextra with -Werror. > > This made me wonder just what sets of conditions these two options > include, some I did a man gcc and went through them. I would > summarize my reactions as follows. > > (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio > (+/- 15%, say). Really? Are you considering just the rate of false positives or also the difficulty of the workarounds? > (C) In any case, the deciding factor should not be community > consensus (if such a thing can even be determined) but the > intersection of condition sets of the relevant stakeholders. If you want to put the effort into that, sure. OTOH, you'll need to revisit that decision every time a new release comes out, as they may have added new warnings or improved old ones. I can see cause for disagreement with particular warnings, but I wouldn't want to have to review _all_ of them every time we upgraded. 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-05-01 08:40 -0700 |
| Message-ID | <kfnfv7gnw6g.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61324 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 28-Apr-15 15:05, Tim Rentsch wrote: >> Stephen Sprunk <stephen@sprunk.org> writes: >>> It's related, at least. Using -Werror is predicated on the >>> warnings being reasonable, and there is such consensus for the >>> warnings in -Wall, but I would suggest that some warnings are >>> relegated to -Wextra because there _isn't_ consensus that they are >>> reasonable. IOW, you can use -Wall with -Werror, but you probably >>> shouldn't use -Wextra with -Werror. >> >> This made me wonder just what sets of conditions these two options >> include, some I did a man gcc and went through them. I would >> summarize my reactions as follows. >> >> (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio >> (+/- 15%, say). > > Really? Are you considering just the rate of false positives or > also the difficulty of the workarounds? Sorry, what I was trying to say didn't come across the way I meant it. What I mean is, of the different warning options included in the -Wall or -Wextra umbrellas, only about 50% are ones I would choose to apply during /every/ compilation. I think most are useful for occasional spot checks, but only about half should be in force all the time (and to be clear, with -Werror in force). >> (C) In any case, the deciding factor should not be community >> consensus (if such a thing can even be determined) but the >> intersection of condition sets of the relevant stakeholders. > > If you want to put the effort into that, sure. OTOH, you'll need > to revisit that decision every time a new release comes out, as > they may have added new warnings or improved old ones. I can see > cause for disagreement with particular warnings, but I wouldn't > want to have to review _all_ of them every time we upgraded. I think it's not nearly as bad as you describe. First there is no reason there has to be a review every time a new version is installed (let alone every time a new version is released, which presumably is more often). It's okay to keep using the same option set until a decision is made to review it (which may be prompted automatically, see next). Second, review of new and revised options will happen naturally through use in different areas of the development process. If an existing option is worsened to the point where it should be excluded rather than included (ie, for every compile), that will be evident immediately when new builds start breaking in stupid ways. (Sadly this has happened to me at least once.) Looking at the flip side, for new options or options that have been improved to the point where they should be added to the "every compile" list, those will be discovered looking over the results of the "spot check" compiles. Suppose for example a full set of compiles is done once a quarter using -Wall and -Wextra, just to look over all the potential trouble spots, not to do a complete build. If we take the output of those compiles and sort it by warning type (easy to do now that gcc supplies the option name along with each diagnostic, right?), any option now of sufficient quality can be added to the list. Any condition that doesn't show up at all doesn't have to be considered, because the condition doesn't appear. So the reviews you're talking about I think will happen naturally without any particular extra effort, as part of the regular development process.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-03 11:42 -0500 |
| Message-ID | <mi5iqg$8o6$2@dont-email.me> |
| In reply to | #61324 |
Stephen Sprunk wrote: > On 28-Apr-15 15:05, Tim Rentsch wrote: >> Stephen Sprunk <stephen@sprunk.org> writes: >>> It's related, at least. Using -Werror is predicated on the >>> warnings being reasonable, and there is such consensus for the >>> warnings in -Wall, but I would suggest that some warnings are >>> relegated to -Wextra because there _isn't_ consensus that they are >>> reasonable. IOW, you can use -Wall with -Werror, but you probably >>> shouldn't use -Wextra with -Werror. >> >> This made me wonder just what sets of conditions these two options >> include, some I did a man gcc and went through them. I would >> summarize my reactions as follows. >> >> (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio >> (+/- 15%, say). > > Really? Are you considering just the rate of false positives or also > the difficulty of the workarounds? > >> (C) In any case, the deciding factor should not be community >> consensus (if such a thing can even be determined) but the >> intersection of condition sets of the relevant stakeholders. > > If you want to put the effort into that, sure. OTOH, you'll need to > revisit that decision every time a new release comes out, as they may > have added new warnings or improved old ones. In my experience, you generally want to freeze the toolchain for a product. > I can see cause for > disagreement with particular warnings, but I wouldn't want to have to > review _all_ of them every time we upgraded. > > S > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-04 17:43 +1200 |
| Message-ID | <cqof7oFm5ldU1@mid.individual.net> |
| In reply to | #61436 |
Les Cargill wrote: > Stephen Sprunk wrote: >> On 28-Apr-15 15:05, Tim Rentsch wrote: >>> Stephen Sprunk <stephen@sprunk.org> writes: >>>> It's related, at least. Using -Werror is predicated on the >>>> warnings being reasonable, and there is such consensus for the >>>> warnings in -Wall, but I would suggest that some warnings are >>>> relegated to -Wextra because there _isn't_ consensus that they are >>>> reasonable. IOW, you can use -Wall with -Werror, but you probably >>>> shouldn't use -Wextra with -Werror. >>> >>> This made me wonder just what sets of conditions these two options >>> include, some I did a man gcc and went through them. I would >>> summarize my reactions as follows. >>> >>> (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio >>> (+/- 15%, say). >> >> Really? Are you considering just the rate of false positives or also >> the difficulty of the workarounds? >> >>> (C) In any case, the deciding factor should not be community >>> consensus (if such a thing can even be determined) but the >>> intersection of condition sets of the relevant stakeholders. >> >> If you want to put the effort into that, sure. OTOH, you'll need to >> revisit that decision every time a new release comes out, as they may >> have added new warnings or improved old ones. > > In my experience, you generally want to freeze the toolchain for a > product. For a product release, yes. Some products have a long lifetime so it makes sense to review the tool-chain from time to time. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-04 07:34 -0500 |
| Message-ID | <mi7okt$fnn$1@dont-email.me> |
| In reply to | #61477 |
Ian Collins wrote: > Les Cargill wrote: >> Stephen Sprunk wrote: >>> On 28-Apr-15 15:05, Tim Rentsch wrote: >>>> Stephen Sprunk <stephen@sprunk.org> writes: >>>>> It's related, at least. Using -Werror is predicated on the >>>>> warnings being reasonable, and there is such consensus for the >>>>> warnings in -Wall, but I would suggest that some warnings are >>>>> relegated to -Wextra because there _isn't_ consensus that they are >>>>> reasonable. IOW, you can use -Wall with -Werror, but you probably >>>>> shouldn't use -Wextra with -Werror. >>>> >>>> This made me wonder just what sets of conditions these two options >>>> include, some I did a man gcc and went through them. I would >>>> summarize my reactions as follows. >>>> >>>> (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio >>>> (+/- 15%, say). >>> >>> Really? Are you considering just the rate of false positives or also >>> the difficulty of the workarounds? >>> >>>> (C) In any case, the deciding factor should not be community >>>> consensus (if such a thing can even be determined) but the >>>> intersection of condition sets of the relevant stakeholders. >>> >>> If you want to put the effort into that, sure. OTOH, you'll need to >>> revisit that decision every time a new release comes out, as they may >>> have added new warnings or improved old ones. >> >> In my experience, you generally want to freeze the toolchain for a >> product. > > For a product release, yes. If it is never released, it doesn't matter much. > Some products have a long lifetime so it > makes sense to review the tool-chain from time to time. > That's fine so long as you have some sort of model for the cost & risk of doing that. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-05-08 17:12 +0300 |
| Message-ID | <87pp6brwda.fsf@bazspaz.fatphil.org> |
| In reply to | #61477 |
Ian Collins <ian-news@hotmail.com> writes: > Les Cargill wrote: > > Stephen Sprunk wrote: > >> On 28-Apr-15 15:05, Tim Rentsch wrote: > >>> Stephen Sprunk <stephen@sprunk.org> writes: > >>>> It's related, at least. Using -Werror is predicated on the > >>>> warnings being reasonable, and there is such consensus for the > >>>> warnings in -Wall, but I would suggest that some warnings are > >>>> relegated to -Wextra because there _isn't_ consensus that they are > >>>> reasonable. IOW, you can use -Wall with -Werror, but you probably > >>>> shouldn't use -Wextra with -Werror. > >>> > >>> This made me wonder just what sets of conditions these two options > >>> include, some I did a man gcc and went through them. I would > >>> summarize my reactions as follows. > >>> > >>> (A) For my money, both -Wall and -Wextra have a roughly 50% hit ratio > >>> (+/- 15%, say). > >> > >> Really? Are you considering just the rate of false positives or also > >> the difficulty of the workarounds? > >> > >>> (C) In any case, the deciding factor should not be community > >>> consensus (if such a thing can even be determined) but the > >>> intersection of condition sets of the relevant stakeholders. > >> > >> If you want to put the effort into that, sure. OTOH, you'll need to > >> revisit that decision every time a new release comes out, as they may > >> have added new warnings or improved old ones. > > > > In my experience, you generally want to freeze the toolchain for a > > product. > > For a product release, yes. Some products have a long lifetime so it > makes sense to review the tool-chain from time to time. I've worked on OSS projects since the mid noughties, and it's impossible for me to even know what compiler any of our users may be using. Nor do I know what compilation options have been selected at configuration time. At least once a week I rotate the compiler that I use, so that I don't let any warnings stay in the repo for too long. I guess I should add a gcc 5.x to my pool. Phil -- A well regulated militia, being necessary to the security of a free state, the right of the people to keep and bear arms, shall be well regulated.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web