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 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-14 19:22 -0500 |
| Message-ID | <q450o5$det$1@dont-email.me> |
| In reply to | #141008 |
On 2/14/19 09:29, Öö Tiib wrote: > On Thursday, 14 February 2019 15:18:01 UTC+2, Bart wrote: >> >> This is a real example: >> >> const unsigned char *py = nj.comp[0].pixels; >> const unsigned char *pcb = nj.comp[1].pixels; >> const unsigned char *pcr = nj.comp[2].pixels; > > That doesn't pass code review in C projects I've > participated this century since coding standards always > required to use "uint8_t" instead of "unsigned char". In principle, uint8_t and unsigned char could be two different types on an implementation where CHAR_BIT==8. However, on a sane implementation, they won't be different unless CHAR_BIT!=8. The only significant difference between those types is that code using uint8_t will fail if that's the case. I can understand why that might be considered desirable for certain kinds of code, though I prefer to tie a #error directive directly to CHAR_BIT when that's the case. However, for much of my code, I use unsigned char as a C90-compatible equivalent of uint_least8_t. Such code has no good reason to fail just because CHAR_BIT != 8. Do the coding standards you refer to really prohibit such use? Do they in fact mandate that such code be written in such a way that it will unnecessarily fail to compile?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-02-15 02:14 -0800 |
| Message-ID | <0efc1b54-d703-4d69-bd08-31607f8a57e5@googlegroups.com> |
| In reply to | #141058 |
On Friday, 15 February 2019 02:22:39 UTC+2, James Kuyper wrote:
>
> However, for much of my code, I use unsigned char as a C90-compatible
> equivalent of uint_least8_t. Such code has no good reason to fail just
> because CHAR_BIT != 8. Do the coding standards you refer to really
> prohibit such use? Do they in fact mandate that such code be written in
> such a way that it will unnecessarily fail to compile?
Usage of raw fundamental integral (types or those _least _fast) types
was basically allowed only for performance issue / request. Like:
int x; /* int to fix SIR-12497 */
At first it was bit inconvenient to follow. For example to run with MSVC
that did not even have the stdint.h until 2010 there was need for custom
header. But in long run there were less bit-width related issues
than in previous projects. It makes some sense to this day since 16-,
32- and 64-bit platforms are still used in mix to this day.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 15:53 -0800 |
| Message-ID | <86tvgrctn5.fsf@mailhub.linuxsc.com> |
| In reply to | #141058 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 2/14/19 09:29, <<D6 F6 [05b6]>> Tiib wrote: > >> On Thursday, 14 February 2019 15:18:01 UTC+2, Bart wrote: >> >>> This is a real example: >>> >>> const unsigned char *py = nj.comp[0].pixels; >>> const unsigned char *pcb = nj.comp[1].pixels; >>> const unsigned char *pcr = nj.comp[2].pixels; >> >> That doesn't pass code review in C projects I've >> participated this century since coding standards always >> required to use "uint8_t" instead of "unsigned char". > > In principle, uint8_t and unsigned char could be two different > types on an implementation where CHAR_BIT==8. However, on a sane > implementation, they won't be different unless CHAR_BIT!=8. If CHAR_BIT != 8, then uint8_t cannot be defined in a conforming implementation. > The only significant difference between those types is that code > using uint8_t will fail if that's the case. Not so. Character types have an exception granted in the rules for effective types and aliasing. Besides providing more stringent type checking, defining uint8_t to be not the same type as the character type unsigned char means uint8_t may be taken as not aliasing, eg, an int object, which almost certainly gives greater opportunities for optimization.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-15 09:27 +1300 |
| Message-ID | <gcm19eFke31U3@mid.individual.net> |
| In reply to | #140997 |
On 15/02/2019 02:17, Bart wrote: > On 14/02/2019 03:30, Ian Collins wrote: >> On 14/02/2019 08:54, Bart wrote: >>> 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. >> >> Whether you used declarations or not is irrelevant, you still introduced >> the variables when you needed them.... > > You mean I first used a variable when I first needed to use it? Yes; > doing otherwise is difficult. There you are then. > But you don't seem to grasp the difference between declaring a variable, > which is adding annotation to define certain attributes, and just using > it. I want to keep that extra annotation separate from the code that > uses that variable. That (in C) is a throwback to one of C's biggest mistakes - implicit int. If C were written today, I'm sure automatic type deduction would be part of the language. C++ now has it, but it had to use a keyword to avoid confusion with its inherited baggage. Splitting using a variable and declaring a variable on first use is a false dichotomy. >>> How many local variables is a function likely to have anyway? >> >> Irrelevant. > > Why? Even if it only had one, declaring it when it was needed would still make more sense. It would probably make more sense with only one! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-13 10:02 +0100 |
| Message-ID | <q40mfi$g0g$1@dont-email.me> |
| In reply to | #140886 |
On 12/02/2019 23:44, Bart wrote: > 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.) > So your justification for writing poor quality C code is that it makes it easier to convert from language X to language Y? I can't answer for anyone else, but I don't often translate programs from one language to another. I use several different programming languages, but I use each for a reason - different languages have their strengths and weaknesses, their idiosyncrasies and idioms, and their different ways to structure things. If I have some code in C, and I want the same functionality in Python, I don't take the C code and try to do textual manipulation to fit the syntax of Python - I write Python code that has basically the same functionality as the C code. >> Majority of your "points" is actually about fixing "problems" that you >> yourself unnecessarily created by detaching declarations from the code >> and moving them up.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-02-13 09:13 +0000 |
| Subject | Just an end-user... (Was: "...the value becomes,indeterminate each time the declaration is) reached" |
| Message-ID | <q40n3k$pnd$1@news.xmission.com> |
| In reply to | #140901 |
In article <q40mfi$g0g$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >I can't answer for anyone else, but I don't often translate programs >from one language to another. I use several different programming >languages, but I use each for a reason - different languages have their >strengths and weaknesses, their idiosyncrasies and idioms, and their >different ways to structure things. That's because you're just an end-user. You're not an implemntor, like Bart is. -- The last time a Republican cared about you, you were a fetus.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-13 11:32 +0000 |
| Message-ID | <yfT8E.922390$3si.541867@fx08.am4> |
| In reply to | #140901 |
On 13/02/2019 09:02, David Brown wrote:
> On 12/02/2019 23:44, Bart wrote:
>> (? 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.)
>>
>
> So your justification for writing poor quality C code is that it makes
> it easier to convert from language X to language Y?
No, the code, in whatever language including C, will be higher quality
and it makes a number of things easier.
With an example like this, if you are trying to understand it, it makes
it a little easier if you have the set of variables used listed just
before you delve into the code:
named constants: num, daysinyear
int variables: numodd, counter
array variables: numtrials, calendar
Loop variables, at least with obvious names like i,j,k, shouldn't need
declaring. But C requires it and it's acceptable that that happens
inside a for-loop (even if it makes a long-winded for-header even longer).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-13 13:37 +0100 |
| Message-ID | <q41331$hm3$1@dont-email.me> |
| In reply to | #140913 |
On 13/02/2019 12:32, Bart wrote: > On 13/02/2019 09:02, David Brown wrote: >> On 12/02/2019 23:44, Bart wrote: > >>> (? 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.) >>> >> >> So your justification for writing poor quality C code is that it makes >> it easier to convert from language X to language Y? > > No, the code, in whatever language including C, will be higher quality > and it makes a number of things easier. > The general (but not universal) opinion is that mixing declarations and statements in C allows better quality code. That is why the feature was added to C. I appreciate you have the opinion - nay, obsession - that putting all variable declarations at the start of the code makes code better. (Despite that you fail to follow that in the code examples you gave of your own language.) Surely, however, you must see that even for people who agree with your general point, this is an absurd justification for it? > With an example like this, if you are trying to understand it, it makes > it a little easier if you have the set of variables used listed just > before you delve into the code: > > named constants: num, daysinyear > int variables: numodd, counter > array variables: numtrials, calendar I disagree. It is easier to understand a variable if two parts of it - the declaration and the usage are tied close together. Separating them across the code does not help. > > Loop variables, at least with obvious names like i,j,k, shouldn't need > declaring. But C requires it and it's acceptable that that happens > inside a for-loop (even if it makes a long-winded for-header even longer). >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-13 14:21 +0000 |
| Message-ID | <DJV8E.1036661$kk4.451394@fx36.am4> |
| In reply to | #140923 |
On 13/02/2019 12:37, David Brown wrote: > On 13/02/2019 12:32, Bart wrote: >> On 13/02/2019 09:02, David Brown wrote: >>> On 12/02/2019 23:44, Bart wrote: >> >>>> (? 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.) >>>> >>> >>> So your justification for writing poor quality C code is that it makes >>> it easier to convert from language X to language Y? >> >> No, the code, in whatever language including C, will be higher quality >> and it makes a number of things easier. >> > > The general (but not universal) opinion is that mixing declarations and > statements in C allows better quality code. Is that just your opinion that it is the general opinion? If I tell my C compiler to print out its internal representation of a program, it will show the AST (syntax tree for executable code) separately from the ST (symbol table). Even if the source code has declarations all mixed up with the executable code. That suggests the two kinds of source really are distinct. Where an initialised non-static declaration is used, the AST will show the assignment (as it really) as executable code. That is why the feature was > added to C. I appreciate you have the opinion - nay, obsession - that > putting all variable declarations at the start of the code makes code > better. (Despite that you fail to follow that in the code examples you > gave of your own language.) In that example those were assignments: executable code, not declarations. Those names are implicitly declared and are function-wide. But such scripting code is also sloppy. You seems to be saying that you want C to adopt some of the same practices as scripting code? This makes it easier to write for lazy programmers who don't want the detour to the top of a function and back to declare a new variable, but in C it also adds clutter in the wrong place. >> With an example like this, if you are trying to understand it, it makes >> it a little easier if you have the set of variables used listed just >> before you delve into the code: >> >> named constants: num, daysinyear >> int variables: numodd, counter >> array variables: numtrials, calendar > > I disagree. > > It is easier to understand a variable if two parts of it - the > declaration and the usage are tied close together. Separating them > across the code does not help. When someone takes a complex bit of code with mixed declarations, and factors the body of it into a separate function, that seems to be considered desirable. Yet, that is doing the same thing: extracting variables (not necessarily all) from the body of the original code, and enumerating them as the parameters to the function, /at the top/ of the new function. You're defining an interface to the code. And somebody might choose to take that same interface and implement it differently. You get some of these same benefits by not striving to couple declarations and code as tightly as possible and with the smallest possible scopes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-13 16:32 +0100 |
| Message-ID | <q41dah$eb0$1@dont-email.me> |
| In reply to | #140929 |
On 13/02/2019 15:21, Bart wrote: > On 13/02/2019 12:37, David Brown wrote: >> On 13/02/2019 12:32, Bart wrote: >>> On 13/02/2019 09:02, David Brown wrote: >>>> On 12/02/2019 23:44, Bart wrote: >>> >>>>> (? 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.) >>>>> >>>> >>>> So your justification for writing poor quality C code is that it makes >>>> it easier to convert from language X to language Y? >>> >>> No, the code, in whatever language including C, will be higher quality >>> and it makes a number of things easier. >>> >> >> The general (but not universal) opinion is that mixing declarations and >> statements in C allows better quality code. > > Is that just your opinion that it is the general opinion? > It turns up a great deal - have a google for "should I declare all my variables at the top of a function", and try to gauge "general opinion". I also note that being able to mix declarations and code is a common feature. Particularly relevant here is that the C committee looked at C++, saw that their experience of mixing declarations and statements was a big success and helpful to writing better programs, and copied the feature for C99. Their opinion on the matter counts /far/ higher than yours. > If I tell my C compiler to print out its internal representation of a > program, it will show the AST (syntax tree for executable code) > separately from the ST (symbol table). Even if the source code has > declarations all mixed up with the executable code. > Why should I - as a programmer - care about that in the slightest? I can well appreciate that the restrictions you like on variables and their declarations - putting them all at the top, having function-wide scope on everything - makes life easier for the implementer of a simple compiler. But for every compiler implementer of real languages, there are 10,000 compiler /users/ - it is /their/ convenience, and the quality of /their/ code, that is important. > That suggests the two kinds of source really are distinct. No, it suggests that the way you implement these things is tightly bound with your prejudice about them. (I can't say which is cause and which is effect.) > > Where an initialised non-static declaration is used, the AST will show > the assignment (as it really) as executable code. > I hope you appreciate the difference here between something that is logically a declaration and assignment in source code, and what actually means reserving space and executable object code. And I hope you appreciate the difference between initialisation and assignment. Quite a number of compilers internally use a structure called "single static assignment". A key aspect of that is that - to the greatest possible extent - no variables are changed. In effect, you aim to make them "const" and initialised at their declaration. Mixing declarations and statements is thus the natural form. So when the compiler sees : int x; int y; x = foo(); x += 1; y = bar(x); x = foobar(x, y); the compiler internally works with: int x1 = foo(); int x2 = x1 + 1; int y1 = bar(x2); int x3 = foobar(x2, y1); > > That is why the feature was >> added to C. I appreciate you have the opinion - nay, obsession - that >> putting all variable declarations at the start of the code makes code >> better. (Despite that you fail to follow that in the code examples you >> gave of your own language.) > > In that example those were assignments: executable code, not > declarations. Those names are implicitly declared and are function-wide. > But such scripting code is also sloppy. Implicit declarations are declarations. > > You seems to be saying that you want C to adopt some of the same > practices as scripting code? Where did I suggest that? > This makes it easier to write for lazy > programmers who don't want the detour to the top of a function and back > to declare a new variable, but in C it also adds clutter in the wrong > place. C is a static and explicitly typed language. Declaring variables by giving their types is not clutter - it is part of the code. > >>> With an example like this, if you are trying to understand it, it makes >>> it a little easier if you have the set of variables used listed just >>> before you delve into the code: >>> >>> named constants: num, daysinyear >>> int variables: numodd, counter >>> array variables: numtrials, calendar >> >> I disagree. >> >> It is easier to understand a variable if two parts of it - the >> declaration and the usage are tied close together. Separating them >> across the code does not help. > > When someone takes a complex bit of code with mixed declarations, and > factors the body of it into a separate function, that seems to be > considered desirable. If you want to move code around into and out of other functions, then having the declarations alongside the use of the variables is vastly simpler than if you have them separated. I cannot imagine how you could think otherwise. If you want to make the process of shuffling code around easier, then the answer would be to extent C's system and allow variables to be re-declared in the same scope, with the same identifier name - creating a new scope for that variable. > > Yet, that is doing the same thing: extracting variables (not necessarily > all) from the body of the original code, and enumerating them as the > parameters to the function, /at the top/ of the new function. > > You're defining an interface to the code. And somebody might choose to > take that same interface and implement it differently. > > You get some of these same benefits by not striving to couple > declarations and code as tightly as possible and with the smallest > possible scopes. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-13 15:18 +0000 |
| Message-ID | <MyW8E.220975$JE1.158553@fx11.am4> |
| In reply to | #140886 |
On 12/02/2019 22:44, Bart wrote:
> 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, ...
I've been talking about block scopes, but I've just realised that
doesn't really pin it down. (Not unusual when talking about C.)
A local variable in C can have a scope starting halfway through a block,
so it cannot have a scope attached to that whole block:
float A; // A1
{
S1;
S2;
int A; // A2
S3;
S4;
}
Call those two As A1 and A2. (Remember when I mentioned the problems
with disambiguating such names, and nobody could see the issue? Well
here it is right here!)
The scope of A2 ranges from half-way through the block, to the end of
the block.
The scope of A1 includes the first part of the block, but it is shadowed
in the second half.
The lifetime of A2, as I've learned is this thread, spans the whole block.
Which means that the first half of the block combines the lifetime of A2
with the visibility of A1. Remember that in the actual code, both of
those are called A.
(In my implementation of C, a local is attached to a block; there is no
information about whereabouts in the block it is declared. So how does
it even work? I guess it works simply because I do name resolution while
it's parsing. If that was split into a separate pass, then A2 would
shadow A1 even in the first half of the block.
Kudos to the C designers for not making the language so simple as to
spoil the fun.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-13 16:36 +0100 |
| Message-ID | <q41dh1$fei$1@dont-email.me> |
| In reply to | #140937 |
On 13/02/2019 16:18, Bart wrote:
> On 12/02/2019 22:44, Bart wrote:
>
>> 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, ...
>
> I've been talking about block scopes, but I've just realised that
> doesn't really pin it down. (Not unusual when talking about C.)
>
> A local variable in C can have a scope starting halfway through a block,
> so it cannot have a scope attached to that whole block:
>
> float A; // A1
> {
> S1;
> S2;
> int A; // A2
> S3;
> S4;
> }
>
> Call those two As A1 and A2. (Remember when I mentioned the problems
> with disambiguating such names, and nobody could see the issue? Well
> here it is right here!)
There was no "issue" before, and there is no "issue" now. If you need
access to both A's, give them different names. As always, pick names
that make sense at the time.
>
> The scope of A2 ranges from half-way through the block, to the end of
> the block.
Yes.
>
> The scope of A1 includes the first part of the block, but it is shadowed
> in the second half.
Yes.
>
> The lifetime of A2, as I've learned is this thread, spans the whole block.
Yes.
>
> Which means that the first half of the block combines the lifetime of A2
> with the visibility of A1. Remember that in the actual code, both of
> those are called A.
Scope is a compile-time property of the name of an object. Lifetime is
a run-time property of the object itself. These are not necessarily the
same thing.
>
> (In my implementation of C, a local is attached to a block; there is no
> information about whereabouts in the block it is declared. So how does
> it even work? I guess it works simply because I do name resolution while
> it's parsing. If that was split into a separate pass, then A2 would
> shadow A1 even in the first half of the block.
>
> Kudos to the C designers for not making the language so simple as to
> spoil the fun.)
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-13 23:09 +0000 |
| Message-ID | <87k1i3i8un.fsf@bsb.me.uk> |
| In reply to | #140937 |
Bart <bc@freeuk.com> writes:
> A local variable in C can have a scope starting halfway through a
> block, so it cannot have a scope attached to that whole block:
>
> float A; // A1
> {
> S1;
> S2;
> int A; // A2
> S3;
> S4;
> }
>
> Call those two As A1 and A2.
Seems odd to do that since you are talking about names. Clearer to call
them the float and the int.
> The scope of A2 ranges from half-way through the block, to the end of
> the block.
A2 has no scope because there is no name A2. The name A is in scope at
every line in your example. It refers to the float in the first 4
lines, and to the int the rest.
> The scope of A1 includes the first part of the block, but it is
> shadowed in the second half.
The second declaration of A shadows the first. That is almost always a
very bad idea. Bad code rarely makes for good examples.
> The lifetime of A2, as I've learned is this thread, spans the whole
> block.
Lifetime applies to objects and not names. The int object exists
throughout the execution of the inner block. The float exits throughout
the execution of the enclosing block which, of course, includes the
execution of the inner block.
> Which means that the first half of the block combines the lifetime of
> A2 with the visibility of A1. Remember that in the actual code, both
> of those are called A.
I don't know what that means.
Anyway, I post only in order to offer a less confusing way to talk about
the example.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 01:51 +0000 |
| Message-ID | <jQ39E.338409$iL2.286764@fx17.am4> |
| In reply to | #140969 |
On 13/02/2019 23:09, Ben Bacarisse wrote: > Anyway, I post only in order to offer a less confusing way to talk about > the example. The point is, it /is/ confusing. At some point during the block, either one A is visible, or another different A is visible, while both As have concurrent lifetimes during the whole block. And it's best not to mention: - a label A that could also be defined in the block - the two struct A tags (one outside one inside) that could also be defined - lower case versions of the 5 As (a, a, a, struct a, struct a) - the possibility of one of the main A's being written as: 'extern int A', as that can repeated an infinite number of times within a block. Is there any way the language designers could have made it any more complicated? While such combinations are unlikely to be encountered, they MIGHT be, and you always have to be bear that in mind as a possibility.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-14 02:35 +0000 |
| Message-ID | <87ef8bhzbw.fsf@bsb.me.uk> |
| In reply to | #140971 |
Bart <bc@freeuk.com> writes: > On 13/02/2019 23:09, Ben Bacarisse wrote: > >> Anyway, I post only in order to offer a less confusing way to talk about >> the example. > > The point is, it /is/ confusing. Apparently so, but the explanation need not be. > At some point during the block, either one A is visible, or another > different A is visible, while both As have concurrent lifetimes during > the whole block. That "explanation" is certainly confusing. Names don't have lifetimes. > And it's best not to mention: > > - a label A that could also be defined in the block > - the two struct A tags (one outside one inside) that could also > be defined > - lower case versions of the 5 As (a, a, a, struct a, struct a) > - the possibility of one of the main A's being written as: > 'extern int A', as that can repeated an infinite number of > times within a block. ... or that the monkey that typed it was call A Mac A face. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 10:00 +0100 |
| Message-ID | <q43an7$gvf$1@dont-email.me> |
| In reply to | #140971 |
On 14/02/2019 02:51, Bart wrote: > On 13/02/2019 23:09, Ben Bacarisse wrote: > >> Anyway, I post only in order to offer a less confusing way to talk about >> the example. > > The point is, it /is/ confusing. > > At some point during the block, either one A is visible, or another > different A is visible, while both As have concurrent lifetimes during > the whole block. > > And it's best not to mention: > > - a label A that could also be defined in the block > - the two struct A tags (one outside one inside) that could also > be defined > - lower case versions of the 5 As (a, a, a, struct a, struct a) > - the possibility of one of the main A's being written as: > 'extern int A', as that can repeated an infinite number of > times within a block. > > Is there any way the language designers could have made it any more > complicated? > > While such combinations are unlikely to be encountered, they MIGHT be, > and you always have to be bear that in mind as a possibility. > Perhaps you should invest in a new keyboard - one that has more than a single letter on it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 12:26 +0000 |
| Message-ID | <b8d9E.526642$AD1.185641@fx05.am4> |
| In reply to | #140979 |
On 14/02/2019 09:00, David Brown wrote:
> On 14/02/2019 02:51, Bart wrote:
>> While such combinations are unlikely to be encountered, they MIGHT be,
>> and you always have to be bear that in mind as a possibility.
>>
>
> Perhaps you should invest in a new keyboard - one that has more than a
> single letter on it.
>
People use i,j,k. They use a,b,c. They use x,y,z.
They just do. And, sometimes, they will reuse the same name, short or
otherwise, within the same function.
Don't believe me? OK, let's take a look:
All locals single letter Reused locals
names
sqlite3.c 6940 18% 380
shell.c 980 21% 85
Lua 1880 33% 220
stb_image.h 700 42% 74
cc.c (my code) 1800 34% 3
Only Seed7 amongst the code I tested used no single letter names and
very rarely reused a local name.
The figures mean this: sqlite3 declared 6940 local variables (exclude
parameter names, type names, tags, labels etc). Of those 18% or 1250
consisted of a single letter.
Of the 6940 variables, in 380 cases was a name (of any length) reusing
the same name used earlier in the function. If:
{int i;}{int i;}{int i;}
is seen, then that counts as two reused locals. (Variables declared
inside a for-loop are not counted for this.)
Maybe your code never uses single-letter names and never uses the same
name within a function, but nearly everyone else seems to be at it. So
my concerns are justified.
BTW everyone seems hung up on the fact that I made use of the short name
"A" in my examples. IT DOESN'T MATTER WHAT NAME I USE! I could have used
a much longer name; my points are exactly the same.
In fact it makes it worse when there are longer names that are only
subtly different; you have to do a double-take.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 15:22 +0100 |
| Message-ID | <q43tju$n5p$1@dont-email.me> |
| In reply to | #140995 |
On 14/02/2019 13:26, Bart wrote: > On 14/02/2019 09:00, David Brown wrote: >> On 14/02/2019 02:51, Bart wrote: > >>> While such combinations are unlikely to be encountered, they MIGHT be, >>> and you always have to be bear that in mind as a possibility. >>> >> >> Perhaps you should invest in a new keyboard - one that has more than a >> single letter on it. >> > > People use i,j,k. They use a,b,c. They use x,y,z. > Exactly. What they /don't/ do is use a, a, a or A, A, A. There's nothing wrong with single-letter identifiers in a small scope. My argument is against using the /same/ single-letter identifier in a dozen places. > They just do. And, sometimes, they will reuse the same name, short or > otherwise, within the same function. > <snip the irrelevant waffle> > > Maybe your code never uses single-letter names and never uses the same > name within a function, but nearly everyone else seems to be at it. So > my concerns are justified. > > BTW everyone seems hung up on the fact that I made use of the short name > "A" in my examples. IT DOESN'T MATTER WHAT NAME I USE! I could have used > a much longer name; my points are exactly the same. > You are hung up on the bizarre idea that because C lets you have nested block scopes and mix declarations and code, everyone uses confusing names, re-uses identifiers, and generally tries to make code hard to follow. > In fact it makes it worse when there are longer names that are only > subtly different; you have to do a double-take. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 15:02 +0000 |
| Message-ID | <Upf9E.935123$3si.589976@fx08.am4> |
| In reply to | #141006 |
On 14/02/2019 14:22, David Brown wrote: > On 14/02/2019 13:26, Bart wrote: >> On 14/02/2019 09:00, David Brown wrote: >>> On 14/02/2019 02:51, Bart wrote: >> >>>> While such combinations are unlikely to be encountered, they MIGHT be, >>>> and you always have to be bear that in mind as a possibility. >>>> >>> >>> Perhaps you should invest in a new keyboard - one that has more than a >>> single letter on it. >>> >> >> People use i,j,k. They use a,b,c. They use x,y,z. >> > > Exactly. What they /don't/ do is use a, a, a or A, A, A. > > There's nothing wrong with single-letter identifiers in a small scope. >> They just do. And, sometimes, they will reuse the same name, short or >> otherwise, within the same function. >> > > <snip the irrelevant waffle> You've snipped the proof that I'm talking sense! You said people don't single single letter names; THEY DO. You said people don't reuse the function identifiers; THEY DO. And the single letter thing was a red herring that you and one or others invented; my concerns weren't over people using the actual name A; it was over reusing the same name as before, no matter what it was. > My argument is against using the /same/ single-letter identifier in a > dozen places. Why only single letter names? The issue is using the same name, and longer ones can be generic too (px, py, pz). But let's have a look: sqlite3.c reuses names 380 times, of which 80 consist of a single letter. The function yy_reduce() defines 'p' seven times. It also reuses 2-letter names (like ii, r1, pX) 60 times. 'r1' is used 5 times in one function. In Lua, one function does actually define 'a' six times (although buried inside macros). The same function defines 'rb' 23 times! Not inside a macro. No doubt you will just dismiss such facts just because YOU never do that. Unfortunately we can't all limit ourselves to dealing with David Brown's code. > You are hung up on the bizarre idea that because C lets you have nested > block scopes and mix declarations and code, everyone uses confusing > names, re-uses identifiers, and generally tries to make code hard to follow. Um, yes they do. See above. See the stuff you snipped from my other post. Only one codebase out of half a dozen I looked at didn't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 16:23 +0100 |
| Message-ID | <q4414k$c79$1@dont-email.me> |
| In reply to | #141016 |
On 14/02/2019 16:02, Bart wrote: > On 14/02/2019 14:22, David Brown wrote: >> On 14/02/2019 13:26, Bart wrote: >>> On 14/02/2019 09:00, David Brown wrote: >>>> On 14/02/2019 02:51, Bart wrote: >>> >>>>> While such combinations are unlikely to be encountered, they MIGHT be, >>>>> and you always have to be bear that in mind as a possibility. >>>>> >>>> >>>> Perhaps you should invest in a new keyboard - one that has more than a >>>> single letter on it. >>>> >>> >>> People use i,j,k. They use a,b,c. They use x,y,z. >>> >> >> Exactly. What they /don't/ do is use a, a, a or A, A, A. >> >> There's nothing wrong with single-letter identifiers in a small scope. >>> They just do. And, sometimes, they will reuse the same name, short or >>> otherwise, within the same function. >>> >> >> <snip the irrelevant waffle> > > > You've snipped the proof that I'm talking sense! Sorry, you honestly thought that statistics from a couple of projects about the use of single-letter identifiers was /proof/ ? > > You said people don't single single letter names; THEY DO. I never said anything like that. I said /your/ examples used only one letter - "a" - not single-letter identifiers. I said /your/ examples were ridiculous and exaggerated because of that. > > You said people don't reuse the function identifiers; THEY DO. I never said anything like that either. I said that using C99's mixed declarations and statements does not force you to re-use identifiers (and certainly not call everything "a") in a way that makes code hard to comprehend. One of the biggest arguments /against/ your "top of the function" declarations is that people don't just re-use identifiers, they re-use the variables. Such code is often found with "int temp, tmp1, t, t2;" at the start, that are then re-used for different purposes throughout the code. (Note that I am not suggesting that you /have/ to do this if you declare variables at the top of the function - merely that people /do/ write such code. In contrast, nobody ever writes code with a dozen different uses of "a" shadowing each other.) > > And the single letter thing was a red herring that you and one or others > invented; my concerns weren't over people using the actual name A; it > was over reusing the same name as before, no matter what it was. > No one but you thinks anyone re-uses names in a confusing manner. >> My argument is against using the /same/ single-letter identifier in a >> dozen places. > > Why only single letter names? The issue is using the same name, and > longer ones can be generic too (px, py, pz). > > But let's have a look: sqlite3.c reuses names 380 times, of which 80 > consist of a single letter. The function yy_reduce() defines 'p' seven > times. > > It also reuses 2-letter names (like ii, r1, pX) 60 times. 'r1' is used 5 > times in one function. > > In Lua, one function does actually define 'a' six times (although buried > inside macros). > > The same function defines 'rb' 23 times! Not inside a macro. > > No doubt you will just dismiss such facts just because YOU never do > that. Unfortunately we can't all limit ourselves to dealing with David > Brown's code. I dismiss them because they are irrelevant. People re-use identifiers - that is nothing new. When you can define the identifiers in a smaller scope, it is less confusing and easier to follow than when you define them at the start of the function. And if people write code where it is hard to follow what is going on (for someone appropriately familiar with the program), then the code is bad - it doesn't matter what style that is used or where identifiers are declared. Letting you declare your variables when you need them, instead of the start of the function or block, gives you the freedom to write better and clearer code in many ways. Like any flexibility, it also gives you new ways to write bad code - but that does not make it a bad idea! You seem to be under the delusion that if a feature can be abused as well as used, then it will be abused more than used. > >> You are hung up on the bizarre idea that because C lets you have nested >> block scopes and mix declarations and code, everyone uses confusing >> names, re-uses identifiers, and generally tries to make code hard to >> follow. > > Um, yes they do. See above. See the stuff you snipped from my other > post. Only one codebase out of half a dozen I looked at didn't. > You have offered absolutely no evidence for that whatsoever. You have meaningless statistics about short identifiers and re-use - but no justification of any sort for suggesting that this is a source of confusion or problems in the code!
[toc] | [prev] | [next] | [standalone]
Page 14 of 19 — ← Prev page 1 … 12 13 [14] 15 16 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web