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 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 16:51 +0000 |
| Message-ID | <WbX9E.446003$9F1.386416@fx39.am4> |
| In reply to | #141113 |
On 16/02/2019 16:33, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Declaration at first point of use has a problem when a variable is
>> first assigned to, inside an expression. This is a very simple
>> instance of that:
>>
>> a = b = f();
>>
>> If this is the first use of a, then your rule would require this:
>>
>> int a = b = f();
>>
>> But what if this is also the first use of b? (#16 in my list)
>>
>> The ability to assign within an expression causes a conflict.
>>
>> A gcc extension allows statements within expressions:
>>
>> int a=({int b=f();b;});
>>
>> But the result is anything but clear, and also this imposes a
>> restriction on the scope of b.
>
> Apart from not being C, it's not the same at all (as you imply). In C
> you would simply write:
>
> int a = f(), b = a;
This point is about first assigning to a variable when that assignment
is inside an expression. That is, when the result of that assignment is
needed rather being standalone statement/expression.
In my example, that would be the assignment to b:
a = (b = f());
You can imagine that assignment being in a more elaborate context, for
example:
while (b = f()) { do something with b... }
So that /in general/ you can easily convert such first-time assignments
to a combined declaration/assignment.
My example was perhaps a poor one.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 16:52 +0000 |
| Message-ID | <sdX9E.446004$9F1.65525@fx39.am4> |
| In reply to | #141114 |
On 16/02/2019 16:51, Bart wrote:
> while (b = f()) { do something with b... }
>
> So that /in general/ you can easily convert such first-time assignments
> to a combined declaration/assignment.
"can't", in case the typo isn't obvious.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-16 18:20 +0000 |
| Message-ID | <87sgwnegsh.fsf@bsb.me.uk> |
| In reply to | #141114 |
Bart <bc@freeuk.com> writes:
> On 16/02/2019 16:33, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> Declaration at first point of use has a problem when a variable is
>>> first assigned to, inside an expression. This is a very simple
>>> instance of that:
>>>
>>> a = b = f();
>>>
>>> If this is the first use of a, then your rule would require this:
>>>
>>> int a = b = f();
>>>
>>> But what if this is also the first use of b? (#16 in my list)
>>>
>>> The ability to assign within an expression causes a conflict.
>>>
>>> A gcc extension allows statements within expressions:
>>>
>>> int a=({int b=f();b;});
>>>
>>> But the result is anything but clear, and also this imposes a
>>> restriction on the scope of b.
>>
>> Apart from not being C, it's not the same at all (as you imply). In C
>> you would simply write:
>>
>> int a = f(), b = a;
>
> This point is about first assigning to a variable when that assignment
> is inside an expression. That is, when the result of that assignment
> is needed rather being standalone statement/expression.
>
> In my example, that would be the assignment to b:
>
> a = (b = f());
Sure. But that one can be done. I was not certain you (and other
readers) knew that.
> You can imagine that assignment being in a more elaborate context, for example:
>
> while (b = f()) { do something with b... }
That's a much better example.
> So that /in general/ you can easily convert such first-time
> assignments to a combined declaration/assignment.
Yes, C does not support "declare at first use" in any truly general way.
> My example was perhaps a poor one.
I certainly missed your intent. The "what if this is also the first use
of b" led me astray because there is a solution if it's the first of a
as well. In fact, the a/b thing is a red herring as your while example
shows.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-16 20:00 +0100 |
| Message-ID | <q49mjs$3kv$1@dont-email.me> |
| In reply to | #141116 |
On 16/02/2019 19:20, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 16/02/2019 16:33, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> Declaration at first point of use has a problem when a variable is
>>>> first assigned to, inside an expression. This is a very simple
>>>> instance of that:
>>>>
>>>> a = b = f();
>>>>
>>>> If this is the first use of a, then your rule would require this:
>>>>
>>>> int a = b = f();
>>>>
>>>> But what if this is also the first use of b? (#16 in my list)
>>>>
>>>> The ability to assign within an expression causes a conflict.
>>>>
>>>> A gcc extension allows statements within expressions:
>>>>
>>>> int a=({int b=f();b;});
>>>>
>>>> But the result is anything but clear, and also this imposes a
>>>> restriction on the scope of b.
>>>
>>> Apart from not being C, it's not the same at all (as you imply). In C
>>> you would simply write:
>>>
>>> int a = f(), b = a;
>>
>> This point is about first assigning to a variable when that assignment
>> is inside an expression. That is, when the result of that assignment
>> is needed rather being standalone statement/expression.
>>
>> In my example, that would be the assignment to b:
>>
>> a = (b = f());
>
> Sure. But that one can be done. I was not certain you (and other
> readers) knew that.
>
>> You can imagine that assignment being in a more elaborate context, for example:
>>
>> while (b = f()) { do something with b... }
>
> That's a much better example.
C++17 allows initialisers in several statements ("if" and "switch",
IIRC) in addition to "for" that is also allowed in C99. I wonder why it
is not also allowed in "while" :
while (int b = f()) { do something with b }
or
while (int b = f(); b) { do something with b }
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-17 08:54 +1300 |
| Message-ID | <gcr842Fke31U6@mid.individual.net> |
| In reply to | #141112 |
On 17/02/2019 04:09, Bart wrote:
> On 12/02/2019 22:01, Ian Collins wrote:
>> On 13/02/2019 10:53, Bart wrote:
>
>>> OK, what would a script look like that listed all the variable
>>> declarations in a C source file? Taking account of user types and macros.
>>
>
>> What I did miss is you contradicting your own argument by saying "Like
>> adding 'const' everywhere"; you could only do that if variables were
>> declared at the first point of use!
>
> Declaration at first point of use has a problem when a variable is first
> assigned to, inside an expression. This is a very simple instance of that:
>
> a = b = f();
What does that have to do with const?
> If this is the first use of a, then your rule would require this:
I don't claim ownership of any rule...
> int a = b = f();
>
> But what if this is also the first use of b? (#16 in my list)
I would simply write
int a = f();
int b = a;
> The ability to assign within an expression causes a conflict.
>
> A gcc extension allows statements within expressions:
>
> int a=({int b=f();b;});
How horrible.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 23:23 +0000 |
| Message-ID | <XX0aE.14023$296.11967@fx10.am4> |
| In reply to | #141118 |
On 16/02/2019 19:54, Ian Collins wrote: > On 17/02/2019 04:09, Bart wrote: >> On 12/02/2019 22:01, Ian Collins wrote: >>> On 13/02/2019 10:53, Bart wrote: >> >>>> OK, what would a script look like that listed all the variable >>>> declarations in a C source file? Taking account of user types and >>>> macros. >>> >> >>> What I did miss is you contradicting your own argument by saying "Like >>> adding 'const' everywhere"; you could only do that if variables were >>> declared at the first point of use! >> >> Declaration at first point of use has a problem when a variable is first >> assigned to, inside an expression. This is a very simple instance of >> that: >> >> a = b = f(); > > What does that have to do with const? This is about first point of use and how practical it is to always declare at that point. >> But what if this is also the first use of b? (#16 in my list) > > I would simply write > > int a = f(); > int b = a; And you've split one expression into two. (BTW those declarations are the way around; b is used first.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-17 12:31 +1300 |
| Message-ID | <gcrkq2Fke31U7@mid.individual.net> |
| In reply to | #141122 |
On 17/02/2019 12:23, Bart wrote: > On 16/02/2019 19:54, Ian Collins wrote: >> On 17/02/2019 04:09, Bart wrote: >>> On 12/02/2019 22:01, Ian Collins wrote: >>>> On 13/02/2019 10:53, Bart wrote: >>> >>>>> OK, what would a script look like that listed all the variable >>>>> declarations in a C source file? Taking account of user types and >>>>> macros. >>>> >>> >>>> What I did miss is you contradicting your own argument by saying "Like >>>> adding 'const' everywhere"; you could only do that if variables were >>>> declared at the first point of use! >>> >>> Declaration at first point of use has a problem when a variable is first >>> assigned to, inside an expression. This is a very simple instance of >>> that: >>> >>> a = b = f(); >> >> What does that have to do with const? > > This is about first point of use and how practical it is to always > declare at that point. > >>> But what if this is also the first use of b? (#16 in my list) >> >> I would simply write >> >> int a = f(); >> int b = a; > > And you've split one expression into two. (BTW those declarations are > the way around; b is used first.) Quite. Many (including mane and my client's) coding standards prohibit more than one declaration per line. With one per line, I wouldn't have got the order wrong... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-17 00:34 +0000 |
| Message-ID | <K_1aE.344424$gy2.268691@fx21.am4> |
| In reply to | #141124 |
On 16/02/2019 23:31, Ian Collins wrote: > On 17/02/2019 12:23, Bart wrote: >> And you've split one expression into two. (BTW those declarations are >> the [other] way around; b is used first.) > > Quite. Many (including mane and my client's) coding standards prohibit > more than one declaration per line. With one per line, I wouldn't have > got the order wrong... [(18)] That sounds like a policy that, rather help localise declarations, deliberately sets them further part. And would cause a problems in a syntax like this: (x, y) = midpt(); where the two parts of the RHS are split and assigned to two values. (Although it would also be syntactically difficult to declare x and y here, especially if they are of different types.) (This, again, is not a problem in that language of mine. It must be doing /something/ right.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-17 14:26 +1300 |
| Message-ID | <gcrrimFke31U8@mid.individual.net> |
| In reply to | #141125 |
On 17/02/2019 13:34, Bart wrote: > On 16/02/2019 23:31, Ian Collins wrote: >> On 17/02/2019 12:23, Bart wrote: > >>> And you've split one expression into two. (BTW those declarations are >>> the [other] way around; b is used first.) >> >> Quite. Many (including mane and my client's) coding standards prohibit >> more than one declaration per line. With one per line, I wouldn't have >> got the order wrong... > > [(18)] That sounds like a policy that, rather help localise > declarations, deliberately sets them further part. No at all. If it cause problems, it wouldn't be so widely used. If adjacent lines aren't localiesed enough for you, what is? > And would cause a > problems in a syntax like this: > > (x, y) = midpt(); > > where the two parts of the RHS are split and assigned to two values. Which C doesn't do... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-17 01:45 +0000 |
| Message-ID | <d13aE.1224971$3si.1101589@fx08.am4> |
| In reply to | #141126 |
On 17/02/2019 01:26, Ian Collins wrote:
> On 17/02/2019 13:34, Bart wrote:
>> On 16/02/2019 23:31, Ian Collins wrote:
>>> On 17/02/2019 12:23, Bart wrote:
>>
>>>> And you've split one expression into two. (BTW those declarations are
>>>> the [other] way around; b is used first.)
>>>
>>> Quite. Many (including mane and my client's) coding standards prohibit
>>> more than one declaration per line. With one per line, I wouldn't have
>>> got the order wrong...
>>
>> [(18)] That sounds like a policy that, rather help localise
>> declarations, deliberately sets them further part.
>
> No at all. If it cause problems, it wouldn't be so widely used. If
> adjacent lines aren't localiesed enough for you, what is?
OK, so those standards prohibit this:
unsigned int x, y, z;
in favour of:
unsigned int x;
unsigned int y;
unsigned int z;
It seems to me that the first lot of declarations are more localised!
(And notice the extra two lines [(19) the style makes functions longer],
the greater dominance of the typespec, the amount of repeated
information which is usually a code smell in source code.)
>> And would cause a
>> problems in a syntax like this:
>>
>> (x, y) = midpt();
>>
>> where the two parts of the RHS are split and assigned to two values.
>
> Which C doesn't do...
It means guidelines such 'declare at first assignment' start to break
down when you look at broader language syntax, not just of C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-17 20:12 +1300 |
| Message-ID | <gcsfqmFke31U9@mid.individual.net> |
| In reply to | #141127 |
On 17/02/2019 14:45, Bart wrote: > On 17/02/2019 01:26, Ian Collins wrote: >> On 17/02/2019 13:34, Bart wrote: >>> On 16/02/2019 23:31, Ian Collins wrote: >>>> On 17/02/2019 12:23, Bart wrote: >>> >>>>> And you've split one expression into two. (BTW those declarations are >>>>> the [other] way around; b is used first.) >>>> >>>> Quite. Many (including mane and my client's) coding standards prohibit >>>> more than one declaration per line. With one per line, I wouldn't have >>>> got the order wrong... >>> >>> [(18)] That sounds like a policy that, rather help localise >>> declarations, deliberately sets them further part. >> >> No at all. If it cause problems, it wouldn't be so widely used. If >> adjacent lines aren't localiesed enough for you, what is? > > OK, so those standards prohibit this: > > unsigned int x, y, z; > > in favour of: > > unsigned int x; > unsigned int y; > unsigned int z; > > It seems to me that the first lot of declarations are more localised! When you declare variables when they are first used in C, there is seldom a need to declare more than on on a single line. The first form above is way more common in old C where everything had to be declared at the top... > (And notice the extra two lines [(19) the style makes functions longer], > the greater dominance of the typespec, the amount of repeated > information which is usually a code smell in source code.) > >>> And would cause a >>> problems in a syntax like this: >>> >>> (x, y) = midpt(); >>> >>> where the two parts of the RHS are split and assigned to two values. >> >> Which C doesn't do... > > It means guidelines such 'declare at first assignment' start to break > down when you look at broader language syntax, not just of C. x, y = something() Is common in Python, where the expression introduces x and y at the point of first use. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-17 11:23 +0000 |
| Message-ID | <4vbaE.1234829$3si.1135905@fx08.am4> |
| In reply to | #141129 |
On 17/02/2019 07:12, Ian Collins wrote: > On 17/02/2019 14:45, Bart wrote: >> It means guidelines such 'declare at first assignment' start to break >> down when you look at broader language syntax, not just of C. > > x, y = something() > > Is common in Python, where the expression introduces x and y at the > point of first use. Python is rather peculiar. AIUI, outside of a function, /any/ use of 'x' is considered to be its first use, requiring a global name lookup, since it could have been deleted (with 'del x') since the last time it was used.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-02-12 23:00 +0000 |
| Message-ID | <slrnq66jvp.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #140879 |
On Tue, 2019-02-12, Bart wrote: > On 12/02/2019 19:47, Ian Collins wrote: [I snipped this] >> On 13/02/2019 01:10, Bart wrote: >>> On 01/02/2019 12:15, Bart wrote: >>> >>> >>> [Enumerating the issues with mixing declarations with code] >>> >>> > (1) .... >>> >>>> (13) I've touched on this, but during development, if striving to have >>>> the smallest scope, then the scope would be constantly changing as lines >>>> are added, moved, removed and modified. It would be chaotic. >>> >>> (14) In some non-C code, I've had to manually tweak every declaration in >>> some modules for a change of syntax. This was easy to do because they're >>> all at the top of a function. But I didn't realise /how/ easy that made >>> it until I encountered errors because one or two were hidden in the >>> function's code and had been missed. Imagine if most declarations had >>> been like that. ... > And there are plenty of other things you can be doing that involves > scanning through every declaration, that would be helped by having them > grouped together. Like adding 'const' everywhere. Except grouping the declarations together is what prevents adding 'const'. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-12 14:12 -0800 |
| Message-ID | <q3vgcg$ec$1@dont-email.me> |
| In reply to | #140872 |
On 2/12/2019 4:10 AM, Bart wrote: > > (14) In some non-C code, I've had to manually tweak every declaration in > some modules for a change of syntax. This was easy to do because they're > all at the top of a function. But I didn't realise /how/ easy that made > it until I encountered errors because one or two were hidden in the > function's code and had been missed. Imagine if most declarations had > been like that. Same fallacy as before. I the variables were declared locally, there wouldn't be any need for that extra tweak in the declaration in the first place. Majority of your "points" is actually about fixing "problems" that you yourself unnecessarily created by detaching declarations from the code and moving them up. > (15) The tweak was to require a 'var' prefix before each declaration. > This has the side-effect of making the declaration block at the top of a > function stand out even more, with a clearer demarcation as to where > that block finishes and the code proper starts. However /now/ mixing > declarations in the code would spoil the look of the code even more. A fallacy again. There's no need and there's never been any need for "clearer demarcation as to where that block finishes and the code proper starts". In any case, every time one needs to separate two sections of code, one just uses vertical spacing. Easy. The matter has nothing to do with the topic. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-12 22:44 +0000 |
| Message-ID | <w%H8E.317301$9E1.125570@fx35.am4> |
| In reply to | #140884 |
On 12/02/2019 22:12, Andrey Tarasevich wrote: > On 2/12/2019 4:10 AM, Bart wrote: >> >> (14) In some non-C code, I've had to manually tweak every declaration >> in some modules for a change of syntax. This was easy to do because >> they're all at the top of a function. But I didn't realise /how/ easy >> that made it until I encountered errors because one or two were hidden >> in the function's code and had been missed. Imagine if most >> declarations had been like that. > > Same fallacy as before. I the variables were declared locally, there > wouldn't be any need for that extra tweak in the declaration in the > first place. (? This is a conversion from language X to Y, neither of which is C, but my habit of collecting declarations at the top of a function, which I do with X, Y /and/ C, made the task considerably simpler.) > Majority of your "points" is actually about fixing "problems" that you > yourself unnecessarily created by detaching declarations from the code > and moving them up. > >> (15) The tweak was to require a 'var' prefix before each declaration. >> This has the side-effect of making the declaration block at the top of >> a function stand out even more, with a clearer demarcation as to where >> that block finishes and the code proper starts. However /now/ mixing >> declarations in the code would spoil the look of the code even more. > > A fallacy again. There's no need and there's never been any need for > "clearer demarcation as to where that block finishes and the code proper > starts". I like to separate executable code from variable metadata. If you needed to list all the local variables in a function, then it is much easier if they are collected together, and if the end of that block of variables is obvious. Disseminated throughout a function, the process is harder and more error prone; you might have to resort to using a tool to do the job. And even then, block scopes means that there could be duplicate identifiers, which may or may not have the same types, and that may or not not have nested or overlapping scopes and lifetimes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-12 23:32 +0000 |
| Message-ID | <DII8E.1045703$Fi6.342169@fx12.am4> |
| In reply to | #140886 |
On 12/02/2019 22:44, Bart wrote:
> On 12/02/2019 22:12, Andrey Tarasevich wrote:
>> On 2/12/2019 4:10 AM, Bart wrote:
>> Same fallacy as before. I the variables were declared locally, there
>> wouldn't be any need for that extra tweak in the declaration in the
>> first place.
> I like to separate executable code from variable metadata.
Here's a case study; this is a program I've just spotted over in
comp.lang.c++ (sorry it's not in C):
----------------------------
int main()
{
constexpr int num = 1000001;
constexpr int daysInYear = 365;
std::vector<int> numTrials(num);
std::default_random_engine generator;
std::mt19937 gen(generator());
std::uniform_int_distribution<int> distribution(0,364);
for(int i = 0; i < num; ++i)
{
int counter = 0;
std::vector<int> calendar(daysInYear);
int numOdd = 0;
do
{
const int next = distribution(gen);
++calendar[next];
if(calendar[next] == 1)
++numOdd;
else if(calendar[next] == 2)
--numOdd;
++counter;
}
while(numOdd);
numTrials[i] = counter;
}
std::sort(numTrials.begin(), numTrials.end());
std::cout << numTrials[num/2];
}
----------------------------
(The original seemed to have lost its indentation, which I've added.)
It looks at first like all the declarations are at the top, but I wanted
to translate this (into my dynamic script language), and as I
transcribed it, I discovered more and more locals. The end result (which
seems to give similar output to the C++) was this:
------------------------------------
proc start=
const num = 1000001
const daysinyear = 365
numtrials:=new(list,num,0)
for i to num do
counter := 0
calendar := new(list,daysinyear,0)
numodd := 0
repeat
case ++calendar[random(1..daysinyear)]
when 1 then ++numodd
when 2 then --numodd
esac
++counter
until not numodd
numtrials[i] := counter
od
isort(numtrials)
println numtrials[num%2]
end
------------------------------------
The primary aim is cleaner, simpler code, and one of doing that is
getting unnecessary declarations out of the main body.
(The above doesn't need declarations, unless added optionally with a
line like this:
var numtrials, calendar, counter, numodd
but a statically typed version, not yet ready, would add two declaration
lines - at the top - while the new() calls are simplified.)
I just can't see what in-place declarations would add to code like this,
other than making certain things harder.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-13 12:51 +1300 |
| Message-ID | <gch4gqFgcocU10@mid.individual.net> |
| In reply to | #140891 |
On 13/02/2019 12:32, Bart wrote: <snip> > > ------------------------------------ > proc start= > const num = 1000001 > const daysinyear = 365 > > numtrials:=new(list,num,0) > > for i to num do > counter := 0 > calendar := new(list,daysinyear,0) > numodd := 0 So you are doing the equivalent of introducing variables at block scope, at least not "all at the top"... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-13 01:13 +0000 |
| Message-ID | <sbK8E.335003$iL2.262788@fx17.am4> |
| In reply to | #140892 |
On 12/02/2019 23:51, Ian Collins wrote: > On 13/02/2019 12:32, Bart wrote: > > <snip> >> >> ------------------------------------ >> proc start= >> const num = 1000001 >> const daysinyear = 365 >> >> numtrials:=new(list,num,0) >> >> for i to num do >> counter := 0 >> calendar := new(list,daysinyear,0) >> numodd := 0 > > So you are doing the equivalent of introducing variables at block scope, > at least not "all at the top"... > (This is scripting code which is convenient to write, but lacks the useful discipline of enumerating all the locals together with their types (making it more error prone among other things). That's why I'm moving this kind of language towards requiring declarations.) Still, there is no 'metadata' here to clutter up the code. All names are unique and have function-wide scope, and the reader can use inference for their types. With the same set of variables described at the top of the function, I can play with different configurations of the algorithm without continually needing to be aware of the varying scopes and lifetimes of those variables. (I understand the original author of that code was asking why the results weren't quite as expected.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-14 07:39 +1300 |
| Message-ID | <gcj6i7Fke31U1@mid.individual.net> |
| In reply to | #140894 |
On 13/02/2019 14:13, Bart wrote: > On 12/02/2019 23:51, Ian Collins wrote: >> On 13/02/2019 12:32, Bart wrote: >> >> <snip> >>> >>> ------------------------------------ >>> proc start= >>> const num = 1000001 >>> const daysinyear = 365 >>> >>> numtrials:=new(list,num,0) >>> >>> for i to num do >>> counter := 0 >>> calendar := new(list,daysinyear,0) >>> numodd := 0 >> >> So you are doing the equivalent of introducing variables at block scope, >> at least not "all at the top"... >> > > (This is scripting code which is convenient to write, but lacks the > useful discipline of enumerating all the locals together with their > types (making it more error prone among other things). Never the less, given a choice you write the code as you did, presumably because you found it more natural that way. The C++ example you posted also used a const, which can only be introduced at the point of first assignment. You conveniently ignored the messages pointing out the error in your "adding 'const' everywhere" argument. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-13 19:54 +0000 |
| Message-ID | <QB_8E.1143170$Fi6.816260@fx12.am4> |
| In reply to | #140949 |
On 13/02/2019 18:39, Ian Collins wrote: > On 13/02/2019 14:13, Bart wrote: > Never the less, given a choice you write the code as you did, presumably > because you found it more natural that way. I just wrote the code that was necessary to implement the algorithm. I didn't write declarations because that dynamic language didn't need them. If I did decide to add them, they would be outside of the code so that there would be less clutter. (Also, in that language, it will trap the use of an uninitialised variable.) > The C++ example you posted also used a const, which can only be > introduced at the point of first assignment. You conveniently ignored > the messages pointing out the error in your "adding 'const' everywhere" > argument. What about it? Sometimes 'const' declarations need to be in-place, as they must be initialised, and their initial value may only be ready at that point. And sometimes they don't. And if you /did/ have to scan your code adding 'const' where it would help, without necessarily having to move the declaration elsewhere, then you would still have the problem of having to examine every line of a function. What I don't understand is this preoccupation with micro-managing variable scopes. When you are writing a function, then you have have ALREADY minimised the possible scope to the extent of the function, and most functions are going to be small, like, 2-3 dozen lines. If a function grows to the extent that you have autonomous regions that want to have their own variables, then perhaps it's time to split it up. How many local variables is a function likely to have anyway? I've measured and the results are interesting: sqlite3: 3.3 average # locals per function lua: 2.0 my C code: 2.0 Seed7: 2.6 stb_image: 3.5 cipher: 2.5 OK, these are averages, but is having half a dozen function-scope variables really so unmanageable that you have to resort to local block-scopes?
[toc] | [prev] | [next] | [standalone]
Page 12 of 19 — ← Prev page 1 … 10 11 [12] 13 14 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web