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 2 of 19 — ← Prev page 1 [2] 3 4 … 19 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-30 11:27 +0000 |
| Message-ID | <MSf4E.867072$Sj4.325343@fx15.am4> |
| In reply to | #140405 |
On 30/01/2019 03:01, Andrey Tarasevich wrote:
> 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.
Look at the rules for VLAs. There, the lifetime starts at the point of
declaration (just as though it started a new implicit block of the kind
I suggested yesterday).
Non-VLAs apparently have a lifetime starting at the start of the block.
The rule for VLAs is presumably to allow for the deallocation needed for
when someone jumps back to just before their declaration.
But what non-VLAs? Their sizes will always be the same, so no need to
dynamically allocate and deallocate them from the stack. The space will
already exist, so it was felt safe to extend their existence back to the
start of this block.
What about their value however? Clearly, before getting to their
declaration/initialisation for the first time, or jumping there from
outside the block (where the same stack space could be shared), the
value will be indeterminate.
Your question appears to be, suppose the value is set, and then you jump
back to that point from within the same block, where the rules suggest
that the value is also indeterminate.
Well, since the the answer is a little uncertain, and what hundreds of
different compilers do is also uncertain, what would /you/ write in the
standard, that the value is perfectly well-defined?
By suggesting that the value /might/ be also indeterminate, people might
avoid writing sloppy code like that.
You made a big deal yesterday about my talking about static block scope
and lifetime together (actually you seemed pretty angry about it).
If all the action takes place in one block, so that the value of 'i' is
needed throughout the block, then what is the advantage is restricting
the visibility? Because you will get things like this:
int i;
{L1:
printf("%d\n",*p); // print value of i at *p
int i=42;
p=&i;
goto L1;
What is someone to make of that comment, since a different 'i' is
visible at that point?
Just put the declaration at the top of the block so this ambiguity
doesn't arise. (Maybe /that/ was the intention of the wording in the
standard as I suggested.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-01-30 04:18 -0800 |
| Message-ID | <c2ac12b4-3cf1-48c6-95cc-f6572b65261f@googlegroups.com> |
| In reply to | #140406 |
On Wednesday, January 30, 2019 at 6:27:49 AM UTC-5, Bart wrote: ... > Look at the rules for VLAs. There, the lifetime starts at the point of > declaration (just as though it started a new implicit block of the kind > I suggested yesterday). True. If a new block were created starting just before the declaration, the object would have a lifetime that started at that point, even if it weren't a VLA. However, this new implicit block is entirely your own creation, and has nothing to do with how the standard describes this situation. No other rules that would apply to such a block apply to this case - only the lifetime start rule - because the only thing the standard actually says about it is that the lifetime starts there. In particular, exiting the block that you've invented does not end the lifetime of objects declared inside that "block", because the "end of lifetime" rule is only talking about real blocks, not your implicit blocks. > Non-VLAs apparently have a lifetime starting at the start of the block. > > The rule for VLAs is presumably to allow for the deallocation needed for > when someone jumps back to just before their declaration. > > But what non-VLAs? Their sizes will always be the same, so no need to > dynamically allocate and deallocate them from the stack. The space will > already exist, so it was felt safe to extend their existence back to the > start of this block. > > What about their value however? Clearly, before getting to their > declaration/initialisation for the first time, or jumping there from > outside the block (where the same stack space could be shared), the > value will be indeterminate. > > Your question appears to be, suppose the value is set, and then you jump > back to that point from within the same block, where the rules suggest > that the value is also indeterminate. > > Well, since the the answer is a little uncertain, There's nothing unclear about the relevant words. I was initially of the belief that they must have been a mistake, but it's clearly intentional, since the particular case Andrey is asking about was directly and explicitly addressed by the Rationale. So how do you reach the conclusion that it's uncertain? > different compilers do is also uncertain, what would /you/ write in the > standard, that the value is perfectly well-defined? Were it up to me, I would write that an object's value is indeterminate from the start of it's lifetime until it is assigned a specific value, either by initialization or assignment, and after that point always retains it's last-set value until the end of its lifetime. I don't see anything problematic about that - are you implying that it would be? The committee, for reasons I don't know about, choose otherwise. > By suggesting that the value /might/ be also indeterminate, people might > avoid writing sloppy code like that. If it weren't for the new clause in C99, I would not have any reason to consider such code sloppy. Overly complicated, yes, but not sloppy.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-30 11:00 -0800 |
| Message-ID | <q2ss8f$hqo$1@dont-email.me> |
| In reply to | #140406 |
On 1/30/2019 3:27 AM, Bart wrote: > > Look at the rules for VLAs. There, the lifetime starts at the point of > declaration (just as though it started a new implicit block of the kind > I suggested yesterday). Yes, an "implicit block" properly describes lifetime properties of VLA in such scenarios. But the question is not about VLA. Everybody acknowledges the fact that VLA are different (they are quite C++-ish/constructor-ish/destructor-ish in their behavior). > Your question appears to be, suppose the value is set, and then you jump > back to that point from within the same block, where the rules suggest > that the value is also indeterminate. Either I misunderstand what you are saying or what you are saying is incorrect. The rules clearly state that if the value is set, it remains set even if we jump back within the block to a point before the declaration (as my illustrated by my example). The only moment where the set value can get "unset" again is when control passes over the point of declaration. *This* is what my question is about. > Well, since the the answer is a little uncertain, and what hundreds of > different compilers do is also uncertain, what would /you/ write in the > standard, that the value is perfectly well-defined? Because in those hundreds of different compilers a previously set value will *naturally* be well-defined. An uninitialized non-VLA variable declaration does not generate any code at all. It is no-op. Everything that had to be allocated was allocated in function prologue. The only way to destroy the well-defined value of such variable is to destroy it *deliberately*. And C compilers do not normally destroy well-defined values just for the sake of destroying them. Granted, the above applies to a "naive" memory model, where variables reside in what we usually call "stack memory". Once we start talking about CPU registers and their management, things start get very different very quickly. And that is too what my question is about: maybe there's a natural register management scenario into which this potential "reset" of variable value fits naturally. > You made a big deal yesterday about my talking about static block scope and lifetime together (actually you seemed pretty angry about it). Not really. I might've been curt (insert Mr. Wolf quote here, even if time is not really a factor), but not angry. > If all the action takes place in one block, so that the value of 'i' is > needed throughout the block, then what is the advantage is restricting > the visibility? Because that's how the language is designed. You have to declare names *before* using them. > Just put the declaration at the top of the block so this ambiguity > doesn't arise. (Maybe /that/ was the intention of the wording in the > standard as I suggested.) This is a "language-lawyer" kind of question, not a question about coding style. And I highly doubt that this part of language specification has coding style as it rationale. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 14:18 -0800 |
| Message-ID | <86bm2zeclk.fsf@mailhub.linuxsc.com> |
| In reply to | #140419 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > On 1/30/2019 3:27 AM, Bart wrote: ... >> Just put the declaration at the top of the block so this ambiguity >> doesn't arise. (Maybe /that/ was the intention of the wording in >> the standard as I suggested.) > > This is a "language-lawyer" kind of question, not a question about > coding style. And I highly doubt that this part of language > specification has coding style as it rationale. A language-lawyer type question is one about parsing the text of the Standard and understanding what it requires. Here there is no question about what is required. Your question is about why whoever made the decision chose the requirement they did. There is no technical necessity for this choice; it is just what they decided. So the question Why is really one of human motivation, which takes it out of the language-lawyer domain, and matters of coding style may very well have played a role (whether they actually did or not) in the discussions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-30 14:34 -0800 |
| Message-ID | <lnftt9wz9d.fsf@kst-u.example.com> |
| In reply to | #140406 |
Bart <bc@freeuk.com> writes:
[...]
> Look at the rules for VLAs. There, the lifetime starts at the point of
> declaration (just as though it started a new implicit block of the kind
> I suggested yesterday).
>
> Non-VLAs apparently have a lifetime starting at the start of the block.
>
> The rule for VLAs is presumably to allow for the deallocation needed for
> when someone jumps back to just before their declaration.
I seriously doubt it. The lifetime of a VLA begins when its
declaration is reached. Before that we don't know how to create it,
because we don't know its size. We don't need to consider contrived
code with gotos to justify the rule. (And there are restrictions
for gotos in the presence of VLAs; you can't jump from outside the
scope of a VLA to within its scope.)
{
int len = rand() % 10 + 10;
int vla[len];
}
The lifetime of len begins on entry to the enclosing block. It's not
initialized until control reaches its declaration. The lifetime of vla
begins when its declaration is reached; that's (probably) the point at
which memory is actually allocated.
(A compiler could generate code that allocates memory earlier or later
than what's described for the abstract machine, as long as the behavior
is still valid.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-30 23:12 +0000 |
| Message-ID | <Mbq4E.450981$3si.40924@fx08.am4> |
| In reply to | #140422 |
On 30/01/2019 22:34, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Look at the rules for VLAs. There, the lifetime starts at the point of
>> declaration (just as though it started a new implicit block of the kind
>> I suggested yesterday).
>>
>> Non-VLAs apparently have a lifetime starting at the start of the block.
>>
>> The rule for VLAs is presumably to allow for the deallocation needed for
>> when someone jumps back to just before their declaration.
>
> I seriously doubt it. The lifetime of a VLA begins when its
> declaration is reached. Before that we don't know how to create it,
> because we don't know its size. We don't need to consider contrived
> code with gotos to justify the rule. (And there are restrictions
> for gotos in the presence of VLAs; you can't jump from outside the
> scope of a VLA to within its scope.)
>
> {
> int len = rand() % 10 + 10;
> int vla[len];
> }
>
> The lifetime of len begins on entry to the enclosing block. It's not
> initialized until control reaches its declaration. The lifetime of vla
> begins when its declaration is reached; that's (probably) the point at
> which memory is actually allocated.
So what happens at the goto in this fragment:
{L1:;
int len = rand() % 10 + 10;
int vla[len];
goto L1;
}
Ignoring optimisations which would eliminate half the code, what happens
to the current allocation of vla?
I'm saying it will be deallocated, so it's contents will not only be
lost at L1, but there wouldn't be any place to put any contents.
(Looking at output of gcc, this is exactly what happens.)
I'm trying to see what you object to in my statement.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-01-31 15:44 +1300 |
| Message-ID | <gbf5p7Ffhg9U1@mid.individual.net> |
| In reply to | #140424 |
On 31/01/2019 12:12, Bart wrote:
> On 30/01/2019 22:34, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Look at the rules for VLAs. There, the lifetime starts at the point of
>>> declaration (just as though it started a new implicit block of the kind
>>> I suggested yesterday).
>>>
>>> Non-VLAs apparently have a lifetime starting at the start of the block.
>>>
>>> The rule for VLAs is presumably to allow for the deallocation needed for
>>> when someone jumps back to just before their declaration.
>>
>> I seriously doubt it. The lifetime of a VLA begins when its
>> declaration is reached. Before that we don't know how to create it,
>> because we don't know its size. We don't need to consider contrived
>> code with gotos to justify the rule. (And there are restrictions
>> for gotos in the presence of VLAs; you can't jump from outside the
>> scope of a VLA to within its scope.)
>>
>> {
>> int len = rand() % 10 + 10;
>> int vla[len];
>> }
>>
>> The lifetime of len begins on entry to the enclosing block. It's not
>> initialized until control reaches its declaration. The lifetime of vla
>> begins when its declaration is reached; that's (probably) the point at
>> which memory is actually allocated.
>
> So what happens at the goto in this fragment:
>
> {L1:;
> int len = rand() % 10 + 10;
> int vla[len];
> goto L1;
> }
You get fired?
:)
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-30 19:00 -0800 |
| Message-ID | <lnbm3xwmz2.fsf@kst-u.example.com> |
| In reply to | #140424 |
Bart <bc@freeuk.com> writes:
> On 30/01/2019 22:34, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Look at the rules for VLAs. There, the lifetime starts at the point of
>>> declaration (just as though it started a new implicit block of the kind
>>> I suggested yesterday).
>>>
>>> Non-VLAs apparently have a lifetime starting at the start of the block.
>>>
>>> The rule for VLAs is presumably to allow for the deallocation needed for
>>> when someone jumps back to just before their declaration.
>>
>> I seriously doubt it. The lifetime of a VLA begins when its
>> declaration is reached. Before that we don't know how to create it,
>> because we don't know its size. We don't need to consider contrived
>> code with gotos to justify the rule. (And there are restrictions
>> for gotos in the presence of VLAs; you can't jump from outside the
>> scope of a VLA to within its scope.)
>>
>> {
>> int len = rand() % 10 + 10;
>> int vla[len];
>> }
>>
>> The lifetime of len begins on entry to the enclosing block. It's not
>> initialized until control reaches its declaration. The lifetime of vla
>> begins when its declaration is reached; that's (probably) the point at
>> which memory is actually allocated.
>
> So what happens at the goto in this fragment:
>
> {L1:;
> int len = rand() % 10 + 10;
> int vla[len];
> goto L1;
> }
N1570 6.2.4p7:
For such an object that does have a variable length array type,
its lifetime extends from the declaration of the object until
execution of the program leaves the scope of the declaration.
(From the context, the phrase "such an object" refers to an object with
automatic storage duration.)
So when control goes from the goto statement to L1, it leaves the scope
of vla, and therefore vla's lifetime ends.
> Ignoring optimisations which would eliminate half the code, what happens
> to the current allocation of vla?
It's deallocated. By contrast, len is not deallocated; it's still
within its lifetime, and could be accessed via a pointer.
> I'm saying it will be deallocated, so it's contents will not only be
> lost at L1, but there wouldn't be any place to put any contents.
> (Looking at output of gcc, this is exactly what happens.)
Right.
> I'm trying to see what you object to in my statement.
The point I disagree with is your presumption that the lifetime rule
for VLAs was motivated by this kind of goto. The rules do apply
consistently in the presence of a goto statement, but I believe
they were designed that way mainly because they're necessary to
make VLAs work even in ordinary gotoless code.
Without the special rule, the lifetime of vla would begin on entry
to the enclosing block, which means its lifetime would begin before
it's possible to determine its size.
No doubt the authors of the standard had the goto case in mind
and made sure the rule would work in the presence of gotos (it's
mentioned in the C99 Rationale), but I doubt that it was the
primary motivation.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-01-31 14:32 +0000 |
| Message-ID | <MFD4E.246857$0z4.73585@fx03.iad> |
| In reply to | #140426 |
Keith Thompson <kst-u@mib.org> writes: >Bart <bc@freeuk.com> writes: >> On 30/01/2019 22:34, Keith Thompson wrote: > >> Ignoring optimisations which would eliminate half the code, what happens >> to the current allocation of vla? > >It's deallocated. By contrast, len is not deallocated; it's still >within its lifetime, and could be accessed via a pointer. > Although to be fair, in implementations where the VLA is allocated on the stack by adjusting the stack pointer, it won't be deallocated until the function returns. It may be overlayed with a subsequent VLA (or block-local declarations).
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-31 09:44 -0800 |
| Message-ID | <q2vc5u$bas$1@dont-email.me> |
| In reply to | #140433 |
On 1/31/2019 6:32 AM, Scott Lurndal wrote: > Keith Thompson <kst-u@mib.org> writes: >> Bart <bc@freeuk.com> writes: >>> On 30/01/2019 22:34, Keith Thompson wrote: > >> >>> Ignoring optimisations which would eliminate half the code, what happens >>> to the current allocation of vla? >> >> It's deallocated. By contrast, len is not deallocated; it's still >> within its lifetime, and could be accessed via a pointer. >> > > Although to be fair, in implementations where the VLA is allocated > on the stack by adjusting the stack pointer, it won't be deallocated > until the function returns. It may be overlayed with a subsequent > VLA (or block-local declarations). Um... It is not clear what you mean exactly. I don't see any scenario in C when there would be any reason to wait "until the function returns". Why? In all typical implementations each VLA is represented by a local pointer, which points to a memory block "allocated on the stack by adjusting the stack pointer" (exactly as you said). But there will never bee any reason to wait "until the function returns" to deallocate such VLA. All VLA allocation/deallocation scenarios in C are *deliberately designed* to adhere to exact LIFO schedule, meaning that it is always possible to deallocate a VLA *immediately*, when the standard says it has to be deallocated. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-31 23:15 +0100 |
| Message-ID | <q2vs1b$u46$1@dont-email.me> |
| In reply to | #140437 |
On 31/01/2019 18:44, Andrey Tarasevich wrote: > On 1/31/2019 6:32 AM, Scott Lurndal wrote: >> Keith Thompson <kst-u@mib.org> writes: >>> Bart <bc@freeuk.com> writes: >>>> On 30/01/2019 22:34, Keith Thompson wrote: >> >>> >>>> Ignoring optimisations which would eliminate half the code, what >>>> happens >>>> to the current allocation of vla? >>> >>> It's deallocated. By contrast, len is not deallocated; it's still >>> within its lifetime, and could be accessed via a pointer. >>> >> >> Although to be fair, in implementations where the VLA is allocated >> on the stack by adjusting the stack pointer, it won't be deallocated >> until the function returns. It may be overlayed with a subsequent >> VLA (or block-local declarations). > > Um... It is not clear what you mean exactly. I don't see any scenario in > C when there would be any reason to wait "until the function returns". Why? > > In all typical implementations each VLA is represented by a local > pointer, which points to a memory block "allocated on the stack by > adjusting the stack pointer" (exactly as you said). But there will never > bee any reason to wait "until the function returns" to deallocate such > VLA. All VLA allocation/deallocation scenarios in C are *deliberately > designed* to adhere to exact LIFO schedule, meaning that it is always > possible to deallocate a VLA *immediately*, when the standard says it > has to be deallocated. > As you say, VLA's can always be deallocated on exit from their block, by a simple stack pointer adjustment (assuming a typical cpu). However, that certainly does not mean that they /should/ be deallocated this way, or that they /will/ be deallocated this way. In most common cases, there is nothing of significance to be gained by deallocating immediately - it makes sense to do a single stack deallocation at the end of the function. This is a simple and common optimisation, much the same as most functions allocate and deallocate the stack space for non-VLA variables all in one lump rather than for each nested block.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-30 15:11 -0800 |
| Message-ID | <q2tauj$fco$1@dont-email.me> |
| In reply to | #140406 |
On 1/30/2019 3:27 AM, Bart wrote: > ... > The rule for VLAs is presumably to allow for the deallocation needed for > when someone jumps back to just before their declaration. > ... I'd say that it is the other way around: the "unconventional" (for C) requirement to *deallocate* VLA when someone jumps back to before their declaration within the same block is there to simplify the specification for what happens when the control passes over VLA declaration again. There are at least three approaches here: 1. Force VLA to conform to "classic" automatic lifetime rules. I.e. VLA is not deallocated when someone jumps back to a point within the same block before the VLA declaration. When control passes the second (third, etc.) time over the declaration of an already allocated VLA nothing happens. The VLA does not get reallocated. Within this approach an already-allocated VLA would "ignore" any changes in the run-time values that defined its size during the first pass. Even though such jumps and passes are rarely encountered in actual code, the behavior would probably strike many people as weird. 2. Force VLA to conform to "classic" automatic lifetime rules, but with reallocation. VLA is not deallocated when someone jumps back to a point within the same block before the VLA declaration. When control passes the second (third, etc.) time over the declaration of an already allocated VLA it gets deallocated and reallocated again. Within this approach a VLA always honors any changes in run-time values that define its size. However, this might be [prohibitively] difficult to implement since VLA are typically allocated on the stack, which is managed in LIFO fashion. Only the last VLA on the top of the stack is easy to reallocate. 3. Develop fundamentally different dedicated rules for VLA lifetime. VLA is unconditionally deallocated when someone jumps back to a point before VLA declaration. In that case every time control passes over the declaration of a VLA it gets unconditionally allocated from scratch. Within this approach a VLA always honors any changes in run-time values that define its size. The approach also agrees well with LIFO memory management, since backward jumps will always destroy top VLA(s) in the stack. I'd say that for a run-time-allocated entity the third approach results in a more "natural" and easy to implement behavior. And that is why it was chosen. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 14:12 -0800 |
| Message-ID | <q2qj46$gfi$1@dont-email.me> |
| In reply to | #140381 |
On 1/29/2019 11:53 AM, Stefan Ram wrote: > >> 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. Let's just say that I used the term "block" in a *temporal* sense, not in a spatial sense. It was just another (shorter) way of saying "... its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way..." -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-29 22:46 +0000 |
| Message-ID | <jJ44E.331975$VH1.22129@fx40.am4> |
| In reply to | #140381 |
On 29/01/2019 18: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?
You're relying on i to have a wider scope than you've actually given it.
I understood that variables declared part-way through a block
effectively start a new block at that point. That means your code is
equivalent to:
{
int *p = NULL;
again:
if (p != NULL)
printf("%d\n", *p); // <-- 1
{ //implicit block start
int i; // <-- 2
if (p == NULL)
{
i = 42; // <-- 3
p = &i;
goto again;
}
// printf("%d\n", i); // <-- 4
} //implicit block end
}
Here it can be seen that you're jumping out of the block in which i is
declared.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 14:57 -0800 |
| Message-ID | <q2qlo5$t2$1@dont-email.me> |
| In reply to | #140391 |
On 1/29/2019 2:46 PM, Bart wrote:
> On 29/01/2019 18: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?
>
> You're relying on i to have a wider scope than you've actually given it.
> I understood that variables declared part-way through a block
> effectively start a new block at that point. That means your code is
> equivalent to:
>
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> { //implicit block start
> int i; // <-- 2
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> } //implicit block end
> }
>
> Here it can be seen that you're jumping out of the block in which i is
> declared.
No, absolutely not. Firstly, *scope* is a compile-time property of a
*name*. It is relevant to *name lookup* only. It has nothing to do with
such issues as storage duration, lifetime or value preservation.
Mistaking scope for lifetime/storage duration is a rather widespread
misconception. And you are making this beaten-to-death mistake right now.
Secondly, no, we do *not* start a new "block" at the point of
declaration. That's completely incorrect. In C when it comes to matters
of object lifetime, a mid-block object declaration is 100% equivalent to
a beginning-of-the block declaration. The only difference is the
compile-time matter of the point after which the *name* becomes
visible/available (*scope*, actually). This is very critical to understand.
My original code is perfectly valid and the value printed at point 1 is
guaranteed by the language to be `42`. That is not subject to dispute.
In your "interpretation" that would be undefined. That's incorrect.
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-29 16:27 -0800 |
| Message-ID | <lnsgxbvvkn.fsf@kst-u.example.com> |
| In reply to | #140391 |
Bart <bc@freeuk.com> writes:
> On 29/01/2019 18: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?
>
> You're relying on i to have a wider scope than you've actually given it.
> I understood that variables declared part-way through a block
> effectively start a new block at that point.
I don't know how you got that impression. This is about lifetime (the
period of execution time during which an object exists), not scope (the
region of program text in which a name is visible).
The lifetime of a non-VLA local object begins when execution enters the
block in which it's defined, not at the point of its declaration.
> That means your code is
> equivalent to:
>
> {
> int *p = NULL;
>
> again:
> if (p != NULL)
> printf("%d\n", *p); // <-- 1
>
> { //implicit block start
> int i; // <-- 2
>
> if (p == NULL)
> {
> i = 42; // <-- 3
> p = &i;
> goto again;
> }
>
> // printf("%d\n", i); // <-- 4
> } //implicit block end
> }
>
> Here it can be seen that you're jumping out of the block in which i is
> declared.
No, you're jumping out of the *scope* of i, so it's not visible, but the
object i continues to exist.
--
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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-01-29 16:48 -0700 |
| Message-ID | <1b36pb58k8.fsf@pfeifferfamily.net> |
| In reply to | #140381 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> 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*?)
<example snipped>
It allows the compiler to only allocate space for the largest number of
variables live at the same time. Here's an example:
int func(void)
{
int i;
i = 1;
{
int j;
j = 2;
}
{
int k;
k = 3;
}
{
int j;
// j's value is indeterminate
}
}
This requires space for two variables on the stack (i is there through
the whole function; the second space is used for both j and k). If we
were to require j retain its value through the second inner block, it
would need space separate from k's.
It would also be weird -- when you've declared j within an inner block,
you've told the compiler it doesn't need to exist any more after the
block has exited. By contrast we told it that i hangs around through
the whole function, so it does. If that's what you want, it's what you
should tell the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-01-29 16:13 -0800 |
| Message-ID | <q2qq7h$ot8$1@dont-email.me> |
| In reply to | #140398 |
On 1/29/2019 3:48 PM, Joe Pfeiffer wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> ...
> It allows the compiler to only allocate space for the largest number of
> variables live at the same time. Here's an example:
>
> int func(void)
> {
> int i;
> i = 1;
>
> {
> int j;
> j = 2;
> }
>
> {
> int k;
> k = 3;
> }
>
> {
> int j;
> // j's value is indeterminate
> }
> }
>
> This requires space for two variables on the stack (i is there through
> the whole function; the second space is used for both j and k). If we
> were to require j retain its value through the second inner block, it
> would need space separate from k's.
I don't see how all this applies to my question and my example. The key
point of my question is that we *never leave* the block that declares
the variable in question. I believe I was perfectly clear about that.
Nobody expects `j` to retain its value in your example. Your example is
not even remotely the same as mine. You have two different unrelated
`j`s with limited lifetime.
The question is, once again, about passing over the same variable
declaration again and again *without leaving the temporal confines of
its lifetime*. This is only achievable with `goto`.
And no, this has nothing to do with "allowing the compiler to only
allocate space for the largest number of variables live at the same time".
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-01-30 16:57 +0000 |
| Message-ID | <5c51d4fb.236542547@news.xmission.com> |
| In reply to | #140381 |
On Tue, 29 Jan 2019 10:50:31 -0800, Andrey Tarasevich
<andreytarasevich@hotmail.com> wrote:
> {
> 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
> }
Others have weighed in with thoughful observations, but I would
briefly opine twice on this code snippet.
First, we have Structured Programming, and code like this is why.
Second - and I'm probably in the vast minority here - I think that
mixing declarations with code is sloppy and lazy, and leads to puzzles
just like this. Move i's declaration up next to p's, your puzzle goes
away.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-01-30 18:04 +0100 |
| Message-ID | <q2slfo$ced$1@gioia.aioe.org> |
| In reply to | #140413 |
On 1/30/2019 5:57 PM, Scott wrote:
> On Tue, 29 Jan 2019 10:50:31 -0800, Andrey Tarasevich
> <andreytarasevich@hotmail.com> wrote:
>
>> {
>> 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
>> }
>
> Others have weighed in with thoughful observations, but I would
> briefly opine twice on this code snippet.
>
> First, we have Structured Programming, and code like this is why.
>
> Second - and I'm probably in the vast minority here - I think that
> mixing declarations with code is sloppy and lazy, and leads to puzzles
> just like this. Move i's declaration up next to p's, your puzzle goes
> away.
>
I'm not in your minority - I think that if you think about using goto,
think harder until you don't use it any more (at least not this way).
[toc] | [prev] | [next] | [standalone]
Page 2 of 19 — ← Prev page 1 [2] 3 4 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web