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 6 of 19 — ← Prev page 1 … 4 5 [6] 7 8 … 19 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 16:10 -0800 |
| Message-ID | <86lg23cstz.fsf@mailhub.linuxsc.com> |
| In reply to | #140755 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: ... > But my confidence comes from that fact that the most general, > type-0 grammars, are in some rather hand-wavy way, "Turing > complete". [...] Why do you say hand-wavy? Is it not the case that Turing Machines and General Rewrite grammars (aka type-0 grammars) are formally equivalent, in the sense that the set of languages each can recognize are identical sets?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-26 02:37 +0000 |
| Message-ID | <87zhqj1di0.fsf@bsb.me.uk> |
| In reply to | #141381 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > ... > >> But my confidence comes from that fact that the most general, >> type-0 grammars, are in some rather hand-wavy way, "Turing >> complete". [...] > > Why do you say hand-wavy? Is it not the case that Turing > Machines and General Rewrite grammars (aka type-0 grammars) are > formally equivalent, in the sense that the set of languages each > can recognize are identical sets? Yes. The hand waving just comes from the fact that "Turing complete" is not really the right term, but it's the best know term. Most people's intuition about what Turing complete means will be in terms of algorithms and "effective procedures" whereas formal grammars denote sets of strings. The domains of discourse are a bit different. Not making that link explicit felt like hand waving at the time. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 14:06 -0800 |
| Message-ID | <86ftsbed4w.fsf@mailhub.linuxsc.com> |
| In reply to | #140743 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Keith Thompson <kst-u@mib.org> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> [...] >> >>> There are some kinds of UB that could be handled by a more complex >>> grammar describing the C language. The grammar rules of C /could/ >>> have precluded invalid multi-byte characters in the source code, >>> or converting a pointer to something other than an integer or >>> pointer type. But they don't preclude them. If they had, then >>> there would be no need to call them "undefined behaviour" - the >>> code would simply not be syntactically valid C. >> >> [...] >> >> I don't think pointer conversion is an example of what you're >> talking about. Converting a pointer to something other than an >> integer or pointer type is a constraint violation. I don't see how >> that could be enforced in the grammar. Given: >> >> some_type x = (some_other_type)y; >> >> we can't tell whether the constraint is violated without knowing >> how some_time and some_other_type are defined. > > Since every constraint violation is checkable at compile time, > there will be some grammar that will only parse C programs with no > such violations. It will almost certainly be impractical, not > context-free and require an exponential-time algorithm to parse, > but I think I am right in saying that such a grammar exists. Such a grammar certainly exists. It will certainly not be context free, but need not be exponential and may even be practical, in much the same way that LALR grammars are a useful subset of general context-free grammars. It's only when we want to exploit the full generality of context-sensitive grammars (or even context-free grammars for that matter) that such problems are inescapable. A grammar for C doesn't need that much power - it can get by on a limited subset that is more tractable.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-07 12:01 -0800 |
| Message-ID | <7615cc12-0e98-4917-a0d0-682c7aeabeb5@googlegroups.com> |
| In reply to | #140742 |
On Thursday, February 7, 2019 at 1:57:10 PM UTC-5, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] > > There are some kinds of UB that could be handled by a more complex > > grammar describing the C language. The grammar rules of C /could/ have > > precluded invalid multi-byte characters in the source code, or > > converting a pointer to something other than an integer or pointer type. > > But they don't preclude them. If they had, then there would be no need > > to call them "undefined behaviour" - the code would simply not be > > syntactically valid C. > [...] > > I don't think pointer conversion is an example of what you're talking > about. Converting a pointer to something other than an integer or > pointer type is a constraint violation. I don't see how that could be > enforced in the grammar. Given: > > some_type x = (some_other_type)y; > > we can't tell whether the constraint is violated without knowing how > some_time and some_other_type are defined. In a hypothetical language very different from C, the type of an expression could always be uniquely determined purely from the expression's syntax. In order for this to be feasible, the number of supported types would have to be much smaller than that allowed by C - user-defined types would be quite problematic. In such a language, this constraint (and many others) could be converted to a syntax error. This is just a proof of principle, I'm not suggesting that such a language should be designed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-07 21:55 +0000 |
| Message-ID | <8736oze00i.fsf@bsb.me.uk> |
| In reply to | #140744 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>user-defined types would be quite problematic. In such a language, this
>>constraint (and many others) could be converted to a syntax error. This
>
> If this is not C, we need definitions for "syntax".
>
> I have a simplified model of a programming language:
>
> |A programming language maps programs to meanings. The set of
> |all such programs (each of which is mapped to a meaning by
> |the language) is called the "syntax" of the language.
> |A grammar is a description of the syntax.
That's not the conventional notion of syntax and grammar. The set of
all strings (programs) described by a grammar is usually called the
language of the grammar. To call that set the syntax is a misuse of the
term. The syntax is the grammar, not the set of strings so described.
The use of "such" in the second line suggests that some programs are not
mapped to meanings, so
(main int)
is not a "such a program", yes? But then many languages have programs
with no meaning at run-time. You are then using the term "grammar" as
Malcolm used it. Run-time undefined programs are
un-Malcolm-grammatical. Is that what you meant or do all programs, even
int main(void) { return 1/0; }
have a "meaning"? That's perfectly in line with some work on formal
semantics. In denotational semantics, undefined programs are given the
meaning "bottom": _|_.
> |A "syntax error" occurs when input is detected by a
> |syntax checker that is not an element of the syntax.
The conventional terminology is "an element of the language of the
grammar", or simply "in the language".
> One might say that the EBNF grammar of a language
> does not completely describe the syntax in that sense
> when there are additional rules not expressed in the
> EBNF grammar.
As there are in C. typedef names being the famous go-to example.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-07 23:17 +0000 |
| Message-ID | <87r2cjcho0.fsf@bsb.me.uk> |
| In reply to | #140747 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>I have a simplified model of a programming language:
>>>|A programming language maps programs to meanings. The set of
>>>|all such programs (each of which is mapped to a meaning by
>>>|the language) is called the "syntax" of the language.
>>>|A grammar is a description of the syntax.
>>That's not the conventional notion of syntax and grammar. The set of
>>all strings (programs) described by a grammar is usually called the
>>language of the grammar. To call that set the syntax is a misuse of the
>>term. The syntax is the grammar, not the set of strings so described.
>
> Yes, I should modify my terminology to better match the
> commonly-used terms.
>
>>un-Malcolm-grammatical. Is that what you meant or do all programs, even
>> int main(void) { return 1/0; }
>>have a "meaning"?
>
> I do not wish the question whether »1/x« is part of the
> language to depend on runtime values (here: on the value of
> »x«). Therefore, I have to call UB a possible meaning.
> So, the above program has a meaning (behavior) for me,
> which is UB.
>
> A text such as
>
> < int int int >
>
> on the other hand does not even have UB (in C).
> It is not part of the language.
I think that, technically, there's no difference in C. A syntax error,
a constraint violation and run-time undefined action are all equivalent:
the C standard imposes no meaning on the text.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 16:36 -0800 |
| Message-ID | <lnlg2rt8t8.fsf@kst-u.example.com> |
| In reply to | #140751 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I think that, technically, there's no difference in C. A syntax error,
> a constraint violation and run-time undefined action are all equivalent:
> the C standard imposes no meaning on the text.
Syntax errors and constraint violations require diagnostics; undefined
behavior does not.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-08 02:04 +0000 |
| Message-ID | <874l9fc9y8.fsf@bsb.me.uk> |
| In reply to | #140754 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> I think that, technically, there's no difference in C. A syntax error, >> a constraint violation and run-time undefined action are all equivalent: >> the C standard imposes no meaning on the text. > > Syntax errors and constraint violations require diagnostics; undefined > behavior does not. Yes. I should perhaps have put "in this respect" before the colon. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-08 01:39 -0800 |
| Message-ID | <3f4afc9e-c532-4ee1-93f6-d6872c55928c@googlegroups.com> |
| In reply to | #140747 |
On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > > > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >>user-defined types would be quite problematic. In such a language, this > >>constraint (and many others) could be converted to a syntax error. This > > > > If this is not C, we need definitions for "syntax". > > > > I have a simplified model of a programming language: > > > > |A programming language maps programs to meanings. The set of > > |all such programs (each of which is mapped to a meaning by > > |the language) is called the "syntax" of the language. > > |A grammar is a description of the syntax. > > That's not the conventional notion of syntax and grammar. The set of > all strings (programs) described by a grammar is usually called the > language of the grammar. To call that set the syntax is a misuse of the > term. The syntax is the grammar, not the set of strings so described. > > The use of "such" in the second line suggests that some programs are not > mapped to meanings, so > > (main int) > > is not a "such a program", yes? But then many languages have programs > with no meaning at run-time. You are then using the term "grammar" as > Malcolm used it. Run-time undefined programs are > un-Malcolm-grammatical. > The grammar is the set of rules that distinguish meaningful from non-meaningful "productions".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-08 11:42 +0100 |
| Message-ID | <q3jme1$blc$1@dont-email.me> |
| In reply to | #140765 |
On 08/02/2019 10:39, Malcolm McLean wrote: > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: >> ram@zedat.fu-berlin.de (Stefan Ram) writes: >> >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> user-defined types would be quite problematic. In such a language, this >>>> constraint (and many others) could be converted to a syntax error. This >>> >>> If this is not C, we need definitions for "syntax". >>> >>> I have a simplified model of a programming language: >>> >>> |A programming language maps programs to meanings. The set of >>> |all such programs (each of which is mapped to a meaning by >>> |the language) is called the "syntax" of the language. >>> |A grammar is a description of the syntax. >> >> That's not the conventional notion of syntax and grammar. The set of >> all strings (programs) described by a grammar is usually called the >> language of the grammar. To call that set the syntax is a misuse of the >> term. The syntax is the grammar, not the set of strings so described. >> >> The use of "such" in the second line suggests that some programs are not >> mapped to meanings, so >> >> (main int) >> >> is not a "such a program", yes? But then many languages have programs >> with no meaning at run-time. You are then using the term "grammar" as >> Malcolm used it. Run-time undefined programs are >> un-Malcolm-grammatical. >> > The grammar is the set of rules that distinguish meaningful from non-meaningful > "productions". > No, it is not. The term "grammar" for computer languages is not much different from its use in human languages (though computer language grammars tend to be more consistent). "My forgetfulness jumps on combined chickens" is perfectly grammatical - but few would consider it meaningful.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-02-08 03:07 -0800 |
| Message-ID | <4151fe88-0b78-4242-ba59-40a6546fd14d@googlegroups.com> |
| In reply to | #140767 |
Haven't you encountered Humpty Dumpty McLaren before? "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-02-08 03:10 -0800 |
| Message-ID | <7cc479f9-b555-4c03-aa6f-7965f7aca3bf@googlegroups.com> |
| In reply to | #140768 |
Oops.For McLaren read McLean.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-08 13:43 +0000 |
| Message-ID | <87h8debdlm.fsf@bsb.me.uk> |
| In reply to | #140765 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: <snip> >> ... But then many languages have programs >> with no meaning at run-time. You are then using the term "grammar" as >> Malcolm used it. Run-time undefined programs are >> un-Malcolm-grammatical. >> > The grammar is the set of rules that distinguish meaningful from non-meaningful > "productions". Why the scare quotes? Provided it is safe the assume the "productions" are just productions, your description is confusing me. A grammar is a set of rules that state what productions are applicable at any point in a derivation. Is that what you mean -- that applicable productions are meaningful and those that can't be applied are not? If that is /not/ what you mean, you need to explain how meaning comes into it in Malcolm-grammars. Finally, what's the connection with what you've been calling ungrammatical programs -- which include those with run-time undefined behaviour? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-08 06:47 -0800 |
| Message-ID | <6cc27732-6b74-4503-88e6-e0b991615a2a@googlegroups.com> |
| In reply to | #140771 |
On Friday, 8 February 2019 13:43:13 UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: > <snip> > >> ... But then many languages have programs > >> with no meaning at run-time. You are then using the term "grammar" as > >> Malcolm used it. Run-time undefined programs are > >> un-Malcolm-grammatical. > >> > > The grammar is the set of rules that distinguish meaningful from non-meaningful > > "productions". > > Why the scare quotes? > > Provided it is safe the assume the "productions" are just productions, > your description is confusing me. A grammar is a set of rules that > state what productions are applicable at any point in a derivation. Is > that what you mean -- that applicable productions are meaningful and > those that can't be applied are not? If that is /not/ what you mean, > you need to explain how meaning comes into it in Malcolm-grammars. > > Finally, what's the connection with what you've been calling > ungrammatical programs -- which include those with run-time undefined > behaviour? > Yes, you can only apply meaningful strings. So in computer theory, we can define a "meaningful string" as "something the compiler will turn into an executable". Then you can program the grammar into the computer. If we define "meaningful string" as "something the compiler will turn into a program with defined behaviour" and the language is C, we can no longer in practice program the grammar into the computer. Undefined behaviour is an admission that the rules of the language have broken down or in other words, that the grammar isn't complete. Remember that the producer is not a program, it's a human programmer applying or trying to apply the rules to communicate his intention.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-08 17:56 +0000 |
| Message-ID | <875ztub1vq.fsf@bsb.me.uk> |
| In reply to | #140772 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 8 February 2019 13:43:13 UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: >> <snip> >> >> ... But then many languages have programs >> >> with no meaning at run-time. You are then using the term "grammar" as >> >> Malcolm used it. Run-time undefined programs are >> >> un-Malcolm-grammatical. >> >> >> > The grammar is the set of rules that distinguish meaningful from non-meaningful >> > "productions". >> >> Why the scare quotes? >> >> Provided it is safe the assume the "productions" are just productions, >> your description is confusing me. A grammar is a set of rules that >> state what productions are applicable at any point in a derivation. Is >> that what you mean -- that applicable productions are meaningful and >> those that can't be applied are not? If that is /not/ what you mean, >> you need to explain how meaning comes into it in Malcolm-grammars. >> >> Finally, what's the connection with what you've been calling >> ungrammatical programs -- which include those with run-time undefined >> behaviour? >> > Yes, you can only apply meaningful strings. So in computer theory, we > can define a "meaningful string" as "something the compiler will turn > into an executable". Then you can program the grammar into the computer. > If we define "meaningful string" as "something the compiler will turn > into a program with defined behaviour" and the language is C, we can no > longer in practice program the grammar into the computer. Undefined > behaviour is an admission that the rules of the language have broken > down or in other words, that the grammar isn't complete. That's not how I'd put it. Undefined behaviour in C is a conscious decision not to specify the semantics of certain constructs and run-time events. It's not an admission of some flaw in the rules, it's a deliberate property of the rules. No practical grammars come close to defining meaningful strings in either of your senses[1]. Only a subset of context-free grammars can be parsed efficiently by current algorithms, and they will permit all sorts meaningless C programs. > Remember that the producer is not a program, it's a human programmer > applying or trying to apply the rules to communicate his intention. And sometimes her intentions. [1] C permits any string to be turned into an executable provided at least one diagnostic is produced. I presume we are not talking about that sort of situation here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-08 10:27 -0800 |
| Message-ID | <0a4cbc2c-4f59-4454-9a7a-730a2252189b@googlegroups.com> |
| In reply to | #140777 |
On Friday, February 8, 2019 at 12:56:21 PM UTC-5, Ben Bacarisse wrote: ... > [1] C permits any string to be turned into an executable provided at > least one diagnostic is produced. I presume we are not talking about > that sort of situation here. There is one exception, that frequently gets missed: "The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion." (4p4) Note to Malcolm: A pre-processing translation unit that fits the C grammar (not the Malcolm-grammar) and contains a #error directive which survives conditional compilation. Such a TU must NOT be successfully translated, even if it would otherwise qualify as strictly conforming. Does that mean it's Malcolm-ungrammatical? If such a source file were modified so it contained a syntax error relevant to processing through translation phases 1-d4, that error would render the behavior undefined, giving the implementation permission to successfully translate the program despite the #error directive, should it choose to do so. Does that mean that such a file is Malcolm- grammatical? If so, that means that a file which is Malcolm-ungrammatical, despite containing no syntax errors, can be turned int a Malcolm-grammatical file, by changing it to contain a syntax error?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-10 05:01 -0800 |
| Message-ID | <cd651906-9c4b-44f7-a88e-8e484c6a2cdf@googlegroups.com> |
| In reply to | #140777 |
On Friday, 8 February 2019 17:56:21 UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > On Friday, 8 February 2019 13:43:13 UTC, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> > >> > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: > >> <snip> > >> >> ... But then many languages have programs > >> >> with no meaning at run-time. You are then using the term "grammar" as > >> >> Malcolm used it. Run-time undefined programs are > >> >> un-Malcolm-grammatical. > >> >> > >> > The grammar is the set of rules that distinguish meaningful from non-meaningful > >> > "productions". > >> > >> Why the scare quotes? > >> > >> Provided it is safe the assume the "productions" are just productions, > >> your description is confusing me. A grammar is a set of rules that > >> state what productions are applicable at any point in a derivation. Is > >> that what you mean -- that applicable productions are meaningful and > >> those that can't be applied are not? If that is /not/ what you mean, > >> you need to explain how meaning comes into it in Malcolm-grammars. > >> > >> Finally, what's the connection with what you've been calling > >> ungrammatical programs -- which include those with run-time undefined > >> behaviour? > >> > > Yes, you can only apply meaningful strings. So in computer theory, we > > can define a "meaningful string" as "something the compiler will turn > > into an executable". Then you can program the grammar into the computer. > > If we define "meaningful string" as "something the compiler will turn > > into a program with defined behaviour" and the language is C, we can no > > longer in practice program the grammar into the computer. Undefined > > behaviour is an admission that the rules of the language have broken > > down or in other words, that the grammar isn't complete. > > That's not how I'd put it. Undefined behaviour in C is a conscious > decision not to specify the semantics of certain constructs and run-time > events. It's not an admission of some flaw in the rules, it's a > deliberate property of the rules. > > No practical grammars come close to defining meaningful strings in > either of your senses[1]. Only a subset of context-free grammars > can be parsed efficiently by current algorithms, and they will permit > all sorts meaningless C programs. > 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. Then few people if any learn C by looking at the formal rules for the grammar. But these people know C grammar, otherwise they couldn't produce C programs. > > > Remember that the producer is not a program, it's a human programmer > > applying or trying to apply the rules to communicate his intention. > > And sometimes her intentions. > That's a grammar rule. The male embraces the female. Currently under challenge. > [1] C permits any string to be turned into an executable provided at > least one diagnostic is produced. I presume we are not talking about > that sort of situation here. > No, and another exception is a program with a processed #error directive. It's clearly meaningful, but it doesn't create a program. So the definition of "meaningful" as "rules which create an executable" isn't in fact quite correct. But it's good enough for most purposes. However if by "meaningful" you mean, "a program with behaviour that a human would accept as interesting or useful" then you've left the world of grammar rules you can program into a computer. Computers can't talk.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-10 16:51 +0000 |
| Message-ID | <87ftsva8o7.fsf@bsb.me.uk> |
| In reply to | #140826 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Friday, 8 February 2019 17:56:21 UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> > On Friday, 8 February 2019 13:43:13 UTC, Ben Bacarisse wrote: >> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> >> >> > On Thursday, 7 February 2019 21:56:07 UTC, Ben Bacarisse wrote: >> >> <snip> >> >> >> ... But then many languages have programs >> >> >> with no meaning at run-time. You are then using the term "grammar" as >> >> >> Malcolm used it. Run-time undefined programs are >> >> >> un-Malcolm-grammatical. >> >> >> >> >> > The grammar is the set of rules that distinguish meaningful from non-meaningful >> >> > "productions". >> >> >> >> Why the scare quotes? >> >> >> >> Provided it is safe the assume the "productions" are just productions, >> >> your description is confusing me. A grammar is a set of rules that >> >> state what productions are applicable at any point in a derivation. Is >> >> that what you mean -- that applicable productions are meaningful and >> >> those that can't be applied are not? If that is /not/ what you mean, >> >> you need to explain how meaning comes into it in Malcolm-grammars. >> >> >> >> Finally, what's the connection with what you've been calling >> >> ungrammatical programs -- which include those with run-time undefined >> >> behaviour? >> >> >> > Yes, you can only apply meaningful strings. So in computer theory, we >> > can define a "meaningful string" as "something the compiler will turn >> > into an executable". Then you can program the grammar into the computer. >> > If we define "meaningful string" as "something the compiler will turn >> > into a program with defined behaviour" and the language is C, we can no >> > longer in practice program the grammar into the computer. Undefined >> > behaviour is an admission that the rules of the language have broken >> > down or in other words, that the grammar isn't complete. >> >> That's not how I'd put it. Undefined behaviour in C is a conscious >> decision not to specify the semantics of certain constructs and run-time >> events. It's not an admission of some flaw in the rules, it's a >> deliberate property of the rules. >> >> No practical grammars come close to defining meaningful strings in >> either of your senses[1]. Only a subset of context-free grammars >> can be parsed efficiently by current algorithms, and they will permit >> all sorts meaningless C programs. >> > 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. Why do you think I'm confused by this? When I said "no practical grammars come close to defining meaningful strings in either of your senses" I was (I'd hoped) making it perfectly clear that others (the impractical ones) can do what you mean. What's more I posted about attribute grammars which would, I'd have thought, flagged the fact I know about /some/ ways in which pure syntax /and/ semantics can be defined. (Don't take this as an endorsement -- I suspect that attribute grammars won't go much further than they did in the first 20 years.) The trouble with your most general statement -- about undefined behaviour being ungrammatical -- is that the implied grammar would be undecidable. That makes the point dubious even in the most abstract and purely theoretical sense. >> > Remember that the producer is not a program, it's a human programmer >> > applying or trying to apply the rules to communicate his intention. >> >> And sometimes her intentions. >> > That's a grammar rule. The male embraces the female. Currently under > challenge. The words we use are useful social indicators. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-10 09:14 -0800 |
| Message-ID | <62e2da0a-0d2d-49d5-8535-8ebf922eb014@googlegroups.com> |
| In reply to | #140829 |
On Sunday, 10 February 2019 16:51:48 UTC, Ben Bacarisse wrote: > > The trouble with your most general statement -- about undefined > behaviour being ungrammatical -- is that the implied grammar would be > undecidable. That makes the point dubious even in the most abstract and > purely theoretical sense. > You can't always tell whether a program has undefined behaviour or not except by running it. But that only applies to unusual cases. Normally programs which exhibit UB are straightforwardsly incorrect, and can be shown to be incorrect by inspection by a human. So the human programmer has a grammar rule that distinguishes defined behaviour (grammatical / meaningful / well-formed / correct) from undefined behaviour (incorrect, ill-formed, meaningless, ungrammatical). The standard prohibits that rule from being programmed into the compiler, but only on a technicality - the compiler can warn and warnings can be treated as errors. A natural language grammar is also undecideable. You can't draw up a complete set of rules for distinguishing between meaningful and non-meaningful English statements, but you can tell whether something makes sense or not.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-11 02:34 +0000 |
| Message-ID | <87a7j39ho4.fsf@bsb.me.uk> |
| In reply to | #140831 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Sunday, 10 February 2019 16:51:48 UTC, Ben Bacarisse wrote: >> >> The trouble with your most general statement -- about undefined >> behaviour being ungrammatical -- is that the implied grammar would be >> undecidable. That makes the point dubious even in the most abstract and >> purely theoretical sense. >> > You can't always tell whether a program has undefined behaviour or not > except by running it. But that only applies to unusual cases. > Normally programs which exhibit UB are straightforwardsly incorrect, > and can be shown to be incorrect by inspection by a human. No. In a large number of perfectly normal cases, UB is property of a computation not a program. That's a combination of the program text, compiler options, the C implementation and the input to the program (and probably other things I've forgotten). It's simply incorrect to talk about program texts being grammatical or ungrammatical if you want to associate that with undefined behaviour. > So the > human programmer has a grammar rule that distinguishes defined behaviour > (grammatical / meaningful / well-formed / correct) from undefined > behaviour (incorrect, ill-formed, meaningless, ungrammatical). No, I don't think they do, though from posts here I've concluded that there are lots of different ways to think about programming. But I, at least, don't favour UB in this way. I have a set of semantic rules for C which I apply to syntactically correct texts to determine if the text will process the input in the desired way. Dividing by 2 when it should be 3 is no less important that dividing by 0. There are semantic rules, not just "UB" rules. But there is another less technical problem. To use "grammar" in its broadest natural language sense when talking about computer programs is perverse. It's not used in that way in this field. > The > standard prohibits that rule from being programmed into the compiler, but > only on a technicality - the compiler can warn and warnings can be > treated as errors. I don't know what you mean here at all. What technicality are you referring to? What rule are you being referring to? > A natural language grammar is also undecideable. You can't draw up > a complete set of rules for distinguishing between meaningful and > non-meaningful English statements, but you can tell whether something > makes sense or not. It's not a good analogy because, for one thing, it's relative to the context and to the person doing the understanding. But putting that aside, natural language has no data. If it did (and there may be an analogous concept that I've missed) then you would not have been led astray by this analogy. Whether an English sentence is meaningful would then obviously /not/ be simply a property of that sentence, but would also depend on the "input" to it. English does have an equivalent of C's implementation: the context in which it occurs. The meaning of "every couple has a moment in a field" depends on the context. Other utterances are meaningless out of context like "char pointer" and "bona riah" but maybe you have a "maximal" view of English, that an utterance is meaningful if it is meaningful in any context at all, but then how many people must agree on a context for it to apply? -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 19 — ← Prev page 1 … 4 5 [6] 7 8 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web