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 1 of 19 [1] 2 3 … 19 Next page →
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 10:50 -0800 |
| Subject | "...the value becomes,indeterminate each time the declaration is reached" |
| Message-ID | <q2q79p$1j7$1@dont-email.me> |
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*?)
Consider the following code sample. According to 6.2.4 the lifetime of a
non-VLA automatic objects in C is the full block that contains its
declaration. Passing control *within the block* to a point before the
declaration has no effect on the object
{
int *p = NULL;
again:
if (p != NULL)
printf("%d\n", *p); // <-- 1
int i; // <-- 2
if (p == NULL)
{
i = 42; // <-- 3
p = &i;
goto again;
}
// printf("%d\n", i); // <-- 4
}
In the above code, once the `printf` at point 1 is reached, it is
supposed to output `42` - the value variable `i` acquired at point `3`.
However, if we uncomment the `printf` at point 4 it will attempt to
output an *indeterminate* value, since passing over point 2 the second
time around "resets" the value of `i` to something indeterminate.
Why? Why can't we just have `i` keep its perfectly determinate value of
`42` in this case? Is there a clear rationale behind this behavior? Or
is this just an "unfortunate" side-effect of a wording that is intended
to simplify some other part of the spec?
--
Best regards,
Andrey Tarasevich
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-29 20:30 +0100 |
| Message-ID | <q2q9l2$h95$1@dont-email.me> |
| In reply to | #140381 |
On 29/01/2019 19:50, 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*?)
>
> Consider the following code sample. According to 6.2.4 the lifetime of a
> non-VLA automatic objects in C is the full block that contains its
> declaration. Passing control *within the block* to a point before the
> declaration has no effect on the object
>
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> int i; // <-- 2
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> }
>
> In the above code, once the `printf` at point 1 is reached, it is
> supposed to output `42` - the value variable `i` acquired at point `3`.
>
> However, if we uncomment the `printf` at point 4 it will attempt to
> output an *indeterminate* value, since passing over point 2 the second
> time around "resets" the value of `i` to something indeterminate.
>
> Why? Why can't we just have `i` keep its perfectly determinate value of
> `42` in this case? Is there a clear rationale behind this behavior? Or
> is this just an "unfortunate" side-effect of a wording that is intended
> to simplify some other part of the spec?
>
Why would you want i to keep its value? If you choose to write
spaghetti code and jump around like this, the compiler is free to do
whatever it likes with the value of "i" the second time around
(including keeping the value). If you want to keep it to a particular
value, move the definition above the label - then you are telling the
compiler what you want.
In code like this, "i" may not be given a memory address by an
optimising compiler - it could be in a register, or ignored altogether.
The wording of the standard here has two benefits. One is that it lets
the compiler generate better object code for sensible source code. The
other is that it lets compilers do better static error checking - it
means compilers can warn about more situations where you are doing
something questionable. Both of these, of course, depend on the tool,
the options, and the code.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 14:47 -0800 |
| Message-ID | <q2ql6g$tk7$1@dont-email.me> |
| In reply to | #140382 |
On 1/29/2019 11:30 AM, David Brown wrote: > > Why would you want i to keep its value? If you choose to write > spaghetti code and jump around like this, the compiler is free to do > whatever it likes with the value of "i" the second time around > (including keeping the value). The question is "why?". The code "jumps around" well within the lifetime of the object in question. Why is the object not guaranteed to keep its value at that specific spot of its lifetime? What is the reason this potential possibility for loss of value was introduced in C99? It wasn't there in C89/90 (unless it was a defect, of course). > If you want to keep it to a particular > value, move the definition above the label - then you are telling the > compiler what you want. This is not a question about coding style. > In code like this, "i" may not be given a memory address by an > optimising compiler - it could be in a register, or ignored altogether. I don't see how it makes any difference. Yes, it could be in a register. And? > The wording of the standard here has two benefits. One is that it lets > the compiler generate better object code for sensible source code. I don't see how. > The > other is that it lets compilers do better static error checking - it > means compilers can warn about more situations where you are doing > something questionable. Both of these, of course, depend on the tool, > the options, and the code. Unlikely. The situation in question relies critically on *indirect* access, since object name is not available above its point of declaration. And once we start talking about indirect access... well, no, it doesn't "let compilers do better static error checking". There's simply no fundamental difference between jumping to a point before object declaration and, say, jumping to another function. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-29 16:36 -0800 |
| Message-ID | <lno97zvv52.fsf@kst-u.example.com> |
| In reply to | #140392 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 1/29/2019 11:30 AM, David Brown wrote:
>> Why would you want i to keep its value? If you choose to write
>> spaghetti code and jump around like this, the compiler is free to do
>> whatever it likes with the value of "i" the second time around
>> (including keeping the value).
>
> The question is "why?". The code "jumps around" well within the lifetime
> of the object in question. Why is the object not guaranteed to keep its
> value at that specific spot of its lifetime? What is the reason this
> potential possibility for loss of value was introduced in C99? It wasn't
> there in C89/90 (unless it was a defect, of course).
Here's one possible rationale.
An uninitialized local object has an indeterminate value until a value
has been assigned to it.
{
int x;
int y = 42;
}
A compiler could treat `int x;` as `int x = SOME_WEIRD_VALUE;` to aid in
debugging. It might store some consistent bit pattern that's unlikely
to appear accidentally. (I think I've seen a repeating 0xe5 pattern used
this way).
{
int x /* = (int)0xe5e5e5e5 */;
int y = 42;
}
If you write code that uses a goto to transfer control to a point
within the lifetime of x but before its declaration (yes, my wording
is a little sloppy), it would not be reasonable to require such a
compiler to treat this as a special case and omit the initialization
when the declaration is reached a second time.
I don't know whether the authors of the standard had this kind of
scenario in mind.
--
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 | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 18:48 -0800 |
| Message-ID | <q2r39v$pbd$1@dont-email.me> |
| In reply to | #140392 |
On 1/29/2019 2:47 PM, Andrey Tarasevich wrote: > ... > What is the reason this > potential possibility for loss of value was introduced in C99? It wasn't > there in C89/90 (unless it was a defect, of course). Just realized that this is a rather nonsensical remark on my part. In C89/90 the issue simply did not exist, since in C89/90 it was not possible to mix declarations and statements. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-01-30 05:48 -0800 |
| Message-ID | <162dbfc7-935e-4954-a219-48c8de71d3ce@googlegroups.com> |
| In reply to | #140392 |
On Wednesday, 30 January 2019 00:47:52 UTC+2, Andrey Tarasevich wrote: > On 1/29/2019 11:30 AM, David Brown wrote: > > In code like this, "i" may not be given a memory address by an > > optimising compiler - it could be in a register, or ignored altogether. > > I don't see how it makes any difference. Yes, it could be in a register. > And? Could it? I thought usage of address of operator makes it bit tricky.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-30 14:06 -0800 |
| Message-ID | <lnk1ilx0k9.fsf@kst-u.example.com> |
| In reply to | #140408 |
Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 30 January 2019 00:47:52 UTC+2, Andrey Tarasevich wrote:
>> On 1/29/2019 11:30 AM, David Brown wrote:
>> > In code like this, "i" may not be given a memory address by an
>> > optimising compiler - it could be in a register, or ignored altogether.
>>
>> I don't see how it makes any difference. Yes, it could be in a register.
>> And?
>
> Could it? I thought usage of address of operator makes it bit tricky.
An object's value can always be stored in a register (if it will
fit and if a register is available). If its address is taken (and
the address is used), it must *also* be stored in memory so that
`&object` works correctly. If the compiler can determine that its
address is never taken, it can just store it in a register and
not bother allocating memory. It can even eliminate the object
altogether if it can prove that the program still behaves correctly
without it.
--
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 | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-01-30 15:07 +0100 |
| Message-ID | <q2sb32$kf6$1@gioia.aioe.org> |
| In reply to | #140392 |
On 1/29/2019 11:47 PM, Andrey Tarasevich wrote: > On 1/29/2019 11:30 AM, David Brown wrote: >> >> Why would you want i to keep its value? If you choose to write >> spaghetti code and jump around like this, the compiler is free to do >> whatever it likes with the value of "i" the second time around >> (including keeping the value). > > The question is "why?". The code "jumps around" well within the lifetime > of the object in question. Why is the object not guaranteed to keep its > value at that specific spot of its lifetime? What is the reason this > potential possibility for loss of value was introduced in C99? It wasn't > there in C89/90 (unless it was a defect, of course). The problem is that in your code, when execution jumps back to again:, the variable 'i' is not referable to, so from a purely abstract point of view you cannot say that it should "keep its value" since such value is not accessible. Obviously if you think in terms of real (not abstract) implementation, this does not make sense: as long as 'i' is allocated a slot on the stack, then its value is there, but the standard works in terms of abstract machine, and it is right to do so, IMHO. > >> If you want to keep it to a particular value, move the definition >> above the label - then you are telling the compiler what you want. > > This is not a question about coding style. Yet, if you want 'i' to hold a value for the entire scope of the block, then you should declare it at the top of the block. This is not a matter of style. It is a matter of coding what you mean. > >> In code like this, "i" may not be given a memory address by an >> optimising compiler - it could be in a register, or ignored altogether. > > I don't see how it makes any difference. Yes, it could be in a register. > And? Actually in this case 'i' must be given a memory address, since such address is taken at point 3. But this is not the point. > >> The wording of the standard here has two benefits. One is that it >> lets the compiler generate better object code for sensible source code. > > I don't see how. I don't see the benefits David points out either, but I see that /in theory/ the memory slot used by 'i' might be used by the compiler for something else before the declaration of 'i'. I don't see (and I don't really mind) how an implementation could result in this behavior, but in abstract it is possible, so the standard should and does allow for it. > >> The other is that it lets compilers do better static error checking - >> it means compilers can warn about more situations where you are doing >> something questionable. Both of these, of course, depend on the tool, >> the options, and the code. > > Unlikely. The situation in question relies critically on *indirect* > access, since object name is not available above its point of > declaration. You get it here: 'i' is not available, so, in principle, it does not exist in terms of "observable behavior" And once we start talking about indirect access... well, > no, it doesn't "let compilers do better static error checking". There's > simply no fundamental difference between jumping to a point before > object declaration and, say, jumping to another function. >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-30 06:42 -0800 |
| Message-ID | <0f423fa0-5bc5-43d4-a827-6588c777111a@googlegroups.com> |
| In reply to | #140409 |
On Wednesday, January 30, 2019 at 9:07:41 AM UTC-5, Manfred wrote:
> On 1/29/2019 11:47 PM, Andrey Tarasevich wrote:
> > On 1/29/2019 11:30 AM, David Brown wrote:
> >>
> >> Why would you want i to keep its value? If you choose to write
> >> spaghetti code and jump around like this, the compiler is free to do
> >> whatever it likes with the value of "i" the second time around
> >> (including keeping the value).
> >
> > The question is "why?". The code "jumps around" well within the lifetime
> > of the object in question. Why is the object not guaranteed to keep its
> > value at that specific spot of its lifetime? What is the reason this
> > potential possibility for loss of value was introduced in C99? It wasn't
> > there in C89/90 (unless it was a defect, of course).
>
> The problem is that in your code, when execution jumps back to again:,
> the variable 'i' is not referable to, so from a purely abstract point of
The term you're looking for is "out of scope".
> view you cannot say that it should "keep its value" since such value is
> not accessible.
In every other case I can think of, if you an object has been given a
value, and there is a pointer value that points to that object, and that
object's name is currently not in scope, the pointer can still be used
to refer to that object, to retrieve that object's last-stored value,
and to store a new value in that object. Situations where this can occur
include a subroutine, or an inner scope in which the outer-scope name
has been hidden. Why does the object "keep its value" in those other
situations, but not in this one?
#include <stdio.h>
static int *pi=NULL;
static int geti(void)
{
if(pi)
// pi points to an object whose value has been set
// but whose name is not in scope.
return *pi;
return 0;
}
int main(void)
{
print: if(pi)
// pi points to an object whose value has been set
// but whose name is not in scope.
printf("%d\n", *pi;
int i=5;
pi = &i;
printf("%d\n", geti());
{
int i=20;
// pi points to an object whose value has been set
// but whose name is not in scope.
(*pi)--;
printf("%d\n", i);
}
if(i)
goto print;
return 0;
}
Why is there a rule that makes the second use of *pi, and only that use,
have an indeterminate value?
> >> If you want to keep it to a particular value, move the definition
> >> above the label - then you are telling the compiler what you want.
> >
> > This is not a question about coding style.
>
> Yet, if you want 'i' to hold a value for the entire scope of the block,
> then you should declare it at the top of the block. This is not a matter
> of style. It is a matter of coding what you mean.
If the rule had not been written that way, then such code would mean
exactly what he expected it to mean (and what I thought it meant). You
can't use the rule to justify the rule.
...
> > Unlikely. The situation in question relies critically on *indirect*
> > access, since object name is not available above its point of
> > declaration.
> You get it here: 'i' is not available, so, in principle, it does not
> exist in terms of "observable behavior"
As pointed out above, in other cases where 'i' is not in scope, it
continues to exist in terms of observable behavior. Why should this case
be treated differently?
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-01-30 17:12 +0100 |
| Message-ID | <q2sid0$1tku$1@gioia.aioe.org> |
| In reply to | #140410 |
On 1/30/2019 3:42 PM, James Kuyper wrote:
> On Wednesday, January 30, 2019 at 9:07:41 AM UTC-5, Manfred wrote:
>> On 1/29/2019 11:47 PM, Andrey Tarasevich wrote:
>>> On 1/29/2019 11:30 AM, David Brown wrote:
>>>>
>>>> Why would you want i to keep its value? If you choose to write
>>>> spaghetti code and jump around like this, the compiler is free to do
>>>> whatever it likes with the value of "i" the second time around
>>>> (including keeping the value).
>>>
>>> The question is "why?". The code "jumps around" well within the lifetime
>>> of the object in question. Why is the object not guaranteed to keep its
>>> value at that specific spot of its lifetime? What is the reason this
>>> potential possibility for loss of value was introduced in C99? It wasn't
>>> there in C89/90 (unless it was a defect, of course).
>>
>> The problem is that in your code, when execution jumps back to again:,
>> the variable 'i' is not referable to, so from a purely abstract point of
>
> The term you're looking for is "out of scope".
>
>> view you cannot say that it should "keep its value" since such value is
>> not accessible.
>
> In every other case I can think of, if you an object has been given a
> value, and there is a pointer value that points to that object, and that
> object's name is currently not in scope, the pointer can still be used
> to refer to that object, to retrieve that object's last-stored value,
> and to store a new value in that object. Situations where this can occur
> include a subroutine, or an inner scope in which the outer-scope name
> has been hidden. Why does the object "keep its value" in those other
> situations, but not in this one?
You are right, my rationale above is less rigorous than I thought, as it
is written.
In the case of subroutine or nested scope, the object is supposed to
keep its value, since the point of declaration precedes the subroutine
call or the nested scope, i.e. the point of declaration precedes the
lifetime span.
In this case there is no question about what happens to 'i' during its
lifetime.
The case at hand the point of declaration is in the middle of the
lifetime span, so the question arises to what happens to 'i' when its
declaration is encountered in the middle of its lifetime - which, by a
naive point of view, is weird BTW.
The example I had in mind is different and derived directly from the OP,
so I will replace yours with mine :)
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> int i; // <-- 2
{
int j;
// do something with j
}
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> }
In a naive stack implementation for this, j could share the same slot as
i, which would make the value of i indeterminate before point 3 is reached.
>
> #include <stdio.h>
> static int *pi=NULL;
>
> static int geti(void)
> {
> if(pi)
> // pi points to an object whose value has been set
> // but whose name is not in scope.
> return *pi;
> return 0;
> }
>
> int main(void)
> {
> print: if(pi)
> // pi points to an object whose value has been set
> // but whose name is not in scope.
> printf("%d\n", *pi;
> int i=5;
> pi = &i;
> printf("%d\n", geti());
> {
> int i=20;
> // pi points to an object whose value has been set
> // but whose name is not in scope.
> (*pi)--;
> printf("%d\n", i);
> }
> if(i)
> goto print;
> return 0;
> }
>
> Why is there a rule that makes the second use of *pi, and only that use,
> have an indeterminate value?
This example is different from the OP, int i=5; is a declaration /with/
initialization.
>
>>>> If you want to keep it to a particular value, move the definition
>>>> above the label - then you are telling the compiler what you want.
>>>
>>> This is not a question about coding style.
>>
>> Yet, if you want 'i' to hold a value for the entire scope of the block,
>> then you should declare it at the top of the block. This is not a matter
>> of style. It is a matter of coding what you mean.
>
> If the rule had not been written that way, then such code would mean
> exactly what he expected it to mean (and what I thought it meant). You
> can't use the rule to justify the rule.
Well, the rule... rules ;)
More seriously, I think the committee has addressed the issue as I put
it above: a declaration in the middle of a lifetime.
This issue was not present in earlier versions of the standard, because,
as it has been pointed out, in C98/C90 declarations had to precede any
statements.
So, they had to make a choice. Personally, I find that choice sensible.
I find your second use of *pi convoluted to follow, and, on the other
hand, there is a simple and more clear syntactical solution to get what
you "thought it meant": move the declaration of 'i' ahead of the label.
In a way, this is an extension of the existing concept for automatic
variables:
int i;
// <-- here i is indeterminate
i = 42; // <-- value of i is determinate from here and onward.
>
> ...
>>> Unlikely. The situation in question relies critically on *indirect*
>>> access, since object name is not available above its point of
>>> declaration.
>> You get it here: 'i' is not available, so, in principle, it does not
>> exist in terms of "observable behavior"
>
> As pointed out above, in other cases where 'i' is not in scope, it
> continues to exist in terms of observable behavior. Why should this case
> be treated differently?
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-30 14:42 +0000 |
| Message-ID | <878sz2ryv9.fsf@bsb.me.uk> |
| In reply to | #140409 |
Manfred <noname@add.invalid> writes: > On 1/29/2019 11:47 PM, Andrey Tarasevich wrote: >> On 1/29/2019 11:30 AM, David Brown wrote: >>> >>> Why would you want i to keep its value? If you choose to write >>> spaghetti code and jump around like this, the compiler is free to do >>> whatever it likes with the value of "i" the second time around >>> (including keeping the value). >> >> The question is "why?". The code "jumps around" well within the >> lifetime of the object in question. Why is the object not guaranteed >> to keep its value at that specific spot of its lifetime? What is the >> reason this potential possibility for loss of value was introduced in >> C99? It wasn't there in C89/90 (unless it was a defect, of course). > > The problem is that in your code, when execution jumps back to again:, > the variable 'i' is not referable to, so from a purely abstract point > of view you cannot say that it should "keep its value" since such > value is not accessible. Talking about variables clouds the issue, because for most people the term refers to a named object and in C values are associated with objects not with names. Thus talking about a "variable's value" mixes up the scope (of the name) and the lifetime (of the object). Jumping to before a non-VLA declaration takes you to a place where the name is not in scope but the object still exists. The object's value is therefore available, if you can get at it. It's possible the everyone here gets all this and there is no disagreement about the facts, but from the way it's put is not always clear that everyone /is/ on the same page. <snip> > Yet, if you want 'i' to hold a value for the entire scope of the > block, then you should declare it at the top of the block. This is not > a matter of style. It is a matter of coding what you mean. Here is a case in point. 'i' does not hold a value. The value is in some object and it (the value) will be available thought the lifetime of the object, even in places where the object's declared name 'i' is not in scope. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-30 11:19 -0800 |
| Message-ID | <q2stcj$ohc$1@dont-email.me> |
| In reply to | #140409 |
On 1/30/2019 6:07 AM, Manfred wrote: > > The problem is that in your code, when execution jumps back to again:, > the variable 'i' is not referable to, so from a purely abstract point of > view you cannot say that it should "keep its value" since such value is > not accessible. That's completely misguided and incorrect reasoning. An *identifier* that identifies an object, and the *object itself* are two completely independent entities in C. Just because you have no access to an identifier, does not even remotely mean that the object "is not referable" and its value "is not accessible". This is even ridiculous to comment on. > Obviously if you think in terms of real (not abstract) implementation, > this does not make sense: as long as 'i' is allocated a slot on the > stack, then its value is there, but the standard works in terms of > abstract machine, and it is right to do so, IMHO. No, there's no need to abandon abstract implementation and switch to "real implementations". Abstract concepts of object lifetime in C language are perfectly sufficient to demonstrate that the code is valid and the value is accessible. "Real implementations" just implement these abstract requirements. The fact that I can access the value of `i` through a pointer `p` above the declaration of `i` is not a parasitic side-effect of "real implementation", as you seem to incorrectly believe. It is a hard guarantee made by *abstract* language specification. >> >>> If you want to keep it to a particular value, move the definition >>> above the label - then you are telling the compiler what you want. >> >> This is not a question about coding style. > > Yet, if you want 'i' to hold a value for the entire scope of the block, > then you should declare it at the top of the block. This is not a matter > of style. It is a matter of coding what you mean. No, I shouldn't. This is a "language-lawyer" kind of question. It is specifically about the code I presented. Irrelevant chaff about "spaghetti code", "bad style" and "coding what I mean" is not appropriate and not welcome in this topic. >> I don't see how it makes any difference. Yes, it could be in a >> register. And? > > Actually in this case 'i' must be given a memory address, since such > address is taken at point 3. But this is not the point. You seem to be confusing register optimizations with `register` storage class. Nobody said anything about declaring `i` with `register` storage class. Just because `i` needs a location in memory (it still can be optimized out, but let's assume it does need it), it still does not block register optimizations for `i`. It simply means that the compiler will have to perform a register spill when a register spill is required. >> >> Unlikely. The situation in question relies critically on *indirect* >> access, since object name is not available above its point of >> declaration. > You get it here: 'i' is not available, so, in principle, it does not > exist in terms of "observable behavior" No, your "does not exist" here makes no sense whatsoever. It is an insult to basic knowledge of C object model. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-29 11:57 -0800 |
| Message-ID | <ln5zu7xmmn.fsf@kst-u.example.com> |
| In reply to | #140381 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 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*?)
Nothing has to be physically reset. An indeterminate value is
consistent with leaving the value as it was previously, and
implementations are free to do that (and most do just because it's
easier).
> Consider the following code sample. According to 6.2.4 the lifetime of a
> non-VLA automatic objects in C is the full block that contains its
> declaration. Passing control *within the block* to a point before the
> declaration has no effect on the object
>
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> int i; // <-- 2
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> }
>
> In the above code, once the `printf` at point 1 is reached, it is
> supposed to output `42` - the value variable `i` acquired at point `3`.
>
> However, if we uncomment the `printf` at point 4 it will attempt to
> output an *indeterminate* value, since passing over point 2 the second
> time around "resets" the value of `i` to something indeterminate.
>
> Why? Why can't we just have `i` keep its perfectly determinate value of
> `42` in this case? Is there a clear rationale behind this behavior? Or
> is this just an "unfortunate" side-effect of a wording that is intended
> to simplify some other part of the spec?
Here's another example:
for (int i = 0; i < WHATEVER; i ++) {
{
int indeterminate;
}
{
int determinate = 42;
}
}
The objects `indeterminate` and `determinate` are likely to be stored in
the same location. You wouldn't expect `indeterminate` to retain its
previously stored value on the second iteration. The standard's wording
covers cases like this.
Now the standard *could* have specified different behavior if control
reaches the declaration of an uninitialized object without reaching the
end of the object's life time. But it would have been difficult to get
all the details right, and it would be useful only for very obscure
code, most likely involving backward gotos.
--
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 | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 14:32 -0800 |
| Message-ID | <q2qka5$o98$1@dont-email.me> |
| In reply to | #140384 |
On 1/29/2019 11:57 AM, Keith Thompson wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> 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*?)
>
> Nothing has to be physically reset. An indeterminate value is
> consistent with leaving the value as it was previously, and
> implementations are free to do that (and most do just because it's
> easier).
It is not about whether it *has* to be reset. It is about why it *can*
be reset.
This wording is new in C99 - it wasn't there in C89/90. In C89/90 I
would've expected `i` to retain its value - there's no reason to think
otherwise. However, C99 changed it.
If this a fix for a defect in C89/90, what is that defect? Otherwise, if
this is a "new feature", what is its purpose?
>
> Here's another example:
>
> for (int i = 0; i < WHATEVER; i ++) {
> {
> int indeterminate;
> }
> {
> int determinate = 42;
> }
> }
>
> The objects `indeterminate` and `determinate` are likely to be stored in
> the same location. You wouldn't expect `indeterminate` to retain its
> previously stored value on the second iteration. The standard's wording
> covers cases like this.
I don't see the relevance. In this case the block with `indeterminate`
is entered and exited at every iteration. And lifetime of
`indeterminate` begins and ends at every iteration. I see no reason to
place any expectations on the value of `indeterminate`.
> Now the standard *could* have specified different behavior if control
> reaches the declaration of an uninitialized object without reaching the
> end of the object's life time. But it would have been difficult to get
> all the details right, and it would be useful only for very obscure
> code, most likely involving backward gotos.
True, but it appears to me that the passage in question was added to
deal specifically with that situation: backward gotos. So, someone took
the time and made the effort after all. Why?
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-29 16:24 -0800 |
| Message-ID | <lnwomnvvq4.fsf@kst-u.example.com> |
| In reply to | #140390 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 1/29/2019 11:57 AM, Keith Thompson wrote:
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>> 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*?)
>>
>> Nothing has to be physically reset. An indeterminate value is
>> consistent with leaving the value as it was previously, and
>> implementations are free to do that (and most do just because it's
>> easier).
>
> It is not about whether it *has* to be reset. It is about why it *can*
> be reset.
>
> This wording is new in C99 - it wasn't there in C89/90. In C89/90 I
> would've expected `i` to retain its value - there's no reason to think
> otherwise. However, C99 changed it.
>
> If this a fix for a defect in C89/90, what is that defect? Otherwise,
> if this is a "new feature", what is its purpose?
[...]
>> Now the standard *could* have specified different behavior if control
>> reaches the declaration of an uninitialized object without reaching the
>> end of the object's life time. But it would have been difficult to get
>> all the details right, and it would be useful only for very obscure
>> code, most likely involving backward gotos.
>
> True, but it appears to me that the passage in question was added to
> deal specifically with that situation: backward gotos. So, someone
> took the time and made the effort after all. Why?
Restoring your example from upthread:
{
int *p = NULL;
again:
if (p != NULL)
printf("%d\n", *p); // <-- 1
int i; // <-- 2
if (p == NULL)
{
i = 42; // <-- 3
p = &i;
goto again;
}
// printf("%d\n", i); // <-- 4
}
C90 says:
An object whose identifier is declared with no linkage and
without the storage-class specitier static has *automatic
storage duration*. Storage is guaranteed to be reserved for a
new instance of such an object on each normal entry into the
block with which it is associated, or on a jump from outside
the block to a labeled statement in the block or in an enclosed
block. If an initialization is specified for the value stored
in the object, it is performed on each normal entry, but not if
the block is entered by a jump to a labeled statement. Storage
for the object is no longer guaranteed to be reserved when
execution of the block ends in any way. (Entering an enclosed
block suspends but does not end execution of the enclosing
block. Calling a function suspends but does not end execution
of the block containing the call.) The value of a pointer that
referred to an object with automatic storage duration that is
no longer guaranteed to be reserved is indeterminate.
C99 says:
For such an object that does not have a variable length array
type, its lifetime extends from entry into the block with which
it is associated until execution of that block ends in any
way. (Entering an enclosed block or calling a function suspends,
but does not end, execution of the current block.) If the block
is entered recursively, a new instance of the object is created
each time. The initial value of the object is indeterminate. If
an initialization is specified for the object, it is performed
each time the declaration is reached in the execution of the
block; otherwise, the value becomes indeterminate each time
the declaration is reached.
I think the main difference is that, given non-contrived code like this:
{
int local;
/* what is the value here? */
}
C90 doesn't explicitly state that the value of local is
indeterminate, but C99 does. By specifying that "the value becomes
indeterminate each time the declaration is reached", C99 covers the
case of, for example, a local object defined inside a loop (where a
new object is created on each iteration), but has the side effect
of allowing the value to become indeterminate if a goto causes
the declaration for the same object to be reached more than once.
It's quite possible this side effect was unintentional.
Note also that your example is not valid in C90, since you have a
declaration folloowing a statement within a block. I'm not sure
you could construct a valid C90 program that would be broken by
the new C99 rule.
(The phrase "don't do that" springs to mind.)
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-29 12:13 -0800 |
| Message-ID | <ln1s4vxlvf.fsf@kst-u.example.com> |
| In reply to | #140381 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>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*?)
>
> Maybe to given the implementation leeway for optimizations,
> maybe to help static code analyzers,
> maybe to making it easier to implement C.
>
>>Consider the following code sample. According to 6.2.4 the lifetime of a
>>non-VLA automatic objects in C is the full block that contains its
>>declaration.
>
> Lifetime is a duration during an execution.
>
> A block is a region in the source code.
>
> They cannot be equal because they are different
> categories of entities.
Yes, the lifetime is the period of execution of the block.
"For such an object that does not have a variable length array type, its
lifetime extends from entry into the block with which it is associated
until execution of that block ends in any way."
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-29 12:20 -0800 |
| Message-ID | <98ab0a2d-bdf2-47fa-8424-0217228c6a8f@googlegroups.com> |
| In reply to | #140381 |
On Tuesday, January 29, 2019 at 1:50:43 PM UTC-5, 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*?)
> Consider the following code sample. According to 6.2.4 the lifetime of a
> non-VLA automatic objects in C is the full block that contains its
> declaration. Passing control *within the block* to a point before the
> declaration has no effect on the object
>
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> int i; // <-- 2
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> }
>
> In the above code, once the `printf` at point 1 is reached, it is
> supposed to output `42` - the value variable `i` acquired at point `3`.
>
> However, if we uncomment the `printf` at point 4 it will attempt to
> output an *indeterminate* value, since passing over point 2 the second
> time around "resets" the value of `i` to something indeterminate.
I believe that the wording "each time the declaration is reached" is
intended to apply only to the first time it is reached during the
lifetime of each instance of the object. I agree that the standard does
not say so, but I can't see any good reason for allowing an object's
value to become indeterminate during it's lifetime. If I'm right about
that, the reason it's worded that way is that they didn't consider the possibility of passing through the declaration twice while the
identifier still identifies the same instance of the object - something
that requires moderately contrived circumstances (such as the above).
> Why? Why can't we just have `i` keep its perfectly determinate value of
> `42` in this case? Is there a clear rationale behind this behavior? Or
> is this just an "unfortunate" side-effect of a wording that is intended
> to simplify some other part of the spec?
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 15:08 -0800 |
| Message-ID | <q2qmdh$6mu$1@dont-email.me> |
| In reply to | #140386 |
On 1/29/2019 2:51 PM, Stefan Ram wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> I believe that the wording "each time the declaration is reached" is >> intended to apply only to the first time it is reached during the >> lifetime of each instance of the object. > > If you read the > > Rationale for International Standard - Programming Languages - C > Revision 5.10, April 2003 > section 6.2.4 Storage durations of objects > > , you can see that the authors clearly thought about wild jumps. > They even provide an example with a loop backward (using "goto") > where the variable "k" takes an "indeterminate value" each time > "int k;" is encountered, even though a value was given to "k" > in the preceding pass of the loop (similar to Andreys example). > > Do they specifically explain why the storage has to take an > indeterminate value, again? No. That Rationale is a good source to check. Thanks for reminding me. Will look there. The matter seems to be related to the long-ongoing debate about the nature of indeterminate values. Is an indeterminate value a consequence of *not storing* any value in an object? Or is it a consequence of actually *storing* some strangely behaving value in it? See DR#260 and DR#451 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_451 So it appears that they are settled on the second concept, however weird it might sound: indeterminate values get into variables by being *stored* in these variables. And that's exactly what supposedly happens to uninitialized variables: there a conceptual action of stuffing an indeterminate value into that variable at the point of its declaration. That is why passing over a declaration of an uninitialized variable triggers that conceptual action again and "damages" the variable value - makes it indeterminate again. Go figure... -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-29 21:38 -0500 |
| Message-ID | <q2r2n0$33o$1@dont-email.me> |
| In reply to | #140386 |
On 1/29/19 17:51, Stefan Ram wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> I believe that the wording "each time the declaration is reached" is >> intended to apply only to the first time it is reached during the >> lifetime of each instance of the object. > > If you read the > > Rationale for International Standard - Programming Languages - C > Revision 5.10, April 2003 > section 6.2.4 Storage durations of objects > > , you can see that the authors clearly thought about wild jumps. > They even provide an example with a loop backward (using "goto") > where the variable "k" takes an "indeterminate value" each time > "int k;" is encountered, even though a value was given to "k" > in the preceding pass of the loop (similar to Andreys example). I didn't have access to the Rationale when I wrote my earlier message. I just checked, and you're right - they made it quite clear that this is intentional. > Do they specifically explain why the storage has to take an > indeterminate value, again? No. Agreed - and I can't see any advantage in it.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 19:01 -0800 |
| Message-ID | <q2r42d$8nn$1@dont-email.me> |
| In reply to | #140386 |
On 1/29/2019 2:51 PM, Stefan Ram wrote: > > , you can see that the authors clearly thought about wild jumps. > They even provide an example with a loop backward (using "goto") > where the variable "k" takes an "indeterminate value" each time > "int k;" is encountered, even though a value was given to "k" > in the preceding pass of the loop (similar to Andreys example). > > Do they specifically explain why the storage has to take an > indeterminate value, again? No. Well, as you said, they just reiterate the same thing that the text of standard says. No rationale is provided as for why the variable should take indeterminate value. Note, BTW, that they explicitly acknowledge the storage/lifetime management approach I described in my original message: "There is a simple rule of thumb: the variable declared is created with an unspecified value when the block is entered, but the initializer is evaluated and the value placed in the variable when the declaration is reached in the normal course of execution." It is still not clear *why* an indeterminate value should be placed into the variable declared without an initializer. Keith Thompson suggested in another message that the situation with local variables in loop bodies was underspecified: it was supposedly not sufficiently clear whether they are destroyed and created repeatedly on each iteration. Was it really underspecified? I thought I saw some dedicated wording in C89/90 that addressed that matter... Also, the wording in the Rationale seems to hint/imply that the behavior in question was introduced in C99 specifically to support mid-block variable declarations. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
Page 1 of 19 [1] 2 3 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web