Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140381 > unrolled thread
| Started by | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| First post | 2019-01-29 10:50 -0800 |
| Last post | 2019-02-19 18:19 -0600 |
| Articles | 20 on this page of 380 — 25 participants |
Back to article view | Back to comp.lang.c
"...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 10:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-29 20:30 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 18:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-01-30 05:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 14:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 15:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 06:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 17:12 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-30 14:42 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 11:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 11:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 12:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-29 12:20 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 15:08 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-29 21:38 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 19:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 11:27 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 04:18 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 11:00 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:18 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 14:34 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 23:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-01-31 15:44 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 19:00 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-01-31 14:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-31 09:44 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-31 23:15 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 15:11 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-29 22:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:27 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-29 16:48 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 16:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-30 16:57 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 18:04 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 17:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-30 19:23 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-31 03:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-31 08:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-01-31 14:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 12:52 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-01-31 18:19 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-31 09:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-31 19:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-01 13:24 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 12:15 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-04 12:08 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 11:14 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-04 03:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-04 15:24 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-04 12:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:34 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ike Naar <ike@sdf.lonestar.org> - 2019-02-04 22:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 21:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 12:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:06 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 23:30 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 13:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 14:36 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 16:50 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 18:44 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 08:23 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-05 12:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:51 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-05 13:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 01:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 22:44 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 02:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-02-06 17:39 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 10:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-07 07:58 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:45 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-26 08:44 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 08:03 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-26 15:29 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-07 07:59 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 12:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 03:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 13:36 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 04:44 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 06:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 06:22 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 15:54 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:56 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 16:04 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 00:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-07 09:39 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 19:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-07 23:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 16:35 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 02:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 02:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-07 12:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 21:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 23:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 02:04 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 01:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-08 11:42 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-08 03:07 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-08 03:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 13:43 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 06:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 17:56 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-08 10:27 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 05:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-10 16:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 09:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 02:34 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 09:54 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 12:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 14:03 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 14:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 02:57 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 14:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 08:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-11 01:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 13:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-11 08:01 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 17:01 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-11 11:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-12 01:40 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 01:51 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-12 12:13 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 03:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-12 16:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 07:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 09:50 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-12 21:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-12 21:52 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 01:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 11:52 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 03:29 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:26 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 11:41 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-13 05:26 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 05:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:34 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-12 16:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 08:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 04:40 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 02:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-13 02:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 03:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-13 03:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 06:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 07:21 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:38 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-13 11:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 21:27 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 00:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-14 02:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 03:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 15:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 07:28 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 01:06 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 20:47 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-24 13:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-25 02:26 -0800
Wow... (Was: "...the value becomes,indeterminate each time the declaration is reached") gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-25 12:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 15:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 08:15 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 18:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-11 13:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-10 12:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 13:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-10 13:59 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-10 17:50 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 15:17 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-25 17:38 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 21:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-26 01:37 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-11 20:24 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 14:47 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-06 07:51 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:22 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:51 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:33 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 21:24 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 00:24 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:13 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 08:56 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 23:59 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 00:15 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 08:25 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 11:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 14:41 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 14:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 06:37 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 14:48 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:09 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-05 10:19 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-04 22:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 12:10 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 08:47 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-12 12:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 20:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 10:07 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 21:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 11:01 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 15:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-16 16:33 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 16:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 16:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-16 18:20 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-16 20:00 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 08:54 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 23:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 12:31 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 00:34 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 14:26 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 01:45 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 20:12 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 11:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-12 23:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-12 14:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 22:44 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 23:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 12:51 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 01:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-14 07:39 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 19:54 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-14 16:30 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 13:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 15:19 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 14:45 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 16:38 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:24 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 07:17 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:28 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 12:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-15 01:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-14 06:29 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-14 14:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 01:33 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@invalid.add> - 2019-02-18 19:33 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 18:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 19:05 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-18 20:11 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 19:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-18 21:39 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 19:22 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 02:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 15:53 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-15 09:27 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 10:02 +0100
Just an end-user... (Was: "...the value becomes,indeterminate each time the declaration is) reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-13 09:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 11:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:37 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 14:21 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 15:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:36 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 23:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 01:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 02:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 10:00 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 12:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 15:22 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 15:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 16:23 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 17:03 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:41 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 21:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-15 10:38 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 22:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-14 08:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:45 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 02:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 11:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 16:47 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 17:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 17:48 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 19:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-02-14 20:21 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 21:20 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 22:24 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 00:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 01:29 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 08:14 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 07:03 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-15 04:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-15 05:26 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 16:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 14:07 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 07:02 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 17:06 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 08:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 21:45 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 14:16 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 15:04 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-26 15:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-26 12:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-26 21:05 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-26 13:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-27 06:41 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-27 12:33 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-27 08:18 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-27 14:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 21:18 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-27 02:41 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" luser droog <luser.droog@gmail.com> - 2019-02-26 19:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 22:29 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 09:33 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-27 07:41 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 14:15 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-27 07:02 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 17:18 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-28 15:05 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-07 11:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 11:13 +0000
Re: Readability (was: "...the value becomes,indeterminate each time the declaration is reached") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-21 23:25 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-24 03:01 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-26 17:38 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-04 21:31 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-02-01 02:38 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-01 01:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-01 13:26 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 07:18 -0500
The look of C (Was: "...the value becomes,indeterminate each time the declaration is) reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-01 14:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 14:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 06:54 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-01 16:42 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 09:56 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 18:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 10:31 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 10:58 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-01 12:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-02 16:18 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-01 21:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 23:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-02 01:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-01 16:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-02 02:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 15:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-02-01 14:36 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 07:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-26 12:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:09 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 05:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-06 10:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 10:27 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 12:14 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 09:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-31 03:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 22:49 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 20:08 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-10 09:11 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" John Bode <jfbode1029@gmail.com> - 2019-02-19 10:23 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-19 22:55 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-19 15:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-20 00:10 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-19 16:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-20 13:05 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-20 10:30 -0600
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-19 16:05 -0600
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-19 18:19 -0600
Page 18 of 19 — ← Prev page 1 … 16 17 [18] 19 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-02-01 14:26 +0000 |
| Subject | The look of C (Was: "...the value becomes,indeterminate each time the declaration is) reached" |
| Message-ID | <q31ku7$edh$1@news.xmission.com> |
| In reply to | #140447 |
In article <q31df3$pkt$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> You can declare a variable at the top but initialise is
>> immediately before use.
>
>Thereby taking the risk of using the value of that variable before it's
>been initialized.
>
>I just don't see any reason (other than the fact that it didn't use to
>be permitted) why it's bad to intermingle statements and declarations,
>so delaying a declaration until it can be initialized with a value
>that's intended to be used seems entirely reasonable to me (assuming
>that a declaration in that place has enough scope to cover all the ways
>in which it will need to be used).
As your text makes clear, this is a matter of personal taste.
Some people like it, others don't.
I think Bart has made some good points about why one might not like it.
You may or may not be impressed by these points.
Personally, I think that it makes C look like something that it,
traditionally, is not. That is, we're used to seeing C as a compiled,
low-level, top-down, tightly structured, close-to-assembler type language.
Requiring all the declarations at the top fits in with this conception of
the language. Allowing mixing them up makes it look like some high-level,
sort-of-interpreted, Microsoft-ish C-like language. Traditionalists simply
aren't going to like that.
Furthermore, allowing them to be mixed does lead to more a few possible
"puzzles" - such as the one that is the topic of this thread.
Personally, I wonder *why* they allow it and don't just either:
1) Make people use the old-and-always-there method of coding a
"superfluous" block. That always works.
2) Implement the new mixing style as if the user *had* coded an
old-and-always-there "superfluous" block. This was one of Bart's
ideas upthread.
The answer to the above is, of course, that:
1) C++ did it the new way.
2) GCC copied C++'s method.
3) The standard, as is its wont, codified existing practice, i.e.,
went with C++/GCC's practice.
And thus we are where we are.
--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-01 14:32 +0000 |
| Message-ID | <9MY4E.238695$Y32.184604@fx19.am4> |
| In reply to | #140447 |
On 01/02/2019 12:18, James Kuyper wrote: > On 2/1/19 05:26, Anton Shepelev wrote: >> Andrey Tarasevich: >> >>> The ability to interleave declarations and statements gives >>> one the opportunity to supply a meaningful initializer at >>> the point of declaration. This alone immediately closes the >>> debate: declarations should be made locally, as close to >>> the point of the actual usage as possible. >> >> You can declare a variable at the top but initialise is >> immediately before use. > > Thereby taking the risk of using the value of that variable before it's > been initialized. > I just don't see any reason (other than the fact that it didn't use to > be permitted) why it's bad to intermingle statements and declarations, > so delaying a declaration until it can be initialized with a value > that's intended to be used seems entirely reasonable to me (assuming > that a declaration in that place has enough scope to cover all the ways > in which it will need to be used). It isn't hard to ensure that local variables are initialised to a known value. I did that experiment with my C compiler: clearing all new local variables to zero. It was done inefficiently (writing a word at a time), and for all variables even those that were initialised anyway. And on the few tests I did, I had difficulty in measuring any difference in performance. This is not the same as initialising something to its correct first value, but it should result in the same consistent behaviour. Also, if such an initial value was guaranteed, probably the need for a lot of such initialisations would disappear.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-01 06:54 -0800 |
| Message-ID | <8307cefa-0614-4113-920f-3972c20d2c97@googlegroups.com> |
| In reply to | #140449 |
On Friday, February 1, 2019 at 9:32:45 AM UTC-5, Bart wrote: > On 01/02/2019 12:18, James Kuyper wrote: > > On 2/1/19 05:26, Anton Shepelev wrote: > >> Andrey Tarasevich: > >> > >>> The ability to interleave declarations and statements gives > >>> one the opportunity to supply a meaningful initializer at > >>> the point of declaration. This alone immediately closes the > >>> debate: declarations should be made locally, as close to > >>> the point of the actual usage as possible. > >> > >> You can declare a variable at the top but initialise is > >> immediately before use. > > > > Thereby taking the risk of using the value of that variable before it's > > been initialized. > > I just don't see any reason (other than the fact that it didn't use to > > be permitted) why it's bad to intermingle statements and declarations, > > so delaying a declaration until it can be initialized with a value > > that's intended to be used seems entirely reasonable to me (assuming > > that a declaration in that place has enough scope to cover all the ways > > in which it will need to be used). > > It isn't hard to ensure that local variables are initialised to a known > value. Correct - but it's frequently difficult to initialize them with a value intended to be used. A known value that's not intended to be used is no better than an uninitialized value, and is in fact slightly worse, because many compilers do a good job of detecting use of uninitialized values, but the compiler has no way of knowing that you initialized the object with a value that you did not intend to use. The freedom to delay definition of an object often makes it feasible to initialize it with a value that I actually intend to use - code that would have triggered such warnings is now outside the scope of the declaration, which will produce a different warning. > This is not the same as initialising something to its correct first > value, but it should result in the same consistent behaviour. Also, if I don't want consistent behavior from code that incorrectly uses a value that I never intended to be used - I want a warning, which is what I will get from many compilers in many cases, if I leave the variable uninitialized. I will get a diagnostic from all conforming implementations in all such cases if I move the definition to a point where I can initialize it with a value intended to be used.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-01 16:42 +0100 |
| Message-ID | <q31pde$clt$1@dont-email.me> |
| In reply to | #140451 |
On 01/02/2019 15:54, James Kuyper wrote: > On Friday, February 1, 2019 at 9:32:45 AM UTC-5, Bart wrote: >> On 01/02/2019 12:18, James Kuyper wrote: >>> On 2/1/19 05:26, Anton Shepelev wrote: >>>> Andrey Tarasevich: >>>> >>>>> The ability to interleave declarations and statements gives >>>>> one the opportunity to supply a meaningful initializer at >>>>> the point of declaration. This alone immediately closes the >>>>> debate: declarations should be made locally, as close to >>>>> the point of the actual usage as possible. >>>> >>>> You can declare a variable at the top but initialise is >>>> immediately before use. >>> >>> Thereby taking the risk of using the value of that variable before it's >>> been initialized. >>> I just don't see any reason (other than the fact that it didn't use to >>> be permitted) why it's bad to intermingle statements and declarations, >>> so delaying a declaration until it can be initialized with a value >>> that's intended to be used seems entirely reasonable to me (assuming >>> that a declaration in that place has enough scope to cover all the ways >>> in which it will need to be used). >> >> It isn't hard to ensure that local variables are initialised to a known >> value. > > Correct - but it's frequently difficult to initialize them with a value > intended to be used. A known value that's not intended to be used is no > better than an uninitialized value, and is in fact slightly worse, > because many compilers do a good job of detecting use of uninitialized > values, but the compiler has no way of knowing that you initialized the > object with a value that you did not intend to use. > The freedom to delay definition of an object often makes it feasible to > initialize it with a value that I actually intend to use - code that > would have triggered such warnings is now outside the scope of the > declaration, which will produce a different warning. > >> This is not the same as initialising something to its correct first >> value, but it should result in the same consistent behaviour. Also, if > > I don't want consistent behavior from code that incorrectly uses a value > that I never intended to be used - I want a warning, which is what I > will get from many compilers in many cases, if I leave the variable uninitialized. I will get a diagnostic from all conforming > implementations in all such cases if I move the definition to a point > where I can initialize it with a value intended to be used. > <aol> Me too! </aol> Getting /correct/ behaviour from your code is the primary concern of programming. Helping the programmer get correct code should therefore a major concern of any programming language and any development tool (meaning "tool to aid the developer" - compilers can also be used as simple build tools by non-developers). A "feature" that makes it easier to write bad code, or harder to write good good, or harder to detect errors, is a misfeature in my book. That applies whether it is a compiler that sets local variables to 0 by default, or a programmer habit of initialising them to 0. I'll add to that a few points about optimisation, since Bart thought it didn't matter. It can be hard to measure the effects of individual optimisations/pessimisations on a PC, especially with a mostly non-optimising compiler. 1. A 1% benefit is hard to notice. Twenty such optimisations makes a difference. Code speed is a matter of many small effects adding up - you rarely see big differences from single optimisations. 2. x86 cpus are good at working with poorer code - scheduling, out-of-order execution, superscaling, write buffers, etc., mean that the cpu can often merge "int x = 0; ... ; x = 1;" so that only the final write actually takes effect. You still lose in instruction bandwidth, instruction cache space, etc., but these loses are minor and very hard to measure. 3. Not everyone uses x86 cpus - on other processors, these wasted instructions count. 4. Wasted code like this can have a knock-on effect, such as changing register allocations and making other parts of the function poorer. If the compiler is not particularly smart in the first place, and has quite simple register allocation and scheduling algorithms, then you won't see a difference - on more optimising compilers, you might.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-01 09:56 -0800 |
| Message-ID | <q3218l$2tr$1@dont-email.me> |
| In reply to | #140449 |
On 2/1/2019 6:32 AM, Bart wrote:
>
> It isn't hard to ensure that local variables are initialised to a known
> value.
>
> I did that experiment with my C compiler: clearing all new local
> variables to zero. It was done inefficiently (writing a word at a time),
> and for all variables even those that were initialised anyway.
>
> And on the few tests I did, I had difficulty in measuring any difference
> in performance.
>
This is a major antipattern. This is even worse than separation of
declaration from initialization.
"Dummy initialization" achieves nothing, besides defeating sanitisation
features provided by many modern implementations. Modern compilers are
pretty good at catching usage of uninitialized values through both
static analysis (compile time) and dynamic analysis (run time, in debug
version of the code). By "all new local variables to zero" you are
overriding and defeating all these compiler features for no meaningful
reason.
Additionally, it has negative impact on code readability: it is not
clear from such "dummy initialization" whether it is just a completely
inconsequential "initialization for the sake of initialization" or
something that the code below critically relies upon.
Do not do this. If you have no meaningful initializer for a variable,
either leave it completely uninitialized or, if you really hate
uninitialized variables, do something like
int i DEBUG_INIT_ONLY(0xBAADF00D);
At least it conveys the intent and purpose very clearly.
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-01 18:09 +0000 |
| Message-ID | <tX%4E.158111$nC1.1546@fx04.am4> |
| In reply to | #140456 |
On 01/02/2019 17:56, Andrey Tarasevich wrote: > On 2/1/2019 6:32 AM, Bart wrote: >> >> It isn't hard to ensure that local variables are initialised to a >> known value. >> >> I did that experiment with my C compiler: clearing all new local >> variables to zero. It was done inefficiently (writing a word at a >> time), and for all variables even those that were initialised anyway. >> >> And on the few tests I did, I had difficulty in measuring any >> difference in performance. >> > > This is a major antipattern. This is even worse than separation of > declaration from initialization. > > "Dummy initialization" achieves nothing, besides defeating sanitisation > features provided by many modern implementations. Modern compilers are > pretty good at catching usage of uninitialized values through both > static analysis (compile time) and dynamic analysis (run time, in debug > version of the code). By "all new local variables to zero" you are > overriding and defeating all these compiler features for no meaningful > reason. > > Additionally, it has negative impact on code readability: it is not > clear from such "dummy initialization" whether it is just a completely > inconsequential "initialization for the sake of initialization" or > something that the code below critically relies upon. > > Do not do this. If you have no meaningful initializer for a variable, > either leave it completely uninitialized or, if you really hate > uninitialized variables, do something like > > int i DEBUG_INIT_ONLY(0xBAADF00D); > > At least it conveys the intent and purpose very clearly. You do know that this is exactly what already happens with module-level variables and with static variables inside functions? Does that make it an anti-pattern?
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-01 10:31 -0800 |
| Message-ID | <q3239c$h4l$1@dont-email.me> |
| In reply to | #140457 |
On 2/1/2019 10:09 AM, Bart wrote: >> >> This is a major antipattern. This is even worse than separation of >> declaration from initialization. >> >> "Dummy initialization" achieves nothing, besides defeating >> sanitisation features provided by many modern implementations. Modern >> compilers are pretty good at catching usage of uninitialized values >> through both static analysis (compile time) and dynamic analysis (run >> time, in debug version of the code). By "all new local variables to >> zero" you are overriding and defeating all these compiler features for >> no meaningful reason. >> >> Additionally, it has negative impact on code readability: it is not >> clear from such "dummy initialization" whether it is just a completely >> inconsequential "initialization for the sake of initialization" or >> something that the code below critically relies upon. >> >> Do not do this. If you have no meaningful initializer for a variable, >> either leave it completely uninitialized or, if you really hate >> uninitialized variables, do something like >> >> int i DEBUG_INIT_ONLY(0xBAADF00D); >> >> At least it conveys the intent and purpose very clearly. > > You do know that this is exactly what already happens with module-level > variables and with static variables inside functions? > > Does that make it an anti-pattern? > Everything we have been discussing in this topic so far is critically tied to *dynamic* initialization, i.e. initialization that happens when control passes (or not) over the initializing line of the code. Static initialization is a beast of completely different nature with its own set of competing considerations. Not relevant here. Lumping all this into one topic will only add unnecessary fog to the discussion. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-01 10:58 -0800 |
| Message-ID | <q324tg$t9p$1@dont-email.me> |
| In reply to | #140456 |
On 2/1/2019 10:16 AM, Stefan Ram wrote: > Andrey Tarasevich <andreytarasevich@hotmail.com> writes: >> Do not do this. If you have no meaningful initializer for a variable, >> either leave it completely uninitialized or, if you really hate >> uninitialized variables, do something like >> int i DEBUG_INIT_ONLY(0xBAADF00D); >> At least it conveys the intent and purpose very clearly. > > Here's a quotation (slightly modified and abbreviated by me): > ... > C++ Core Guidelines - Bjarne Stroustrup (2016-04-07) Firstly, the world of C and C++ programming is full of canned "recommendations" and "guidelines" that might be perfectly appropriate for a *freshman* programming language course, but must be immediately discarded and forgotten when/if the student proceeds to the sophomore year of their education. "Umm, Johnny... Regarding that 'always initialize your variables' rule you learned last year... Well, you are a big boy now, and it's about time you learned that what we've been telling you before is not exactly accurate..." Before dumping a copy-paste of some "guideline" into a professional forum it is always a good idea to stop for a second and think whether this forum is really its intended target audience. Secondly, the Bjarne Stroustrup's quite you provided is quite a mixed bag: it makes several valuable points, but at the same time contains quite a few instances of the aforementioned "kindergarten-grade" advice. Many of his "guidelines" suffer from this in various degree (remember the disastrous "use std::vector every time you need an array"), but it is not a problem as long as you understand the limits of their applicability and their target audience. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-01 12:47 -0800 |
| Message-ID | <ln7eejw80y.fsf@kst-u.example.com> |
| In reply to | #140460 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
> This is an uninitialized pointer dereference vulnerability
> discovered in the Linux kernel and patched in April 2015:
>
> static int queue_manag(void *data)
> {
> /* back log is defined without initialization */
> struct crypto_async_request *backlog;
>
> if (cpg->eng_st == ENGINE_IDLE) {
> backlog = crypto_get_backlog(&cpg->queue);
> }
>
> if (backlog) {
> /* uninitialized pointer dereferenced! */
> backlog->complete(backlog, -EINPROGRESS);
> }
>
> return 0;
> }
>
> A »= 0« is enough to remove the vulnerability in this case.
Yes, and in this case initializing backlog to 0 (I'd use NULL)
is the correct fix. (Blindly initializing objects to 0 in cases
where that's not a meaningful value is more questionable.)
A sufficiently clever compiler can issue a warning in this case,
by determining that there are execution paths that lead to `backlog`
being dereferenced before a value is assigned to it. (And in fact
the `if (backlog)` has undefined behavior, though it's not going
to cause problems in this particular environment.)
gcc warns that `backlog` is used uninitialized with "-Wall" along
with "-O1" or higher. (gcc 4.1.2, from 2008, is able to issue a
warning.) clang gives a more detailed warning with "-Wall" at all
optimization levels. I wonder how that bug went unfixed until 2015.
I'm not suggesting that it's ok to write incorrect code because
the compiler will catch it, but compiler warnings and other forms
of static analysis are valuable tools.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-02 16:18 +0100 |
| Message-ID | <q34ccm$hln$1@dont-email.me> |
| In reply to | #140462 |
On 01/02/2019 21:47, Keith Thompson wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> [...]
>> This is an uninitialized pointer dereference vulnerability
>> discovered in the Linux kernel and patched in April 2015:
>>
>> static int queue_manag(void *data)
>> {
>> /* back log is defined without initialization */
>> struct crypto_async_request *backlog;
>>
>> if (cpg->eng_st == ENGINE_IDLE) {
>> backlog = crypto_get_backlog(&cpg->queue);
>> }
>>
>> if (backlog) {
>> /* uninitialized pointer dereferenced! */
>> backlog->complete(backlog, -EINPROGRESS);
>> }
>>
>> return 0;
>> }
>>
>> A »= 0« is enough to remove the vulnerability in this case.
>
> Yes, and in this case initializing backlog to 0 (I'd use NULL)
> is the correct fix. (Blindly initializing objects to 0 in cases
> where that's not a meaningful value is more questionable.)
>
That is probably /a/ correct fix, but not necessarily the best - and
certainly not /the/ fix. For one thing, we don't know the rest of the
code (I suspect there is more, since the parameter "data" is not used).
Other immediately obvious fixes would be:
struct crypto_async_request *backlog =
(cpg->eng_st == ENGINE_IDLE) ?
crypto_get_backlog(&cpg->queue) : 0;
or:
if (cpg->eng_st == ENGINE_IDLE) {
struct crypto_async_request *backlog =
crypto_get_backlog(&cpg->queue);
backlog->complete(backlog, -EINPROGRESS);
}
or:
if (cpg->eng_st != ENGINE_IDLE) return; // early exit
struct crypto_async_request *backlog =
crypto_get_backlog(&cpg->queue);
backlog->complete(backlog, -EINPROGRESS);
Generally speaking, I'd say that a policy of not declaring or defining
variables until you have a valid and useful initial value makes this
kind of problem far less likely.
Simply setting the variable to 0 may well cover up other faults (as I
said, I don't think this is the whole code), even though it would be a
fix for this example.
> A sufficiently clever compiler can issue a warning in this case,
> by determining that there are execution paths that lead to `backlog`
> being dereferenced before a value is assigned to it. (And in fact
> the `if (backlog)` has undefined behavior, though it's not going
> to cause problems in this particular environment.)
>
> gcc warns that `backlog` is used uninitialized with "-Wall" along
> with "-O1" or higher. (gcc 4.1.2, from 2008, is able to issue a
> warning.) clang gives a more detailed warning with "-Wall" at all
> optimization levels. I wonder how that bug went unfixed until 2015.
>
It is particularly strange that such a bug was possible in code that is
apparently important for security. As you say, common compilers have
been able to spot such problems for a decade at least. Linters and
other static checkers (which should be used for such important code)
have managed it for a decade or two more. And code reviews have worked
from before C was developed. This is not a complicated or hard to spot
bug (again, depending on any other code involved) and should have raised
red flags immediately on code review.
> I'm not suggesting that it's ok to write incorrect code because
> the compiler will catch it, but compiler warnings and other forms
> of static analysis are valuable tools.
>
Agreed entirely. You do your best to write correct code, /and/ use all
tools that are reasonably available (depending on things like cost,
compatibility with the rest of your coding, etc.) to the best of their
abilities. If you are writing security code, and you are able to
compile this code, then your compiler flags are wrong. (-Werror exists
for a purpose - stopping such code.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-01 21:52 +0000 |
| Message-ID | <87tvhnnpmn.fsf@bsb.me.uk> |
| In reply to | #140460 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>"Umm, Johnny... Regarding that 'always initialize your
>>variables' rule you learned last year... Well, you are a big
>>boy now, and it's about time you learned that what we've been
>>telling you before is not exactly accurate..."
>
> No one here wants to waste his time reading little
> self-gratifying phantasy stories and unfounded judgements.
> We prefer comprehensible and factual information and reasoning.
>
> This is an uninitialized pointer dereference vulnerability
> discovered in the Linux kernel and patched in April 2015:
>
> static int queue_manag(void *data)
> {
> /* back log is defined without initialization */
> struct crypto_async_request *backlog;
>
> if (cpg->eng_st == ENGINE_IDLE) {
> backlog = crypto_get_backlog(&cpg->queue);
> }
>
> if (backlog) {
> /* uninitialized pointer dereferenced! */
> backlog->complete(backlog, -EINPROGRESS);
> }
>
> return 0;
> }
>
> A »= 0« is enough to remove the vulnerability in this case.
I was going to post this more obvious version:
static int queue_manag(void *data)
{
if (cpg->eng_st == ENGINE_IDLE) {
struct crypto_async_request *backlog = crypto_get_backlog(&cpg->queue);
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
}
return 0;
}
but then I thought that the example is probably over-simplified. Indeed
it is. The code is actually:
static int queue_manag(void *data)
{
cpg->eng_st = ENGINE_IDLE;
do {
struct crypto_async_request *async_req = NULL;
struct crypto_async_request *backlog;
__set_current_state(TASK_INTERRUPTIBLE);
if (cpg->eng_st == ENGINE_W_DEQUEUE)
dequeue_complete_req();
spin_lock_irq(&cpg->lock);
if (cpg->eng_st == ENGINE_IDLE) {
backlog = crypto_get_backlog(&cpg->queue);
async_req = crypto_dequeue_request(&cpg->queue);
if (async_req) {
BUG_ON(cpg->eng_st != ENGINE_IDLE);
cpg->eng_st = ENGINE_BUSY;
}
}
spin_unlock_irq(&cpg->lock);
if (backlog) {
backlog->complete(backlog, -EINPROGRESS);
backlog = NULL;
}
if (async_req) {
if (crypto_tfm_alg_type(async_req->tfm) !=
CRYPTO_ALG_TYPE_AHASH) {
struct ablkcipher_request *req =
ablkcipher_request_cast(async_req);
mv_start_new_crypt_req(req);
} else {
struct ahash_request *req =
ahash_request_cast(async_req);
mv_start_new_hash_req(req);
}
async_req = NULL;
}
schedule();
} while (!kthread_should_stop());
return 0;
}
The real problem is all the shared global state that makes reasoning
about this code almost impossible, but I assume that is usual in this
sort of driver. (If it usual, I want to ask why that is so in 2019, but
that's another topic!)
cpg->eng_st is set to ENGINE_IDLE so the code /looks/ fine from the
single-threaded point of view. Presumably some other thread can come
along and alter cpg->eng_s. but then I'd imagine all kinds of possible
messes because lots of the code manipulates *cpg in ways that don't
appear to be thread safe. At first glance it look like the call to
dequeue_complete_req should really be locked.
Do you have a reference for original report?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-01 23:52 +0000 |
| Message-ID | <%Y45E.691479$kk4.114039@fx36.am4> |
| In reply to | #140463 |
On 01/02/2019 21:52, Ben Bacarisse wrote:
> static int queue_manag(void *data)
> {
> cpg->eng_st = ENGINE_IDLE;
> do {
> struct crypto_async_request *backlog;
> if (cpg->eng_st == ENGINE_IDLE) {
> backlog = crypto_get_backlog(&cpg->queue);
> }
>
> if (backlog) {
> backlog->complete(backlog, -EINPROGRESS);
> backlog = NULL;
> }
> } while (!kthread_should_stop());
> return 0;
> }
>
> The real problem is all the shared global state that makes reasoning
> about this code almost impossible, but I assume that is usual in this
> sort of driver. (If it usual, I want to ask why that is so in 2019, but
> that's another topic!)
To me, it brings us back to the observation in the OP.
backlog isn't initialised first time round. Later it is set to NULL, but
is not used again in the rest of the loop, so presumably the NULL is
there for the next time around.
But what actually happens the next time around; does backlog still keeps
its value? It might explain why it can't be initialised if it's meant to
keep the value from last iteration (although that appears to be always
null).
This is an example where it would be far clearer if backlog was declared
outside the loop (and initialised to NULL), then you KNOW what its value
is first time around, and you KNOW for certain that it will keep its
value from the last iteration. And of course that will allow it to be
initialised.
(One more argument in my list against declarations inside the code.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-02 01:00 +0000 |
| Message-ID | <87imy3ngw3.fsf@bsb.me.uk> |
| In reply to | #140466 |
Bart <bc@freeuk.com> writes:
> On 01/02/2019 21:52, Ben Bacarisse wrote:
(what follows is and edited version of the code)
>> static int queue_manag(void *data)
>> {
>> cpg->eng_st = ENGINE_IDLE;
>> do {
>> struct crypto_async_request *backlog;
>
>> if (cpg->eng_st == ENGINE_IDLE) {
>> backlog = crypto_get_backlog(&cpg->queue);
>> }
>>
>> if (backlog) {
>> backlog->complete(backlog, -EINPROGRESS);
>> backlog = NULL;
>> }
>> } while (!kthread_should_stop());
>> return 0;
>> }
>>
>> The real problem is all the shared global state that makes reasoning
>> about this code almost impossible, but I assume that is usual in this
>> sort of driver. (If it usual, I want to ask why that is so in 2019, but
>> that's another topic!)
>
> To me, it brings us back to the observation in the OP.
>
> backlog isn't initialised first time round.
It isn't initialised any time round. Simpler to say, it isn't initialised.
> Later it is set to NULL, but is not used again in the rest of the
> loop, so presumably the NULL is there for the next time around.
No. My guess would be that setting to NULL is just a pattern in the
programmer's head: if (p) { single_use(p); p = 0; }, but I don't know
the code well enough to speculate.
What's certain is that the NULL is not there next time round except by
misfortune that an indeterminate value might be the one left over from
earlier.
> But what actually happens the next time around; does backlog still
> keeps its value? It might explain why it can't be initialised if it's
> meant to keep the value from last iteration (although that appears to
> be always null).
No, it's not kept. The lifetime ends and the end of each execution of
the loop.
> This is an example where it would be far clearer if backlog was
> declared outside the loop (and initialised to NULL), then you KNOW
> what its value is first time around, and you KNOW for certain that it
> will keep its value from the last iteration. And of course that will
> allow it to be initialised.
If there is a problem with this code (and I don't yet understand it),
then it is solved by initialising backlog. Extending the lifetime of
backlog is not helpful. In fact it's unhelpful. The more state that is
preserved over any piece of code the harder it is to reason about it.
> (One more argument in my list against declarations inside the code.)
Once the supposed problem is fixed (the initialisation) there is nothing
to be gained by moving the declaration outside the loop. You claim that
somehow you would know more about it (you write KNOW in CAPS twice). If
you declare and initialise it in the loop you know exactly the same
about its value at every point, except that it easier to reason about
the value because it is not held over from previous loops. In addition
you know /more/ about its purpose -- you know that it is not supposed to
be state that is maintained over the loop.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-01 16:41 -0800 |
| Message-ID | <lnzhrfuimw.fsf@kst-u.example.com> |
| In reply to | #140463 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> but then I thought that the example is probably over-simplified. Indeed
> it is. The code is actually:
>
> static int queue_manag(void *data)
> {
> cpg->eng_st = ENGINE_IDLE;
> do {
> struct crypto_async_request *async_req = NULL;
> struct crypto_async_request *backlog;
>
> __set_current_state(TASK_INTERRUPTIBLE);
>
> if (cpg->eng_st == ENGINE_W_DEQUEUE)
> dequeue_complete_req();
>
> spin_lock_irq(&cpg->lock);
> if (cpg->eng_st == ENGINE_IDLE) {
> backlog = crypto_get_backlog(&cpg->queue);
> async_req = crypto_dequeue_request(&cpg->queue);
> if (async_req) {
> BUG_ON(cpg->eng_st != ENGINE_IDLE);
> cpg->eng_st = ENGINE_BUSY;
> }
> }
> spin_unlock_irq(&cpg->lock);
>
> if (backlog) {
> backlog->complete(backlog, -EINPROGRESS);
> backlog = NULL;
> }
>
> if (async_req) {
> if (crypto_tfm_alg_type(async_req->tfm) !=
> CRYPTO_ALG_TYPE_AHASH) {
> struct ablkcipher_request *req =
> ablkcipher_request_cast(async_req);
> mv_start_new_crypt_req(req);
> } else {
> struct ahash_request *req =
> ahash_request_cast(async_req);
> mv_start_new_hash_req(req);
> }
> async_req = NULL;
> }
>
> schedule();
>
> } while (!kthread_should_stop());
> return 0;
> }
>
> The real problem is all the shared global state that makes reasoning
> about this code almost impossible, but I assume that is usual in this
> sort of driver. (If it usual, I want to ask why that is so in 2019, but
> that's another topic!)
>
> cpg->eng_st is set to ENGINE_IDLE so the code /looks/ fine from the
> single-threaded point of view. Presumably some other thread can come
> along and alter cpg->eng_s. but then I'd imagine all kinds of possible
> messes because lots of the code manipulates *cpg in ways that don't
> appear to be thread safe. At first glance it look like the call to
> dequeue_complete_req should really be locked.
cpg->eng_st is set to ENGINE_IDLE before the loop starts, but it can
be set to ENGINE_BUSY in the body of the loop, which will cause an
uninitialized pointer (backlog) to be accessed on a later iteration.
It invokes BUG_ON() before setting cpg->eng_st to ENGINE_BUSY,
implying that it's something that shouldn't normally happen, but
it still needs to handle it sanely.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-02 02:00 +0000 |
| Message-ID | <871s4rne3y.fsf@bsb.me.uk> |
| In reply to | #140467 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> but then I thought that the example is probably over-simplified. Indeed
>> it is. The code is actually:
>>
>> static int queue_manag(void *data)
>> {
>> cpg->eng_st = ENGINE_IDLE;
>> do {
>> struct crypto_async_request *async_req = NULL;
>> struct crypto_async_request *backlog;
>>
>> __set_current_state(TASK_INTERRUPTIBLE);
>>
>> if (cpg->eng_st == ENGINE_W_DEQUEUE)
>> dequeue_complete_req();
>>
>> spin_lock_irq(&cpg->lock);
>> if (cpg->eng_st == ENGINE_IDLE) {
>> backlog = crypto_get_backlog(&cpg->queue);
>> async_req = crypto_dequeue_request(&cpg->queue);
>> if (async_req) {
>> BUG_ON(cpg->eng_st != ENGINE_IDLE);
>> cpg->eng_st = ENGINE_BUSY;
>> }
>> }
>> spin_unlock_irq(&cpg->lock);
>>
>> if (backlog) {
>> backlog->complete(backlog, -EINPROGRESS);
>> backlog = NULL;
>> }
>>
>> if (async_req) {
>> if (crypto_tfm_alg_type(async_req->tfm) !=
>> CRYPTO_ALG_TYPE_AHASH) {
>> struct ablkcipher_request *req =
>> ablkcipher_request_cast(async_req);
>> mv_start_new_crypt_req(req);
>> } else {
>> struct ahash_request *req =
>> ahash_request_cast(async_req);
>> mv_start_new_hash_req(req);
>> }
>> async_req = NULL;
>> }
>>
>> schedule();
>>
>> } while (!kthread_should_stop());
>> return 0;
>> }
>>
>> The real problem is all the shared global state that makes reasoning
>> about this code almost impossible, but I assume that is usual in this
>> sort of driver. (If it usual, I want to ask why that is so in 2019, but
>> that's another topic!)
>>
>> cpg->eng_st is set to ENGINE_IDLE so the code /looks/ fine from the
>> single-threaded point of view. Presumably some other thread can come
>> along and alter cpg->eng_s. but then I'd imagine all kinds of possible
>> messes because lots of the code manipulates *cpg in ways that don't
>> appear to be thread safe. At first glance it look like the call to
>> dequeue_complete_req should really be locked.
>
> cpg->eng_st is set to ENGINE_IDLE before the loop starts, but it can
> be set to ENGINE_BUSY in the body of the loop, which will cause an
> uninitialized pointer (backlog) to be accessed on a later iteration.
Oh, yes. Thanks. I don't know why I was not seeing that. I thought
some other thread might access cpg->eng_st but it's right there in the
loop!
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-01 15:10 -0800 |
| Message-ID | <q32jlg$2g0$1@dont-email.me> |
| In reply to | #140460 |
On 2/1/2019 11:59 AM, Stefan Ram wrote:
> ...
> This is an uninitialized pointer dereference vulnerability
> discovered in the Linux kernel and patched in April 2015:
>
> static int queue_manag(void *data)
> {
> /* back log is defined without initialization */
> struct crypto_async_request *backlog;
>
> if (cpg->eng_st == ENGINE_IDLE) {
> backlog = crypto_get_backlog(&cpg->queue);
> }
>
> if (backlog) {
> /* uninitialized pointer dereferenced! */
> backlog->complete(backlog, -EINPROGRESS);
> }
>
> return 0;
> }
>
> A »= 0« is enough to remove the vulnerability in this case.
Another misleading example.
In this case it is not about what's "enough to remove the
vulnerability". Initialization of `backlog` is actually a *critical*
element of the original code design. The author of the code deliberately
decided to rely on the natural "start with default value - update as
necessary" coding idiom. However, the author of the code made an obvious
error while implementing that idiom.
In this case the initialization of `backlog` is definitely NOT an
example of "dummy initialization". For which reason it is completely
unclear to me why you are posting this here. Nobody is arguing with the
fact that initialization is necessary here.
That's not the topic we are talking about.
> In 2015 and 2016 alone, 16 uninitialized-use vulnerabilities
> have been patched in the Linux Kernel. Those are "a critical
> attack vector that can be reliably exploited to launch
> privilege escalation attacks in the Linux kernel".
Regardless of how many "uninitialized-use vulnerabilities" were patched
in the Linux Kernel, it will never be a reason to use "carpet bombing"
approach to initialization (or anything else).
You cannot "fix" an incompetent and sloppy developers by making them
blindly and mechanically follow various "One True Rule" practices. This
will not fix problems. This can only sweep problems under the carpet and
make them more difficult to detect.
Granted, the net result might prove to be positive in development
environments based on huge "farms" of incompetent developers with
"revolving door" participation policy... but I sure hope things are not
that bad in Linux development.
> The C++ Core Guidelines are a collaborative effort led by
> Bjarne Stroustrup and Herb Sutter and are aimed at C++
> programmers. They are the result of many person-years of
> discussion and design across a number of organizations.
Nobody here says that these guidelines are bad, wrong or useless. I'm
just pointing out that every tool has its area of applicability.
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-01 14:36 +0000 |
| Message-ID | <TPY4E.296798$JW5.11689@fx46.iad> |
| In reply to | #140447 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >On 2/1/19 05:26, Anton Shepelev wrote: >> Andrey Tarasevich: >> >>> The ability to interleave declarations and statements gives >>> one the opportunity to supply a meaningful initializer at >>> the point of declaration. This alone immediately closes the >>> debate: declarations should be made locally, as close to >>> the point of the actual usage as possible. >> >> You can declare a variable at the top but initialise is >> immediately before use. > >Thereby taking the risk of using the value of that variable before it's >been initialized. Which pretty much every modern compiler will diagnose fo you.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-01 07:05 -0800 |
| Message-ID | <6fbf1fa7-7659-48e4-813d-550b87cf6202@googlegroups.com> |
| In reply to | #140450 |
On Friday, February 1, 2019 at 9:36:43 AM UTC-5, Scott Lurndal wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >On 2/1/19 05:26, Anton Shepelev wrote: ... > >> You can declare a variable at the top but initialise is > >> immediately before use. > > > >Thereby taking the risk of using the value of that variable before it's > >been initialized. > > Which pretty much every modern compiler will diagnose fo you. Diagnosing it in all possible cases is provably equivalent to solving the Halting Problem. That is why producing such diagnostics is not mandatory. Because it's not mandatory, you can't rely upon getting such a diagnostics even in cases where it's relatively easy to diagnose. The diagnostic you will get from such code if you delay defining the variable until after you can initialize the variable with a value that's intended to be used is mandatory when it occurs outside the new, reduced scope of the variable, which is often the case.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 22:30 -0800 |
| Message-ID | <86zhqjawoz.fsf@mailhub.linuxsc.com> |
| In reply to | #140447 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... > I just don't see any reason (other than the fact that it didn't > use to be permitted) why it's bad to intermingle statements and > declarations, Nothing wrong with that, as long as you don't make the mistake of leaping to the conclusion that just because you don't see any reason that means there isn't one.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-02-26 12:37 +0000 |
| Message-ID | <q53buf$lbq$1@news.xmission.com> |
| In reply to | #141390 |
In article <86zhqjawoz.fsf@mailhub.linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >... > >> I just don't see any reason (other than the fact that it didn't >> use to be permitted) why it's bad to intermingle statements and >> declarations, > >Nothing wrong with that, as long as you don't make the mistake of >leaping to the conclusion that just because you don't see any >reason that means there isn't one. Your statement has the same weight as saying that just because I don't see any Flying Spaghetti Monsters, that there aren't any. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/BestCLCPostEver
[toc] | [prev] | [next] | [standalone]
Page 18 of 19 — ← Prev page 1 … 16 17 [18] 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web