Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #59888 > unrolled thread
| Started by | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| First post | 2015-04-10 20:54 +0000 |
| Last post | 2015-04-18 08:11 -0700 |
| Articles | 20 on this page of 211 — 35 participants |
Back to article view | Back to comp.lang.c
Problems with va_list & friends... gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-10 20:54 +0000
Re: Problems with va_list & friends... Andrew Cooper <amc96@cam.ac.uk> - 2015-04-10 22:36 +0100
Re: Problems with va_list & friends... Martin Shobe <martin.shobe@yahoo.com> - 2015-04-10 16:47 -0500
Re: Problems with va_list & friends... Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 16:50 -0500
Re: Problems with va_list & friends... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 15:33 -0700
Re: Problems with va_list & friends... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-10 23:02 +0100
Re: Problems with va_list & friends... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-11 03:00 +0000
Re: Problems with va_list & friends... gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-11 03:18 +0000
Re: Problems with va_list & friends... Richard Damon <Richard@Damon-Family.org> - 2015-04-11 00:04 -0400
Re: Problems with va_list & friends... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-11 16:02 +0000
Re: Problems with va_list & friends... Ian Collins <ian-news@hotmail.com> - 2015-04-12 08:27 +1200
Re: Problems with va_list & friends... Richard Damon <Richard@Damon-Family.org> - 2015-04-11 17:48 -0400
Re: Problems with va_list & friends... Robert Wessel <robertwessel2@yahoo.com> - 2015-04-12 01:06 -0500
Re: Problems with va_list & friends... Martin Shobe <martin.shobe@yahoo.com> - 2015-04-11 10:49 -0500
Re: Problems with va_list & friends... Lőrinczy Zsigmond <nospam@for.me> - 2015-04-12 17:58 +0200
Re: Problems with va_list & friends... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-13 17:31 +0000
Re: Problems with va_list & friends... gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-13 17:48 +0000
Re: Problems with va_list & friends... Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-14 20:26 +0000
Re: Problems with va_list & friends... Noob <root@127.0.0.1> - 2015-04-14 22:58 +0200
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 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-16 12:14 -0500 |
| Message-ID | <mgoqb0$n79$1@dont-email.me> |
| In reply to | #60126 |
Philipp Klaus Krause wrote: > On 12.04.2015 17:58, Lőrinczy Zsigmond wrote: >> To put it simply: never compile without these flags: >> -W -Wall -Wextra -Werror > > I'd rather say the opposite: > > Never compile with -Werror. And more important: never ship anything (be > it tarball, snapshots, or something in your public repository) that uses > -Werror in the build system. > > And I really can't see any advantage that -Werror would provide. On the > other hand, there are lots of disadvantages: You write perfectly fine > code today, and ship it. Tomorrow, a compiler vendor decides they don't > like the coding style you used, and emit a warning on it. Now with > -Werror compilation will fail for whoever wants to compile your code > with the latest compiler version. > I've seent his happen in GNU binutils, where it is hard o get out the > -Werror, and where there was a time when the latest released binutils > failed to compile with the latest released GCC due to -Werror turning a > "Warning: right-hand operand of comma expression has no effect" into an > error. > > Philipp > I'd say fix the errors produced by -Werror . -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-04-16 17:18 +0000 |
| Message-ID | <mgoqtf$iu6$2@news.xmission.com> |
| In reply to | #60154 |
In article <mgoqb0$n79$1@dont-email.me>, Les Cargill <lcargill99@comcast.com> wrote: ... >I'd say fix the errors produced by -Werror . I see the previous poster's point (PPP), although I don't think it is the percentage position. That is, more often than not, it will be wrong, but it will hit the bullseye occasionally. The PPP is that you can write perfectly valid, standards conforming and CLC-reg-approved, C code but some compiler somewhere might complain about it (since a compiler can complain about anything it likes and still be standards conforming - as has been pointed out many a time in CLC over the years). In that case, your build (on the foreign machine with the funky compiler) will fail - and you'd be stuck with egg on your face. -- - Since the shootings on Friday, the ultra-defensive [maybe wrongly - hyphenated, but that would be fitting] Roy "News" LIEberman has posted - at least 90 times, and almost every single post is about his obsessive - knee-jerk loonball [wacko] gun politics. How much longer before the - authorities [police] finally disable the trip wires and confiscate the - arsenal in his St. Louie hovel? So true. So true.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-16 18:43 +0100 |
| Message-ID | <mgosb6$j9$1@dont-email.me> |
| In reply to | #60154 |
On 16/04/15 18:14, Les Cargill wrote: > Philipp Klaus Krause wrote: >> On 12.04.2015 17:58, Lőrinczy Zsigmond wrote: >>> To put it simply: never compile without these flags: >>> -W -Wall -Wextra -Werror >> >> I'd rather say the opposite: >> >> Never compile with -Werror. And more important: never ship anything (be >> it tarball, snapshots, or something in your public repository) that uses >> -Werror in the build system. >> >> And I really can't see any advantage that -Werror would provide. On the >> other hand, there are lots of disadvantages: You write perfectly fine >> code today, and ship it. Tomorrow, a compiler vendor decides they don't >> like the coding style you used, and emit a warning on it. Now with >> -Werror compilation will fail for whoever wants to compile your code >> with the latest compiler version. >> I've seent his happen in GNU binutils, where it is hard o get out the >> -Werror, and where there was a time when the latest released binutils >> failed to compile with the latest released GCC due to -Werror turning a >> "Warning: right-hand operand of comma expression has no effect" into an >> error. >> >> Philipp >> > > > I'd say fix the errors produced by -Werror . > If they really are errors, sure; but what if they're not? -- 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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-16 21:03 -0500 |
| Message-ID | <mgppau$c3b$1@dont-email.me> |
| In reply to | #60162 |
Richard Heathfield wrote: > On 16/04/15 18:14, Les Cargill wrote: >> Philipp Klaus Krause wrote: >>> On 12.04.2015 17:58, Lőrinczy Zsigmond wrote: >>>> To put it simply: never compile without these flags: >>>> -W -Wall -Wextra -Werror >>> >>> I'd rather say the opposite: >>> >>> Never compile with -Werror. And more important: never ship anything (be >>> it tarball, snapshots, or something in your public repository) that uses >>> -Werror in the build system. >>> >>> And I really can't see any advantage that -Werror would provide. On the >>> other hand, there are lots of disadvantages: You write perfectly fine >>> code today, and ship it. Tomorrow, a compiler vendor decides they don't >>> like the coding style you used, and emit a warning on it. Now with >>> -Werror compilation will fail for whoever wants to compile your code >>> with the latest compiler version. >>> I've seent his happen in GNU binutils, where it is hard o get out the >>> -Werror, and where there was a time when the latest released binutils >>> failed to compile with the latest released GCC due to -Werror turning a >>> "Warning: right-hand operand of comma expression has no effect" into an >>> error. >>> >>> Philipp >>> >> >> >> I'd say fix the errors produced by -Werror . >> > > If they really are errors, sure; but what if they're not? > I rather like "zero warnings" policies. YMMV. -Werror stops the build for you. Once the code base passes a clean build with -Werror, any halts that occur after that, you know you put in. In some contexts, this can be infuriating but it's not a bad default position. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-16 23:38 -0400 |
| Message-ID | <mgpv65$4fb$1@dont-email.me> |
| In reply to | #60190 |
On 04/16/2015 10:03 PM, Les Cargill wrote: > Richard Heathfield wrote: >> On 16/04/15 18:14, Les Cargill wrote: ... >>> I'd say fix the errors produced by -Werror . I presume you meant "errors identified by"? Or perhaps "errors casing the messages printed by"? >> If they really are errors, sure; but what if they're not? > > I rather like "zero warnings" policies. ... Compilers are free to warn about things that aren't actually errors - most do. Given that fact, I prefer a more flexible policy. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-17 07:39 +0100 |
| Message-ID | <mgq9ov$2qo$1@dont-email.me> |
| In reply to | #60190 |
On 17/04/15 03:03, Les Cargill wrote: > Richard Heathfield wrote: >> On 16/04/15 18:14, Les Cargill wrote: <snip> >>> >>> >>> I'd say fix the errors produced by -Werror . >>> >> >> If they really are errors, sure; but what if they're not? >> > > > I rather like "zero warnings" policies. YMMV. No, MMDNV. I like them too. But I don't like them as much as I like good code. > -Werror stops the build > for you. Once the code base passes a clean build with -Werror, any > halts that occur after that, you know you put in. And then you may have to damage the code in order to get it to compile. That's not actually a step forward. > > In some contexts, this can be infuriating but it's not a bad > default position. I used to agree with you, but that was when I was working mostly with Visual C++, which any fool could get to compile cleanly at level 4, and mainframe compilers such as C/370, which is fairly laid back about C code too. 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, 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. That isn't ignoring the warning. That's taking due account of the warning, thinking through the issues all over again, and deciding to proceed with caution. -Werror drives a coach and horses over that, and forces you to make your code worse in order to get it to compile. -- 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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-17 13:31 -0500 |
| Message-ID | <mgrjgr$tj3$1@dont-email.me> |
| In reply to | #60198 |
On 17-Apr-15 01:39, Richard Heathfield wrote:
> On 17/04/15 03:03, Les Cargill wrote:
>> Richard Heathfield wrote:
>>> On 16/04/15 18:14, Les Cargill wrote:
>>>> I'd say fix the errors produced by -Werror .
>>>
>>> If they really are errors, sure; but what if they're not?
>>
>> I rather like "zero warnings" policies. YMMV.
>
> No, MMDNV. I like them too. But I don't like them as much as I like
> good code.
Of course; everyone likes good code.
The problem is that you may _think_ your code is good, but it actually
isn't. That's what warnings are designed to address.
>> -Werror stops the build for you. Once the code base passes a clean
>> build with -Werror, any halts that occur after that, you know you
>> put in.
>
> And then you may have to damage the code in order to get it to
> compile. That's not actually a step forward.
If you "damage" the code to get rid of warnings, you're doing it wrong.
Yes, sometimes the constructs you need to eliminate an invalid warning
can make the code _slightly_ less clear. But IMHO and IME, that is
outweighed by forcing people to fix code with _valid_ warnings.
For instance:
if (x=y) { ... }
It may be that's actually what you intended. In most cases, though,
it's a typo. And the two most common solutions really aren't any less
readable:
if ((x=y)) { ... }
if ((x=y)!=0) { ... }
The former doesn't fully convey the intent to a human reader, but it's
enough to shut GCC up. The latter does convey clearly the intent, and
eliminates the potential ambiguity in the original.
> 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, 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. That isn't ignoring the warning. That's taking due account of
> the warning, thinking through the issues all over again, and deciding
> to proceed with caution.
That's because you're apparently an excellent programmer. Most of us,
however, aren't on the same level. The vast majority of warnings I see,
both in my own code and others', are diagnosing real problems, and
eliminating them _does_ make the code better.
One large (>1M LOC) project I was involved with had _hundreds_ of
warnings on a regular build. We did test builds with -Werror, filed
lots of bugs, and forced people to fix them. It was quite painful for a
few months, but once we shipped the first clean build to customers, the
rate of customer-found defects (particularly ones we couldn't reproduce
in our lab) dropped sharply--and now we can devote more time to writing
new features that generate new revenue instead of fixing bugs in code
we've already sold. So, it was worth it.
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-17 14:46 -0400 |
| Message-ID | <5531551D.1060703@verizon.net> |
| In reply to | #60255 |
On 04/17/2015 02:31 PM, Stephen Sprunk wrote: > On 17-Apr-15 01:39, Richard Heathfield wrote: >> On 17/04/15 03:03, Les Cargill wrote: ... >>> I rather like "zero warnings" policies. YMMV. >> >> No, MMDNV. I like them too. But I don't like them as much as I like >> good code. > > Of course; everyone likes good code. > > The problem is that you may _think_ your code is good, but it actually > isn't. That's what warnings are designed to address. No, that's what error messages are designed to address. Warnings are designed to address a similar but different issue: code that has features which suggest it might be bad, but the compiler can't be sure, so it leaves it up to the developer to decide. A warning message is a reminder to the programmer that the decision needs to be made. >>> -Werror stops the build for you. Once the code base passes a clean >>> build with -Werror, any halts that occur after that, you know you >>> put in. >> >> And then you may have to damage the code in order to get it to >> compile. That's not actually a step forward. > > If you "damage" the code to get rid of warnings, you're doing it wrong. Not necessarily - the compiler could be doing it wrong - at least from the point of view that says warnings must be avoided. An inherent consequence of that view is that warnings should not be issued unless they can be avoided by re-writing the code in a way that does not damage it. Most compilers issue at least a few warnings that violate that principle. That's probably because that don't agree with that attitude. Instead, they feel that warnings are meant to be ignorable if the programmer thinks it wise to do so. If the possibility of a defect is so clear that it should never be ignored, the message reporting that possibility should be labeled as an "error message" not a "warning message".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-18 11:46 -0700 |
| Message-ID | <kfnioctw9yo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60256 |
James Kuyper <jameskuyper@verizon.net> writes: > On 04/17/2015 02:31 PM, Stephen Sprunk wrote: >> On 17-Apr-15 01:39, Richard Heathfield wrote: >>> On 17/04/15 03:03, Les Cargill wrote: > > ... > >>>> I rather like "zero warnings" policies. YMMV. >>> >>> No, MMDNV. I like them too. But I don't like them as much as I >>> like good code. >> >> Of course; everyone likes good code. >> >> The problem is that you may _think_ your code is good, but it >> actually isn't. That's what warnings are designed to address. > > No, that's what error messages are designed to address. Warnings > are designed to address a similar but different issue: code that > has features which suggest it might be bad, but the compiler can't > be sure, so it leaves it up to the developer to decide. A warning > message is a reminder to the programmer that the decision needs to > be made. uhm, reality check. That may be a useful way to think of the distinction, but it isn't how gcc actually behaves. In particular, in some cases gcc gives "warnings" for conditions that are constraint violations. There is no question that a constraint has been violated, and there shouldn't be any decision necessary about fixing it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-18 15:35 -0700 |
| Message-ID | <87y4lpoyid.fsf@kst-u.example.com> |
| In reply to | #60334 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 04/17/2015 02:31 PM, Stephen Sprunk wrote:
>>> On 17-Apr-15 01:39, Richard Heathfield wrote:
>>>> On 17/04/15 03:03, Les Cargill wrote:
>>
>> ...
>>
>>>>> I rather like "zero warnings" policies. YMMV.
>>>>
>>>> No, MMDNV. I like them too. But I don't like them as much as I
>>>> like good code.
>>>
>>> Of course; everyone likes good code.
>>>
>>> The problem is that you may _think_ your code is good, but it
>>> actually isn't. That's what warnings are designed to address.
>>
>> No, that's what error messages are designed to address. Warnings
>> are designed to address a similar but different issue: code that
>> has features which suggest it might be bad, but the compiler can't
>> be sure, so it leaves it up to the developer to decide. A warning
>> message is a reminder to the programmer that the decision needs to
>> be made.
>
> uhm, reality check. That may be a useful way to think of the
> distinction, but it isn't how gcc actually behaves. In
> particular, in some cases gcc gives "warnings" for conditions
> that are constraint violations. There is no question that a
> constraint has been violated, and there shouldn't be any
> decision necessary about fixing it.
I think that's more or less what "-pedantic-errors" is for.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 10:57 -0700 |
| Message-ID | <kfnk2x4t5ad.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60353 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> James Kuyper <jameskuyper@verizon.net> writes: >>> On 04/17/2015 02:31 PM, Stephen Sprunk wrote: >>>> On 17-Apr-15 01:39, Richard Heathfield wrote: >>>>> On 17/04/15 03:03, Les Cargill wrote: >>> >>> ... >>> >>>>>> I rather like "zero warnings" policies. YMMV. >>>>> >>>>> No, MMDNV. I like them too. But I don't like them as much as I >>>>> like good code. >>>> >>>> Of course; everyone likes good code. >>>> >>>> The problem is that you may _think_ your code is good, but it >>>> actually isn't. That's what warnings are designed to address. >>> >>> No, that's what error messages are designed to address. Warnings >>> are designed to address a similar but different issue: code that >>> has features which suggest it might be bad, but the compiler can't >>> be sure, so it leaves it up to the developer to decide. A warning >>> message is a reminder to the programmer that the decision needs to >>> be made. >> >> uhm, reality check. That may be a useful way to think of the >> distinction, but it isn't how gcc actually behaves. In >> particular, in some cases gcc gives "warnings" for conditions >> that are constraint violations. There is no question that a >> constraint has been violated, and there shouldn't be any >> decision necessary about fixing it. > > I think that's more or less what "-pedantic-errors" is for. I might agree with that _if_ the conditions in question were given diagnostics only when -pedantic is used. However that is not the case. So if we want to turn those cases into errors, but do not want to flag all the cases under -pedantic, then -pedantic-errors isn't a viable choice.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-19 11:58 +0100 |
| Message-ID | <mh01m4$nth$1@dont-email.me> |
| In reply to | #60255 |
On 17/04/15 19:31, Stephen Sprunk wrote:
> On 17-Apr-15 01:39, Richard Heathfield wrote:
>> On 17/04/15 03:03, Les Cargill wrote:
>>> Richard Heathfield wrote:
>>>> On 16/04/15 18:14, Les Cargill wrote:
>>>>> I'd say fix the errors produced by -Werror .
>>>>
>>>> If they really are errors, sure; but what if they're not?
>>>
>>> I rather like "zero warnings" policies. YMMV.
>>
>> No, MMDNV. I like them too. But I don't like them as much as I like
>> good code.
>
> Of course; everyone likes good code.
>
> The problem is that you may _think_ your code is good, but it actually
> isn't. That's what warnings are designed to address.
Right. But I may think my code is good, and it actually is. That's why
they're warnings, not errors.
For example:
x = y;
can cause a diagnostic message if, for example, y's type is wider than
x's. But if the value stored in y is known (by the nature of the
problem, or perhaps by a prior filtering if()) to be storable in x,
there is no problem, and the assignment can proceed. The compiler warns,
we look, we check, we perhaps add a comment so that we don't have to
check again next time, and we're done. What we don't do is try to find a
way to fool the compiler into thinking we've fixed the non-existent problem.
>>> -Werror stops the build for you. Once the code base passes a clean
>>> build with -Werror, any halts that occur after that, you know you
>>> put in.
>>
>> And then you may have to damage the code in order to get it to
>> compile. That's not actually a step forward.
>
> If you "damage" the code to get rid of warnings, you're doing it wrong.
I agree entirely. That's entirely my point.
> Yes, sometimes the constructs you need to eliminate an invalid warning
> can make the code _slightly_ less clear.
Then you're doing it wrong. You're making the code worse in order to
satisfy a spurious warning.
> But IMHO and IME, that is
> outweighed by forcing people to fix code with _valid_ warnings.
Fine, but MMV. If the warning is valid, I fix the code. I don't need
-Werror to bully me into doing that.
>
> For instance:
>
> if (x=y) { ... }
>
> It may be that's actually what you intended.
Yes, it may be. So let's have a warning - possibly incorrect assignment.
And then, if it's actually right, we'll add a comment that yes, we did
actually mean an assignment here.
> In most cases, though,
> it's a typo. And the two most common solutions really aren't any less
> readable:
>
> if ((x=y)) { ... }
> if ((x=y)!=0) { ... }
They are a little less readable, and they're a whole lot less readable
than a comment.
> The former doesn't fully convey the intent to a human reader, but it's
> enough to shut GCC up. The latter does convey clearly the intent, and
> eliminates the potential ambiguity in the original.
A comment is even clearer.
>
>> 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, 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. That isn't ignoring the warning. That's taking due account of
>> the warning, thinking through the issues all over again, and deciding
>> to proceed with caution.
>
> That's because you're apparently an excellent programmer.
No, it's because I'm /not/ an excellent programmer that I spend a lot of
time looking at warning messages. After all, they might be right and in
fact probably are right most of the time. On occasion, they're wrong.
When that happens, I'll write it down somewhere, but I'm not going to
change the code. I *used* to change the code, only to find that it was
like trying to flatten out a bubble in badly-put-up wallpaper - the act
of changing it very often made some other warning pop up. After a while,
it got to be silly, so I resorted to using comments instead.
> Most of us,
> however, aren't on the same level. The vast majority of warnings I see,
> both in my own code and others', are diagnosing real problems, and
> eliminating them _does_ make the code better.
Sure, but people are grown-ups. We don't need to be bullied into fixing
warnings. We fix the warnings anyway, don't we?
> One large (>1M LOC) project I was involved with had _hundreds_ of
> warnings on a regular build. We did test builds with -Werror, filed
> lots of bugs, and forced people to fix them. It was quite painful for a
> few months, but once we shipped the first clean build to customers, the
> rate of customer-found defects (particularly ones we couldn't reproduce
> in our lab) dropped sharply--and now we can devote more time to writing
> new features that generate new revenue instead of fixing bugs in code
> we've already sold. So, it was worth it.
If -Werror made any difference, forgive me but you started out with the
wrong programmers.
--
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 | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-20 10:50 -0500 |
| Message-ID | <mh375t$iue$1@dont-email.me> |
| In reply to | #60386 |
On 19-Apr-15 05:58, Richard Heathfield wrote:
> On 17/04/15 19:31, Stephen Sprunk wrote:
>> On 17-Apr-15 01:39, Richard Heathfield wrote:
>>> On 17/04/15 03:03, Les Cargill wrote:
>>>> I rather like "zero warnings" policies. YMMV.
>>>
>>> No, MMDNV. I like them too. But I don't like them as much as I
>>> like good code.
>>
>> Of course; everyone likes good code.
>>
>> The problem is that you may _think_ your code is good, but it
>> actually isn't. That's what warnings are designed to address.
>
> Right. But I may think my code is good, and it actually is. That's
> why they're warnings, not errors.
>
> For example:
>
> x = y;
>
> can cause a diagnostic message if, for example, y's type is wider
> than x's. But if the value stored in y is known (by the nature of
> the problem, or perhaps by a prior filtering if()) to be storable in
> x, there is no problem, and the assignment can proceed. The compiler
> warns, we look, we check, we perhaps add a comment so that we don't
> have to check again next time, and we're done. What we don't do is
> try to find a way to fool the compiler into thinking we've fixed the
> non-existent problem.
No reasonable (I know, I know) compiler writer would add such a warning
unless they had a way of determining when it wasn't necessary, such as
by tracking the possible range of each variable by examining the
filtering if()s.
>> In most cases, though, it's a typo. And the two most common
>> solutions really aren't any less readable:
>>
>> if ((x=y)) { ... }
>> if ((x=y)!=0) { ... }
>
> They are a little less readable, and they're a whole lot less
> readable than a comment.
>
>> The former doesn't fully convey the intent to a human reader, but
>> it's enough to shut GCC up. The latter does convey clearly the
>> intent, and eliminates the potential ambiguity in the original.
>
> A comment is even clearer.
IMHO, one should never express in comments what one can express in the
code itself because the compiler can only read the latter; if you don't
give it the full picture, it can't do as good a job.
So, I'd prefer the second solution above because it expresses the true
intent of the code to both the compiler _and_ programmers. While I
agree that it's slightly less readable, it's more expressive, and that
is a reasonable tradeoff.
>> Most of us, however, aren't on the same level. The vast majority
>> of warnings I see, both in my own code and others', are diagnosing
>> real problems, and eliminating them _does_ make the code better.
>
> Sure, but people are grown-ups. We don't need to be bullied into
> fixing warnings. We fix the warnings anyway, don't we?
IME, most average programmers do not. Heck, most of them don't even
seem to compile their code with warnings enabled at all.
>> One large (>1M LOC) project I was involved with had _hundreds_ of
>> warnings on a regular build. We did test builds with -Werror,
>> filed lots of bugs, and forced people to fix them. It was quite
>> painful for a few months, but once we shipped the first clean build
>> to customers, the rate of customer-found defects (particularly ones
>> we couldn't reproduce in our lab) dropped sharply--and now we can
>> devote more time to writing new features that generate new revenue
>> instead of fixing bugs in code we've already sold. So, it was
>> worth it.
>
> If -Werror made any difference, forgive me but you started out with
> the wrong programmers.
Not everyone can be a rock star; most programmers are average, so if we
only hired rock stars, we'd be ten years behind schedule--or bankrupt.
We make do with the resources available, and experience shows that using
-Werror delivers better results in practice, regardless of how much I
may agree with you in theory.
For the record, I despise "zero tolerance" policies, such as expelling
girls from school for having a bottle of Midol. But we've tried it the
other way, and that didn't work because kids quickly learned to put
their other drugs in Midol bottles. Nobody actually cared about Midol;
they cared about putting a fence in front of the slippery slope.
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 17:55 +0100 |
| Message-ID | <mh3b0i$2rp$1@dont-email.me> |
| In reply to | #60532 |
On 20/04/15 16:50, Stephen Sprunk wrote: > On 19-Apr-15 05:58, Richard Heathfield wrote: >> On 17/04/15 19:31, Stephen Sprunk wrote: >>> On 17-Apr-15 01:39, Richard Heathfield wrote: >>>> On 17/04/15 03:03, Les Cargill wrote: >>>>> I rather like "zero warnings" policies. YMMV. >>>> >>>> No, MMDNV. I like them too. But I don't like them as much as I >>>> like good code. >>> >>> Of course; everyone likes good code. >>> >>> The problem is that you may _think_ your code is good, but it >>> actually isn't. That's what warnings are designed to address. >> >> Right. But I may think my code is good, and it actually is. That's >> why they're warnings, not errors. >> >> For example: >> >> x = y; >> >> can cause a diagnostic message if, for example, y's type is wider >> than x's. But if the value stored in y is known (by the nature of >> the problem, or perhaps by a prior filtering if()) to be storable in >> x, there is no problem, and the assignment can proceed. The compiler >> warns, we look, we check, we perhaps add a comment so that we don't >> have to check again next time, and we're done. What we don't do is >> try to find a way to fool the compiler into thinking we've fixed the >> non-existent problem. > > No reasonable (I know, I know) compiler writer would add such a warning > unless they had a way of determining when it wasn't necessary, such as > by tracking the possible range of each variable by examining the > filtering if()s. It seems we all have ways to deal with warnings we don't agree with. I document my code so that people can go from the warning to the code and see for themselves why it's not a problem. Your method is more subtle - you insist that All Warnings Are Errors, but then make sure you choose a "reasonable" compiler - presumably one that doesn't generate warnings you don't like. I know it sounds silly, but I really do prefer my way. -- 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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-17 23:01 -0500 |
| Message-ID | <mgskj3$2p8$1@dont-email.me> |
| In reply to | #60198 |
Richard Heathfield wrote: > On 17/04/15 03:03, Les Cargill wrote: >> Richard Heathfield wrote: >>> On 16/04/15 18:14, Les Cargill wrote: > <snip> >>>> >>>> >>>> I'd say fix the errors produced by -Werror . >>>> >>> >>> If they really are errors, sure; but what if they're not? >>> >> >> >> I rather like "zero warnings" policies. YMMV. > > No, MMDNV. I like them too. But I don't like them as much as I like good > code. > >> -Werror stops the build >> for you. Once the code base passes a clean build with -Werror, any >> halts that occur after that, you know you put in. > > And then you may have to damage the code in order to get it to compile. > That's not actually a step forward. > >> >> In some contexts, this can be infuriating but it's not a bad >> default position. > > I used to agree with you, but that was when I was working mostly with > Visual C++, which any fool could get to compile cleanly at level 4, and > mainframe compilers such as C/370, which is fairly laid back about C > code too. > > 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. > 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. > That isn't > ignoring the warning. That's taking due account of the warning, thinking > through the issues all over again, and deciding to proceed with caution. > Understood again. > -Werror drives a coach and horses over that, and forces you to make your > code worse in order to get it to compile. > 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. 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. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-18 00:24 -0500 |
| Message-ID | <9vp3jahj3ccqg5mcphtlib64coaaihcf41@4ax.com> |
| In reply to | #60292 |
On Fri, 17 Apr 2015 23:01:14 -0500, Les Cargill
<lcargill99@comcast.com> wrote:
>Richard Heathfield wrote:
>> On 17/04/15 03:03, Les Cargill wrote:
>>> Richard Heathfield wrote:
>>>> On 16/04/15 18:14, Les Cargill wrote:
>> <snip>
>>>>>
>>>>>
>>>>> I'd say fix the errors produced by -Werror .
>>>>>
>>>>
>>>> If they really are errors, sure; but what if they're not?
>>>>
>>>
>>>
>>> I rather like "zero warnings" policies. YMMV.
>>
>> No, MMDNV. I like them too. But I don't like them as much as I like good
>> code.
>>
>>> -Werror stops the build
>>> for you. Once the code base passes a clean build with -Werror, any
>>> halts that occur after that, you know you put in.
>>
>> And then you may have to damage the code in order to get it to compile.
>> That's not actually a step forward.
>>
>>>
>>> In some contexts, this can be infuriating but it's not a bad
>>> default position.
>>
>> I used to agree with you, but that was when I was working mostly with
>> Visual C++, which any fool could get to compile cleanly at level 4, and
>> mainframe compilers such as C/370, which is fairly laid back about C
>> code too.
>>
>> 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.
>
>> 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.
>
>> That isn't
>> ignoring the warning. That's taking due account of the warning, thinking
>> through the issues all over again, and deciding to proceed with caution.
>>
>
>Understood again.
>
>> -Werror drives a coach and horses over that, and forces you to make your
>> code worse in order to get it to compile.
>>
>
>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.
>
>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.
I personally come down on the side of not allowing any warnings, and
-Werror or -WX is an enforcement mechanism. It does cause problems at
times, and I've seen compilers generate unnecessary warnings that
appeared to have no way (other than perhaps a major restructuring of
the application) to resolve. MSVC, for example, will warn if you have
a "do {...} while (0)". The problem is that's a common idiom for
wrapping a chunk of code in a macro. So there's a pragma disabling
that error in a number of source modules. I'm certain that sooner or
later I'm going to find a compiler warning about that pragma...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-18 07:50 -0400 |
| Message-ID | <mgtgbv$gvj$1@dont-email.me> |
| In reply to | #60292 |
On 04/18/2015 12:01 AM, Les Cargill wrote: > Richard Heathfield wrote: ... >> 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? It isn't broken. >> 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. "You missed something" is always a possibility. At some point you've paid enough attention to an issue to justify ignoring that possibility. He's asserting that he did pay that amount of attention. Do you have a credible reason for doubting that he did? The fact the compiler chose to issue a warning does not, in my books, count as sufficient evidence to discount his judgment. ... > 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. > > 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. Warning are sufficient to avoid getting complacent. Making them fatal gives them more power than they deserve. Warning messages are supposed to be ignorable after due consideration - if not, they should be error messages, and as such, unaffected by -Werrer. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-18 11:56 -0700 |
| Message-ID | <kfnegnhw9hz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60292 |
Les Cargill <lcargill99@comcast.com> writes: > Richard Heathfield wrote: >> On 17/04/15 03:03, Les Cargill wrote: >>> Richard Heathfield wrote: >>>> On 16/04/15 18:14, Les Cargill wrote: >> >> <snip> >>>>> >>>>> >>>>> I'd say fix the errors produced by -Werror . >>>> >>>> If they really are errors, sure; but what if they're not? >>> >>> I rather like "zero warnings" policies. YMMV. >> >> No, MMDNV. I like them too. But I don't like them as much as I >> like good code. >> >>> -Werror stops the build for you. Once the code base passes a >>> clean build with -Werror, any halts that occur after that, you >>> know you put in. >> >> And then you may have to damage the code in order to get it to >> compile. That's not actually a step forward. >> >>> In some contexts, this can be infuriating but it's not a bad >>> default position. >> >> I used to agree with you, but that was when I was working mostly >> with Visual C++, which any fool could get to compile cleanly at >> level 4, and mainframe compilers such as C/370, which is fairly >> laid back about C code too. >> >> 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. > >> 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. > >> That isn't ignoring the warning. That's taking due account of >> the warning, thinking through the issues all over again, and >> deciding to proceed with caution. > > Understood again. > >> -Werror drives a coach and horses over that, and forces you to >> make your code worse in order to get it to compile. > > 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. > > 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. I agree that priorities have been hijacked, but it is -Wall and -Wextra that hijacked them, not -Werror. Using -Werror just forces you to face the consequences of the bad decision of always using -Wall and -Wextra, rather than using them only occasionally as spot checks.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-19 14:59 +0100 |
| Message-ID | <mh0caf$t34$1@dont-email.me> |
| In reply to | #60292 |
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? Not 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. >> 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. <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. > > 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. 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. -- 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 | 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]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web