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 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-10 13:14 -0800 |
| Message-ID | <2184de8c-519a-4048-b0a9-d52ee34c49b4@googlegroups.com> |
| In reply to | #140837 |
On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > A compiler turns some strings into executables and rejects others. So > > it has grammar rules, in the first sense. What's confusing you is that > > in basic computer science class rules for composing strings like "aab > > aaaabaabaaaaab" are described as "grammars". The strings have a form, > > but don't mean anything. So the so-called "grammar" actually lacks an > > essential attribute of grammar. Then it's not sufficient, it needs > > extra higher level rules if it is to specify a real programming language. > [...] > > No, what's confusing *you* is that, in the context of programming > languages, the word "grammar" is used to refer to *syntax*, in the > sense defined, for example, in Annex A of the C standard. > > A.1 is titled "Lexical grammar". A.2 is titled "Phase structure > grammar". > > Rules defining constraints and semantics are not referred to as > "grammar" rules. I understand that the word "grammar" might be > appropriate by analogy with the way we talk about, for example, > English grammar, but that's not the way the word is typically used > for programming languages. > > You insist on using the word "grammar" in a much wider sense, > and you refuse to acknowledge that any other use of the word could > be correct. > > I don't expect you to acknowledge the possibility that you might > be wrong. > You insisted on rejecting the use of the word "grammatical" in a slightly wider sense.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-10 13:59 -0800 |
| Message-ID | <lnr2cfs3s4.fsf@kst-u.example.com> |
| In reply to | #140839 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote:
[...]
>> I don't expect you to acknowledge the possibility that you might
>> be wrong.
>>
> You insisted on rejecting the use of the word "grammatical" in a
> slightly wider sense.
As I expected.
--
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-10 17:50 -0500 |
| Message-ID | <vU18E.366305$P55.291369@fx39.iad> |
| In reply to | #140839 |
On 2/10/19 4:14 PM, Malcolm McLean wrote: > On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> [...] >>> A compiler turns some strings into executables and rejects others. So >>> it has grammar rules, in the first sense. What's confusing you is that >>> in basic computer science class rules for composing strings like "aab >>> aaaabaabaaaaab" are described as "grammars". The strings have a form, >>> but don't mean anything. So the so-called "grammar" actually lacks an >>> essential attribute of grammar. Then it's not sufficient, it needs >>> extra higher level rules if it is to specify a real programming language. >> [...] >> >> No, what's confusing *you* is that, in the context of programming >> languages, the word "grammar" is used to refer to *syntax*, in the >> sense defined, for example, in Annex A of the C standard. >> >> A.1 is titled "Lexical grammar". A.2 is titled "Phase structure >> grammar". >> >> Rules defining constraints and semantics are not referred to as >> "grammar" rules. I understand that the word "grammar" might be >> appropriate by analogy with the way we talk about, for example, >> English grammar, but that's not the way the word is typically used >> for programming languages. >> >> You insist on using the word "grammar" in a much wider sense, >> and you refuse to acknowledge that any other use of the word could >> be correct. >> >> I don't expect you to acknowledge the possibility that you might >> be wrong. >> > You insisted on rejecting the use of the word "grammatical" in a > slightly wider sense. > When discussing things in a community, especially a technical one, it is normal to use the definitions, when they exist, of specialized terms that the particular community uses. To insist on using some other definition (without qualifying it when used to make it clear that you are using something out of community) is at best rude, or possibly a sign that the person is intentionally trying to cause problems or being deceitful. This is a technical C user community, terms used in the Standards that define the language, should generally be used in the way the Standards use them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 15:17 -0800 |
| Message-ID | <86y363cvaf.fsf@mailhub.linuxsc.com> |
| In reply to | #140843 |
Richard Damon <Richard@Damon-Family.org> writes: > On 2/10/19 4:14 PM, Malcolm McLean wrote: > >> On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote: >> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> [...] >>> >>>> A compiler turns some strings into executables and rejects others. So >>>> it has grammar rules, in the first sense. What's confusing you is that >>>> in basic computer science class rules for composing strings like "aab >>>> aaaabaabaaaaab" are described as "grammars". The strings have a form, >>>> but don't mean anything. So the so-called "grammar" actually lacks an >>>> essential attribute of grammar. Then it's not sufficient, it needs >>>> extra higher level rules if it is to specify a real programming language. >>> >>> [...] >>> >>> No, what's confusing *you* is that, in the context of programming >>> languages, the word "grammar" is used to refer to *syntax*, in the >>> sense defined, for example, in Annex A of the C standard. >>> >>> A.1 is titled "Lexical grammar". A.2 is titled "Phase structure >>> grammar". >>> >>> Rules defining constraints and semantics are not referred to as >>> "grammar" rules. I understand that the word "grammar" might be >>> appropriate by analogy with the way we talk about, for example, >>> English grammar, but that's not the way the word is typically used >>> for programming languages. >>> >>> You insist on using the word "grammar" in a much wider sense, >>> and you refuse to acknowledge that any other use of the word could >>> be correct. >>> >>> I don't expect you to acknowledge the possibility that you might >>> be wrong. >> >> You insisted on rejecting the use of the word "grammatical" in a >> slightly wider sense. > > When discussing things in a community, especially a technical one, it is > normal to use the definitions, when they exist, of specialized terms > that the particular community uses. To insist on using some other > definition (without qualifying it when used to make it clear that you > are using something out of community) is at best rude, or possibly a > sign that the person is intentionally trying to cause problems or being > deceitful. > > This is a technical C user community, terms used in the Standards that > define the language, should generally be used in the way the Standards > use them. Malcolm would have us believe that if a sentence is grammatical it is necessarily sensical. That isn't right. It isn't right in Computer Science, and it isn't right in Linguistics either. The Chomsky sentence "Colorless green ideas sleep furiously" provides the famous counter-example: grammatical, but not sensical.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-02-25 17:38 -0700 |
| Message-ID | <1bh8crz8n1.fsf@pfeifferfamily.net> |
| In reply to | #141374 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 2/10/19 4:14 PM, Malcolm McLean wrote: >> >>> On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote: >>> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> [...] >>>> >>>>> A compiler turns some strings into executables and rejects others. So >>>>> it has grammar rules, in the first sense. What's confusing you is that >>>>> in basic computer science class rules for composing strings like "aab >>>>> aaaabaabaaaaab" are described as "grammars". The strings have a form, >>>>> but don't mean anything. So the so-called "grammar" actually lacks an >>>>> essential attribute of grammar. Then it's not sufficient, it needs >>>>> extra higher level rules if it is to specify a real programming language. >>>> >>>> [...] >>>> >>>> No, what's confusing *you* is that, in the context of programming >>>> languages, the word "grammar" is used to refer to *syntax*, in the >>>> sense defined, for example, in Annex A of the C standard. >>>> >>>> A.1 is titled "Lexical grammar". A.2 is titled "Phase structure >>>> grammar". >>>> >>>> Rules defining constraints and semantics are not referred to as >>>> "grammar" rules. I understand that the word "grammar" might be >>>> appropriate by analogy with the way we talk about, for example, >>>> English grammar, but that's not the way the word is typically used >>>> for programming languages. >>>> >>>> You insist on using the word "grammar" in a much wider sense, >>>> and you refuse to acknowledge that any other use of the word could >>>> be correct. >>>> >>>> I don't expect you to acknowledge the possibility that you might >>>> be wrong. >>> >>> You insisted on rejecting the use of the word "grammatical" in a >>> slightly wider sense. >> >> When discussing things in a community, especially a technical one, it is >> normal to use the definitions, when they exist, of specialized terms >> that the particular community uses. To insist on using some other >> definition (without qualifying it when used to make it clear that you >> are using something out of community) is at best rude, or possibly a >> sign that the person is intentionally trying to cause problems or being >> deceitful. >> >> This is a technical C user community, terms used in the Standards that >> define the language, should generally be used in the way the Standards >> use them. > > Malcolm would have us believe that if a sentence is grammatical > it is necessarily sensical. That isn't right. It isn't right > in Computer Science, and it isn't right in Linguistics either. > The Chomsky sentence "Colorless green ideas sleep furiously" > provides the famous counter-example: grammatical, but not > sensical. If I understand him correctly (a big if) he's working the other way around: if a sentence is not sensible, then he regards it as not grammatical (regardless of whether it can be generated by applying productions in the grammar).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 21:40 -0800 |
| Message-ID | <86d0nfcdk7.fsf@mailhub.linuxsc.com> |
| In reply to | #141383 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 2/10/19 4:14 PM, Malcolm McLean wrote:
>>>
>>>> On Sunday, 10 February 2019 20:43:41 UTC, Keith Thompson wrote:
>>>>
>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>> [...]
>>>>>
>>>>>> A compiler turns some strings into executables and rejects others. So
>>>>>> it has grammar rules, in the first sense. What's confusing you is that
>>>>>> in basic computer science class rules for composing strings like "aab
>>>>>> aaaabaabaaaaab" are described as "grammars". The strings have a form,
>>>>>> but don't mean anything. So the so-called "grammar" actually lacks an
>>>>>> essential attribute of grammar. Then it's not sufficient, it needs
>>>>>> extra higher level rules if it is to specify a real programming language.
>>>>>
>>>>> [...]
>>>>>
>>>>> No, what's confusing *you* is that, in the context of programming
>>>>> languages, the word "grammar" is used to refer to *syntax*, in the
>>>>> sense defined, for example, in Annex A of the C standard.
>>>>>
>>>>> A.1 is titled "Lexical grammar". A.2 is titled "Phase structure
>>>>> grammar".
>>>>>
>>>>> Rules defining constraints and semantics are not referred to as
>>>>> "grammar" rules. I understand that the word "grammar" might be
>>>>> appropriate by analogy with the way we talk about, for example,
>>>>> English grammar, but that's not the way the word is typically used
>>>>> for programming languages.
>>>>>
>>>>> You insist on using the word "grammar" in a much wider sense,
>>>>> and you refuse to acknowledge that any other use of the word could
>>>>> be correct.
>>>>>
>>>>> I don't expect you to acknowledge the possibility that you might
>>>>> be wrong.
>>>>
>>>> You insisted on rejecting the use of the word "grammatical" in a
>>>> slightly wider sense.
>>>
>>> When discussing things in a community, especially a technical one, it is
>>> normal to use the definitions, when they exist, of specialized terms
>>> that the particular community uses. To insist on using some other
>>> definition (without qualifying it when used to make it clear that you
>>> are using something out of community) is at best rude, or possibly a
>>> sign that the person is intentionally trying to cause problems or being
>>> deceitful.
>>>
>>> This is a technical C user community, terms used in the Standards that
>>> define the language, should generally be used in the way the Standards
>>> use them.
>>
>> Malcolm would have us believe that if a sentence is grammatical
>> it is necessarily sensical. That isn't right. It isn't right
>> in Computer Science, and it isn't right in Linguistics either.
>> The Chomsky sentence "Colorless green ideas sleep furiously"
>> provides the famous counter-example: grammatical, but not
>> sensical.
>
> If I understand him correctly (a big if) he's working the other way
> around: if a sentence is not sensible, then he regards it as not
> grammatical (regardless of whether it can be generated by applying
> productions in the grammar).
Yes, I got that. The Chomsky example sentence is squarely on
point because Chomsky identified it as grammatically correct
even though semantically nonsensical. Given Chomsky's stature
in the field of Linguistics, I think I'm on pretty solid ground
citing his example and also the man himself as an authority.
For those who are interested here is a Wikipedia reference:
https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-26 01:37 -0800 |
| Message-ID | <ce7e9f51-e69e-4ae4-9ab9-ae317172f611@googlegroups.com> |
| In reply to | #141374 |
On Monday, 25 February 2019 23:17:52 UTC, Tim Rentsch wrote: > > Malcolm would have us believe that if a sentence is grammatical > it is necessarily sensical. That isn't right. It isn't right > in Computer Science, and it isn't right in Linguistics either. > The Chomsky sentence "Colorless green ideas sleep furiously" > provides the famous counter-example: grammatical, but not > sensical. > But there's also this famous sentence Time flies like an arrow, fruit flies like a banana. Which shows that in fact English speakers parse to make sense. You could parse "Time flies like an arrow" as "measure the flight of flies as you would that of an arrow", but no-one does so.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-02-11 20:24 -0700 |
| Message-ID | <1bef8dd6yy.fsf@pfeifferfamily.net> |
| In reply to | #140826 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> > A compiler turns some strings into executables and rejects others. So > it has grammar rules, in the first sense. What's confusing you is that > in basic computer science class rules for composing strings like "aab > aaaabaabaaaaab" are described as "grammars". The strings have a form, > but don't mean anything. So the so-called "grammar" actually lacks an > essential attribute of grammar. Then it's not sufficient, it needs > extra higher level rules if it is to specify a real programming language. Please, please tell me you don't teach formal language theory.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 10:41 -0800 |
| Message-ID | <lny36rtpa6.fsf@kst-u.example.com> |
| In reply to | #140626 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> No, a program with UB is not "grammatical". The C grammar breaks down
> and fails to describe the behaviour.
That's not what "grammar" means.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 14:47 +0100 |
| Message-ID | <q3eoh7$dr9$1@dont-email.me> |
| In reply to | #140614 |
On 06/02/2019 13:44, Malcolm McLean wrote: > On Wednesday, 6 February 2019 12:36:31 UTC, David Brown wrote: >> On 06/02/2019 12:42, Malcolm McLean wrote: >>> On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: >>>> >>>> So what you meant to say is that any program that is correct in C with >>>> "const", will remain correct when "const" is removed entirely? >>>> >>>> Adding "const" to a correct C program is unlikely to result in a correct >>>> program - you don't get to count "restoring the const you took away" as >>>> adding "const". >>>> >>> "Correct" means "with correct behaviour". It assumes "grammatical". >>> >> >> Yes - so what? >> >> Adding "const" to a correct C program is unlikely to result in a correct >> program - one that will compile and do the same job as before. Keith >> gave a simple example. Do you agree with that? (Please answer yes or >> no, rather than posting more pointless tangents.) >> >> You said that in C (but not C++) adding "const" qualifiers to a correct >> program does not make it incorrect. Again, answer yes or no - >> remembering that your post was made in public. >> > Take these 3 sentences > 1) "Water is an element" > 2) "Water is composed of hydrogen and oxygen" > 3) "Composed hydrogen water oxygen" > > 1) is incorrect. 2) is correct. 3) is neither correct not incorrect. It's > not grammatical English, it can't communicate false or true information > at all. > > Now adding const to a program cannot make it incorrect. It can make > it non-grammatical (uncompileable). Then the program is neither correct > nor incorrect, it can't have any behaviour. > So pointless tangents and nonsense, as expected. Why do you feel such a need for silly arguments here? Your first post had a point - in C, but not in C++, you can remove all the "const" qualifiers without causing a change in functionality or breaking a working program. You incorrectly said you could safely (in the same sense) /add/ "const" to C programs - this is clearly incorrect. Stop digging a hole and making yourself look ridiculous, and say "Whoops - I didn't mean to write that!".
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-02-06 07:51 -0500 |
| Message-ID | <ILA6E.408675$Aq8.268619@fx47.iad> |
| In reply to | #140612 |
On 2/6/19 7:36 AM, David Brown wrote: > On 06/02/2019 12:42, Malcolm McLean wrote: >> On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: >>> >>> So what you meant to say is that any program that is correct in C with >>> "const", will remain correct when "const" is removed entirely? >>> >>> Adding "const" to a correct C program is unlikely to result in a correct >>> program - you don't get to count "restoring the const you took away" as >>> adding "const". >>> >> "Correct" means "with correct behaviour". It assumes "grammatical". >> > > Yes - so what? > > Adding "const" to a correct C program is unlikely to result in a correct > program - one that will compile and do the same job as before. Keith > gave a simple example. Do you agree with that? (Please answer yes or > no, rather than posting more pointless tangents.) > > You said that in C (but not C++) adding "const" qualifiers to a correct > program does not make it incorrect. Again, answer yes or no - > remembering that your post was made in public. > > I believe the assumption in the statement is that given a correct C program, adding or removing a const, AND PROPAGATING THE NEEDED CHANGES to be grammatically correct (if that is possible), won't change the correctness of a program. (There are cases where adding const to the definition of an object might not have a possibility to propagate, especially if that object actually varies). This is not true in C++, as C++ allow overriding on constness, so changing the constness of an object, can change the execution path of the program, and thus impact correctness. C doesn't allow changing behavior based on constness, thus doesn't have this issue.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-06 05:12 -0800 |
| Message-ID | <7712dc0b-7b34-455b-80ae-fd46b57ba7a4@googlegroups.com> |
| In reply to | #140610 |
On Wednesday, February 6, 2019 at 6:42:31 AM UTC-5, Malcolm McLean wrote: > On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: > > > > So what you meant to say is that any program that is correct in C with > > "const", will remain correct when "const" is removed entirely? > > > > Adding "const" to a correct C program is unlikely to result in a correct > > program - you don't get to count "restoring the const you took away" as > > adding "const". > > > "Correct" means "with correct behaviour". It assumes "grammatical". Keith's example was correct, as originally written, and grammatically correct both with and without the "const" keyword - but it was a constraint violation after the addition of that keyword. What exactly is your point, if any? I can reword your point to be correct: "If you start with a correct program, and add in 'const' in those locations, and only those locations, that don't render it incorrect, then the resulting program will still be correct." Is that an accurate statement of your point? It's perfectly true, but it would be equally true if you replace "const" with anything else, including "Malcolm". It's tautologically true, and correspondingly useless. What would it take to make your point meaningful? Describing the kinds of locations where "const" can be added without rendering the code incorrect. A correct description of those places is fairly complicated. "The places where it's grammatically permitted" is NOT the right description. The reverse statement is far simpler, equally true, and much more meaningful: if you remove all occurrences of the "const" keyword from a correct program, it remains a correct program. That's because it doesn't impose any restrictions on where you can remove the keyword from.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 05:22 -0800 |
| Message-ID | <248ca5f3-b257-4ab0-a1ca-8a8c5a0f6056@googlegroups.com> |
| In reply to | #140618 |
On Wednesday, 6 February 2019 13:12:25 UTC, James Kuyper wrote: > On Wednesday, February 6, 2019 at 6:42:31 AM UTC-5, Malcolm McLean wrote: > > On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: > > > > > > So what you meant to say is that any program that is correct in C with > > > "const", will remain correct when "const" is removed entirely? > > > > > > Adding "const" to a correct C program is unlikely to result in a correct > > > program - you don't get to count "restoring the const you took away" as > > > adding "const". > > > > > "Correct" means "with correct behaviour". It assumes "grammatical". > > Keith's example was correct, as originally written, and grammatically > correct both with and without the "const" keyword - but it was a > constraint violation after the addition of that keyword. What exactly is > your point, if any? > If it won't compile, it's not a grammatical C program. "Grammar" means more than the rules you feed to the parser, it also incorporates more integrative concepts.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-06 05:51 -0800 |
| Message-ID | <a3a86bf9-7c94-4248-b420-e5ca076d1ea4@googlegroups.com> |
| In reply to | #140619 |
On Wednesday, February 6, 2019 at 8:22:18 AM UTC-5, Malcolm McLean wrote: > On Wednesday, 6 February 2019 13:12:25 UTC, James Kuyper wrote: ... > > Keith's example was correct, as originally written, and grammatically > > correct both with and without the "const" keyword - but it was a > > constraint violation after the addition of that keyword. What exactly is > > your point, if any? > > > If it won't compile, it's not a grammatical C program. "Grammar" means more > than the rules you feed to the parser, it also incorporates more integrative > concepts. Ah - this is "Malcolm-grammatical"! Sorry, nothing that anyone else has said was using the term "grammatical" in that sense. If you're requiring that the program start out and remain "Malcolm-grammatical", then my tautological re-write of your point is correct. Based upon past experience, I won't bother debating the meaning of "Malcolm-grammatical" with you.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 10:33 -0800 |
| Message-ID | <ln7eebv470.fsf@kst-u.example.com> |
| In reply to | #140601 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 5 February 2019 21:14:28 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> > On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote:
>> >> You are being willfully obtuse, const in C++ is a significant
>> >> improvement over const in C.
>> >>
>> > It's significantly more complex.
>> >
>> > It's no longer true, as it is in C, that a correct program cannot
>> > be turned into an incorrect program by const-qualifying or const-
>> > dequalifying identifiers.
>>
>> Can you clarify what you mean by that?
>>
>> I can turn this correct program:
>>
>> int main(void) {
>> int n = 10;
>> n = 20;
>> }
>>
>> into an incorrect program by const-qualifying n.
>>
> What I (actually Dennis Ritchie) meant is this.
>
> We have
>
> double total_salaries(const Employee *emp, int N);
>
> The function works, and it doesn't corrupt the employee array.
> Now we can take the const away, and the function must still work
> correctly. We can add it again, and it still works correctly.
If I have a call like this:
const Employee staff[42];
double cost = total_salaries(staff, 42);
then removing the "const" from the parameter declaration makes the
program incorrect.
I think that if you remove *all* occurrences of "const" from a correct
program, the result is still a correct program (though removing "const"
makes it easier to make the program incorrect).
--
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-05 21:24 +0000 |
| Message-ID | <V9n6E.243725$fF1.132112@fx37.am4> |
| In reply to | #140573 |
On 05/02/2019 19:23, Ian Collins wrote:
> On 06/02/2019 07:44, Bart wrote:
>> On 05/02/2019 15:50, David Brown wrote:
>>> On 05/02/2019 15:36, Bart wrote:
>>
>>> Again, you have completely missed my point. If you manage to control
>>> your knee-jerk panic attack whenever C++ is mentioned, you will get on
>>> better.
>>
>> And you've missed mine. C++ is one of the last languages you'd want want
>> to take tips from in language design.
>
> You are being willfully obtuse, const in C++ is a significant
> improvement over const in C.
The first hit for "C++ const" gave me:
"The 'const' system is one of the really messy features of C++.
It is simple in concept: variables declared with ‘const’ added become
constants and cannot be altered by the program. However it is also used
to bodge in a substitute for one of the missing features of C++ and
there it gets horridly complicated and sometimes frustratingly restrictive."
So what is 'const' in C++:
is it a way of naming a literal or literal expression;
is it a way of declaring readonly variables;
does it apply to variable names, object, types or any combination;
does it propagate downwards into a data structure, or does it only
protect the top level and other levels need their own const;
is it a way of declaring 'in' parameters to functions (but see last item);
can it be applied to names that are used for fixed array bounds and
switch-case values;
is it actually impossible to change the value of a const object or
/could/ that be done by deliberate or malicious code?
it is possible to create a pointer to a const object?
It looks like it's trying to do too much.
I'm just saying that for inspiration, it's best to look elsewhere. We
all know the sorts of things that we want.
------------------------------
Here's a repeat-N-times loop in C:
for (int i=0; i<N; ++i) {body...}
What's to stop code in the body from writing to 'i' do that it executes
fewer or more iterations? Nothing. You can't use 'const int' because
then ++i can't work. I solve that problem like this:
to N do body... od
Now, it is impossible to write to the loop index, because it's not
accessible from the source code.
And a language can choose to extend that property to explicit loop
indices - not allowing user code to modify them, but allowing increment
because that is done behind the scenes. That's not possible in C or C++
because there are no special loop variables; just variables.
Two features then that can stop inadvertently modifying variables, all
without use of 'const' which wouldn't have been of any help anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 00:24 +0100 |
| Message-ID | <q3d5vj$ras$1@dont-email.me> |
| In reply to | #140582 |
On 05/02/2019 22:24, Bart wrote:
> On 05/02/2019 19:23, Ian Collins wrote:
>> On 06/02/2019 07:44, Bart wrote:
>>> On 05/02/2019 15:50, David Brown wrote:
>>>> On 05/02/2019 15:36, Bart wrote:
>>>
>>>> Again, you have completely missed my point. If you manage to control
>>>> your knee-jerk panic attack whenever C++ is mentioned, you will get on
>>>> better.
>>>
>>> And you've missed mine. C++ is one of the last languages you'd want want
>>> to take tips from in language design.
>>
>> You are being willfully obtuse, const in C++ is a significant
>> improvement over const in C.
>
> The first hit for "C++ const" gave me:
>
> "The 'const' system is one of the really messy features of C++.
I looked at the link - it's mostly highly biased. Some people seem to
get really worked up about C++ - it's just a language, a tool. It is
useful for many purposes, but is neither perfect nor the epitome of evil.
>
> It looks like it's trying to do too much.
A fair point. But it is usually quite easy to use once you have tried
it a bit.
>
> I'm just saying that for inspiration, it's best to look elsewhere. We
> all know the sorts of things that we want.
Look elsewhere as well - but also look at C++ "const". Also look at its
"constexpr" and "consteval". I have not suggested you copy it - before
you went into panic-mode to post as much fear and hatred of C++ as you
could, you /might/ have noticed that I suggest you look at it, study it,
and learn from its pros and cons. That means learning from what you see
as its mistakes, as well as its advantages.
>
> ------------------------------
>
> Here's a repeat-N-times loop in C:
>
> for (int i=0; i<N; ++i) {body...}
>
> What's to stop code in the body from writing to 'i' do that it executes
> fewer or more iterations? Nothing. You can't use 'const int' because
> then ++i can't work. I solve that problem like this:
>
> to N do body... od
>
> Now, it is impossible to write to the loop index, because it's not
> accessible from the source code.
I want read-only access to the loop variable. You can't get that in C
or C++, unless you write somewhat odd stuff:
for (int i = 0; i < N; i++) {
const int ii = i;
const int i = ii;
// Now "i" is read-only
}
>
> And a language can choose to extend that property to explicit loop
> indices - not allowing user code to modify them, but allowing increment
> because that is done behind the scenes. That's not possible in C or C++
> because there are no special loop variables; just variables.
>
Agreed. You can improve on C and C++ here in your new language.
> Two features then that can stop inadvertently modifying variables, all
> without use of 'const' which wouldn't have been of any help anyway.
It would certainly have helped here, as shown above. You just can't do
it as neatly in C and C++. Macros and gcc extensions can help:
#define lock(x) const __auto_type x##$ = x; const __auto_type x = x##$
for (int i = 0; i < N; i++) {
lock(i);
// Now "i" is read-only
}
The equivalent C++ (with "auto") does not work - in C, the loop variable
scope starts inside the loop body, and so you can't redeclare (shadow)
"i" there. In C, it starts inside the "for" statement and you /can/
redeclare "i" in the loop. For C++ you need:
#define lock(x) const auto x##$ = x; const auto x = x##$
for (int i = 0; i < N; i++) {{
lock(i);
// Now "i" is read-only
}}
That's getting messy.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-06 14:13 +1300 |
| Message-ID | <gbuqleFfhg9U11@mid.individual.net> |
| In reply to | #140582 |
On 06/02/2019 10:24, Bart wrote: > On 05/02/2019 19:23, Ian Collins wrote: >> On 06/02/2019 07:44, Bart wrote: >>> On 05/02/2019 15:50, David Brown wrote: >>>> On 05/02/2019 15:36, Bart wrote: >>> >>>> Again, you have completely missed my point. If you manage to control >>>> your knee-jerk panic attack whenever C++ is mentioned, you will get on >>>> better. >>> >>> And you've missed mine. C++ is one of the last languages you'd want want >>> to take tips from in language design. >> >> You are being willfully obtuse, const in C++ is a significant >> improvement over const in C. > > The first hit for "C++ const" gave me: A really biased page... Applying the C++ const rules to the C subset of C++ is simple. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 08:56 +0100 |
| Message-ID | <q3e3vd$t2f$1@dont-email.me> |
| In reply to | #140591 |
On 06/02/2019 02:13, Ian Collins wrote: > On 06/02/2019 10:24, Bart wrote: >> On 05/02/2019 19:23, Ian Collins wrote: >>> On 06/02/2019 07:44, Bart wrote: >>>> On 05/02/2019 15:50, David Brown wrote: >>>>> On 05/02/2019 15:36, Bart wrote: >>>> >>>>> Again, you have completely missed my point. If you manage to control >>>>> your knee-jerk panic attack whenever C++ is mentioned, you will get on >>>>> better. >>>> >>>> And you've missed mine. C++ is one of the last languages you'd want >>>> want >>>> to take tips from in language design. >>> >>> You are being willfully obtuse, const in C++ is a significant >>> improvement over const in C. >> >> The first hit for "C++ const" gave me: > > A really biased page... > > Applying the C++ const rules to the C subset of C++ is simple. > Yes. It is basically : if you've got a "const", and the compiler can figure out the value at compile time, then you can use it as a compile time constant (array size, initialiser, etc.). File-level C++ "const" are static by default - and if you have a static const that does not need to exist as an object (you don't take its address), then the compiler does not need to create it as an object.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-05 23:59 +0100 |
| Message-ID | <q3d4hf$guu$1@dont-email.me> |
| In reply to | #140570 |
On 05/02/2019 19:44, Bart wrote: > On 05/02/2019 15:50, David Brown wrote: >> On 05/02/2019 15:36, Bart wrote: > >> Again, you have completely missed my point. If you manage to control >> your knee-jerk panic attack whenever C++ is mentioned, you will get on >> better. > > And you've missed mine. C++ is one of the last languages you'd want want > to take tips from in language design. > As I said, you have a knee-jerk panic reaction to C++. Since you don't appear to have much knowledge or experience with it, I can only assume it is because it is a large language and is not easily comprehensible until you know it. And since you don't understand it, you are foolish to dismiss what can be learned about its use of "const". > However it seems to be common for C++ users not to see the issues. You'd be hard pushed to find any C++ user who likes everything in the language. It has a lot of historical baggage, and many very odd and complex corners (most of which are of no concern to general users, but only needed by library writers). You'd be even harder pushed to find any C++ user who does not see C++ "const" as having significant benefits compared to C "const". > > "A C compiler takes roughly one to two man years to create, whereas a > C++ compiler takes 15 to 20" No one is suggesting you write a C++ compiler. > > "> Basically, writing a C++ front end takes 10 man years." > > "This is insane. No language needs to be that complex. I guess that's > the power of backward compatibility: forcing an entire industry to dig > itself into an ever growing hole, because in the short term we move > faster by digging than by first clawing our way out." If you ever raised your gaze beyond your navel, you might find C++ is a rather successful language. It is also a language that people know can be improved - that is why it is being improved. > >>> That second declaration gives you exactly the ability of assigning to >>> assign to x (it doesn't matter which version) a second time. >>> >> >> No, it gives the ability to create a second constant "x". Each "x" is >> initialised exactly once (no assignments). > > This is not allowed: > > const int x=rand(); > .... > x=rand(); Correct. > > But with your new feature, you can just do this: > > const int x=rand(); > .... > const int x=rand(); Correct. > > You are circumventing the 'const' restriction and allowing two > assignments to a const variable called 'x' within one block lifetime. No, I am not. It is creating two const variables. Neither "x" can be changed after initialisation. > >> Fair enough - but why would you want to do that? Locals in block scope >> have limited lifetimes. It doesn't make sense to refer to them from >> outside that scope, since they don't exist. > > There are other things declared in block scopes: typedefs, structs, > enums, static variables, named constants [not C]. These have > program-wide lifetimes. > Static variables have lifetimes - the others do not. >>> const area = width*height >>> const width = 20, height = 10 > >> That does not look like something I'd want. I really do not want to do >> calculations first, then define the data for the calculations. And like >> your circular enums, this can only work in limited cases. > > This is not executing code, they are compile-time expressions, and not > necessarily evaluated in sequence. That they necessarily have to be > written in sequence might give the impression of some order, but that is > not the case. So how do you deal with: const width = height * 2; const height = width / 2; That's just an easy example. > >>> The advantage is that it helps keep the actual function of the code >>> clearer. That line 'raises i to 'power' and assigns the result to p'. >>> The 'const int' is not a part of that. >>> >> >> Yes, it is. > > Obviously, it isn't, because it is only relevant to C, and specific to > the way you decided to write it, even there. Such stuff is > language-specific metadata that I prefer to keep separate. > The "const" is important - it tells you it is not modifiable. The "int" is important - it tells you the type of "p". These are relevant to the statement.
[toc] | [prev] | [next] | [standalone]
Page 10 of 19 — ← Prev page 1 … 8 9 [10] 11 12 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web