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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-10 07:40 -0700 |
| Message-ID | <kfnd228fqcb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61764 |
Phil Carmody <pc+usenet@asdf.org> writes: > Ian Collins <ian-news@hotmail.com> writes: >> Les Cargill wrote: >> [snip] >>> 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. Do you mind if I ask what some of those are? > 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. Have you tried setting up a comprehensive target that builds with multiple compilers (potentially all) so you get everything at once (perhaps only on nightly builds)? I've been doing that lately and I find it very helpful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-04 08:49 -0700 |
| Message-ID | <87bni0mjgh.fsf@kst-u.example.com> |
| In reply to | #61436 |
Les Cargill <lcargill99@comcast.com> writes:
[...]
> In my experience, you generally want to freeze the toolchain for a
> product.
That's assuming you can control the toolchain. For open source
software, the toolchain is whatever your your users decide to use.
Though you could always include a disclaimer that your software has
only been tested with some particular toolchain.
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-05-04 12:23 -0500 |
| Message-ID | <mi89j5$lf5$1@dont-email.me> |
| In reply to | #61505 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: > [...] >> In my experience, you generally want to freeze the toolchain for a >> product. > > That's assuming you can control the toolchain. I cannot imagine not being able to. Yes, I mean FPGA guys too. > For open source > software, the toolchain is whatever your your users decide to use. Then they're on the hook for this issue, although you may well get calls/emails/postings. And i really sort of assumed we're talking about real work here - real deployable full systems, not the sort of thing open source is more famous for. You're just in a slightly different constituency than most open source users. Even for production systems that use open source, I'd think they'd lock down versions or they'd never actually get finished. > Though you could always include a disclaimer that your software has > only been tested with some particular toolchain. > Yeah, I am not 100% sure how you'd manage this. I know that for anything I was on, we'd freeze it. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-04-20 07:49 -0500 |
| Message-ID | <mh2s8v$876$1@dont-email.me> |
| In reply to | #60472 |
James Kuyper wrote: > 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. Yes. > However, > if by "step on something" you mean "write perfectly good code that > happens to trigger a warning message", then the answer is "No".' > Somehow, you're never gonna convince me that code that generates a warning is "perfectly good" because I have certain ideas about the meaning of the word "perfect". >> 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. > The rule "your code should have no warnings" is a normative, process based one. If you have such a rule to work with, then it's not "bad code" to fix the warning. If you make a change to fix a warning, it should not affect the object code output in any meaningful way. Indeed, you should be able to demonstrate that by inspection of the object/assembly code. Here's the critical detail - if it *does* affect the generated code, then you have a deeper problem to deal with. If we're using risk as a steering principle, then warnings are not something you can easily discard. > ... >>> 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. And I remain skeptical of that idea. That code may be "simpler" - lacking a cast or something - but I don't see how that's necessarily better. > That becomes a "worse is better" argument only if you take it > as a matter of dogma (or perhaps, as a matter of definition), that code > which triggers a warning message can always be made better by a re-write > which avoids the warning. But such dogma exists. It's used as an operating principle in places. What I called a "zero warnings policy" is just such dogma. > 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. > None of that is necessary. If there's a shop expectation that there won't be warnings, then it is what it is. It's more a sop to the expectation of team members than to anything else. You're requiring everyone to know that this warning is a "good warning" from now until the code base falls out of use. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 14:27 +0100 |
| Message-ID | <mh2uqv$i6c$1@dont-email.me> |
| In reply to | #60518 |
On 20/04/15 13:49, Les Cargill wrote: > James Kuyper wrote: >> 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> > > Somehow, you're never gonna convince me that code that generates a > warning is "perfectly good" because I have certain ideas about the > meaning of the word "perfect". You appear to define "perfect" code as code that does not generate warnings (always assuming, of course, that the code fulfils the purpose required of it!), and therefore any code that generates a warning cannot be as code that does not generate a warning. That's an understandable position (indeed, it's a position I once held). Now, what would you do if, in the next release of your compiler of choice, a new warning were to be introduced in which the addition of two unsigned integers (of any unsigned integer type) were to produce a diagnostic message such as this: foo.c:248:18: warning: addition of unsigned integer types can result in a value lower than either operand (-Waddition-of-unsigned-integer-types) This warning is quite right - it is indeed possible for the described result to occur, and there are certainly circumstances in which it may be a problem. Your code requires you to add two unsigned integers together. It may be that you actually /want/ the wraparound behaviour (modular arithmetic), or it may be that you happen to know that the values in question cannot possibly sum to such a value that wraparound occurs. How do you solve this problem? You can't cast your way out because you need integer precision (so you can't use float or double) so the only thing you could cast to that might not generate the warning would be a signed integer type, which dumps you right into the world of undefined behaviour. You can't break up the line into: x = firstnum; x += secondnum; because the warning happens for += too, not just for +. You could tell the compiler not to generate that warning - but this brings problems of its own: (a) you tell the compiler at the command switch level (in which case you turn off the warning for /all/ occurrences, not just the ones you know aren't a problem; (b) you tell the compiler via, say, a pragma, in which case you introduce a portability problem; (c) there is the philosophical dilemma that, if you're prepared to switch a warning OFF in order to silence it, you have no real grounds for complaint against people who simply take note of the warning and then decide (after due consideration) not to act upon it - they are at least reading the message, whereas you would, by switching the warning off, be sticking your metaphorical fingers in your metaphorical ears. So what can you do? Personally, I can't think of any way out (other than allowing the warning to be displayed), but I'd be interested to hear your views. <snip> > The rule "your code should have no warnings" is a normative, process > based one. If you have such a rule to work with, then it's not "bad > code" to fix the warning. Actually, it's not only bad code but also a bad process, if the process requires you to make the code less readable in order to silence a spurious warning. > If you make a change to fix a warning, it should not affect the object > code output in any meaningful way. Indeed, you should be able to > demonstrate that by inspection of the object/assembly code. What it affects is the readability of the code. It therefore increases the cost of maintaining that code. > Here's the critical detail - if it *does* affect the generated code, > then you have a deeper problem to deal with. If we're using risk as a > steering principle, then warnings are not something you can easily > discard. What if the cost of the expected risk is lower than the cost of increased maintenance time? <snip> >>> 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. > > And I remain skeptical of that idea. That code may be "simpler" - > lacking a cast or something - but I don't see how that's necessarily > better. It isn't /necessarily/ better. If the code can be /improved/ by changing it to silence the warning, great, let's do that! You, however, are arguing that code that produces a warning is /necessarily/ worse than code that does not produce that warning, and here I must disagree. > >> That becomes a "worse is better" argument only if you take it >> as a matter of dogma (or perhaps, as a matter of definition), that code >> which triggers a warning message can always be made better by a re-write >> which avoids the warning. > > But such dogma exists. It's used as an operating principle in places. Yes. And, like all dogma, the possibility exists that it is false and short-sighted. > What I called a "zero warnings policy" is just such dogma. Indeed. <snip> > None of that is necessary. If there's a shop expectation that there > won't be warnings, then it is what it is. It's more a sop to the > expectation of team members than to anything else. Right. If your house style says "no warnings", then you have a limited number of choices: 1) get the house style changed (this is my preferred option); 2) shut up and get coding, and to hell with the quality; 3) walk. > You're requiring everyone to know that this warning is a "good > warning" from now until the code base falls out of use. That's (partly) what comments are for. -- 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 09:39 -0500 |
| Message-ID | <mh3321$342$1@dont-email.me> |
| In reply to | #60523 |
On 20-Apr-15 08:27, Richard Heathfield wrote: > On 20/04/15 13:49, Les Cargill wrote: >> The rule "your code should have no warnings" is a normative, >> process based one. If you have such a rule to work with, then it's >> not "bad code" to fix the warning. > > Actually, it's not only bad code but also a bad process, if the > process requires you to make the code less readable in order to > silence a spurious warning. You're assuming that silencing the warning makes the code less readable. Also, IMHO the metric should be that the cost of changing the code is greater than the cost (to every person who builds the code for all eternity) of determining the warning is spurious, which is a rather high bar for long-lived projects with large teams. Do you have such an example? >> And I remain skeptical of that idea. That code may be "simpler" - >> lacking a cast or something - but I don't see how that's >> necessarily better. > > It isn't /necessarily/ better. If the code can be /improved/ by > changing it to silence the warning, great, let's do that! You, > however, are arguing that code that produces a warning is > /necessarily/ worse than code that does not produce that warning, and > here I must disagree. IME, if the compiler is concerned about the potential meaning of the code, then so will at least some of the programmers who will have to maintain it. Then again, I've never run into a truly spurious warning, nor one that can only be silenced by making the code materially less readable. 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:48 +0100 |
| Message-ID | <mh3ain$cb$1@dont-email.me> |
| In reply to | #60529 |
On 20/04/15 15:39, Stephen Sprunk wrote: > On 20-Apr-15 08:27, Richard Heathfield wrote: >> On 20/04/15 13:49, Les Cargill wrote: >>> The rule "your code should have no warnings" is a normative, >>> process based one. If you have such a rule to work with, then it's >>> not "bad code" to fix the warning. >> >> Actually, it's not only bad code but also a bad process, if the >> process requires you to make the code less readable in order to >> silence a spurious warning. > > You're assuming that silencing the warning makes the code less readable. Let's map it out: Situation A: warning fires, code rewritten to silence warning, code is now more readable Situation B: warning fires, code rewritten to silence warning, code is now as readable as before Situation C: warning fires, code rewritten to silence warning, code is now less readable I have no problem with the first two situations - if Les insists I rewrite the code to silence the warning and I can do so by making the code at least as readable or more so, I will happily do it. Les's process and mine both work just fine in those scenarios. It is therefore only the third case that is under discussion. > Also, IMHO the metric should be that the cost of changing the code is > greater than the cost (to every person who builds the code for all > eternity) of determining the warning is spurious, which is a rather high > bar for long-lived projects with large teams. You have two lines of code. Each of them /might/ have a problem. For one of them, you get a diagnostic message, a file name, a line number, and a comment explaining why the diagnostic message can on this occasion safely be set aside. For the other, you don't get any of that information. Which is easier (therefore cheaper) to check? > Do you have such an example? Code that can generate a spurious warning? Sure. So do you. Your entire code base is packed with statements that could generate a spurious warning. And, assuming you're getting a clean compile now, at your next compiler upgrade you might not be any more. > >>> And I remain skeptical of that idea. That code may be "simpler" - >>> lacking a cast or something - but I don't see how that's >>> necessarily better. >> >> It isn't /necessarily/ better. If the code can be /improved/ by >> changing it to silence the warning, great, let's do that! You, >> however, are arguing that code that produces a warning is >> /necessarily/ worse than code that does not produce that warning, and >> here I must disagree. > > IME, if the compiler is concerned about the potential meaning of the > code, then so will at least some of the programmers who will have to > maintain it. I sure hope so. And I hope they'll go to the comment, and read it, and check to see whether it's right. And I hope they'll do the same for every other line of code, too, diagnostic message or no. <snip> -- 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 15:58 -0500 |
| Message-ID | <mh3p72$vp4$1@dont-email.me> |
| In reply to | #60536 |
On 20-Apr-15 11:48, Richard Heathfield wrote: > On 20/04/15 15:39, Stephen Sprunk wrote: >> On 20-Apr-15 08:27, Richard Heathfield wrote: >>> Actually, it's not only bad code but also a bad process, if the >>> process requires you to make the code less readable in order to >>> silence a spurious warning. >> >> You're assuming that silencing the warning makes the code less >> readable. > > Let's map it out: > > Situation A: warning fires, code rewritten to silence warning, code is > now more readable > Situation B: warning fires, code rewritten to silence warning, code is > now as readable as before > Situation C: warning fires, code rewritten to silence warning, code is > now less readable > > I have no problem with the first two situations - if Les insists I > rewrite the code to silence the warning and I can do so by making the > code at least as readable or more so, I will happily do it. Les's > process and mine both work just fine in those scenarios. > > It is therefore only the third case that is under discussion. Okay, at least we're agreed on that much; it wasn't clear from your more absolute statement above. >> Also, IMHO the metric should be that the cost of changing the code >> is greater than the cost (to every person who builds the code for >> all eternity) of determining the warning is spurious, which is a >> rather high bar for long-lived projects with large teams. > > You have two lines of code. Each of them /might/ have a problem. For > one of them, you get a diagnostic message, a file name, a line > number, and a comment explaining why the diagnostic message can on > this occasion safely be set aside. For the other, you don't get any > of that information. Which is easier (therefore cheaper) to check? Zero work is always easier (and cheaper) than non-zero work. If there are warnings on a build, that means hundreds of people each doing several builds _per day_ have to look at each of those warnings and dismiss them every time--and there is the chance that, in all that clutter, they'll miss a _new_ warning that _isn't_ spurious. If the build is normally clean, then _any_ warning is notable and someone (hopefully the person responsible) will address it. Yes, there is a chance that the warning is spurious and the workaround may make the code less readable, but IMHO that is outweighed by the benefits. >> Do you have such an example? > > Code that can generate a spurious warning? Sure. So do you. Your > entire code base is packed with statements that could generate a > spurious warning. And, assuming you're getting a clean compile now, > at your next compiler upgrade you might not be any more. Fair enough, but I was looking for real-world examples, not a theoretical bogeyman. We regularly upgrade compilers, and it's rarely an issue. Sure, some new warnings appear each time, but most are legitimate problems that had been lurking for years, so it's a net win, even if _some_ of them are spurious and we have to invest some time in applying workarounds. If it didn't pay off in practice, we wouldn't do 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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 22:25 +0100 |
| Message-ID | <mh3qra$6m9$1@dont-email.me> |
| In reply to | #60574 |
On 20/04/15 21:58, Stephen Sprunk wrote: > On 20-Apr-15 11:48, Richard Heathfield wrote: >> On 20/04/15 15:39, Stephen Sprunk wrote: >>> On 20-Apr-15 08:27, Richard Heathfield wrote: >>>> Actually, it's not only bad code but also a bad process, if the >>>> process requires you to make the code less readable in order to >>>> silence a spurious warning. >>> >>> You're assuming that silencing the warning makes the code less >>> readable. >> >> Let's map it out: >> >> Situation A: warning fires, code rewritten to silence warning, code is >> now more readable >> Situation B: warning fires, code rewritten to silence warning, code is >> now as readable as before >> Situation C: warning fires, code rewritten to silence warning, code is >> now less readable >> >> I have no problem with the first two situations - if Les insists I >> rewrite the code to silence the warning and I can do so by making the >> code at least as readable or more so, I will happily do it. Les's >> process and mine both work just fine in those scenarios. >> >> It is therefore only the third case that is under discussion. > > Okay, at least we're agreed on that much; it wasn't clear from your more > absolute statement above. > >>> Also, IMHO the metric should be that the cost of changing the code >>> is greater than the cost (to every person who builds the code for >>> all eternity) of determining the warning is spurious, which is a >>> rather high bar for long-lived projects with large teams. >> >> You have two lines of code. Each of them /might/ have a problem. For >> one of them, you get a diagnostic message, a file name, a line >> number, and a comment explaining why the diagnostic message can on >> this occasion safely be set aside. For the other, you don't get any >> of that information. Which is easier (therefore cheaper) to check? > > Zero work is always easier (and cheaper) than non-zero work. So the line that was hastily changed to gag the warning receives no scrutiny. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 13:22 -0400 |
| Message-ID | <553535D5.5060200@verizon.net> |
| In reply to | #60529 |
On 04/20/2015 10:39 AM, Stephen Sprunk wrote:
> On 20-Apr-15 08:27, Richard Heathfield wrote:
...
>> Actually, it's not only bad code but also a bad process, if the
>> process requires you to make the code less readable in order to
>> silence a spurious warning.
>
> You're assuming that silencing the warning makes the code less readable.
>
> Also, IMHO the metric should be that the cost of changing the code is
> greater than the cost (to every person who builds the code for all
> eternity) of determining the warning is spurious, which is a rather high
> bar for long-lived projects with large teams.
>
> Do you have such an example?
The example he gave in the very same message you were responding to
seems an excellent one. What re-write would you propose to the following
line:
c = a + b;
in order to avoid the following warning?:
> foo.c:248:18: warning: addition of unsigned integer types can result in
> a value lower than either operand (-Waddition-of-unsigned-integer-types)
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 11:15 -0700 |
| Message-ID | <f61ad10b-3b23-481e-9bf2-66e3370aebae@googlegroups.com> |
| In reply to | #60540 |
On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: > On 04/20/2015 10:39 AM, Stephen Sprunk wrote: > > On 20-Apr-15 08:27, Richard Heathfield wrote: > ... > >> Actually, it's not only bad code but also a bad process, if the > >> process requires you to make the code less readable in order to > >> silence a spurious warning. > > > > You're assuming that silencing the warning makes the code less readable. > > > > Also, IMHO the metric should be that the cost of changing the code is > > greater than the cost (to every person who builds the code for all > > eternity) of determining the warning is spurious, which is a rather high > > bar for long-lived projects with large teams. > > > > Do you have such an example? > > The example he gave in the very same message you were responding to > seems an excellent one. What re-write would you propose to the following > line: > > c = a + b; > > in order to avoid the following warning?: > > > foo.c:248:18: warning: addition of unsigned integer types can result in > > a value lower than either operand (-Waddition-of-unsigned-integer-types) Wasn't it purely hypothetical and especially constructed example? Most programmers silence such warning from command line and some also ridicule compiler vendor about it in forums. Since compiler is subject of competition it is unlikely that such outcome is desirable to compiler writers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 15:02 -0400 |
| Message-ID | <55354D5F.8070805@verizon.net> |
| In reply to | #60553 |
On 04/20/2015 02:15 PM, Öö Tiib wrote: > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: ... >> The example he gave in the very same message you were responding to >> seems an excellent one. What re-write would you propose to the following >> line: >> >> c = a + b; >> >> in order to avoid the following warning?: >> >>> foo.c:248:18: warning: addition of unsigned integer types can result in >>> a value lower than either operand (-Waddition-of-unsigned-integer-types) > > Wasn't it purely hypothetical and especially constructed example? Most It's not very different from examples I've seen in real life, so the fact that it's hypothetical doesn't bother me. I'd prefer a real life example (and have in fact given two), but this particular hypothetical doesn't strike as particularly implausible. > programmers silence such warning from command line and some also > ridicule compiler vendor about it in forums. Since compiler is subject of > competition it is unlikely that such outcome is desirable to compiler > writers. I work under rules that prohibit the disabling of warning messages. That makes it harder to hide the fact that they're being ignored from Configuration Management (who keep track of all updates). I have no desire to hide the fact that I'm ignoring particular warning messages, and in fact the documentation for building my programs frequently mentions the messages being ignored, and explains why its a good idea to ignore them. None of the current reasons I have for ignoring the particular error messages I am ignoring would justify ridiculing the vendor (though I have seen some ridiculous cases in the past). They've written code that attempts to identify problems, and it unavoidably produces some false positives or false negatives (in some cases, both). I can understand what my code does in ways that the compiler can't (and vice versa!), so I know the code is safe, even though compiler isn't sure. That's what warnings are for - if the compiler were certain, it should have issued an error message.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 12:51 -0700 |
| Message-ID | <540b9762-9b9e-462c-8a99-5b7b5ef85c24@googlegroups.com> |
| In reply to | #60557 |
On Monday, 20 April 2015 22:03:08 UTC+3, James Kuyper wrote: > On 04/20/2015 02:15 PM, Öö Tiib wrote: > > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: > ... > >> The example he gave in the very same message you were responding to > >> seems an excellent one. What re-write would you propose to the following > >> line: > >> > >> c = a + b; > >> > >> in order to avoid the following warning?: > >> > >>> foo.c:248:18: warning: addition of unsigned integer types can result in > >>> a value lower than either operand (-Waddition-of-unsigned-integer-types) > > > > Wasn't it purely hypothetical and especially constructed example? Most > > It's not very different from examples I've seen in real life, so the > fact that it's hypothetical doesn't bother me. I'd prefer a real life > example (and have in fact given two), but this particular hypothetical > doesn't strike as particularly implausible. You don't consider a warning for every addition of two 'size_t' values as particularly implausible? It would produce piles of garbage diagnostics for most of code bases. > > programmers silence such warning from command line and some also > > ridicule compiler vendor about it in forums. Since compiler is subject of > > competition it is unlikely that such outcome is desirable to compiler > > writers. > > I work under rules that prohibit the disabling of warning messages. That > makes it harder to hide the fact that they're being ignored from > Configuration Management (who keep track of all updates). I have no > desire to hide the fact that I'm ignoring particular warning messages, > and in fact the documentation for building my programs frequently > mentions the messages being ignored, and explains why its a good idea to > ignore them. > > None of the current reasons I have for ignoring the particular error > messages I am ignoring would justify ridiculing the vendor (though I > have seen some ridiculous cases in the past). They've written code that > attempts to identify problems, and it unavoidably produces some false > positives or false negatives (in some cases, both). I can understand > what my code does in ways that the compiler can't (and vice versa!), so > I know the code is safe, even though compiler isn't sure. That's what > warnings are for - if the compiler were certain, it should have issued > an error message. That is the usual case unlike example under discussion. It is not clear if the code is safe or unsafe. It may be possible to rewrite it in manner that it becomes more clear that it is safe. Doesn't it make the code more robust? For me robustness of code tends to be among most desirable features. So it seems to be worth to try.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 21:17 +0100 |
| Message-ID | <mh3mq8$ma6$1@dont-email.me> |
| In reply to | #60561 |
On 20/04/15 20:51, Öö Tiib wrote:
> On Monday, 20 April 2015 22:03:08 UTC+3, James Kuyper wrote:
>> On 04/20/2015 02:15 PM, Öö Tiib wrote:
>> > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote:
>> ...
>> >> The example he gave in the very same message you were responding to
>> >> seems an excellent one. What re-write would you propose to the following
>> >> line:
>> >>
>> >> c = a + b;
>> >>
>> >> in order to avoid the following warning?:
>> >>
>> >>> foo.c:248:18: warning: addition of unsigned integer types can result in
>> >>> a value lower than either operand (-Waddition-of-unsigned-integer-types)
>> >
>> > Wasn't it purely hypothetical and especially constructed example? Most
>>
>> It's not very different from examples I've seen in real life, so the
>> fact that it's hypothetical doesn't bother me. I'd prefer a real life
>> example (and have in fact given two), but this particular hypothetical
>> doesn't strike as particularly implausible.
>
> You don't consider a warning for every addition of two 'size_t' values
> as particularly implausible? It would produce piles of garbage
> diagnostics for most of code bases.
It's no more implausible than diagnosing struct foo aggregate = {0},
which is an existing gcc warning, and it does indeed produce a great
many diagnostic messages.
<snip>
>> None of the current reasons I have for ignoring the particular error
>> messages I am ignoring would justify ridiculing the vendor (though I
>> have seen some ridiculous cases in the past). They've written code that
>> attempts to identify problems, and it unavoidably produces some false
>> positives or false negatives (in some cases, both). I can understand
>> what my code does in ways that the compiler can't (and vice versa!), so
>> I know the code is safe, even though compiler isn't sure. That's what
>> warnings are for - if the compiler were certain, it should have issued
>> an error message.
>
> That is the usual case unlike example under discussion. It is not clear
> if the code is safe or unsafe. It may be possible to rewrite it in manner
> that it becomes more clear that it is safe. Doesn't it make the code
> more robust? For me robustness of code tends to be among most desirable
> features. So it seems to be worth to try.
Please show me how, for the hypothetical example I gave. (I really,
truly can't think of a way.)
Or, if you prefer, show me how to initialise all the elements of a
struct to static defaults without triggering a warning and without
switching off the warning (and without bullying the gcc guys!) and
without having to list the members of the struct and thus introducing a
maintenance headache. C90 please - it has to work everywhere, not just
in C99land and C11land.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-20 16:09 -0700 |
| Message-ID | <87618qo0rn.fsf@kst-u.example.com> |
| In reply to | #60563 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/04/15 20:51, Öö Tiib wrote:
[...]
>> You don't consider a warning for every addition of two 'size_t' values
>> as particularly implausible? It would produce piles of garbage
>> diagnostics for most of code bases.
>
> It's no more implausible than diagnosing struct foo aggregate = {0},
> which is an existing gcc warning, and it does indeed produce a great
> many diagnostic messages.
[...]
Apparently that warning has been improved. With a small program
including the following lines:
struct foo obj0 = { 0 };
struct foo obj1 = { 1 };
gcc 4.4.5 warns about both lines, but gcc 4.8.2 only warns about the
second. Apparently it recognizes { 0 } as the idiom that it is.
(I haven't taken the time to track down exactly which option enables the
warning or which version of gcc made the change.)
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-21 00:33 +0100 |
| Message-ID | <mh429v$23r$1@dont-email.me> |
| In reply to | #60587 |
On 21/04/15 00:09, Keith Thompson wrote:
<snip>
> Apparently that warning has been improved. With a small program
> including the following lines:
>
> struct foo obj0 = { 0 };
> struct foo obj1 = { 1 };
>
> gcc 4.4.5 warns about both lines, but gcc 4.8.2 only warns about the
> second. Apparently it recognizes { 0 } as the idiom that it is.
That's a definite improvement.
> (I haven't taken the time to track down exactly which option enables the
> warning or which version of gcc made the change.)
Well, I can help you narrow it down a bit -- gcc 4.6.3 does /not/ have
that improvement.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-20 16:26 -0400 |
| Message-ID | <55356106.4080309@verizon.net> |
| In reply to | #60561 |
On 04/20/2015 03:51 PM, Öö Tiib wrote:
> On Monday, 20 April 2015 22:03:08 UTC+3, James Kuyper wrote:
...
>> None of the current reasons I have for ignoring the particular error
>> messages I am ignoring would justify ridiculing the vendor (though I
>> have seen some ridiculous cases in the past). They've written code that
>> attempts to identify problems, and it unavoidably produces some false
>> positives or false negatives (in some cases, both). I can understand
>> what my code does in ways that the compiler can't (and vice versa!), so
>> I know the code is safe, even though compiler isn't sure. That's what
>> warnings are for - if the compiler were certain, it should have issued
>> an error message.
>
> That is the usual case unlike example under discussion. It is not clear
> if the code is safe or unsafe. It may be possible to rewrite it in manner
> that it becomes more clear that it is safe. Doesn't it make the code
> more robust? For me robustness of code tends to be among most desirable
> features. So it seems to be worth to try.
Well, let's look at the two real world cases I mentioned. Does the
(void) cast make the following code clearer or more robust?
(void)function_with_side_effects_returning_a_value(log, "new message");
How about the 'const' in the following code?:
void increment(int * const pint)
{
*pint++;
}
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 15:46 -0700 |
| Message-ID | <4ee81629-1c7d-41c2-b8e7-53b018515b9e@googlegroups.com> |
| In reply to | #60565 |
On Monday, 20 April 2015 23:26:55 UTC+3, James Kuyper wrote:
> On 04/20/2015 03:51 PM, Öö Tiib wrote:
> > On Monday, 20 April 2015 22:03:08 UTC+3, James Kuyper wrote:
> ...
> >> None of the current reasons I have for ignoring the particular error
> >> messages I am ignoring would justify ridiculing the vendor (though I
> >> have seen some ridiculous cases in the past). They've written code that
> >> attempts to identify problems, and it unavoidably produces some false
> >> positives or false negatives (in some cases, both). I can understand
> >> what my code does in ways that the compiler can't (and vice versa!), so
> >> I know the code is safe, even though compiler isn't sure. That's what
> >> warnings are for - if the compiler were certain, it should have issued
> >> an error message.
> >
> > That is the usual case unlike example under discussion. It is not clear
> > if the code is safe or unsafe. It may be possible to rewrite it in manner
> > that it becomes more clear that it is safe. Doesn't it make the code
> > more robust? For me robustness of code tends to be among most desirable
> > features. So it seems to be worth to try.
>
> Well, let's look at the two real world cases I mentioned. Does the
> (void) cast make the following code clearer or more robust?
>
> (void)function_with_side_effects_returning_a_value(log, "new message");
It feels that it adds somewhat to clarity that return value is
deliberately left unused.
> How about the 'const' in the following code?:
>
> void increment(int * const pint)
> {
> *pint++;
> }
It prevents postfix incrementing the 'pint' and so the code won't
compile? If 'pint' is meant as immutable pointer to mutable 'int'
then it seems that it adds somewhat to clarity.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-20 16:17 -0700 |
| Message-ID | <87wq16mlu8.fsf@kst-u.example.com> |
| In reply to | #60586 |
Öö Tiib <ootiib@hot.ee> writes:
> On Monday, 20 April 2015 23:26:55 UTC+3, James Kuyper wrote:
[...]
>> How about the 'const' in the following code?:
>>
>> void increment(int * const pint)
>> {
>> *pint++;
>> }
>
> It prevents postfix incrementing the 'pint' and so the code won't
> compile? If 'pint' is meant as immutable pointer to mutable 'int'
> then it seems that it adds somewhat to clarity.
For a parameter, I probably wouldn't add "const", since it's meaningless
to the caller. For a variable, I likely would; I like to use "const"
for anything that isn't actually modified.
--
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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-21 07:43 -0700 |
| Message-ID | <cd87642d-e005-4f72-8d20-35f8f61127ba@googlegroups.com> |
| In reply to | #60586 |
On Tuesday, 21 April 2015 02:41:58 UTC+3, Stefan Ram wrote:
> Öö Tiib <ootiib@hot.ee> writes:
> >>(void)function_with_side_effects_returning_a_value(log, "new message");
> >It feels that it adds somewhat to clarity that return value is
> >deliberately left unused.
>
> This style looks inappropriate to me.
Why? PC-Lint warns if you ignore return values.
Gcc warns if the 'function_with_side_effects_returning_a_value'
was declared like that:
int
__attribute__((warn_unused_result))
function_with_side_effects_returning_a_value(struct Log, char const*);
Some consider it inappropriate that code that ignores return values
has most terse syntax.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web