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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-21 08:06 -0700 |
| Message-ID | <87sibtmsh2.fsf@kst-u.example.com> |
| In reply to | #60586 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Öö 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.
>
> The expression statement is the /most fundamental/
> and /most used/ statement of C.
>
> I explain the expression statement near the beginning
> of my beginner's courses.
>
> The whole point of the expression statement is to
> evaluate an expression, /in the case that one wants to
> ignore the value of the expression and only have the
> effects of the evaluation/. So, when someone uses
> the expression statement he /must/ /deliberately/
> ignore the value, unless he is utterly clueless or
> utterly inattentive.
>
> If someone needs to be reminded of this, then he
> must lack the most basic knowledge of C. But in
> this case, we might wonder whether he will understand
> the meaning and the intention of a cast to void, so it
> might not even help in this case.
The problem isn't a lack of understanding of how expression statements
work. The problem is that it's not obvious whether the called function
returns void or some other type.
func1(42);
func2(42);
One of these calls is to a void function. The other is a call to a
function that returns a result whose value is potentially significant;
that result is silently ignored. You can't tell which without looking
at the declarations of the functions. (Ideally the names of the
functions would be a clue, but they often arent.)
func1(42);
(void)func2(42);
Now you can see that the result of func2() is being *deliberately*
ignored.
--
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 | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-04-22 21:55 -0700 |
| Message-ID | <MPG.2fa21b056b88181418@news.eternal-september.org> |
| In reply to | #60586 |
Stefan Ram wrote: > Reminds me of a story one of my students told me yesterday: > He had a job interview and used the ternary »?:« operator. > He was rejected based on this... Lucky for him.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 20:04 +0100 |
| Message-ID | <mh3iif$3mo$1@dont-email.me> |
| In reply to | #60553 |
On 20/04/15 19:15, Öö Tiib wrote: > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: <snip> >> The example he gave in the very same message you were responding to >> seems an excellent one. What re-write would you propose to the following >> line: >> >> c = a + b; >> >> in order to avoid the following warning?: >> >> > foo.c:248:18: warning: addition of unsigned integer types can result in >> > a value lower than either operand (-Waddition-of-unsigned-integer-types) > > Wasn't it purely hypothetical and especially constructed example? It was indeed, but it could be in the next gcc release, for all we know. So it is not unreasonable to ask the -Werror camp how they would deal with it. > Most > programmers silence such warning from command line So instead of switching off -Werror, you switch off the warning! I see. Now it makes perfect sense. House style guide ================= Section 1. Warnings. Section 1.1 House policy is a clean compilation - the build must not generate any warnings, as warnings indicate poor code. Section 1.2 If you don't like a warning, switch it off. Your code is no longer poor. It's laughable. > 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. So rather than switch off -Werror, you'll disable any warnings you don't like and attempt to bully your vendor into removing them from future releases. Do you realise just how flaky this "policy" sounds? -- 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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 13:22 -0700 |
| Message-ID | <bda0f0ef-9305-4f17-a0f0-17c7cdc8ccc3@googlegroups.com> |
| In reply to | #60558 |
On Monday, 20 April 2015 22:04:50 UTC+3, Richard Heathfield wrote: > On 20/04/15 19:15, Öö Tiib wrote: > > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: > > <snip> > > >> The example he gave in the very same message you were responding to > >> seems an excellent one. What re-write would you propose to the following > >> line: > >> > >> c = a + b; > >> > >> in order to avoid the following warning?: > >> > >> > foo.c:248:18: warning: addition of unsigned integer types can result in > >> > a value lower than either operand (-Waddition-of-unsigned-integer-types) > > > > Wasn't it purely hypothetical and especially constructed example? > > It was indeed, but it could be in the next gcc release, for all we know. > So it is not unreasonable to ask the -Werror camp how they would deal > with it. I feel gcc devs have (undeservedly for me) low credits if you consider it plausible scenario. > > > > Most > > programmers silence such warning from command line > > So instead of switching off -Werror, you switch off the warning! I see. > Now it makes perfect sense. What else is there to do? Just watch thousands of warnings about adding two unsigneds to scroll by so you see next to nothing else? Then apply external filters to achieve same thing? > House style guide > ================= > Section 1. Warnings. > Section 1.1 House policy is a clean compilation - the build must not > generate any warnings, as warnings indicate poor code. > Section 1.2 If you don't like a warning, switch it off. Your code is no > longer poor. > > It's laughable. Tools can be broken. My team would consider your warning as example of broken feature of compiler. Fixing broken features of software is where goes most of effort in our industry. Turning it off is easiest way to deal with it. May be laughable but so it is. > > 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. > > > So rather than switch off -Werror, you'll disable any warnings you don't > like and attempt to bully your vendor into removing them from future > releases. Do you realise just how flaky this "policy" sounds? I don't parse what you say? I claimed that most programmers would turn off your odd warning *AND* some would ridicule compiler vendor about it in forums. I feel you misrepresent what I wrote.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 21:42 +0100 |
| Message-ID | <mh3o95$s8j$1@dont-email.me> |
| In reply to | #60564 |
On 20/04/15 21:22, Öö Tiib wrote: > On Monday, 20 April 2015 22:04:50 UTC+3, Richard Heathfield wrote: >> On 20/04/15 19:15, Öö Tiib wrote: >> > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote: >> >> <snip> >> >> >> The example he gave in the very same message you were responding to >> >> seems an excellent one. What re-write would you propose to the following >> >> line: >> >> >> >> c = a + b; >> >> >> >> in order to avoid the following warning?: >> >> >> >> > foo.c:248:18: warning: addition of unsigned integer types can result in >> >> > a value lower than either operand (-Waddition-of-unsigned-integer-types) >> > >> > Wasn't it purely hypothetical and especially constructed example? >> >> It was indeed, but it could be in the next gcc release, for all we know. >> So it is not unreasonable to ask the -Werror camp how they would deal >> with it. > > I feel gcc devs have (undeservedly for me) low credits if you consider > it plausible scenario. Do you not see the inconsistency of your position? You are claiming that code is of poor quality if it generates a diagnostic message, but you are also claiming that only diagnostic messages that /you/ like are worthy of being enabled. Okay, so you think that the particular example I gave is contrived. So take the aggregate initialisation warning instead. Is /that/ contrived? Do you consider that any diagnostic message appearing in your buld process must ipso facto be contrived? I hope not, but you seem to be saying that it's okay to switch off messages in order to meet your -Werror criterion; and /that/ means that your fellow developers have licence to put any old junk through the compiler as long as they know how to switch off warnings so as not to trigger -Werror. It's a hack, and not a good one. > >> >> >> > Most >> > programmers silence such warning from command line >> >> So instead of switching off -Werror, you switch off the warning! I see. >> Now it makes perfect sense. > > What else is there to do? Just watch thousands of warnings about adding > two unsigneds to scroll by so you see next to nothing else? Then apply > external filters to achieve same thing? So what do you do about -Wmissing-field-initializers ? Do you switch that off, too? >> House style guide >> ================= >> Section 1. Warnings. >> Section 1.1 House policy is a clean compilation - the build must not >> generate any warnings, as warnings indicate poor code. >> Section 1.2 If you don't like a warning, switch it off. Your code is no >> longer poor. >> >> It's laughable. > > Tools can be broken. My team would consider your warning as > example of broken feature of compiler. Fixing broken features of > software is where goes most of effort in our industry. Turning it > off is easiest way to deal with it. May be laughable but so it is. Is -Wmissing-field-initializers a broken feature? >> > 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. >> >> >> So rather than switch off -Werror, you'll disable any warnings you don't >> like and attempt to bully your vendor into removing them from future >> releases. Do you realise just how flaky this "policy" sounds? > > I don't parse what you say? I claimed that most programmers would > turn off your odd warning *AND* some would ridicule compiler vendor > about it in forums. I feel you misrepresent what I wrote. I don't mean to misrepresent you. You seem to be focussing solely on the hypothetical example I gave, and purely from the point of view that you can't believe a sane implementor would produce such a diagnostic message. That's actually irrelevant to my point. My point is this: in a -Werror shop, how do you deal with diagnostic messages that won't just go away with a simple re-touching of the code, or which morph into some other message when you try such re-touching? You have not yet explained this, despite several invitations so to do. -- 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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 16:58 -0700 |
| Message-ID | <69aa835d-e5d3-44fa-a62b-833517803ded@googlegroups.com> |
| In reply to | #60567 |
On Monday, 20 April 2015 23:42:17 UTC+3, Richard Heathfield wrote:
> On 20/04/15 21:22, Öö Tiib wrote:
> > On Monday, 20 April 2015 22:04:50 UTC+3, Richard Heathfield wrote:
> >> On 20/04/15 19:15, Öö Tiib wrote:
> >> > On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote:
> >>
> >> <snip>
> >>
> >> >> The example he gave in the very same message you were responding to
> >> >> seems an excellent one. What re-write would you propose to the following
> >> >> line:
> >> >>
> >> >> c = a + b;
> >> >>
> >> >> in order to avoid the following warning?:
> >> >>
> >> >> > foo.c:248:18: warning: addition of unsigned integer types can result in
> >> >> > a value lower than either operand (-Waddition-of-unsigned-integer-types)
> >> >
> >> > Wasn't it purely hypothetical and especially constructed example?
> >>
> >> It was indeed, but it could be in the next gcc release, for all we know.
> >> So it is not unreasonable to ask the -Werror camp how they would deal
> >> with it.
> >
> > I feel gcc devs have (undeservedly for me) low credits if you consider
> > it plausible scenario.
>
> Do you not see the inconsistency of your position? You are claiming that
> code is of poor quality if it generates a diagnostic message, but you
> are also claiming that only diagnostic messages that /you/ like are
> worthy of being enabled.
My team. Yes. If we consider a particular compiler overly paranoid about
something then it is so for us and we turn it off. We are also normal
humans and may consider it wrong. If we later find that the paranoia
to be good after all then we may rethink it again. Then we will turn it
on and invest into fixing the warnings.
> Okay, so you think that the particular example
> I gave is contrived. So take the aggregate initialisation warning
> instead. Is /that/ contrived? Do you consider that any diagnostic
> message appearing in your buld process must ipso facto be contrived? I
> hope not, but you seem to be saying that it's okay to switch off
> messages in order to meet your -Werror criterion; and /that/ means that
> your fellow developers have licence to put any old junk through the
> compiler as long as they know how to switch off warnings so as not to
> trigger -Werror. It's a hack, and not a good one.
Yes for me it would be indeed bad if what you describe would happen in
my team. It fortunately had not happened.
>
> >
> >>
> >>
> >> > Most
> >> > programmers silence such warning from command line
> >>
> >> So instead of switching off -Werror, you switch off the warning! I see.
> >> Now it makes perfect sense.
> >
> > What else is there to do? Just watch thousands of warnings about adding
> > two unsigneds to scroll by so you see next to nothing else? Then apply
> > external filters to achieve same thing?
>
> So what do you do about -Wmissing-field-initializers ? Do you switch
> that off, too?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
It seems to be discussed as a bug/too strict in gcc bugzilla about both C
and C++.
> >> House style guide
> >> =================
> >> Section 1. Warnings.
> >> Section 1.1 House policy is a clean compilation - the build must not
> >> generate any warnings, as warnings indicate poor code.
> >> Section 1.2 If you don't like a warning, switch it off. Your code is no
> >> longer poor.
> >>
> >> It's laughable.
> >
> > Tools can be broken. My team would consider your warning as
> > example of broken feature of compiler. Fixing broken features of
> > software is where goes most of effort in our industry. Turning it
> > off is easiest way to deal with it. May be laughable but so it is.
>
> Is -Wmissing-field-initializers a broken feature?
Yes, I do not really see how separate 'memset' is better than '={0}'.
>
> >> > 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.
> >>
> >>
> >> So rather than switch off -Werror, you'll disable any warnings you don't
> >> like and attempt to bully your vendor into removing them from future
> >> releases. Do you realise just how flaky this "policy" sounds?
> >
> > I don't parse what you say? I claimed that most programmers would
> > turn off your odd warning *AND* some would ridicule compiler vendor
> > about it in forums. I feel you misrepresent what I wrote.
>
> I don't mean to misrepresent you. You seem to be focussing solely on the
> hypothetical example I gave, and purely from the point of view that you
> can't believe a sane implementor would produce such a diagnostic
> message.
No, I believe that they sometimes do. They are imperfect like everybody.
They fix it later and over years their compilers get smarter and do all
less and less such things.
> That's actually irrelevant to my point. My point is this: in a
> -Werror shop, how do you deal with diagnostic messages that won't just
> go away with a simple re-touching of the code, or which morph into some
> other message when you try such re-touching? You have not yet explained
> this, despite several invitations so to do.
Yes it may be slightly more than trivial to fix all such cases.
For example one compiler does (wrongly) detect a potential path that
does not return a value. If to mechanically add a bogus return there
then other compiler (correctly) diagnoses the return as unreachable
code. However even such cases are usually more clear and robust when
fixed so that both compilers are happy.
I well understand that it may be is pointless work just on its own but
both of the warnings are useful so we don't generally want to turn them
off or to ignore.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-21 01:16 +0100 |
| Message-ID | <mh44qk$9mo$1@dont-email.me> |
| In reply to | #60596 |
[Mostly we're just going round and round. But just one point did attract
my attention, which is...]
On 21/04/15 00:58, Öö Tiib wrote:
> On Monday, 20 April 2015 23:42:17 UTC+3, Richard Heathfield wrote:
<snip>
>> Is -Wmissing-field-initializers a broken feature?
>
> Yes, I do not really see how separate 'memset' is better than '={0}'.
It doesn't do the same thing, so I don't see how they're comparable.
The memset function sets the value of a set of bytes to 0. The = {0}
initialisation idiom sets the value of each member of a struct to its
default static initialiser value.
Undoubtedly these two actions have the same practical effect on a number
of platforms, but this is not guaranteed by the Standard.
<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 | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-04-21 02:19 +0200 |
| Message-ID | <20150421021933.734351ce@maxa-pc> |
| In reply to | #60597 |
On Tue, 21 Apr 2015 01:16:14 +0100
Richard Heathfield <rjh@cpax.org.uk> wrote:
> [Mostly we're just going round and round. But just one point did
> attract my attention, which is...]
>
> On 21/04/15 00:58, Öö Tiib wrote:
> > On Monday, 20 April 2015 23:42:17 UTC+3, Richard Heathfield wrote:
>
> <snip>
>
> >> Is -Wmissing-field-initializers a broken feature?
> >
> > Yes, I do not really see how separate 'memset' is better than
> > '={0}'.
>
> It doesn't do the same thing, so I don't see how they're comparable.
>
> The memset function sets the value of a set of bytes to 0. The = {0}
> initialisation idiom sets the value of each member of a struct to its
> default static initialiser value.
>
> Undoubtedly these two actions have the same practical effect on a
> number of platforms, but this is not guaranteed by the Standard.
>
> <snip>
>
I think that memset would not work portably on pointer members.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-20 23:14 -0700 |
| Message-ID | <50b6b736-021a-4ec6-9097-efac52ac0a10@googlegroups.com> |
| In reply to | #60597 |
On Tuesday, 21 April 2015 03:16:25 UTC+3, Richard Heathfield wrote:
> [Mostly we're just going round and round. But just one point did attract
> my attention, which is...]
>
> On 21/04/15 00:58, Öö Tiib wrote:
> > On Monday, 20 April 2015 23:42:17 UTC+3, Richard Heathfield wrote:
>
> <snip>
>
> >> Is -Wmissing-field-initializers a broken feature?
> >
> > Yes, I do not really see how separate 'memset' is better than '={0}'.
>
> It doesn't do the same thing, so I don't see how they're comparable.
>
> The memset function sets the value of a set of bytes to 0. The = {0}
> initialisation idiom sets the value of each member of a struct to its
> default static initialiser value.
>
> Undoubtedly these two actions have the same practical effect on a number
> of platforms, but this is not guaranteed by the Standard.
It was brought up as potential alternative when the warning was discussed.
Add static asserts that defaults are zeroes and use 'memset'. It didn't
fly and the warning was turned off.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-21 11:47 -0400 |
| Message-ID | <55367118.6090308@verizon.net> |
| In reply to | #60607 |
On 04/21/2015 02:14 AM, Öö Tiib wrote:
> On Tuesday, 21 April 2015 03:16:25 UTC+3, Richard Heathfield wrote:
...
>> The memset function sets the value of a set of bytes to 0. The = {0}
>> initialisation idiom sets the value of each member of a struct to its
>> default static initialiser value.
>>
>> Undoubtedly these two actions have the same practical effect on a number
>> of platforms, but this is not guaranteed by the Standard.
>
> It was brought up as potential alternative when the warning was discussed.
> Add static asserts that defaults are zeroes and use 'memset'. It didn't
> fly and the warning was turned off.
What would the static asserts look like? I know how to test this
non-statically:
static double d=0.0;
static void *pv=NULL;
static unsigned char array1[sizeof d];
static unsigned char array2[sizeof pv];
assert(!memcmp(array1, &d, sizeof d) &&
!memcmp(array2, &pv, sizeof pv));
However, the argument of a _Static_assert() must be a constant
expression, which prohibits use memcmp() (6.6p3). Accessing the
individual bytes of 'd' using an expression like
((unsigned char*)&d)[0] == 0
is not a workable alternative, because "Cast operators in an arithmetic
constant expression shall only convert arithmetic types to arithmetic
types," (6.6p8), and the left operand of the equality comparison
expression does not qualify as any of the permitted kinds of operands in
constant expressions that listed in the first part of 6.6p8.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-22 00:13 -0700 |
| Message-ID | <2116d554-7bef-416e-bc96-2d8f4d1c8cc0@googlegroups.com> |
| In reply to | #60652 |
On Tuesday, 21 April 2015 18:47:44 UTC+3, James Kuyper wrote:
> On 04/21/2015 02:14 AM, Öö Tiib wrote:
> > On Tuesday, 21 April 2015 03:16:25 UTC+3, Richard Heathfield wrote:
> ...
> >> The memset function sets the value of a set of bytes to 0. The = {0}
> >> initialisation idiom sets the value of each member of a struct to its
> >> default static initialiser value.
> >>
> >> Undoubtedly these two actions have the same practical effect on a number
> >> of platforms, but this is not guaranteed by the Standard.
> >
> > It was brought up as potential alternative when the warning was discussed.
> > Add static asserts that defaults are zeroes and use 'memset'. It didn't
> > fly and the warning was turned off.
>
> What would the static asserts look like? I know how to test this
> non-statically:
>
> static double d=0.0;
> static void *pv=NULL;
> static unsigned char array1[sizeof d];
> static unsigned char array2[sizeof pv];
>
> assert(!memcmp(array1, &d, sizeof d) &&
> !memcmp(array2, &pv, sizeof pv));
It wasn't considered too seriously I think. Something like that may
be ran during configuration and a define like 'DEFAULTS_ARE_ZEROES' can
be added on success. Turning the overly strict warning off and
continuing to use the traditional '={0}' is clearly better idea.
> However, the argument of a _Static_assert() must be a constant
> expression, which prohibits use memcmp() (6.6p3). Accessing the
> individual bytes of 'd' using an expression like
>
> ((unsigned char*)&d)[0] == 0
>
> is not a workable alternative, because "Cast operators in an arithmetic
> constant expression shall only convert arithmetic types to arithmetic
> types," (6.6p8), and the left operand of the equality comparison
> expression does not qualify as any of the permitted kinds of operands in
> constant expressions that listed in the first part of 6.6p8.
Yes, you are correct. Also C++ does not allow type punning compile-time.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 08:36 +0100 |
| Message-ID | <mh7j02$mi6$1@dont-email.me> |
| In reply to | #60698 |
On 22/04/15 08:13, Öö Tiib wrote:
<snip>
> Turning the overly strict warning off and
> continuing to use the traditional '={0}' is clearly better idea.
I agree entirely. Now, up until it was turned off, what was the -Werror
crowd to do? (Bear in mind that it's still turned on in shops where they
don't ride the latest gcc crest.)
They had an overly-strict warning that they weren't allowed to turn off.
They weren't allowed to ignore it. They had to code around it. How?
<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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-22 03:15 -0700 |
| Message-ID | <c377892f-ed00-4aff-98d8-34cb837d3e07@googlegroups.com> |
| In reply to | #60701 |
On Wednesday, 22 April 2015 10:36:38 UTC+3, Richard Heathfield wrote:
> On 22/04/15 08:13, Öö Tiib wrote:
>
> <snip>
>
> > Turning the overly strict warning off and
> > continuing to use the traditional '={0}' is clearly better idea.
>
> I agree entirely. Now, up until it was turned off, what was the -Werror
> crowd to do? (Bear in mind that it's still turned on in shops where they
> don't ride the latest gcc crest.)
Migrating to other tool (or version) is an effort. Dealing with warnings is
just a part of the effort. It can easily happen that compiler from Microsoft
gives warnings about API headers written by Microsoft. Such warnings
have to be silenced without touching the code in headers.
> They had an overly-strict warning that they weren't allowed to turn off.
> They weren't allowed to ignore it. They had to code around it. How?
If a team-mate has issue that he can't figure out how to handle then he
asks help from others. It is not specific to warnings. The team has to
deliver so the team has to decide how it does things.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 11:52 +0100 |
| Message-ID | <mh7ues$vod$1@dont-email.me> |
| In reply to | #60719 |
On 22/04/15 11:15, Öö Tiib wrote:
> On Wednesday, 22 April 2015 10:36:38 UTC+3, Richard Heathfield wrote:
>> On 22/04/15 08:13, Öö Tiib wrote:
>>
>> <snip>
>>
>> > Turning the overly strict warning off and
>> > continuing to use the traditional '={0}' is clearly better idea.
>>
>> I agree entirely. Now, up until it was turned off, what was the -Werror
>> crowd to do? (Bear in mind that it's still turned on in shops where they
>> don't ride the latest gcc crest.)
>
> Migrating to other tool (or version) is an effort. Dealing with warnings is
> just a part of the effort.
What you're not saying is how -Werror people dealt with = {0} in gcc
environments prior to the recent fix of that warning by the gcc people.
Did they (a) change the code, and if so how? or (b) suppress the warning?
> It can easily happen that compiler from Microsoft
> gives warnings about API headers written by Microsoft.
Yes, IIRC math.h had a // comment in it (in pre-C99 days). How did "no
warnings allowed in final build" cope with that?
> Such warnings
> have to be silenced without touching the code in headers.
So you advocate suppressing the message, rather than changing the code.
So why not suppress the warnings you get in your own code, too, rather
than change the code to avoid the warning? Answer: you want to know,
right? Fine, so don't suppress them. But since you've shown that you're
willing to suppress warnings rather than change the code, it's not so
very inconsistent to /allow/ the warnings but not insist that the code
should change in order to eliminate them. A very sensible approach.
>
>> They had an overly-strict warning that they weren't allowed to turn off.
>> They weren't allowed to ignore it. They had to code around it. How?
>
> If a team-mate has issue that he can't figure out how to handle then he
> asks help from others. It is not specific to warnings. The team has to
> deliver so the team has to decide how it does things.
Okay, I'm a team-mate. We are using gcc, but a version prior to the
improvement in the diagnostics for partial initialisation, and we can't
upgrade because we don't have a good enough reason to convince
management. I have this code:
struct foo bar = {0};
and I'm getting a warning about it. I could list all the values:
struct foo bar = {0, 0.0, NULL, 0, 0, { 0, 0, 0.0, NULL }, NULL };
but this is clearly worse code - in fact, it's a maintenance nightmare.
I could use memset, but then the code wouldn't be portable to platforms
where NULL isn't all-bits-zero.
I'm stuck. I wander over to your desk and show you the code and the
diagnostic message, and ask your advice: how do I get this code to
compile without making it worse and without generating a warning?
What is your advice?
You've had several chances to answer this question, and you haven't yet
taken up any of them. Is that because you cannot construct a
satisfactory answer?
--
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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-22 09:04 -0700 |
| Message-ID | <0de2789d-00c0-4dc2-bcd4-111f8493f830@googlegroups.com> |
| In reply to | #60723 |
On Wednesday, 22 April 2015 13:52:17 UTC+3, Richard Heathfield wrote:
> On 22/04/15 11:15, Öö Tiib wrote:
> > On Wednesday, 22 April 2015 10:36:38 UTC+3, Richard Heathfield wrote:
> >> On 22/04/15 08:13, Öö Tiib wrote:
> >>
> >> <snip>
> >>
> >> > Turning the overly strict warning off and
> >> > continuing to use the traditional '={0}' is clearly better idea.
> >>
> >> I agree entirely. Now, up until it was turned off, what was the -Werror
> >> crowd to do? (Bear in mind that it's still turned on in shops where they
> >> don't ride the latest gcc crest.)
> >
> > Migrating to other tool (or version) is an effort. Dealing with warnings is
> > just a part of the effort.
>
> What you're not saying is how -Werror people dealt with = {0} in gcc
> environments prior to the recent fix of that warning by the gcc people.
> Did they (a) change the code, and if so how? or (b) suppress the warning?
I do not know how others dealt with it. All I know is that we did decide
to suppress it. I trust that I already wrote it.
> > It can easily happen that compiler from Microsoft
> > gives warnings about API headers written by Microsoft.
>
> Yes, IIRC math.h had a // comment in it (in pre-C99 days). How did "no
> warnings allowed in final build" cope with that?
>
> > Such warnings
> > have to be silenced without touching the code in headers.
>
> So you advocate suppressing the message, rather than changing the code.
We do not want to branch third party library, it is their intellectual property.
We can suggest what we think that they can improve in it for mutual benefit.
So we typically compile third party code without warnings.
> So why not suppress the warnings you get in your own code, too, rather
> than change the code to avoid the warning? Answer: you want to know,
> right? Fine, so don't suppress them. But since you've shown that you're
> willing to suppress warnings rather than change the code, it's not so
> very inconsistent to /allow/ the warnings but not insist that the code
> should change in order to eliminate them. A very sensible approach.
It is case-by-case in our own code. The examples when changes that
are needed will make code more fragile and/or harder to read are rare,
but can happen. On such cases we suppress the warnings because
we don't want to see these warnings at all.
We use several testing tools and therefore have to compile code
with several compilers. So that makes changes in build scripts more
common and suppressed warning of one tool less important loss
for us than it may be is for others. Tool authors are humans too
so we consider it worth to use several.
> >
> >> They had an overly-strict warning that they weren't allowed to turn off.
> >> They weren't allowed to ignore it. They had to code around it. How?
> >
> > If a team-mate has issue that he can't figure out how to handle then he
> > asks help from others. It is not specific to warnings. The team has to
> > deliver so the team has to decide how it does things.
>
> Okay, I'm a team-mate. We are using gcc, but a version prior to the
> improvement in the diagnostics for partial initialisation, and we can't
> upgrade because we don't have a good enough reason to convince
> management. I have this code:
>
>
> struct foo bar = {0};
>
> and I'm getting a warning about it. I could list all the values:
>
> struct foo bar = {0, 0.0, NULL, 0, 0, { 0, 0, 0.0, NULL }, NULL };
>
> but this is clearly worse code - in fact, it's a maintenance nightmare.
> I could use memset, but then the code wouldn't be portable to platforms
> where NULL isn't all-bits-zero.
>
> I'm stuck. I wander over to your desk and show you the code and the
> diagnostic message, and ask your advice: how do I get this code to
> compile without making it worse and without generating a warning?
>
> What is your advice?
My advice is that the warning looks too paranoid so we should suppress
it.
> You've had several chances to answer this question, and you haven't yet
> taken up any of them. Is that because you cannot construct a
> satisfactory answer?
I trust I wrote already that we discussed it and decided that other
alternatives are worse. Exactly like you say. We did not turn
off -Werror, we suppressed particular warning for particular
compiler. The only (minor for us) downside is that it also
suppressed same warning for unorthodox 'struct foo bar = {42};'.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 17:14 +0100 |
| Message-ID | <mh8hb5$ckm$1@dont-email.me> |
| In reply to | #60747 |
On 22/04/15 17:04, Öö Tiib wrote:
> On Wednesday, 22 April 2015 13:52:17 UTC+3, Richard Heathfield wrote:
>> On 22/04/15 11:15, Öö Tiib wrote:
>> > On Wednesday, 22 April 2015 10:36:38 UTC+3, Richard Heathfield wrote:
>> >> On 22/04/15 08:13, Öö Tiib wrote:
>> >>
>> >> <snip>
>> >>
>> >> > Turning the overly strict warning off and
>> >> > continuing to use the traditional '={0}' is clearly better idea.
>> >>
>> >> I agree entirely. Now, up until it was turned off, what was the -Werror
>> >> crowd to do? (Bear in mind that it's still turned on in shops where they
>> >> don't ride the latest gcc crest.)
>> >
>> > Migrating to other tool (or version) is an effort. Dealing with warnings is
>> > just a part of the effort.
>>
>> What you're not saying is how -Werror people dealt with = {0} in gcc
>> environments prior to the recent fix of that warning by the gcc people.
>> Did they (a) change the code, and if so how? or (b) suppress the warning?
>
> I do not know how others dealt with it. All I know is that we did decide
> to suppress it.
Thank you. I rest my case.
<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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-20 15:24 -0700 |
| Message-ID | <87a8y2o2uc.fsf@kst-u.example.com> |
| In reply to | #60558 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 20/04/15 19:15, Öö Tiib wrote:
>> On Monday, 20 April 2015 20:22:37 UTC+3, James Kuyper wrote:
>
> <snip>
>
>>> The example he gave in the very same message you were responding to
>>> seems an excellent one. What re-write would you propose to the following
>>> line:
>>>
>>> c = a + b;
>>>
>>> in order to avoid the following warning?:
>>>
>>> > foo.c:248:18: warning: addition of unsigned integer types can result in
>>> > a value lower than either operand (-Waddition-of-unsigned-integer-types)
>>
>> Wasn't it purely hypothetical and especially constructed example?
>
> It was indeed, but it could be in the next gcc release, for all we
> know. So it is not unreasonable to ask the -Werror camp how they would
> deal with it.
And the -Werror camp could respond that they depend on the gcc
maintainers *not* to introduce such a warning in a new version of
gcc. In this specific case, I think that's a reasonable assumption.
The disadvantage of -Werror is that it enforces an arbitrary set
of restrictions on your code, namely those restrictions chosen by
the authors of the compiler you're using. The advantage is that
it's mechanically enforceable. Choosing to trust the gcc authors
(for example) to issue reasonable warnings is not an obviously
wrong decision -- nor is it an obviously right one.
If you choose to permit some warnings, then for each build you have
to verify that each warning is one you've chosen (presumably with
good reason) to ignore, so you can detect warnings that indicate
real problems. The trick is to automate that process. If you can
add a formatted comment on the line that produces the warning *and*
the line is included in the error message, then you can do that.
Otherwise you might need some kind of add-on tool, or perhaps a
compiler-specific directive to suppress a specified warning on a
specified line.
The -Werror approach is to modify the code as necessary to
avoid warnings, even if the code was already ok in your opinion.
With luck, you can change the code in ways that don't damage it
too severely. It's not ideal, but it's the price you pay if you
want to simplify the process of determining whether there are any
acceptable warnings (because by definition there are none).
New warnings in a new release of the compiler can certainly be a
problem. If you're able to control which compiler version is used
to compile your code (say, because it's a closed-source product and
nobody else builds it), then you can stick to one compiler version
for a while, upgrading only when you've decided you're willing to
pay the price of "fixing" all the new warnings. For open-source
software that you expect others to compile with whatever tools they
prefer, it's more awkward.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-04-21 00:24 -0500 |
| Message-ID | <mh4mtb$kt4$1@dont-email.me> |
| In reply to | #60585 |
On 20-Apr-15 17:24, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 20/04/15 19:15, Öö Tiib wrote: >>> Wasn't it purely hypothetical and especially constructed >>> example? >> >> It was indeed, but it could be in the next gcc release, for all we >> know. So it is not unreasonable to ask the -Werror camp how they >> would deal with it. > > And the -Werror camp could respond that they depend on the gcc > maintainers *not* to introduce such a warning in a new version of > gcc. In this specific case, I think that's a reasonable assumption. Indeed, which is the problem with contrived examples--and why I asked for a real-world one that would be more persuasive. > The disadvantage of -Werror is that it enforces an arbitrary set of > restrictions on your code, namely those restrictions chosen by the > authors of the compiler you're using. The advantage is that it's > mechanically enforceable. Choosing to trust the gcc authors (for > example) to issue reasonable warnings is not an obviously wrong > decision -- nor is it an obviously right one. Well, that assumes you're using -Wall (or worse, -Wall -Wextra). The keepers of the build scripts may decide that some warnings are _not_ worth the effort and turn them off, but keep -Werror for the rest. So, it's not like you're completely at the GCC team's mercy. I do see a lot of Windows code with #pragmas to disable various MSVC warnings, whereas I didn't even realize GCC had similar #pragmas until someone else mentioned it in this thread. That probably says quite a bit about the "reasonableness" of each compiler's warnings. > New warnings in a new release of the compiler can certainly be a > problem. If you're able to control which compiler version is used to > compile your code (say, because it's a closed-source product and > nobody else builds it), then you can stick to one compiler version > for a while, upgrading only when you've decided you're willing to pay > the price of "fixing" all the new warnings. Indeed, though that _should_ be a relatively small part of the cost of upgrading your compiler, especially if it's been a few years. Having a clean build _before_ you upgrade tends to make doing so less painful, mostly because you know any _new_ warnings are related to the upgrade, rather than having to sift through thousands of existing warnings (which may have changed enough to break your filter scripts) to find the new ones--or worse, figure out which ones mysteriously disappeared. > For open-source software that you expect others to compile with > whatever tools they prefer, it's more awkward. My experience is that, for OSS projects, maintainers use -Werror for their own builds, so they're motivated to "fix" the warnings, but it's not in the public build scripts, so others (with other versions of GCC or even other compilers) aren't bothered. Those others may not see a reason for such "fixes", but that's a relatively minor concern. 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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-21 09:33 +0000 |
| Message-ID | <5536191c.4629765@news.xs4all.nl> |
| In reply to | #60585 |
Keith Thompson <kst-u@mib.org> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > > On 20/04/15 19:15, Öö Tiib wrote: > >> Wasn't it purely hypothetical and especially constructed example? > > > > It was indeed, but it could be in the next gcc release, for all we > > know. So it is not unreasonable to ask the -Werror camp how they would > > deal with it. > > And the -Werror camp could respond that they depend on the gcc > maintainers *not* to introduce such a warning in a new version of > gcc. In this specific case, I think that's a reasonable assumption. In the general case, however, it isn't. That's the real problem: you don't know what the next compiler edition may bring, _and_ we're talking about Ganuck, who have historically had a rather self-serving attitude towards what is acceptable C (read: Ganuck is, ISO isn't always). Richard
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-04-21 11:57 +0000 |
| Message-ID | <mh5duf$g3$1@news.xmission.com> |
| In reply to | #60618 |
In article <5536191c.4629765@news.xs4all.nl>, Richard Bos <rlbos@xs4all.nl> wrote: ... >In the general case, however, it isn't. That's the real problem: you >don't know what the next compiler edition may bring, _and_ we're talking >about Ganuck, who have historically had a rather self-serving attitude >towards what is acceptable C (read: Ganuck is, ISO isn't always). Yes, see sig. It's kinda the Microsoft (and, for that matter, that of the US of A) attitude; we're big enough that even though we're "wrong" about many things, we're big enough that people will follow and do things our way regardless. For example, the US's insistence on not using the metric system. GCC is so widely used, that it *is* a standard, even if CLC regs insist otherwise. -- For instance, Standard C says that nearly all extensions to C are prohibited. How silly! GCC implements many extensions, some of which were later adopted as part of the standard. If you want these constructs to give an error message as “required” by the standard, you must specify ‘--pedantic’, which was implemented only so that we can say “GCC is a 100% implementation of the standard”, not because there is any reason to actually use it.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web