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 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 17:03 +0000 |
| Message-ID | <Jbh9E.288405$fF1.28976@fx37.am4> |
| In reply to | #141021 |
On 14/02/2019 15:23, David Brown wrote: > On 14/02/2019 16:02, Bart wrote: >> 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. Why? Would identifier would YOU have used if you had to make an example involving scopes of two names? Your OBJECTION is ridiculous. It amounts to saying that no one ever uses 'foo' and 'bar' in real code, so that any point such an example is trying to illustrate can therefore be dismissed. > I dismiss them because they are irrelevant. People re-use identifiers - > that is nothing new. OK. That's is different from your earlier argument that no one does that. > When you can define the identifiers in a smaller > scope, Do me a favour, and actually have a look at some sqlite3 code. It's barely possible to make out where any function starts and ends. > 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! At least now you seem to have conceded that this does happen. Single letter identifiers are used EXTENSIVELY in real code. And reuse of the same names in a function is also very common (more so than I expected actually). Which is somewhat crazy, given that most functions are small and only have handful of local variables; is it really that hard to think up a new name? And if it is just a using the same name for a similar purpose, why not just share the one declaration. > 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. Well, so what? Is having 28 non-nested blocks each defining their own 'temp' much of an improvement over them all sharing the same one? What happens when you decide to change all of them from int16_t to uint32_t? (Oops, I forget; your own code is always so perfect that that never happens; it was right first time!) But the rest of us now have to track down 28 instances of 'temp' to modify (and missing out one or two along the way because we don't actually know here are 28). If you think 28 instances is an exaggeration, don't forget that real example of 23 'rb' names from Lua.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 20:41 +0100 |
| Message-ID | <q44g97$dv5$1@dont-email.me> |
| In reply to | #141031 |
On 14/02/2019 18:03, Bart wrote: > On 14/02/2019 15:23, David Brown wrote: >> On 14/02/2019 16:02, Bart wrote: > >>> 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. > > Why? Surely that is obvious. You wrote them specifically to be exaggerated - to make them as confusing as you could within the syntax of C, without any pretense at realism. > > Would identifier would YOU have used if you had to make an example > involving scopes of two names? Your complaints were about lots of uses of the same name - struct A and typedef A and file-level variable A and local A and more locals all called A. That is silly exaggeration. The reality is that you rarely have shadowing of names. You might redefine "i" as a loop variable in several loops in the same function - but these will be non-overlapping. People generally write their code with an aim of being clear and understandable, not trying to make it obtuse. (Of course people don't always succeed in that.) > > Your OBJECTION is ridiculous. It amounts to saying that no one ever uses > 'foo' and 'bar' in real code, so that any point such an example is > trying to illustrate can therefore be dismissed. > >> I dismiss them because they are irrelevant. People re-use identifiers - >> that is nothing new. > > OK. That's is different from your earlier argument that no one does that. > Please identify where I said that. >> When you can define the identifiers in a smaller >> scope, > > Do me a favour, and actually have a look at some sqlite3 code. It's > barely possible to make out where any function starts and ends. > I have no idea about that code, and certainly can't tell you if it is well-written on badly written. I can't tell you what priorities the authors had, or what restrictions they had. (For all I know, maybe they restricted themselves to C90.) All I can tell you is that mixing declarations and code, or defining variables at the start of inner blocks, gives you freedom to write clearer and neater code. (This is rather obvious, actually, since it gives you /more/ freedom. If it turns out that for a particular piece of code, the neatest and clearest coding happens to declare all variables at the start of the function, then that is exactly what you should write - nothing in C99 stops you from doing that.) >> 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! > > At least now you seem to have conceded that this does happen. Single > letter identifiers are used EXTENSIVELY in real code. And reuse of the > same names in a function is also very common (more so than I expected > actually). I have never suggested anything else. This is all in your imagination. > > Which is somewhat crazy, given that most functions are small and only > have handful of local variables; is it really that hard to think up a > new name? And if it is just a using the same name for a similar purpose, > why not just share the one declaration. > > > 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. > > Well, so what? > > Is having 28 non-nested blocks each defining their own 'temp' much of an > improvement over them all sharing the same one? Yes. It is a vast improvement. (Of course, we all agree that it would be better to split up the function into smaller parts.) > > What happens when you decide to change all of them from int16_t to > uint32_t? (Oops, I forget; your own code is always so perfect that that > never happens; it was right first time!) If you need to change the types, change the types. Why would you find that difficult? > > But the rest of us now have to track down 28 instances of 'temp' to > modify (and missing out one or two along the way because we don't > actually know here are 28). > So now you can change the ones that actually need to be changed. > If you think 28 instances is an exaggeration, don't forget that real > example of 23 'rb' names from Lua. Please do not forget that the samples you take are particular individual pieces of code with particular purposes - you cannot take them as judgment of all C code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 21:23 +0000 |
| Message-ID | <j%k9E.360318$XD2.324247@fx10.am4> |
| In reply to | #141037 |
On 14/02/2019 19:41, David Brown wrote:
> On 14/02/2019 18:03, Bart wrote:
> Your complaints were about lots of uses of the same name - struct A and
> typedef A and file-level variable A and local A and more locals all
> called A. That is silly exaggeration.
C allows it. Therefore any code you look at might allow it, and it has
to be considered a possibility.
My checks only looked at one name space in a function, and only for
local /variables/, not things like typedef names (which are the same
name space as variables). So I don't know the prevalence of stuff like this:
struct T T;
(Where, as it seems I need to spell it out, 'T' is a placeholder symbol
representing any identifier of any length.)
> The reality is that you rarely have shadowing of names.
(And I don't check for shadowing either. It's a harder check to make,
and it is not worth doing as you will just dismiss any results.)
You or someone said that localised declarations mean it makes it easier
to copy blocks of code around.
In that case, it quite possible that those declarations might shadow
some more outer variables without being aware of the fact.
> I have no idea about that code, and certainly can't tell you if it is
> well-written on badly written. I can't tell you what priorities the
> authors had, or what restrictions they had. (For all I know, maybe they
> restricted themselves to C90.) All I can tell you is that mixing
> declarations and code, or defining variables at the start of inner
> blocks, gives you freedom to write clearer and neater code.
Yeah, people keep saying that. But it does seem a paradox that you can
clutter up code with extra declaration syntax and yet it becomes neater
and clearer...
> (This is rather obvious, actually, since it gives you /more/ freedom. If
> it turns out that for a particular piece of code, the neatest and
> clearest coding happens to declare all variables at the start of the
> function, then that is exactly what you should write - nothing in C99
> stops you from doing that.)
The tidiest looking code omits anything superfluous, and that means
leaving out declaration clutter. It also keeps it general purpose
instead of hard-coding data types into the code.
This business of interspersing type info everywhere seems to be a
peculiarity of many people's C code, and actually it reminds me of
Hungarian notation, where the type of a variable was hard-coded into a
prefix added to its name, and therefore present every time you used that
variable.
With some language support, it could even eliminate declarations! Yet
the practice has died out.
>>> 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!
>>
>> At least now you seem to have conceded that this does happen. Single
>> letter identifiers are used EXTENSIVELY in real code. And reuse of the
>> same names in a function is also very common (more so than I expected
>> actually).
>
> I have never suggested anything else. This is all in your imagination.
So what did you mean by this:
>Perhaps you should invest in a new keyboard - one that has more than a
>single letter on it.
> If you need to change the types, change the types. Why would you find
> that difficult?
Because there will be 28 of them scattered throughout a (necessarily
large) function? Or perhaps in DB-world that is not a problem (nothing
ever is).
>> If you think 28 instances is an exaggeration, don't forget that real
>> example of 23 'rb' names from Lua.
>
> Please do not forget that the samples you take are particular individual
> pieces of code with particular purposes - you cannot take them as
> judgment of all C code.
You seem to have forgotten the hundreds of instances where there were a
lot less than 24 (as it was) instances of the same variable. Just 2 is
enough.
I mentioned that one as an extreme example, but also because you said this:
> What they /don't/ do is use a, a, a or A, A, A.
and that function DOES define six instances of 'a'. (Whether shadowing
each other or not I've no idea; I'm just glad I don't need to debug it.)
Of course, that doesn't mean a function literally defining:
int a, a, a, a, a, a;
That's not allowed, not in a function anyway. To do that in C means writing:
extern int a, a, a, a, a, a;
Yes, that's allowed! Even inside a function. I would say you wouldn't
see this very often (N lots of 'extern int a' is more likely), but with
C you can never be sure.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-15 10:38 +1300 |
| Message-ID | <gcm5drFke31U4@mid.individual.net> |
| In reply to | #141049 |
On 15/02/2019 10:23, Bart wrote: > On 14/02/2019 19:41, David Brown wrote: > >> (This is rather obvious, actually, since it gives you /more/ freedom. If >> it turns out that for a particular piece of code, the neatest and >> clearest coding happens to declare all variables at the start of the >> function, then that is exactly what you should write - nothing in C99 >> stops you from doing that.) > > The tidiest looking code omits anything superfluous, and that means > leaving out declaration clutter. It also keeps it general purpose > instead of hard-coding data types into the code. C is a typed language, so the "declaration clutter" is a fact of life. What you say is partly correct, the reader often does not need to know or care about the type of a variable. The re-branding of auto from C++ could be a useful addition to C. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 22:53 +0100 |
| Message-ID | <q44o1k$to2$1@dont-email.me> |
| In reply to | #141049 |
On 14/02/2019 22:23, Bart wrote: > On 14/02/2019 19:41, David Brown wrote: >> On 14/02/2019 18:03, Bart wrote: > >> Your complaints were about lots of uses of the same name - struct A >> and typedef A and file-level variable A and local A and more locals >> all called A. That is silly exaggeration. > > C allows it. Therefore any code you look at might allow it, and it has > to be considered a possibility. > /All/ programming languages allow all sorts of idiocy. The extent to which you need to consider it will depend on the code and its source. When people look at code written in your language, do they have to consider the possibility that you might have named one variable OOOOOOOO0OO and another one OOOOOOO0OOO ? > My checks only looked at one name space in a function, and only for > local /variables/, not things like typedef names (which are the same > name space as variables). So I don't know the prevalence of stuff like > this: > > struct T T; > > (Where, as it seems I need to spell it out, 'T' is a placeholder symbol > representing any identifier of any length.) People do write that kind of thing. They also write typedef struct T T; (Obviously they don't do both in the same code.) It is usually entirely obvious what is meant and how the code works - it does not cause confusion. > >> The reality is that you rarely have shadowing of names. > > (And I don't check for shadowing either. It's a harder check to make, > and it is not worth doing as you will just dismiss any results.) > > You or someone said that localised declarations mean it makes it easier > to copy blocks of code around. > Yes, it was I. > In that case, it quite possible that those declarations might shadow > some more outer variables without being aware of the fact. Yes. And that's fine - it is what you want. > >> I have no idea about that code, and certainly can't tell you if it is >> well-written on badly written. I can't tell you what priorities the >> authors had, or what restrictions they had. (For all I know, maybe >> they restricted themselves to C90.) All I can tell you is that mixing >> declarations and code, or defining variables at the start of inner >> blocks, gives you freedom to write clearer and neater code. > > Yeah, people keep saying that. But it does seem a paradox that you can > clutter up code with extra declaration syntax and yet it becomes neater > and clearer... It is only a paradox if you first assume that the declarations inside the code are cluttering it up. Your arguments here are entirely circular, begging the question. > >> (This is rather obvious, actually, since it gives you /more/ freedom. >> If it turns out that for a particular piece of code, the neatest and >> clearest coding happens to declare all variables at the start of the >> function, then that is exactly what you should write - nothing in C99 >> stops you from doing that.) > > The tidiest looking code omits anything superfluous, and that means > leaving out declaration clutter. It also keeps it general purpose > instead of hard-coding data types into the code. Wrong and wrong. Or at least, it might make code /look/ tidy but it will not necessarily help make the code easy to understand or modify. > > This business of interspersing type info everywhere seems to be a > peculiarity of many people's C code, and actually it reminds me of > Hungarian notation, where the type of a variable was hard-coded into a > prefix added to its name, and therefore present every time you used that > variable. > What you call "Hungarian notation" there is an abuse and misunderstanding of the whole concept (you can look this up on the Wikipedia article). And if people had used declarations mixed with their code, it would never have happened - but this bad habit came from the world of Windows C programming using MS tools, which did not support C90. When you have the type immediately there in the code, the temptation to prefix your identifiers with a type code disappears. > With some language support, it could even eliminate declarations! Yet > the practice has died out. > The "Systems Hungarian notation" (using the terms from Wikipedia - they are as good as any) died out as people started using better types in their coding, especially for C++. > >>>> 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! >>> >>> At least now you seem to have conceded that this does happen. Single >>> letter identifiers are used EXTENSIVELY in real code. And reuse of >>> the same names in a function is also very common (more so than I >>> expected actually). >> >> I have never suggested anything else. This is all in your imagination. > > So what did you mean by this: > > >Perhaps you should invest in a new keyboard - one that has more than a > >single letter on it. Was your sarcasm detector out for lunch when you read that? You had made a series of posts about the horrors of calling everything "a". > >> If you need to change the types, change the types. Why would you find >> that difficult? > > Because there will be 28 of them scattered throughout a (necessarily > large) function? Or perhaps in DB-world that is not a problem (nothing > ever is). You don't randomly change the types of 28 variables. You would have to think about what they are, and what they do, and why you need to change their types. That means looking through the whole function (especially if you have declared them at the top of the function, so you can't limit your search scope). The actual task of changing the types is tiny in comparison. (And if you think it is so difficult, you'll find many editors support "search and replace".) > >>> If you think 28 instances is an exaggeration, don't forget that real >>> example of 23 'rb' names from Lua. >> >> Please do not forget that the samples you take are particular >> individual pieces of code with particular purposes - you cannot take >> them as judgment of all C code. > > You seem to have forgotten the hundreds of instances where there were a > lot less than 24 (as it was) instances of the same variable. Just 2 is > enough. > > I mentioned that one as an extreme example, but also because you said this: > > > What they /don't/ do is use a, a, a or A, A, A. > > and that function DOES define six instances of 'a'. (Whether shadowing > each other or not I've no idea; I'm just glad I don't need to debug it.) > > Of course, that doesn't mean a function literally defining: > > int a, a, a, a, a, a; > > That's not allowed, not in a function anyway. To do that in C means > writing: > > extern int a, a, a, a, a, a; > > Yes, that's allowed! Even inside a function. I would say you wouldn't > see this very often (N lots of 'extern int a' is more likely), but with > C you can never be sure. C allows many things that might not be considered a good idea. Personally, it is extremely rare in my coding to see more than one variable declared or defined on the same line. You will never see an "extern" declaration inside a function - this is enforced by compiler flags. People generally program to a certain coding standard (which may be entirely informal and in their own head) - just because something is allowed by the language, does /not/ mean people will write it.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-02-14 08:19 -0800 |
| Message-ID | <9189f099-71e7-462a-a612-a49e26334ef2@googlegroups.com> |
| In reply to | #141016 |
On Thursday, 14 February 2019 17:02:24 UTC+2, Bart wrote: > > 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. It is 500-line switch case of executing instructions. Handling of different instructions is written directly into that switch-case. Perhaps pointlessly, that makes it bit long for taste of most programmers and also likely less convenient to unit-test. The different lua instructions can have "argument b" (that the rb perhaps means) of different type and so it is declared inside of handling of those instructions that have it. There were no labels a, variables a, structs a and enum a of nested scopes hiding each other what you were initially arguing about.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 20:45 +0100 |
| Message-ID | <q44ghd$fes$1@dont-email.me> |
| In reply to | #141027 |
On 14/02/2019 17:19, Öö Tiib wrote: > On Thursday, 14 February 2019 17:02:24 UTC+2, Bart wrote: >> >> 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. > > It is 500-line switch case of executing instructions. > > Handling of different instructions is written directly into that switch-case. > Perhaps pointlessly, that makes it bit long for taste of most programmers > and also likely less convenient to unit-test. > > The different lua instructions can have "argument b" (that the rb > perhaps means) of different type and so it is declared inside of > handling of those instructions that have it. > > There were no labels a, variables a, structs a and enum a of nested > scopes hiding each other what you were initially arguing about. > It is probably written in this way because it is designed to give efficient generated code on a very wide variety of compilers and options. People use it on all sorts of systems - many years ago, I included Lua in a project on a 16-bit DSP with a limited compiler. Most people can write code that does not need to be so portable - they can rely on having a solid compiler with modern C support, and know that they can use lots of small functions to improve readability, testability and maintainability, and rely on the compiler to tie it all together in optimal output code. But for some types of code, that is not an option, and you have to write code with poorer structure to suit more limited tools. Alternatively, the Lua folks may just be messy coders.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-02-15 02:32 -0800 |
| Message-ID | <88f65c99-1e4f-4944-8be3-46994d3be27d@googlegroups.com> |
| In reply to | #141038 |
On Thursday, 14 February 2019 21:45:57 UTC+2, David Brown wrote: > On 14/02/2019 17:19, Öö Tiib wrote: > > On Thursday, 14 February 2019 17:02:24 UTC+2, Bart wrote: > >> > >> 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. > > > > It is 500-line switch case of executing instructions. > > > > Handling of different instructions is written directly into that switch-case. > > Perhaps pointlessly, that makes it bit long for taste of most programmers > > and also likely less convenient to unit-test. > > > > The different lua instructions can have "argument b" (that the rb > > perhaps means) of different type and so it is declared inside of > > handling of those instructions that have it. > > > > There were no labels a, variables a, structs a and enum a of nested > > scopes hiding each other what you were initially arguing about. > > > > It is probably written in this way because it is designed to give > efficient generated code on a very wide variety of compilers and > options. People use it on all sorts of systems - many years ago, I > included Lua in a project on a 16-bit DSP with a limited compiler. Most > people can write code that does not need to be so portable - they can > rely on having a solid compiler with modern C support, and know that > they can use lots of small functions to improve readability, testability > and maintainability, and rely on the compiler to tie it all together in > optimal output code. But for some types of code, that is not an option, > and you have to write code with poorer structure to suit more limited tools. Yes. Heavy usage of inline-function-like-macros indicates that implementations that do inline badly or not at all were among targets. That is quite understandable, considering that Lua is about quarter of century old language. > Alternatively, the Lua folks may just be messy coders. Quite decent interpreter with clear and simple C API indicate that its authors had not messy mind. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-15 11:51 +0000 |
| Message-ID | <mJx9E.2$296.0@fx10.am4> |
| In reply to | #141070 |
On 15/02/2019 10:32, Öö Tiib wrote:
> On Thursday, 14 February 2019 21:45:57 UTC+2, David Brown wrote:
>> It is probably written in this way because it is designed to give
>> efficient generated code on a very wide variety of compilers and
>> options. People use it on all sorts of systems - many years ago, I
>> included Lua in a project on a 16-bit DSP with a limited compiler. Most
>> people can write code that does not need to be so portable - they can
>> rely on having a solid compiler with modern C support, and know that
>> they can use lots of small functions to improve readability, testability
>> and maintainability, and rely on the compiler to tie it all together in
>> optimal output code. But for some types of code, that is not an option,
>> and you have to write code with poorer structure to suit more limited tools.
>
> Yes. Heavy usage of inline-function-like-macros indicates that
> implementations that do inline badly or not at all were among
> targets. That is quite understandable, considering that Lua is
> about quarter of century old language.
Here's an old version of one of my interpreters as generated C:
https://raw.githubusercontent.com/sal55/qx/master/qq.c [1.4MB]
Out of 37,000 lines, there is just instance of #ifdef/#define:
#ifndef CALLBACK
#define CALLBACK
#endif
and one instance of a block scope declaration (from generated code). No
other macros, inline attributes, nested block scopes, nor 'const'
attributes at all.
Yet if I run this, and Lua, on the same Fibonacci benchmark, I get:
QQ Lua
gcc-O3 6 7 seconds
bcc 11 15 seconds
Not only comparable performance but somewhat better. (QQ is not quite
C90 compatible, needing some C99 features.)
>> Alternatively, the Lua folks may just be messy coders.
>
> Quite decent interpreter with clear and simple C API
> indicate that its authors had not messy mind. ;-)
If you look at LuaJIT sources, then Lua appears a model of clarity.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-14 16:47 +0000 |
| Message-ID | <87o97egvvs.fsf@bsb.me.uk> |
| In reply to | #141016 |
Bart <bc@freeuk.com> writes: > In Lua, one function does actually define 'a' six times (although > buried inside macros). Can you post it (or link)? I don't trust your characterisation of the code. > The same function defines 'rb' 23 times! Not inside a macro. This one I found. It does not mix declarations with statements and none of the scopes overlap, so it's not at all like your example. > On 14/02/2019 14:22, David Brown wrote: >> 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. The one I found does nothing in the least bit confusing. Picking different names would have been daft, and none of the scopes overlap (which seemed to be one thing you considered confusing) and all have the declarations at the top of the block (which I thought was what you were advocating). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 17:18 +0000 |
| Message-ID | <pph9E.1328203$kk4.1039206@fx36.am4> |
| In reply to | #141030 |
On 14/02/2019 16:47, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> In Lua, one function does actually define 'a' six times (although >> buried inside macros). > > Can you post it (or link)? I don't trust your characterisation of the > code. That example is from function luaV_execute() inside lvm.c. The definitions of 'a' are inside macro dojump() which is mostly invoked from macro donextjump() inside that function. You won't see it in the source unless working from a preprocessed code (as I have done in the past), or otherwise trying to debug such code. >> The same function defines 'rb' 23 times! Not inside a macro. > > This one I found. It does not mix declarations with statements and none > of the scopes overlap, so it's not at all like your example. But you don't know that, you have to scan the function to make sure (and this one is over 500 lines). Look at the variable 'ra'; this one /is/ declared at the top of the function and used as needed within the function. Of the 'rb' variables (of which there are 24 in total; 23 reuses), 21 of those are of type TValue*, 3 are of type StkId. So they are even of mixed types! (I would have put rb with ra at the top for TValue* version, and had a different variable name for the StkId versions.) > The one I found does nothing in the least bit confusing. Picking > different names would have been daft, and none of the scopes overlap > (which seemed to be one thing you considered confusing) and all have the > declarations at the top of the block (which I thought was what you were > advocating). No, at the top of a function.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-14 17:48 +0000 |
| Message-ID | <878syigt18.fsf@bsb.me.uk> |
| In reply to | #141032 |
Bart <bc@freeuk.com> writes: > On 14/02/2019 16:47, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> In Lua, one function does actually define 'a' six times (although >>> buried inside macros). >> >> Can you post it (or link)? I don't trust your characterisation of the >> code. > > That example is from function luaV_execute() inside lvm.c. > > The definitions of 'a' are inside macro dojump() which is mostly > invoked from macro donextjump() inside that function. Is a link too much to ask? I found a macro with that name but it appeared not to declare anything. There may be others, of course. > You won't see it in the source unless working from a preprocessed code > (as I have done in the past), or otherwise trying to debug such code. > >>> The same function defines 'rb' 23 times! Not inside a macro. >> >> This one I found. It does not mix declarations with statements and none >> of the scopes overlap, so it's not at all like your example. > > But you don't know that, you have to scan the function to make sure > (and this one is over 500 lines). But I don't care. If the local, block-constrained name shadows a name in an outer scope, I don't care (and neither should anyone). I point out that the scopes don't overlap because that makes it not an example or what I though you were searching for. > Look at the variable 'ra'; this one /is/ declared at the top of the > function and used as needed within the function. > > Of the 'rb' variables (of which there are 24 in total; 23 reuses), 21 > of those are of type TValue*, 3 are of type StkId. So they are even of > mixed types! I'm losing track of what's bothering you (other than it's C code it must be awful). If the scope is small, the type is easy to find. That some other object somewhere else has the same name but some other type seems like something you've decided to worry about. > (I would have put rb with ra at the top for TValue* version, and had a > different variable name for the StkId versions.) I'm fine with that. I don't have to read your code. >> The one I found does nothing in the least bit confusing. Picking >> different names would have been daft, and none of the scopes overlap >> (which seemed to be one thing you considered confusing) and all have the >> declarations at the top of the block (which I thought was what you were >> advocating). > > No, at the top of a function. Ah. Then, yes, there are examples of top-of-a block declarations in code the world over. Did you think David claimed that was rare? I can't imagine that he does. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 19:26 +0000 |
| Message-ID | <Xhj9E.9937$bV5.2301@fx01.am4> |
| In reply to | #141033 |
On 14/02/2019 17:48, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 14/02/2019 16:47, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> In Lua, one function does actually define 'a' six times (although
>>>> buried inside macros).
>>>
>>> Can you post it (or link)? I don't trust your characterisation of the
>>> code.
>>
>> That example is from function luaV_execute() inside lvm.c.
>>
>> The definitions of 'a' are inside macro dojump() which is mostly
>> invoked from macro donextjump() inside that function.
>
> Is a link too much to ask? I found a macro with that name but it
> appeared not to declare anything. There may be others, of course.
Links to Lua are a little elusive to track down, there seem to be
various versions (and then I would have to download and expand some
.tar.gz2 file and check it is the same file, a pita).
But the file I'm talking about is this one:
https://github.com/sal55/qx/blob/master/lvm.c
I don't know if this is sufficient or you need everything else to be
able to apply your tools.
> I'm losing track of what's bothering you (other than it's C code it must
> be awful). If the scope is small, the type is easy to find. That some
> other object somewhere else has the same name but some other type seems
> like something you've decided to worry about.
Within the same function, yes. Not just that they have the same name,
but they COULD.
>> (I would have put rb with ra at the top for TValue* version, and had a
>> different variable name for the StkId versions.)
>
> I'm fine with that. I don't have to read your code.
Well, OK, I don't have to read yours.
However, the author could have decided to declare ra per block too, but
instead put one shared version of it at the top. Presumably that doesn't
bother you?
In that case why don't you like the idea of the same thing being done
with those 21 rb's? (You won't know about the other 3 rb's as they will
have a different name.)
>>> The one I found does nothing in the least bit confusing. Picking
>>> different names would have been daft, and none of the scopes overlap
>>> (which seemed to be one thing you considered confusing) and all have the
>>> declarations at the top of the block (which I thought was what you were
>>> advocating).
>>
>> No, at the top of a function.
>
> Ah. Then, yes, there are examples of top-of-a block declarations in
> code the world over. Did you think David claimed that was rare? I
> can't imagine that he does.
I was pointing out scenarios where block scopes /and/ declarations in
the middle of a block /could/ result in ambiguity and confusion.
But actually reusing names within a function was even more widespread
than I'd thought. Whether it causes confusion or not, the fact that is
is /possible/ means that it can: you see an 'rx' declaration at the top
of a function, then you page down and see a variable 'rx' being used.
Is that the same 'rx' you've just seen at the top? You can't be sure
without closer scrutiny, and even then you can make a mistake (you might
miss the StrId rb from this block if your eye is drawn to the TValue *rb
in the previous one).
It is something that just cannot happen in a different design of
language, so you don't have to consider it. Like, for example, one of
mine (I think Javascript has similar rules).
Given an identifer name 'foo' (since people seem to hate my single
letter ones), here's how C and a different language X might compare:
C X
Max instances of foo per function: Unlimited 1
(ie. in different blocks)
**Shadowing of one foo with another: Yes not possible
Different types per foo: Yes not possible
Parallel use of foo as a tag: Yes not possible
Max instances of foo as a tag: Unlimited not possible
Parallel use of foo as a label: Yes not possible
Number of times you can declare:
'extern T foo;'
in ONE block: Unlimited not possible
Two foos visible in the same block: Yes not possible
(in different halves)
(** shadowing between foos declared in this function. Both languages can
shadow a global foo from outside the function.)
Which language do you think might be easier to read, reason about, port
(to a language that may or may have not C rules), implement, or harder
to inadvertently redeclare a variable?
(I say 'you', but you are hardly typical as you like difficult
languages. I mean a more general 'you'.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-02-14 20:21 +0000 |
| Message-ID | <d5k9E.6$pB1.4@fx28.iad> |
| In reply to | #141035 |
Bart <bc@freeuk.com> writes: >On 14/02/2019 17:48, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 14/02/2019 16:47, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> In Lua, one function does actually define 'a' six times (although >>>>> buried inside macros). >>>> >>>> Can you post it (or link)? I don't trust your characterisation of the >>>> code. >>> >>> That example is from function luaV_execute() inside lvm.c. >>> >>> The definitions of 'a' are inside macro dojump() which is mostly >>> invoked from macro donextjump() inside that function. >> >> Is a link too much to ask? I found a macro with that name but it >> appeared not to declare anything. There may be others, of course. > >Links to Lua are a little elusive to track down, there seem to be https://www.lua.org/source/5.1/lvm.c.html HTH
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-14 21:20 +0000 |
| Message-ID | <87y36if4nv.fsf@bsb.me.uk> |
| In reply to | #141035 |
Bart <bc@freeuk.com> writes:
> On 14/02/2019 17:48, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 14/02/2019 16:47, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> In Lua, one function does actually define 'a' six times (although
>>>>> buried inside macros).
>>>>
>>>> Can you post it (or link)? I don't trust your characterisation of the
>>>> code.
>>>
>>> That example is from function luaV_execute() inside lvm.c.
>>>
>>> The definitions of 'a' are inside macro dojump() which is mostly
>>> invoked from macro donextjump() inside that function.
>>
>> Is a link too much to ask? I found a macro with that name but it
>> appeared not to declare anything. There may be others, of course.
>
> Links to Lua are a little elusive to track down, there seem to be
> various versions (and then I would have to download and expand some
> .tar.gz2 file and check it is the same file, a pita).
>
> But the file I'm talking about is this one:
>
> https://github.com/sal55/qx/blob/master/lvm.c
>
> I don't know if this is sufficient or you need everything else to be
> able to apply your tools.
No, just the relevant source file will do. Thanks. (I could have
downloaded the source, of course, but this is just a Usenet discussion
and that seems like asking your readers to do rather more than you
should expect.)
As I thought that 'a' is in a block. I'm not sure how you think such
things /should/ be done. You can't move the declaration outside and the
block keeps the name "local". The 'a's from the macro won't shadow each
other, and if there is an outer 'a' somewhere the macro is used, the
language ensures the right things happen.
It seems an odd example.
>> I'm losing track of what's bothering you (other than it's C code it must
>> be awful). If the scope is small, the type is easy to find. That some
>> other object somewhere else has the same name but some other type seems
>> like something you've decided to worry about.
>
> Within the same function, yes. Not just that they have the same name,
> but they COULD.
I see no reason to worry since it does not cause a problem, but I can't
stop you worrying about it if you've decided to.
>>> (I would have put rb with ra at the top for TValue* version, and had a
>>> different variable name for the StkId versions.)
>>
>> I'm fine with that. I don't have to read your code.
>
> Well, OK, I don't have to read yours.
You, and the world, are lucky that way! My coding style (when not
constrained by cooperation) appears to be widely disliked.
> However, the author could have decided to declare ra per block too,
> but instead put one shared version of it at the top. Presumably that
> doesn't bother you?
Hmm... Let me go look... No, that seems logical. Every opcode uses ra
so it makes sense to put its declaration, and the code to set it up, in
one place.
> In that case why don't you like the idea of the same thing being done
> with those 21 rb's? (You won't know about the other 3 rb's as they
> will have a different name.)
The same thing can't be done with it. All you can do is move the
declaration. You can't set it up outside of the switch.
>>>> The one I found does nothing in the least bit confusing. Picking
>>>> different names would have been daft, and none of the scopes overlap
>>>> (which seemed to be one thing you considered confusing) and all have the
>>>> declarations at the top of the block (which I thought was what you were
>>>> advocating).
>>>
>>> No, at the top of a function.
>>
>> Ah. Then, yes, there are examples of top-of-a block declarations in
>> code the world over. Did you think David claimed that was rare? I
>> can't imagine that he does.
>
> I was pointing out scenarios where block scopes /and/ declarations in
> the middle of a block /could/ result in ambiguity and confusion.
I thought you were trying to show that the code pattern you originally
posted really did occur in the wild. But in fact you picked these
examples because you think someone might cause that pattern by adding a
mid-code declaration of 'a' into this macro body:
{ int a = GETARG_A(i); \
if (a != 0) luaF_close(L, ci->u.l.base + a - 1); \
ci->u.l.savedpc += GETARG_sBx(i) + e; }
or, similarly, one for 'rb' into this sort of short block:
vmcase(OP_GETTABLE) {
StkId rb = RB(i);
TValue *rc = RKC(i);
gettableProtected(L, rb, rc, ra);
vmbreak;
}
Is that the point of these Lua examples?
> Which language do you think might be easier to read, reason about,
> port (to a language that may or may have not C rules), implement, or
> harder to inadvertently redeclare a variable?
>
> (I say 'you', but you are hardly typical as you like difficult
> languages. I mean a more general 'you'.)
Ah, ok. I don't feel able to answer in this more general sense.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-14 22:24 +0000 |
| Message-ID | <fUl9E.434416$dE1.94443@fx22.am4> |
| In reply to | #141048 |
On 14/02/2019 21:20, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> Is that the point of these Lua examples?
No. I simply ran a program which scanned these projects looking for
functions where the same local variables names occur more than once. I
didn't look at the codebase except to verify some results, or check
whether variables were shadowing each other.
(From what people had been saying, I expected far fewer instances of
name reuse.)
As I said in a post earlier, I mentioned that particular function
because it seemed to define 6 'a's, when David Brown had said no one
would do that, but it also had lots of those 'rb's.
Looking at the luaV_execute function however, I now see that 'ra' isn't
declared right at the top at all, but inside a giant for-loop which
constitutes the function body.
(See how the block-scope scheme caused me to mistake its location? You
have now look at code MUCH more carefully.)
What the advantage is of having 'ra' and 'i' declared just inside the
loop body instead of just outside is not clear.
>> Which language do you think might be easier to read, reason about,
>> port (to a language that may or may have not C rules), implement, or
>> harder to inadvertently redeclare a variable?
>>
>> (I say 'you', but you are hardly typical as you like difficult
>> languages. I mean a more general 'you'.)
>
> Ah, ok. I don't feel able to answer in this more general sense.
Well look at my chart again, and think instead about which language
might be easier to explain when talking about scopes and name spaces
within a function.
That might need one more line:
C X
Name spaces in a function: 3 1
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-15 00:18 +0000 |
| Message-ID | <87sgwpgb0b.fsf@bsb.me.uk> |
| In reply to | #141054 |
Bart <bc@freeuk.com> writes: > On 14/02/2019 21:20, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >> Is that the point of these Lua examples? > > No. I simply ran a program which scanned these projects looking for > functions where the same local variables names occur more than once. I > didn't look at the codebase except to verify some results, or check > whether variables were shadowing each other. How odd. I don't know why you'd do that. > (From what people had been saying, I expected far fewer instances of > name reuse.) Hmm, so much spin there. Who said it? What evidence is there of the rarity or otherwise or re-use? What kinds of re-use were implied by your example? How much of the world's code base did you sample? How was the sample chosen... > As I said in a post earlier, I mentioned that particular function > because it seemed to define 6 'a's, when David Brown had said no one > would do that, but it also had lots of those 'rb's. David is well aware of name re-use in macros. If he ever said that would not occur it would be simply because he'd forgotten about macros. >>> Which language do you think might be easier to read, reason about, >>> port (to a language that may or may have not C rules), implement, or >>> harder to inadvertently redeclare a variable? >>> >>> (I say 'you', but you are hardly typical as you like difficult >>> languages. I mean a more general 'you'.) >> >> Ah, ok. I don't feel able to answer in this more general sense. > > Well look at my chart again, and think instead about which language > might be easier to explain when talking about scopes and name spaces > within a function. > > That might need one more line: > C X > Name spaces in a function: 3 1 Or you could think about what's easier to ignore -- leading questions, closed questions or questions about unspecified languages. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-15 01:29 +0000 |
| Message-ID | <LBo9E.1333151$kk4.1256998@fx36.am4> |
| In reply to | #141057 |
On 15/02/2019 00:18, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 14/02/2019 21:20, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>> Is that the point of these Lua examples? >> >> No. I simply ran a program which scanned these projects looking for >> functions where the same local variables names occur more than once. I >> didn't look at the codebase except to verify some results, or check >> whether variables were shadowing each other. > > How odd. I don't know why you'd do that. I'm sure there has been a discussion more than once about the length of identifiers. If anyone thought single letter names should not be used in real programs, then the results from those half-dozen projects (selected only by my 'bcc' program being able to compile them) would be illuminating. >> (From what people had been saying, I expected far fewer instances of >> name reuse.) > > Hmm, so much spin there. Who said it? What evidence is there of the > rarity or otherwise or re-use? I would have to trawl through ancient discussions when block scopes have come up before. That is too much effort considering that everyone's minds are made up and their opinions won't change. But it is certainly the impression I got; and I still have the impression that people don't expect shadowing (reuse a name while it is still visible from an outer scope) to be that prevalent. What kinds of re-use were implied by > your example? How much of the world's code base did you sample? How > was the sample chosen... See above. I said only Seed7 .c modules eschewed single letter identifiers and name reuse. (Seed7 itself is rather wordy, and I believe it doesn't have block scopes, so that may not be surprising.) >> Well look at my chart again, and think instead about which language >> might be easier to explain when talking about scopes and name spaces >> within a function. > Or you could think about what's easier to ignore -- leading questions, > closed questions or questions about unspecified languages. Actually it wasn't a serious question since the answer is so obvious. Even knowing nothing about X except what is implied by my table, it is easy to see that X's approach is VASTLY simpler to C's: 1 instance of any name in a function; 1 namespace; and ... that's it. And yet such a simple scheme is still perfectly well capable of writing applications, and writing them cleanly. Here's my last sizeable C program written to exactly those guidelines (since it was ported from such a language): https://github.com/sal55/qx/blob/master/bignum.c
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-15 08:14 +0100 |
| Message-ID | <q45osl$ilm$1@dont-email.me> |
| In reply to | #141061 |
On 15/02/2019 02:29, Bart wrote: > On 15/02/2019 00:18, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 14/02/2019 21:20, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>> Is that the point of these Lua examples? >>> >>> No. I simply ran a program which scanned these projects looking for >>> functions where the same local variables names occur more than once. I >>> didn't look at the codebase except to verify some results, or check >>> whether variables were shadowing each other. >> >> How odd. I don't know why you'd do that. > > I'm sure there has been a discussion more than once about the length of > identifiers. If anyone thought single letter names should not be used in > real programs, then the results from those half-dozen projects (selected > only by my 'bcc' program being able to compile them) would be illuminating. > You are tilting at windmills. No one has ever suggested that single-letter identifiers are not used, or are not useful. >>> (From what people had been saying, I expected far fewer instances of >>> name reuse.) >> >> Hmm, so much spin there. Who said it? What evidence is there of the >> rarity or otherwise or re-use? > > I would have to trawl through ancient discussions when block scopes have > come up before. That is too much effort considering that everyone's > minds are made up and their opinions won't change. > > But it is certainly the impression I got; Your impressions are always highly coloured by your prejudice. > and I still have the > impression that people don't expect shadowing (reuse a name while it is > still visible from an outer scope) to be that prevalent. > It isn't very prevalent - at the written source level. As Ben discussed, it happens through the use of macros. But such macros are structurally similar to functions - they do not cause the kind of confusion you have when reading the source code. (But to the compiler, they shadow other identifiers.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-15 07:03 -0500 |
| Message-ID | <q469qu$d7v$1@dont-email.me> |
| In reply to | #141064 |
On 2/15/19 02:14, David Brown wrote:
> On 15/02/2019 02:29, Bart wrote:
...
>> I'm sure there has been a discussion more than once about the length of
>> identifiers. If anyone thought single letter names should not be used in
>> real programs, then the results from those half-dozen projects (selected
>> only by my 'bcc' program being able to compile them) would be illuminating.
>>
>
> You are tilting at windmills. No one has ever suggested that
> single-letter identifiers are not used, or are not useful.
As for the "not useful" part, I might count as a counter-example. When
searching for all uses of a given identifier, I've found there's far too
many false positives when using single-letter identifiers. I set myself
a hard lower limit of three letters for an identifier. I've also found
it very helpful in error checking to use meaningful names rather than
meaningless ones like i, j, k. For instance:
for(eci = 0; eci < 3; eci++)
{
position_eci[eci] = 0.0;
for(ecr = 0; ecr < 3; ecr++)
position_eci[eci] +=
T_ecr2eci[eci][ecr] *
position_ecr[ecr];
}
Each of the arrays listed can only be meaningfully indexed as shown in
that example; position_eci[ecr] would be a blatant error.
position_eci[i] would not be.
I've mentioned my policy of using meaningful identifiers with a length
of at least 3 in previous messages in this forum. That might have
influenced Bart's perceptions.
[toc] | [prev] | [next] | [standalone]
Page 15 of 19 — ← Prev page 1 … 13 14 [15] 16 17 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web