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 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-15 04:42 -0800 |
| Message-ID | <d2ad1f8f-805e-49b0-abb7-f356b616de53@googlegroups.com> |
| In reply to | #141073 |
On Friday, 15 February 2019 12:03:51 UTC, James Kuyper wrote: > > 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: > There's a strong convention that i,j are indices, N is a count, x is an unknown or horizontal co-ordinate, y is the derived value or a vertical co-ordinate. Use of single letter identifiers keeps expression length down.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-02-15 05:26 -0800 |
| Message-ID | <99a15063-b87e-4302-acfe-f03ad8209b5a@googlegroups.com> |
| In reply to | #141074 |
On Friday, 15 February 2019 12:42:26 UTC, Malcolm McLean wrote: > On Friday, 15 February 2019 12:03:51 UTC, James Kuyper wrote: > > > > 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: > > > There's a strong convention that i,j are indices, Possibly for a generation that grew up with Fortran. Whether the current bright young things with Javascript, Haskell and whatever else under their belts adopt that convention, I wouldn't like to say. Even if they are conventionally indexes, it's not necessarily obvious what they are indexing, so I'd probably prefer something like James's convention linking the index names with the array names. > N is a count, I'd prefer "number_of_bananas" (for example) to N, personally. > x is an unknown or horizontal co-ordinate, y is the derived value or a > vertical co-ordinate. The co-ordinates I'd accept, perhaps. Not being of a mathematical or even formal computer science bent, I'd probably again prefer more meaningful names for unknown and derived values, but then I've spent several decades fixing other people's (and my own) code, so have something of a bias toward clear, explicit coding. > Use of single letter identifiers keeps expression length down. And that's necessarily a good thing?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-15 16:37 +0000 |
| Message-ID | <874l95f1nd.fsf@bsb.me.uk> |
| In reply to | #141076 |
mark.bluemel@gmail.com writes: > On Friday, 15 February 2019 12:42:26 UTC, Malcolm McLean wrote: <cut> >> There's a strong convention that i,j are indices, > > Possibly for a generation that grew up with Fortran. Whether the current > bright young things with Javascript, Haskell and whatever else under their > belts adopt that convention, I wouldn't like to say. Even if they are > conventionally indexes, it's not necessarily obvious what they are indexing, > so I'd probably prefer something like James's convention linking the index > names with the array names. i, j, k, m and n are often used as "indexes" in mathematics, hence Fortran's bizarre-to-modern-eyes idea that names starting [i-n] should be integer when not otherwise explicitly typed. >> N is a count, > > I'd prefer "number_of_bananas" (for example) to N, personally. You don't always know it's bananas. If the function is generic, both the index and the count need to be generic. You may still prefer something like 'index' or 'elem_num' over 'i', and 'number_of_elements' over 'n' (I'd never use 'N' unless it was a macro), but I find 'i' and 'n' relatively innocent in a short generic function. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 14:24 -0800 |
| Message-ID | <867edneccd.fsf@mailhub.linuxsc.com> |
| In reply to | #141076 |
mark.bluemel@gmail.com writes: > On Friday, 15 February 2019 12:42:26 UTC, Malcolm McLean wrote: ... >> Use of single letter identifiers keeps expression length down. > > And that's necessarily a good thing? It necessarily offers some benefits. Whether those benefits outweigh the associated costs depends on many factors and on the particular situation: in some it will, in others it won't.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-15 14:07 +0000 |
| Message-ID | <LIz9E.1351500$kk4.733580@fx36.am4> |
| In reply to | #141073 |
On 15/02/2019 12:03, James Kuyper wrote:
> 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.
What about T_ecr2eci[ecr][eci] ?
> I've mentioned my policy of using meaningful identifiers with a length
> of at least 3 in previous messages in this forum.
I see a few problems including the fact that, while 'i' and 'r' differ
by 100%, 'eci' and 'ecr' differ by only 33%. Try:
for(i = 0; i < 3; i++)
{
position_i[i] = 0.0;
for(r = 0; r < 3; r++)
position_i[i] +=
T_r2i[i][r] *
position_r[r];
}
You still have the correspondence between _i and [i], but now you don't
have the common prefix of "ec" on both kinds of arrays and indices that
makes it take marginally longer to grok which is which, and which adds
clutter.
All I can see on the 'T_ecr2eci[eci][ecr]' line is a bunch of 'ec's;
that it is a double index comes a second later.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-15 07:02 -0800 |
| Message-ID | <1c01ec2d-bcbd-4685-aad5-c326f9667f93@googlegroups.com> |
| In reply to | #141081 |
On Friday, February 15, 2019 at 9:07:48 AM UTC-5, Bart wrote:
> On 15/02/2019 12:03, James Kuyper wrote:
...
> > 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.
>
> What about T_ecr2eci[ecr][eci] ?
The naming convention we used for transformation matrices, and my
personal naming convention for array indices, together guarantee that
the only valid way to subscript T_ecr2eci is [eci][ecr]. The naming
convention is arbitrary - it could have been specified the other way -
but the important point is to remain consistent. We used 7 different
coordinate systems in that code (one oriented with the focal plane, one
oriented with the current position of a rotating mirror, one oriented
with the satellite, ECR, ECI, geodetic coordinates with height above
the ellipsoid, and geodetic coordinates with height above the geoid).
Without consistent conventions it would have been nearly impossible to
confirm whether the code was correct. Before I introduced my naming
convention for indices, the code had numerous errors in the way the
arrays were accessed.
If the matrix were symmetrical (which this one isn't), it wouldn't make
any difference - but for precisely that reason, there's no reason not to
subscript it the way that is consistent with the naming convention.
> I see a few problems including the fact that, while 'i' and 'r' differ
> by 100%, 'eci' and 'ecr' differ by only 33%. Try:
Perhaps I should have used the ecr2geo matrix for my example. I find it
a lot easier to search for all occurrences of "eci" than to search for
all occurrences of "i".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-15 17:06 +0100 |
| Message-ID | <q46o2d$2bi$1@dont-email.me> |
| In reply to | #141073 |
On 15/02/2019 13:03, James Kuyper wrote:
> 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];
> }
>
I would find "i" and "r" easier to distinguish than "eci" and "ecr".
But of course that is depend on the programmer, the code, your
IDE/editor, and everything else.
> 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 would be happier if C had strong types, especially strong integer
types, and arrays indexed over specific types (like Pascal has). Then
"position_eci[ecr]" would be a type error, not a merely checked
visually. But it does not have such types or array indexes. And if the
names you have here make it harder to write incorrect code or to spot
incorrect mode, then they sound a good idea in this code.
>
> 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.
>
It's hard to know what forms Bart's impressions. He has a tendency to
latch on to something that was mentioned once - and perhaps
misunderstood (as it was in this case), and declare that this is the
general opinion of the group.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-15 08:10 +0100 |
| Message-ID | <q45olp$hre$1@dont-email.me> |
| In reply to | #141057 |
On 15/02/2019 01: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. > >> (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. > I think what bothers Bart is that he runs C programs through a pre-processor, then examines the output and finds it hard to follow. My objection to Bart's example was a short function with a half-dozen different uses of "a" shadowing each other - and I said people don't do that in their code. The point is that people do not write deliberately confusing code, or re-use the same identifier just because C allows you. Of course the same identifier can end up re-used when it is in a macro. Who cares about that, however? As far as your /programming/ is concerned, the function-like macro that uses the identifier is structurally similar to a function - merely one that is intended to be inlined, even if the compiler isn't smart enough to do so automatically. The identifier is local to the macro, and the fact that this shadows any identifiers of the same name visible in the "calling" function is a clear advantage. (The Lua source, IIRC, makes heavy use of complicated macros. It's not a good modern style, where you would try to use inline functions, but as I mentioned earlier the code is designed with a focus on efficient results on as wide a range of compilers as possible. Not all code focuses on being as legible as it could be.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 21:45 -0800 |
| Message-ID | <868sy3cdbp.fsf@mailhub.linuxsc.com> |
| In reply to | #141048 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: ... > My coding style (when not constrained by cooperation) appears to > be widely disliked. Well that has me curious. Can you say what about your style choices people dislike? Or post a small example (perhaps with commentary)? I'm always interested to learn what people react to.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-26 14:16 +0000 |
| Message-ID | <87imx61vq7.fsf@bsb.me.uk> |
| In reply to | #141388 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> ...
>
>> My coding style (when not constrained by cooperation) appears to
>> be widely disliked.
(I was talking about C, of course)
> Well that has me curious. Can you say what about your style
> choices people dislike? Or post a small example (perhaps
> with commentary)? I'm always interested to learn what
> people react to.
I've probably forgotten many, but
(a) I like using multiple declarators in one declaration to collect
related objects:
double dest[SIZE], *dp = dest, *ep = (&dest)[1];
(b) I don't mind using slightly obscure parts of the language if it
seems right, like using (&dest)[1] above to avoid duplicating the
use of SIZE.
(c) I don't like unnecessary {}s. I remove them when I find a compound
statement has only one statement in it, and I put them back if
editing adds more:
void selection_sort(int n, T A[])
{
for (int i = 0; i < n - 1; i++) {
int min = i;
for (int j = i + 1; j < n; j++)
if (less_than(A[j], A[min]))
min = j;
swap(&A[i], &A[min]);
}
}
(I'd /like/ to be able to do this for function bodies too! The
function above has only one statement in the body, but I am forced
to write it in {}s. I think this last point comes from taking too
much BCPL in my youth.)
(d) Ditto ()s in expressions. I don't always use minimal bracketing,
but some extra ()s annoy me. && binding more tightly than || seems
so natural to me that I don't like reminding myself with extra ()s.
(e) I have no qualms about some side-effects in expressions. Not sure
exactly which are OK with me and which not, but the odd
while ((c = *ptr++) != target) ...
is certainly fine in my book.
(I'd prefer every statement to be an expression with a value, though
there will be some cases where that value is of type 'void'. That's
probably from taking too much Algol 68 in my youth.)
As I say, there are probably loads more. The point is that pretty much
every one of these has been met with opprobrium here at some time or
other. Nothing wrong with that of course.
I'm ignoring formatting and layout issues which, quite rightly, is less
frequently commented on.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-26 15:04 +0000 |
| Message-ID | <877edm1tgr.fsf@bsb.me.uk> |
| In reply to | #141430 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> double dest[SIZE], *dp = dest, *ep = (&dest)[1]; >>(b) I don't mind using slightly obscure parts of the language if it >> seems right, like using (&dest)[1] above to avoid duplicating the >> use of SIZE. > > Yeah, show it to those poor chaps! (aka maintenance > programmers). Hmm... Who are these mystery programmers who can't or won't take a moment to understand code like that? >>(e) I have no qualms about some side-effects in expressions. > > printf( "hello, world" ) > > is an expression whose evaluation has an effect. We would > not get very far without those. Heck, /everything/ C gets > done is via the effect of the evaluation of an expression, > except for the empty statement which can do the NOP effect > without any expression. > > Maybe you meant side-effects in subexpressions. No, I meant what I said. For example while (c = *cp++) ... has a side effect at the top-level of the expression (as well as in a sub-expression). I'd simply hoped that people would not bother to comment on those side-effects in expressions that no one has any qualms about. They can't really be considered interesting in this context. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-26 15:26 +0000 |
| Message-ID | <2VcdE.442$t1l.423@fx15.am4> |
| In reply to | #141430 |
On 26/02/2019 14:16, Ben Bacarisse wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Well that has me curious. Can you say what about your style
>> choices people dislike? Or post a small example (perhaps
>> with commentary)? I'm always interested to learn what
>> people react to.
>
> I've probably forgotten many, but
>
> (a) I like using multiple declarators in one declaration to collect
> related objects:
>
> double dest[SIZE], *dp = dest, *ep = (&dest)[1];
It took me a while to figure it out:
ep has type 'pointer to double'.
&dest has type 'pointer to array 10 of double' (when SIZE is 10).
(&dest)[1] has type 'pointer to double'
It works because (&dest)[1] attempts to access the next double[10] array
that would follow dest, but which doesn't actually exist. Fortunately
that array 'decays' to a pointer to its first element, which coincides
with a pointer to the element following the last actual element of dest.
However, it is worth it to avoid having to write '&dest[SIZE]', which is
one character longer ...
> (c) I don't like unnecessary {}s. I remove them when I find a compound
> statement has only one statement in it, and I put them back if
> editing adds more:
>
> void selection_sort(int n, T A[])
> {
> for (int i = 0; i < n - 1; i++) {
> int min = i;
> for (int j = i + 1; j < n; j++)
> if (less_than(A[j], A[min]))
> min = j;
> swap(&A[i], &A[min]);
> }
> }
You must spend half your time inserting or removing braces as your code
evolves. (And, if it was me, spending a considerable amount of time
sorting out the problems caused by inadvertently inserting statements
you thought were inside a block, and look properly indented, but are
actually outside because there are no braces.)
> (I'd /like/ to be able to do this for function bodies too! The
> function above has only one statement in the body, but I am forced
> to write it in {}s. I think this last point comes from taking too
> much BCPL in my youth.)
I tried it on my compiler; it seemed to work with the following fragment
but I haven't tried anything more complex:
int itemcheck(treenode* tree)
if (tree->left==NULL)
return tree->item;
else
return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
treenode* bottomuptree(int item, int depth)
if (depth>0)
return newtreenode(bottomuptree(2*item-1,depth-1),
bottomuptree(2*item,depth-1),item);
else
return newtreenode(NULL,NULL,item);
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-26 12:06 -0800 |
| Message-ID | <lna7iinwkq.fsf@kst-u.example.com> |
| In reply to | #141436 |
Bart <bc@freeuk.com> writes:
[...]
> I tried it on my compiler; it seemed to work with the following fragment
> but I haven't tried anything more complex:
>
> int itemcheck(treenode* tree)
> if (tree->left==NULL)
> return tree->item;
> else
> return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
[...]
Assuming that your compiler is intended to be a C compiler, accepting
that code indicates that it has a bug. (Or that it's an extension, but
it's still a syntax error that must be diagnosed in your compiler's
conforming mode, if it has one.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-26 21:05 +0000 |
| Message-ID | <5ShdE.17803$Li2.7732@fx39.am4> |
| In reply to | #141461 |
On 26/02/2019 20:06, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I tried it on my compiler; it seemed to work with the following fragment
>> but I haven't tried anything more complex:
>>
>> int itemcheck(treenode* tree)
>> if (tree->left==NULL)
>> return tree->item;
>> else
>> return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
> [...]
>
> Assuming that your compiler is intended to be a C compiler, accepting
> that code indicates that it has a bug. (Or that it's an extension, but
> it's still a syntax error that must be diagnosed in your compiler's
> conforming mode, if it has one.)
>
No, I modified it to be able to accept such code, to see if it was possible.
It seems to be, assuming a function header can only be followed by
either "{" or ";" (some compilers allow attributes at that point, which
might be taken care of during preprocessing).
But:
- A single empty statement consisting of only ";" is not possible
- A single declaration statement is not possible (I think there is the
same restriction for branches of if/else/etc if not using braces)
Probably there are other issues.
However I always use braces anyway for everything, including manually
written and generated C code, so it's not a 'keeper'.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-26 13:55 -0800 |
| Message-ID | <ln5zt6nrjm.fsf@kst-u.example.com> |
| In reply to | #141463 |
Bart <bc@freeuk.com> writes:
> On 26/02/2019 20:06, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> I tried it on my compiler; it seemed to work with the following fragment
>>> but I haven't tried anything more complex:
>>>
>>> int itemcheck(treenode* tree)
>>> if (tree->left==NULL)
>>> return tree->item;
>>> else
>>> return tree->item+itemcheck(tree->left)-itemcheck(tree->right);
>> [...]
>>
>> Assuming that your compiler is intended to be a C compiler, accepting
>> that code indicates that it has a bug. (Or that it's an extension, but
>> it's still a syntax error that must be diagnosed in your compiler's
>> conforming mode, if it has one.)
>
> No, I modified it to be able to accept such code, to see if it was possible.
Fine, I have no problem at all with that. My point is that your
modification makes your compiler non-conforming. (I didn't realize
that you had made a temporary modification just for this purpose.)
> It seems to be, assuming a function header can only be followed by
> either "{" or ";" (some compilers allow attributes at that point, which
> might be taken care of during preprocessing).
The syntax of a function-definition is:
function-definition:
declaration-specifiers declarator declaration-list[opt] compound-statement
where a compound-statement begins with a "{" and ends with a "}".
If the grammar had "statement" rather than "compound-statement",
then a function definition like the one above would be permitted
-- and as far as I can tell, it wouldn't break any existing code.
It's just not, in my opinion, worth making such a change.
> But:
>
> - A single empty statement consisting of only ";" is not possible
Yes, that would have to be disambiguated by treating it as a function
declaration, not a function definition with a null statement.
> - A single declaration statement is not possible (I think there is the
> same restriction for branches of if/else/etc if not using braces)
Because a single declaration is not a statement. (It is in C++.)
> Probably there are other issues.
>
> However I always use braces anyway for everything, including manually
> written and generated C code, so it's not a 'keeper'.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-02-27 06:41 -0500 |
| Message-ID | <THudE.19101$Rr2.15870@fx46.iad> |
| In reply to | #141436 |
On 2/26/19 10:26 AM, Bart wrote: > On 26/02/2019 14:16, Ben Bacarisse wrote: >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >>> Well that has me curious. Can you say what about your style >>> choices people dislike? Or post a small example (perhaps >>> with commentary)? I'm always interested to learn what >>> people react to. >> >> I've probably forgotten many, but >> >> (a) I like using multiple declarators in one declaration to collect >> related objects: >> >> double dest[SIZE], *dp = dest, *ep = (&dest)[1]; > > It took me a while to figure it out: > > ep has type 'pointer to double'. > > &dest has type 'pointer to array 10 of double' (when SIZE is 10). > > (&dest)[1] has type 'pointer to double' > > It works because (&dest)[1] attempts to access the next double[10] array > that would follow dest, but which doesn't actually exist. Fortunately > that array 'decays' to a pointer to its first element, which coincides > with a pointer to the element following the last actual element of dest. > > However, it is worth it to avoid having to write '&dest[SIZE]', which is > one character longer ... > Maybe I have been programming C too long, but the expression (&array)[1] is to me the idiomatic way to express the 'one pass end of array' pointer without having to specify (at that location) the length of the array. Of course, idiomatic doesn't mean clear to people who don't know the idiom.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-27 12:33 +0000 |
| Message-ID | <usvdE.79493$DD3.38968@fx29.am4> |
| In reply to | #141475 |
On 27/02/2019 11:41, Richard Damon wrote:
> On 2/26/19 10:26 AM, Bart wrote:
>> It took me a while to figure it out:
>>
>> ep has type 'pointer to double'.
>>
>> &dest has type 'pointer to array 10 of double' (when SIZE is 10).
>>
>> (&dest)[1] has type 'pointer to double'
>>
>> It works because (&dest)[1] attempts to access the next double[10] array
>> that would follow dest, but which doesn't actually exist. Fortunately
>> that array 'decays' to a pointer to its first element, which coincides
>> with a pointer to the element following the last actual element of dest.
>>
>> However, it is worth it to avoid having to write '&dest[SIZE]', which is
>> one character longer ...
>>
>
> Maybe I have been programming C too long, but the expression (&array)[1]
> is to me the idiomatic way to express the 'one pass end of array'
> pointer without having to specify (at that location) the length of the
> array.
>
> Of course, idiomatic doesn't mean clear to people who don't know the idiom.
I normally use another language, and tend to use the idioms from that
one even when writing C. Which IMV are more obvious. So what is
(&dest)[1] above I would write (in the other language):
&dest[dest.len+1] # (1-based default array)
or better, since lower bounds need not be 1:
&dest[dest.upb+1]
However, when no one's looking I might use a gimmick like this:
&dest[$+1]
where $ in an index expression means the upper bound of the array.
I think I would have some difficulty in expressing the C version, since
it's not possible to index pointers, and array expressions yield actual
arrays, not pointers. It appears to be something like:
&(&a+1)^[1]
where the '1' means the first element of that second array. But
something that involves that much head-scratching, I would never write.
According to Ben, even the C version wouldn't be that popular.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-02-27 08:18 -0500 |
| Message-ID | <c6wdE.94100$ne2.45106@fx11.iad> |
| In reply to | #141476 |
On 2/27/19 7:33 AM, Bart wrote: > On 27/02/2019 11:41, Richard Damon wrote: >> On 2/26/19 10:26 AM, Bart wrote: > >>> It took me a while to figure it out: >>> >>> ep has type 'pointer to double'. >>> >>> &dest has type 'pointer to array 10 of double' (when SIZE is 10). >>> >>> (&dest)[1] has type 'pointer to double' >>> >>> It works because (&dest)[1] attempts to access the next double[10] array >>> that would follow dest, but which doesn't actually exist. Fortunately >>> that array 'decays' to a pointer to its first element, which coincides >>> with a pointer to the element following the last actual element of dest. >>> >>> However, it is worth it to avoid having to write '&dest[SIZE]', which is >>> one character longer ... >>> >> >> Maybe I have been programming C too long, but the expression (&array)[1] >> is to me the idiomatic way to express the 'one pass end of array' >> pointer without having to specify (at that location) the length of the >> array. >> >> Of course, idiomatic doesn't mean clear to people who don't know the >> idiom. > > > I normally use another language, and tend to use the idioms from that > one even when writing C. Which IMV are more obvious. So what is > (&dest)[1] above I would write (in the other language): > > &dest[dest.len+1] # (1-based default array) > > or better, since lower bounds need not be 1: > > &dest[dest.upb+1] > > However, when no one's looking I might use a gimmick like this: > > &dest[$+1] > > where $ in an index expression means the upper bound of the array. > > I think I would have some difficulty in expressing the C version, since > it's not possible to index pointers, and array expressions yield actual > arrays, not pointers. It appears to be something like: > > &(&a+1)^[1] > > where the '1' means the first element of that second array. But > something that involves that much head-scratching, I would never write. > > According to Ben, even the C version wouldn't be that popular. But of course, French idioms mean little in English (unless we have already stolen them). AFAICT none of your idiomatic expression are proper for C, so aren't going to appear in C code. Code written by experienced coders, intended to be maintained by experienced coders, will typically, and in my opinion properly so, use the common idioms for the language, and should avoid overly complicated non-idiomatic ways of doing things, as that lowers the comprehensibility of the code. Someone who doesn't understand those idioms will be at a disadvantage in trying to understand the code, but that would be expected, they aren't the target audience for it. Of course there always is the issue that different sub-cultures will develop somewhat different idiom, so if dealing with code from a different sub-culture of the language, will require learning some new idioms, which is to be expected. A bit like an American going to England, he may speak the 'same' language, but shouldn't be surprised that some things are unfamiliar (like cars on the 'wrong' side of the road). They should adapt, and not try to insist that the country just needs to change to be like his home.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-27 14:02 +0000 |
| Message-ID | <iMwdE.12184$Dv1.10377@fx05.am4> |
| In reply to | #141479 |
On 27/02/2019 13:18, Richard Damon wrote:
> On 2/27/19 7:33 AM, Bart wrote:
>> I normally use another language, and tend to use the idioms from that
>> one even when writing C. Which IMV are more obvious. So what is
>> (&dest)[1] above I would write (in the other language):
>> &dest[dest.upb+1]
>> According to Ben, even the C version wouldn't be that popular.
>
> But of course, French idioms mean little in English (unless we have
> already stolen them). AFAICT none of your idiomatic expression are
> proper for C, so aren't going to appear in C code.
But in either language you would avoid obscure idioms that most people
would have difficulty with, if you wanted to be understood.
In English, you'd express that pointer value as something like: "address
of the (N+1)th element of D' (where D is dest and N is SIZE). In pseudo
code:
&D[N+1]
This happens to be /exactly/ what I can write in my language (when
arrays are 1-based, as things usually are in real life, and ignoring
Ben's restriction on not repeating the named bound of the array).
The nearest C version would be:
&D[N]
to allow for 0-based arrays, but which then makes it even shorter than
mine, and makes it harder to see the case for writing:
(&D)[1]
instead, even if N was a considerably longer name.
> Code written by experienced coders, intended to be maintained by
> experienced coders, will typically, and in my opinion properly so, use
> the common idioms for the language, and should avoid overly complicated
> non-idiomatic ways of doing things, as that lowers the comprehensibility
> of the code. Someone who doesn't understand those idioms will be at a
> disadvantage in trying to understand the code, but that would be
> expected, they aren't the target audience for it.
That's where we differ. I tend to write my for a wider audience (even if
it doesn't actually exist). Including my future self. It also makes it
MUCH easier to port anywhere else if there is no reliance on highly
language-specific behaviour as is the case with (&D)[1].
C /can/ be used to write clear code, and that's what I strive to do.
Although there are some obstacles; I don't fancy writing:
&D[sizeof(D)/sizeof(D[0])
and it seems to be bad form to depend on private macros such as:
#define LEN(a) (sizeof(a)/sizeof(a[0]))
&D[LEN(D)]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-26 21:18 -0500 |
| Message-ID | <q54s1a$7fd$1@dont-email.me> |
| In reply to | #141430 |
On 2/26/19 09:16, Ben Bacarisse wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
...
>>> My coding style (when not constrained by cooperation) appears to
>>> be widely disliked.
>
> (I was talking about C, of course)
>
>> Well that has me curious. Can you say what about your style
>> choices people dislike? Or post a small example (perhaps
>> with commentary)? I'm always interested to learn what
>> people react to.
>
> I've probably forgotten many, but
>
> (a) I like using multiple declarators in one declaration to collect
> related objects:
>
> double dest[SIZE], *dp = dest, *ep = (&dest)[1];
>
> (b) I don't mind using slightly obscure parts of the language if it
> seems right, like using (&dest)[1] above to avoid duplicating the
> use of SIZE.
>
> (c) I don't like unnecessary {}s. I remove them when I find a compound
> statement has only one statement in it, and I put them back if
> editing adds more:
>
> void selection_sort(int n, T A[])
> {
> for (int i = 0; i < n - 1; i++) {
> int min = i;
> for (int j = i + 1; j < n; j++)
> if (less_than(A[j], A[min]))
> min = j;
> swap(&A[i], &A[min]);
> }
> }
>
> (I'd /like/ to be able to do this for function bodies too! The
> function above has only one statement in the body, but I am forced
> to write it in {}s. I think this last point comes from taking too
> much BCPL in my youth.)
>
> (d) Ditto ()s in expressions. I don't always use minimal bracketing,
> but some extra ()s annoy me. && binding more tightly than || seems
> so natural to me that I don't like reminding myself with extra ()s.
I could say the same about my preferences.
> (e) I have no qualms about some side-effects in expressions. Not sure
This, however, confuses me. Are there people who object to side-effects
in expressions? I suspect that the kind of code that they object to
requires additional description, because assignment expressions have
side-effects, and I can't imagine anyone objecting to the use of
assignment expressions.
> exactly which are OK with me and which not, but the odd
>
> while ((c = *ptr++) != target) ...
>
> is certainly fine in my book.
>
> (I'd prefer every statement to be an expression with a value, though
By definition, in a statement that is an expression with a value, that
expression is evaluated as a void expression, meaning that its value is
discarded, unused. It therefore seems an odd thing to even care about
whether or not a statement qualifies as such.
On the flip side, the types of statements that don't have a value
include labeled statements, compound statements, null statements,
selection statements, iteration statements, and jump statements. That
being the case, I have a hard time imagining how a preference for
statements with a value over statements without a value would work.
I strongly suspect that your description of the thing you prefer is
incomplete.
[toc] | [prev] | [next] | [standalone]
Page 16 of 19 — ← Prev page 1 … 14 15 [16] 17 18 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web