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 19 of 19 — ← Prev page 1 … 17 18 [19]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-06 09:09 -0800 |
| Message-ID | <86wolcszeu.fsf@mailhub.linuxsc.com> |
| In reply to | #141420 |
gazelle@shell.xmission.com (Kenny McCormack) writes: > 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. It's a broken analogy. And you need a course in logic.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-26 05:50 -0800 |
| Message-ID | <87adaeb3-0bda-485f-82d5-2be7babd1776@googlegroups.com> |
| In reply to | #141390 |
On Tuesday, February 26, 2019 at 1:30:28 AM UTC-5, Tim Rentsch 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. I don't. I'm willing to consider the possibility that there is one, if a reasonable candidate is suggested - which has not yet occurred. Until then, I consider that the preponderance of the evidence I've collected justifies my guessing (and any statement about reality is necessarily at best an informed guess) that there is none.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-06 09:06 -0800 |
| Message-ID | <861s3kue40.fsf@mailhub.linuxsc.com> |
| In reply to | #141428 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Tuesday, February 26, 2019 at 1:30:28 AM UTC-5, Tim Rentsch 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. > > I don't. I'm willing to consider the possibility that there is one, if a > reasonable candidate is suggested - which has not yet occurred. Until > then, I consider that the preponderance of the evidence I've collected > justifies my guessing (and any statement about reality is necessarily at > best an informed guess) that there is none. That isn't really much different than jumping to the conclusion. Note also that the word "bad" implies a personal judgment, which makes the question one of opinion rather than one of fact. So what you might be saying is you don't see any reason /that you agree with/. That is very different than saying no reason exists. Also let's look at some actual code samples. If you look at the function definitions given in "Numerical Recipes in C", I think you will find that all of them never declare variables once the statements start. This evidence strongly suggests that /some/ people think there's a good reason not to mix statements and declarations. Even if you don't know what the reason is, it seems silly to deny that there is one.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-06 10:48 -0800 |
| Message-ID | <b2a71b06-f2e2-4594-bb86-b6d95a228926@googlegroups.com> |
| In reply to | #141735 |
On Wednesday, March 6, 2019 at 12:06:31 PM UTC-5, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > On Tuesday, February 26, 2019 at 1:30:28 AM UTC-5, Tim Rentsch 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. > > > > I don't. I'm willing to consider the possibility that there is one, if a > > reasonable candidate is suggested - which has not yet occurred. Until > > then, I consider that the preponderance of the evidence I've collected > > justifies my guessing (and any statement about reality is necessarily at > > best an informed guess) that there is none. > > That isn't really much different than jumping to the conclusion. No, there's a huge difference - in the phrase "jumping to the conclusion", the word "jump" is a metaphor for skipping the evaluation of "the preponderance of the evidence" that I was referring to. I didn't skip that stop, so my conclusion doesn't qualify as having been jumped to. > Note also that the word "bad" implies a personal judgment, which What wording would you use instead of "bad" to express an impersonal judgement that something should be avoided? The position that I was talking about was that it's always bad to intermingle them, not that it was a purely personal matter for each developer to decide for themselves. ... > Also let's look at some actual code samples. If you look at the > function definitions given in "Numerical Recipes in C", I think > you will find that all of them never declare variables once the > statements start. This evidence strongly suggests that /some/ > people think there's a good reason not to mix statements and > declarations. As I said, "I just don't see any reason (other than the fact that it didn't use to be permitted)". "it didn't used to be permitted" is probably sufficient to explain a lot of the evidence of that type which you might choose to cite. Numerical Recipes in C was first published in 1988, even before C90 was approved, and the 2nd edition came out in 1992, long before C99 was approved. If you're looking at a later edition - well, just because someone doesn't feel that it's worthwhile re-writing a large body of existing code to intermix statements and declarations doesn't mean that they're opposed to writing new code that way. The fact that some people think there's a good reason to not do something is not sufficient reason to not do it, not even if that group constitutes a majority of the relevant group. There used to be sufficiently many people who thought there were good reasons to not miscegenate that it was still illegal in many US states at the time I was born, and there's still quite a few who think that way. But I married my wife anyway. > ... Even if you don't know what the reason is, it > seems silly to deny that there is one. But I do know what the reasons usually given are. In many cases, it's "that it didn't use to be permitted". A need to write code that is compatible with C90 is sufficient to make that a good reason. In other cases, the reason is personal judgement that I've never seen adequately justified - the arguments presented in this thread being a prime example of inadequate justification. I never denied that inadequately justified reasons exist, only that they weren't adequately justified. I've also never claimed that adequately justified reasons don't exist. Only a fool would make such a general claim - I'm generally careful to qualify my statements to avoid making such claims. In this case the qualifying clause was "I just don't see any reason ...", which leaves open the possibility that there's a reason I haven't seen yet. How is it that I can get criticized for ignoring that possibility after explicitly addressing it at the very beginning of the statement being criticized? Do you actually think about what I've said before jumping to conclusions about what I meant?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-23 10:27 -0700 |
| Message-ID | <86ftrdo60q.fsf@mailhub.linuxsc.com> |
| In reply to | #141743 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Wednesday, March 6, 2019 at 12:06:31 PM UTC-5, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> On Tuesday, February 26, 2019 at 1:30:28 AM UTC-5, Tim Rentsch 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. >>> >>> I don't. I'm willing to consider the possibility that there is >>> one, if a reasonable candidate is suggested - which has not yet >>> occurred. Until then, I consider that the preponderance of the >>> evidence I've collected justifies my guessing (and any statement >>> about reality is necessarily at best an informed guess) that there >>> is none. >> >> That isn't really much different than jumping to the conclusion. > > No, there's a huge difference - in the phrase "jumping to the > conclusion", the word "jump" is a metaphor for skipping the > evaluation of "the preponderance of the evidence" that I was > referring to. [...] The problem with this line of reasoning is the "evidence" you're talking about is not something independently presented but whatever "evidence" you happen to collect or think is relevant. But you aren't all that good at collecting evidence. For example, your statement elsethread "I can't imagine what the argument might be that calls for 1000+ bits [...]". You easily could have imagined such an argument if only you had done a better job of looking for evidence to back it up.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-25 12:14 -0700 |
| Message-ID | <65d5b2ec-fc05-4f7a-81aa-8190066c6c5d@googlegroups.com> |
| In reply to | #142299 |
On Saturday, March 23, 2019 at 1:27:41 PM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > On Wednesday, March 6, 2019 at 12:06:31 PM UTC-5, Tim Rentsch wrote: > > > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> > >>> On Tuesday, February 26, 2019 at 1:30:28 AM UTC-5, Tim Rentsch 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. > >>> > >>> I don't. I'm willing to consider the possibility that there is > >>> one, if a reasonable candidate is suggested - which has not yet > >>> occurred. Until then, I consider that the preponderance of the > >>> evidence I've collected justifies my guessing (and any statement > >>> about reality is necessarily at best an informed guess) that there > >>> is none. > >> > >> That isn't really much different than jumping to the conclusion. > > > > No, there's a huge difference - in the phrase "jumping to the > > conclusion", the word "jump" is a metaphor for skipping the > > evaluation of "the preponderance of the evidence" that I was > > referring to. [...] > > The problem with this line of reasoning is the "evidence" you're > talking about is not something independently presented but > whatever "evidence" you happen to collect or think is relevant. > But you aren't all that good at collecting evidence. I never claimed that I was, though I have examined all of the "evidence" presented in favor of that point of view in this thread, and found it wanting. The possibility that I've missed some relevant evidence is why I explicitly said "I'm willing to consider ...".
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-01 09:43 -0800 |
| Message-ID | <q320gs$s5m$1@dont-email.me> |
| In reply to | #140445 |
On 2/1/2019 2:26 AM, 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. This is exactly the terrible practice that we can finally forget about, thanks to C99 declarations. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-01-31 03:46 +0000 |
| Message-ID | <5c526b05.274953391@news.xmission.com> |
| In reply to | #140413 |
On 30 Jan 2019 17:20:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote: >nobody@example.org (Scott) writes: >>Second - and I'm probably in the vast minority here - I think that >>mixing declarations with code is sloppy and lazy, > > Declarations /are/ code. In C we can write: Well, yes but no. I tried to reformulate Andrei's enigma without mixing code with declarations, but could not. According to a GCC diagnostic, "...a declaration is not a statement" Can't argue with that.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-30 22:49 -0500 |
| Message-ID | <q2tr8c$kk1$1@dont-email.me> |
| In reply to | #140428 |
On 1/30/19 22:46, Scott wrote: > On 30 Jan 2019 17:20:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram) > wrote: > >> nobody@example.org (Scott) writes: >>> Second - and I'm probably in the vast minority here - I think that >>> mixing declarations with code is sloppy and lazy, >> >> Declarations /are/ code. In C we can write: > > Well, yes but no. I tried to reformulate Andrei's enigma without > mixing code with declarations, but could not. According to a GCC > diagnostic, > "...a declaration is not a statement" > > Can't argue with that. True, declarations are not statements, but both statements and declarations are source code. Other kinds of C source code includes preprocessing directives, whitespace, and comments.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-30 20:08 -0800 |
| Message-ID | <q2tsbt$50k$1@dont-email.me> |
| In reply to | #140413 |
On 1/30/2019 9:20 AM, Stefan Ram wrote:
>
> Declarations /are/ code.
>
One of the properties of C99 variably modified types that proved to be
most surprising for me, was the fact that even typedef declarations for
VLA types produce code.
int n = 42;
typedef int ARRAY[n];
n = 53;
ARRAY a; // <-- this is an `int [42]` VLA
The above typedef declaration is required to stand for a `int [42]` VLA
even after the value of `n` changed to `53`. So, the typedef cannot just
tie itself to `n`. It has no other choice but to to generate code: it is
required to take a "snapshot" of all values that affect VLA's sizes and
store them in internal variables.
For this reason, the restriction on jumps over VLA declarations applies
not only to declarations of VLA objects, but also to declarations of VLA
typedefs
goto after; // <- ERROR: illegal jump
int n = 42;
typedef int ARRAY[n];
after:;
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-02-10 09:11 -0800 |
| Message-ID | <6a8dd44f-4970-4c6f-a5d1-12881c742792@googlegroups.com> |
| In reply to | #140381 |
On Tuesday, January 29, 2019 at 1:50:43 PM UTC-5, Andrey Tarasevich wrote: > [snip] The first few pages of this thread (first ~80 messages) have been some of the more interesting content / debate / discussion I've read in a long time (C-content-wise). -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2019-02-19 10:23 -0800 |
| Message-ID | <a1d79525-8782-4f0e-a216-e8d38c5d2ad3@googlegroups.com> |
| In reply to | #140381 |
On Tuesday, January 29, 2019 at 12:50:43 PM UTC-6, Andrey Tarasevich wrote:
> Hello
>
> I would be nice if someone could explain to me the rationale behind this
> part of the specification
>
> > 6.2.4 Storage durations of objects
> > 6 [...] If an initialization is specified for the object, it is
> > performed each time the declaration or compound literal is reached
> > in the execution of the block; otherwise, the value becomes
> > indeterminate each time the declaration is reached.
>
> Specifically, the last part about the value's becoming indeterminate.
>
> Why would we want to "reset" an object to an indeterminate value *each
> time* we reach its declaration within its block? (As opposed to giving
> it indeterminate value only *initially*?)
>
I'm sure somebody's already said this, but...
All that language means is that there's no guarantee that the prior value is retained.
Nothing gets "reset" as part of the normal flow of execution, but it's possible for that
normal flow of execution to overwrite that memory location before it's used again.
Even in a loop like
for ( int i = 0; i < N; i++ )
{
int x;
...
x = foo( i );
}
it's *possible* (however unlikely on any current implementation) that the value of `x` is
not retained from the end of one loop iteration to the beginning of the next one. On any
implementation you or I are familiar with it will be, but there may be some oddball
platform out there where block-scope objects are somehow overwritten when the
end of the block is reached.
There's nothing that mandates an object be "reset" with an indeterminate value (which
brings up the question of *which* indeterminate value). "Becomes indeterminate" simply
means "it may be the same as before, or it may not, we can't guarantee either way."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-19 22:55 +0100 |
| Message-ID | <q4hu06$5u7$1@dont-email.me> |
| In reply to | #141145 |
On 19/02/2019 19:23, John Bode wrote:
> On Tuesday, January 29, 2019 at 12:50:43 PM UTC-6, Andrey Tarasevich wrote:
>> Hello
>>
>> I would be nice if someone could explain to me the rationale behind this
>> part of the specification
>>
>> > 6.2.4 Storage durations of objects
>> > 6 [...] If an initialization is specified for the object, it is
>> > performed each time the declaration or compound literal is reached
>> > in the execution of the block; otherwise, the value becomes
>> > indeterminate each time the declaration is reached.
>>
>> Specifically, the last part about the value's becoming indeterminate.
>>
>> Why would we want to "reset" an object to an indeterminate value *each
>> time* we reach its declaration within its block? (As opposed to giving
>> it indeterminate value only *initially*?)
>>
>
> I'm sure somebody's already said this, but...
>
> All that language means is that there's no guarantee that the prior value is retained.
> Nothing gets "reset" as part of the normal flow of execution, but it's possible for that
> normal flow of execution to overwrite that memory location before it's used again.
>
> Even in a loop like
>
> for ( int i = 0; i < N; i++ )
> {
> int x;
> ...
> x = foo( i );
> }
>
> it's *possible* (however unlikely on any current implementation) that the value of `x` is
> not retained from the end of one loop iteration to the beginning of the next one. On any
> implementation you or I are familiar with it will be, but there may be some oddball
> platform out there where block-scope objects are somehow overwritten when the
> end of the block is reached.
Sorry, but in the C compilers I use, there will be no "x" at all and
thus no meaning to what its value might be. When a variable's value is
set but not used, compilers tend to eliminate them altogether.
Even if the variable was used after setting it, it still would not make
sense to talk about its value being "retained" - to the compiler, the
variable won't be "live" until it is set.
And even if the variable was used in several places earlier, there is
/still/ nothing to suggest it has the same value - it is highly likely
that it is not even in the same register on the processor.
>
> There's nothing that mandates an object be "reset" with an indeterminate value (which
> brings up the question of *which* indeterminate value). "Becomes indeterminate" simply
> means "it may be the same as before, or it may not, we can't guarantee either way."
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-19 15:48 -0800 |
| Message-ID | <lnd0nnqqz8.fsf@kst-u.example.com> |
| In reply to | #141147 |
David Brown <david.brown@hesbynett.no> writes:
> On 19/02/2019 19:23, John Bode wrote:
[...]
>> Even in a loop like
>>
>> for ( int i = 0; i < N; i++ )
>> {
>> int x;
>> ...
>> x = foo( i );
>> }
>>
>> it's *possible* (however unlikely on any current implementation) that
>> the value of `x` is not retained from the end of one loop iteration
>> to the beginning of the next one. On any implementation you or I are
>> familiar with it will be, but there may be some oddball platform out
>> there where block-scope objects are somehow overwritten when the end
>> of the block is reached.
>
> Sorry, but in the C compilers I use, there will be no "x" at all and
> thus no meaning to what its value might be. When a variable's value is
> set but not used, compilers tend to eliminate them altogether.
Agreed.
> Even if the variable was used after setting it, it still would not make
> sense to talk about its value being "retained" - to the compiler, the
> variable won't be "live" until it is set.
>
> And even if the variable was used in several places earlier, there is
> /still/ nothing to suggest it has the same value - it is highly likely
> that it is not even in the same register on the processor.
OK, let's assume that x is used after being set. Of course the standard
is clear that its value becomes indeterminate when the declaration is
reached on each iteration -- but it's likely (but by no means certain)
that the stored value will be retained and visible in x on the next
iteration.
Unless the compiler performs loop unrolling, there's only one copy of
the machine code for the body of the loop. That machine code will refer
to x in the same memory location, or in the same register, on each
iteration. Because of that, the new x created in the second iteration
of the loop is very likely to be in the same location as the x created
in the first iteration.
It is, of course, entirely consistent with the standard's requirements
for the new x to acquire the value of the previous x (or to state it in
a strictly incorrect way, for x to retain its value across iterations).
(BTW, a quick experiment showed x "retaining" its previous value
across iterations, with gcc and clang, -O0, -O1, -O2, and -O3. I'd be
interested in the results of such an experiment on the implementations
you use.)
>> There's nothing that mandates an object be "reset" with an
>> indeterminate value (which brings up the question of *which*
>> indeterminate value). "Becomes indeterminate" simply means "it may
>> be the same as before, or it may not, we can't guarantee either way."
Of course optimization can cause the value to differ from the previous
one. For example, if the loop is unrolled, the separate code for two
iterations might store x in different registers.
IMHO the most plausible scenario that would cause the value to differ
across iterations is an implementation (or compiler option) that, as an
aid to debugging, treats
int x;
as equivalent to
int x = some_recognizable_value;
so that if you see that value in memory, it's an indication that you
forgot to initialize something.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-20 00:10 +0000 |
| Message-ID | <lW0bE.232574$DF1.4870@fx34.am4> |
| In reply to | #141150 |
On 19/02/2019 23:48, Keith Thompson wrote: > (BTW, a quick experiment showed x "retaining" its previous value > across iterations, with gcc and clang, -O0, -O1, -O2, and -O3. I'd be > interested in the results of such an experiment on the implementations > you use.) When I do such tests then they are usually considered meaningless. For example, every test I might do would show that twos complement arithmetic is being used, and that signed overflow exhibits predictable behaviour. But that's something that can't be assumed. Same with assuming that variable 'x' retains its value. I can spend 30 minutes modifying a compiler such that its value is reset every time its declaration is encountered, so disproving your point. And if I can do it, then anyone can. (Why would I do that? So that when first encountered, x doesn't have an indeterminate value. And it might be easier to reset it each time than just once.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-19 16:42 -0800 |
| Message-ID | <ln1s43qohl.fsf@kst-u.example.com> |
| In reply to | #141151 |
Bart <bc@freeuk.com> writes:
> On 19/02/2019 23:48, Keith Thompson wrote:
>> (BTW, a quick experiment showed x "retaining" its previous value
>> across iterations, with gcc and clang, -O0, -O1, -O2, and -O3. I'd be
>> interested in the results of such an experiment on the implementations
>> you use.)
>
> When I do such tests then they are usually considered meaningless. For
> example, every test I might do would show that twos complement
> arithmetic is being used, and that signed overflow exhibits predictable
> behaviour. But that's something that can't be assumed.
>
> Same with assuming that variable 'x' retains its value. I can spend 30
> minutes modifying a compiler such that its value is reset every time its
> declaration is encountered, so disproving your point. And if I can do
> it, then anyone can.
I didn't assume any such thing. I speculated that x is likely
to "retain its value" in most implementations, and demonstrated
that my speculation happens to be correct for a limited number of
implementations. Modifying a compiler wouldn't disprove anything I
wrote. In fact, in text that you snipped, I explicitly acknowledged
that some compilers might reset the value of x.
(The phrase "retains its value" isn't strictly accurate from the
point of view of the abstract machine.)
If I had said that it's reasonable to write code that depends on
the assumption that x retains its value, you might have a point.
But I didn't say that.
> (Why would I do that? So that when first encountered, x doesn't have an
> indeterminate value. And it might be easier to reset it each time than
> just once.)
It's easier to initialize x than to modify a compiler. If you want
x to have a determinate value, just give it one.
--
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-20 13:05 +0100 |
| Message-ID | <q4jfq0$mq4$1@dont-email.me> |
| In reply to | #141150 |
On 20/02/2019 00:48, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 19/02/2019 19:23, John Bode wrote:
> [...]
>>> Even in a loop like
>>>
>>> for ( int i = 0; i < N; i++ )
>>> {
>>> int x;
>>> ...
>>> x = foo( i );
>>> }
>>>
>>> it's *possible* (however unlikely on any current implementation) that
>>> the value of `x` is not retained from the end of one loop iteration
>>> to the beginning of the next one. On any implementation you or I are
>>> familiar with it will be, but there may be some oddball platform out
>>> there where block-scope objects are somehow overwritten when the end
>>> of the block is reached.
>>
>> Sorry, but in the C compilers I use, there will be no "x" at all and
>> thus no meaning to what its value might be. When a variable's value is
>> set but not used, compilers tend to eliminate them altogether.
>
> Agreed.
>
>> Even if the variable was used after setting it, it still would not make
>> sense to talk about its value being "retained" - to the compiler, the
>> variable won't be "live" until it is set.
>>
>> And even if the variable was used in several places earlier, there is
>> /still/ nothing to suggest it has the same value - it is highly likely
>> that it is not even in the same register on the processor.
>
> OK, let's assume that x is used after being set. Of course the standard
> is clear that its value becomes indeterminate when the declaration is
> reached on each iteration -- but it's likely (but by no means certain)
> that the stored value will be retained and visible in x on the next
> iteration.
I don't think it is fair to say "likely". "Possible", yes, but whether
or not it is "likely" depends on many factors - the rest of the code,
the optimisation, the complexity of the compiler. On a compiler
(including options) which puts "x" in a slot in the stack frame and
keeps it there, it is likely that the stored value will be retained for
the next iteration. On one which keeps x in whatever register happens
to be convenient at the time, "likely" is too strong.
>
> Unless the compiler performs loop unrolling, there's only one copy of
> the machine code for the body of the loop.
Yes.
> That machine code will refer
> to x in the same memory location, or in the same register, on each
> iteration.
The code will refer to x in the same register or memory location at the
same point within each loop - but at different points within a loop, it
could be in different positions.
If the code contained the sequence:
int x, y;
foo1();
x = foo2();
x += 3;
y = foo3();
x = x + y;
foo4(x);
then the compiler is likely to see it as:
// Ignoring "int x, y;"
foo1();
const int x1 = foo2();
const int x2 = x1 + 3;
// end-of-life for x1
const int y1 = foo3();
const int x3 = x2 + y1;
// eol for x2
// eol for y1
foo4(x3);
// eol for x3
This is called "single static assignment" form. As far as the compiler
is concerned, there are 4 different variables here and each could be put
in whatever register makes sense at the time, taking into account the
lifespans of the variables. There is no difference between the x's and
the y's. (Debugging options might encourage a consistency and a "home
register" or "home stack slot" to make life easier for debugger software.)
So each assignment to x might go to a different register. On an ISA
like the x86, it will usually be the same logical register -
instructions are typically of the form "x += y". (On the actual
hardware, there will be a new register used - but that is not visible
from the ISA.) On common RISC systems, the compiler may prefer to
assign to a new register with a "x_new = x + y" instruction as that can
give better pipelining.
Once you go back to the beginning of the loop, you are back to the
original registers again - but that may be different from ones used
underway in the loop contents.
> Because of that, the new x created in the second iteration
> of the loop is very likely to be in the same location as the x created
> in the first iteration.
>
> It is, of course, entirely consistent with the standard's requirements
> for the new x to acquire the value of the previous x (or to state it in
> a strictly incorrect way, for x to retain its value across iterations).
>
Yes.
> (BTW, a quick experiment showed x "retaining" its previous value
> across iterations, with gcc and clang, -O0, -O1, -O2, and -O3. I'd be
> interested in the results of such an experiment on the implementations
> you use.)
I expect you'll see that on quick experiments - without reason to do
otherwise, the compiler will probably keep the same register assignment
throughout the instruction sequence. But if you have more complex code
leading to register pressure, you are more likely to see the register
moving around. (And as noted, you are more likely to see it on RISC
architectures with 3 register instructions.)
>
>>> There's nothing that mandates an object be "reset" with an
>>> indeterminate value (which brings up the question of *which*
>>> indeterminate value). "Becomes indeterminate" simply means "it may
>>> be the same as before, or it may not, we can't guarantee either way."
>
> Of course optimization can cause the value to differ from the previous
> one. For example, if the loop is unrolled, the separate code for two
> iterations might store x in different registers.
>
Yes.
> IMHO the most plausible scenario that would cause the value to differ
> across iterations is an implementation (or compiler option) that, as an
> aid to debugging, treats
> int x;
> as equivalent to
> int x = some_recognizable_value;
> so that if you see that value in memory, it's an indication that you
> forgot to initialize something.
>
I haven't seen such options on any compiler I have used.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-02-20 10:30 -0600 |
| Message-ID | <r2vq6e9o88vfmbnkassqg65p9spjdq3qo4@4ax.com> |
| In reply to | #141159 |
On Wed, 20 Feb 2019 13:05:19 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 20/02/2019 00:48, Keith Thompson wrote: > >> IMHO the most plausible scenario that would cause the value to differ >> across iterations is an implementation (or compiler option) that, as an >> aid to debugging, treats >> int x; >> as equivalent to >> int x = some_recognizable_value; >> so that if you see that value in memory, it's an indication that you >> forgot to initialize something. >> > >I haven't seen such options on any compiler I have used. With MSVC, if you ask for the right run time debugging checks (-RTCs), he'll initialize stack frames to all 0xcccccccc. He won't actually do that at a block entry, just at function entry. So close, but not quite, although the necessary extension is conceptually straight-forward from there.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-02-19 16:05 -0600 |
| Message-ID | <l5vo6et1j81m5168khb4qqf0h6j5ahpoj5@4ax.com> |
| In reply to | #141145 |
On Tue, 19 Feb 2019 10:23:56 -0800 (PST), John Bode
<jfbode1029@gmail.com> wrote:
>On Tuesday, January 29, 2019 at 12:50:43 PM UTC-6, Andrey Tarasevich wrote:
>> Hello
>>
>> I would be nice if someone could explain to me the rationale behind this
>> part of the specification
>>
>> > 6.2.4 Storage durations of objects
>> > 6 [...] If an initialization is specified for the object, it is
>> > performed each time the declaration or compound literal is reached
>> > in the execution of the block; otherwise, the value becomes
>> > indeterminate each time the declaration is reached.
>>
>> Specifically, the last part about the value's becoming indeterminate.
>>
>> Why would we want to "reset" an object to an indeterminate value *each
>> time* we reach its declaration within its block? (As opposed to giving
>> it indeterminate value only *initially*?)
>>
>
>I'm sure somebody's already said this, but...
>
>All that language means is that there's no guarantee that the prior value is retained.
>Nothing gets "reset" as part of the normal flow of execution, but it's possible for that
>normal flow of execution to overwrite that memory location before it's used again.
>
>Even in a loop like
>
> for ( int i = 0; i < N; i++ )
> {
> int x;
> ...
> x = foo( i );
> }
>
>it's *possible* (however unlikely on any current implementation) that the value of `x` is
>not retained from the end of one loop iteration to the beginning of the next one. On any
>implementation you or I are familiar with it will be, but there may be some oddball
>platform out there where block-scope objects are somehow overwritten when the
>end of the block is reached.
I don't think it's unlikely at all. Consider a scenario where the
compiler can enregister x, between its first and last actual use
inside the loop, thus eliminating the storage location completely, and
then reuses that register either before or after that section.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-02-19 18:19 -0600 |
| Message-ID | <q77p6e5frt6gjn4ck1a2as2arjrel5u7io@4ax.com> |
| In reply to | #141148 |
On Tue, 19 Feb 2019 16:05:13 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:
>On Tue, 19 Feb 2019 10:23:56 -0800 (PST), John Bode
><jfbode1029@gmail.com> wrote:
>
>>On Tuesday, January 29, 2019 at 12:50:43 PM UTC-6, Andrey Tarasevich wrote:
>>> Hello
>>>
>>> I would be nice if someone could explain to me the rationale behind this
>>> part of the specification
>>>
>>> > 6.2.4 Storage durations of objects
>>> > 6 [...] If an initialization is specified for the object, it is
>>> > performed each time the declaration or compound literal is reached
>>> > in the execution of the block; otherwise, the value becomes
>>> > indeterminate each time the declaration is reached.
>>>
>>> Specifically, the last part about the value's becoming indeterminate.
>>>
>>> Why would we want to "reset" an object to an indeterminate value *each
>>> time* we reach its declaration within its block? (As opposed to giving
>>> it indeterminate value only *initially*?)
>>>
>>
>>I'm sure somebody's already said this, but...
>>
>>All that language means is that there's no guarantee that the prior value is retained.
>>Nothing gets "reset" as part of the normal flow of execution, but it's possible for that
>>normal flow of execution to overwrite that memory location before it's used again.
>>
>>Even in a loop like
>>
>> for ( int i = 0; i < N; i++ )
>> {
>> int x;
>> ...
>> x = foo( i );
>> }
>>
>>it's *possible* (however unlikely on any current implementation) that the value of `x` is
>>not retained from the end of one loop iteration to the beginning of the next one. On any
>>implementation you or I are familiar with it will be, but there may be some oddball
>>platform out there where block-scope objects are somehow overwritten when the
>>end of the block is reached.
>
>
>I don't think it's unlikely at all. Consider a scenario where the
>compiler can enregister x, between its first and last actual use
>inside the loop, thus eliminating the storage location completely, and
>then reuses that register either before or after that section.
And if the loop is unrolled, each copy may get its own x, in storeage
or in a register.
[toc] | [prev] | [standalone]
Page 19 of 19 — ← Prev page 1 … 17 18 [19]
Back to top | Article view | comp.lang.c
csiph-web