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 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-11 09:54 +0100 |
| Message-ID | <q3rd7d$c2f$1@dont-email.me> |
| In reply to | #140845 |
On 11/02/2019 03:34, Ben Bacarisse wrote: > 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. That is something that is often understated. People often seem to view "undefined behaviour" as a terrible evil to be feared, while being less bothered about defined but incorrect behaviour. If Malcolm wants to invent a set of magical Malcolm-grammar rules that avoid undefined behaviour, they should be equally capable of avoiding incorrect behaviour. > > 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. > Malcolm is not using "grammar" in its broadest natural language sense - he is using it in a far broader sense than that. (He did not reply to my post noting that.) His use of the word "grammar" is so broad as to be almost completely meaningless - I think it is trying to encompass magical rules that will determine if a text file is a valid, correct, functioning, bug-free program that does exactly what the programmer wants it to do. >> 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? > We can take some more relevant examples. Malcolm's posts here have been grammatically correct English, but few people find them meaningful, at least outside of the context of his own mind!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-11 12:35 +0000 |
| Message-ID | <874l9ao64m.fsf@bsb.me.uk> |
| In reply to | #140850 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/02/2019 03:34, Ben Bacarisse wrote:
<snip>
>> 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.
>
> Malcolm is not using "grammar" in its broadest natural language sense -
> he is using it in a far broader sense than that.
Hmm... I don't think so. The word has a meaning broad enough to be the
one he is using:
"The whole system and structure of a language or of languages in
general, usually taken as consisting of syntax and morphology
(including inflections) and sometimes also phonology and semantics."
https://en.oxforddictionaries.com/definition/grammar
This meaning is not so common these days, even in the field of
linguistics, but it was prevalent in the era MM probably regards with
wistful nostalgia.
To take one example, I have on my shelf "A Practical English Grammar" by
Thomson and Martinet. Opening it at random I see
The *be going to* form used for prediction
The *be going to* form can express the speaker's feeling of certainty.
/Listen to the wind. We're going to have a rough crossing./
This is partly syntax, but mainly semantics.
[Note: the word "grammar" in the title is yet another related meaning,
but that is beside the point. The grammar (the book) explains English
grammar (the syntax and associated meanings).]
Anyway, however the word is used by boarding school Latin masters, it is
almost never used that way when talking about programming languages, and
never when talking about C. C's grammar is in Appendix A.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-11 14:03 +0100 |
| Message-ID | <q3rrrs$u1t$1@dont-email.me> |
| In reply to | #140852 |
On 11/02/2019 13:35, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 11/02/2019 03:34, Ben Bacarisse wrote:
> <snip>
>>> 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.
>>
>> Malcolm is not using "grammar" in its broadest natural language sense -
>> he is using it in a far broader sense than that.
>
> Hmm... I don't think so. The word has a meaning broad enough to be the
> one he is using:
>
> "The whole system and structure of a language or of languages in
> general, usually taken as consisting of syntax and morphology
> (including inflections) and sometimes also phonology and semantics."
> https://en.oxforddictionaries.com/definition/grammar
>
> This meaning is not so common these days, even in the field of
> linguistics, but it was prevalent in the era MM probably regards with
> wistful nostalgia.
>
I would not have considered semantics to be part of grammar. Spelling
of words could be viewed as grammar, though I think that is borderline
("The Jabberwocky" is, I would say, grammatically correct though many of
the words are nonsense and have no correct spelling or semantics).
But if this is an archaic meaning of "grammar", who am I to argue with
the OED ?
> To take one example, I have on my shelf "A Practical English Grammar" by
> Thomson and Martinet. Opening it at random I see
>
> The *be going to* form used for prediction
>
> The *be going to* form can express the speaker's feeling of certainty.
> /Listen to the wind. We're going to have a rough crossing./
>
> This is partly syntax, but mainly semantics.
I can see that grammar requires a meaning for a number of words - you'll
need meaning for articles, pronouns, auxiliary verbs, etc., in order to
be able to construct sentences. What you don't need is meanings for
nouns, verbs, adjectives and adverbs. (These lists are not meant to be
complete.) Similarly, the grammar of C includes the meaning of its
keywords - but not the meaning of identifiers.
>
> [Note: the word "grammar" in the title is yet another related meaning,
> but that is beside the point. The grammar (the book) explains English
> grammar (the syntax and associated meanings).]
>
> Anyway, however the word is used by boarding school Latin masters, it is
> almost never used that way when talking about programming languages, and
> never when talking about C. C's grammar is in Appendix A.
>
> <snip>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-11 14:53 +0000 |
| Message-ID | <87y36mml69.fsf@bsb.me.uk> |
| In reply to | #140855 |
David Brown <david.brown@hesbynett.no> writes: > On 11/02/2019 13:35, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 11/02/2019 03:34, Ben Bacarisse wrote: >> <snip> >>>> 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. >>> >>> Malcolm is not using "grammar" in its broadest natural language sense - >>> he is using it in a far broader sense than that. >> >> Hmm... I don't think so. The word has a meaning broad enough to be the >> one he is using: >> >> "The whole system and structure of a language or of languages in >> general, usually taken as consisting of syntax and morphology >> (including inflections) and sometimes also phonology and semantics." >> https://en.oxforddictionaries.com/definition/grammar >> >> This meaning is not so common these days, even in the field of >> linguistics, but it was prevalent in the era MM probably regards with >> wistful nostalgia. > > I would not have considered semantics to be part of grammar. <snip> > But if this is an archaic meaning of "grammar", who am I to argue with > the OED ? It's not really archaic. That was not the OED but the English "Oxford Living Dictionary". (My local library no longer subscribes to the online OED. At least it's still open.) >> To take one example, I have on my shelf "A Practical English Grammar" by >> Thomson and Martinet. Opening it at random I see >> >> The *be going to* form used for prediction >> >> The *be going to* form can express the speaker's feeling of certainty. >> /Listen to the wind. We're going to have a rough crossing./ >> >> This is partly syntax, but mainly semantics. > > I can see that grammar requires a meaning for a number of words - you'll > need meaning for articles, pronouns, auxiliary verbs, etc., in order to > be able to construct sentences. What you don't need is meanings for > nouns, verbs, adjectives and adverbs. You do if you want to understand the construct, and you'll find them in many things that go by the name "grammar". Such things are not as comprehensive as a dictionary, but they will define many word meanings. But more to the point, they define the relationship between syntactic forms and meanings, just as the "semantics" sections of the C standard explain the meaning of the various syntactic constructs. > (These lists are not meant to be > complete.) Similarly, the grammar of C includes the meaning of its > keywords - but not the meaning of identifiers. Are you now using the term in this non-technical sense? I would stick with using "the grammar of C" to mean Appendix A, and that barely tells you what strings are syntactically valid! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 16:36 -0800 |
| Message-ID | <86h8crcrnv.fsf@mailhub.linuxsc.com> |
| In reply to | #140852 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 11/02/2019 03:34, Ben Bacarisse wrote:
>
> <snip>
>
>>> 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.
>>
>> Malcolm is not using "grammar" in its broadest natural language
>> sense - he is using it in a far broader sense than that.
>
> Hmm... I don't think so. The word has a meaning broad enough to
> be the one he is using:
>
> "The whole system and structure of a language or of languages in
> general, usually taken as consisting of syntax and morphology
> (including inflections) and sometimes also phonology and semantics."
> https://en.oxforddictionaries.com/definition/grammar
Semantics enters into matters of grammar for things like the
distinction between mass nouns and count nouns. For example, we
might say
My tank is almost empty; the car needs more gas.
But we would not say
I got a flat (or puncture); the car needs more tire.
The second sentence is ungrammatical because "tire" is a count
noun, not a mass noun. The ungrammaticalness is independent
of whether the word makes sense in the given context. For
example, the word "pencil" is also a count noun rather than
a mass noun:
I got a flat (or puncture); the car needs more pencil.
Besides being ungrammatical, the sentence doesn't make sense.
Conversly, we can give a sentence that is grammatical but
nonsensical:
I got a flat, so I need a new headlight.
or another example:
My car has a confidence problem; it needs more applause.
Both of these last two are just fine in terms of grammar.
But for meaning (aka semantics), not so much.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-26 02:57 +0000 |
| Message-ID | <87woln1ckk.fsf@bsb.me.uk> |
| In reply to | #141382 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 11/02/2019 03:34, Ben Bacarisse wrote: >> >> <snip> >> >>>> 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. >>> >>> Malcolm is not using "grammar" in its broadest natural language >>> sense - he is using it in a far broader sense than that. >> >> Hmm... I don't think so. The word has a meaning broad enough to >> be the one he is using: >> >> "The whole system and structure of a language or of languages in >> general, usually taken as consisting of syntax and morphology >> (including inflections) and sometimes also phonology and semantics." >> https://en.oxforddictionaries.com/definition/grammar > > Semantics enters into matters of grammar for things like the > distinction between mass nouns and count nouns. For example, we > might say > > My tank is almost empty; the car needs more gas. > > But we would not say > > I got a flat (or puncture); the car needs more tire. > > The second sentence is ungrammatical because "tire" is a count > noun, not a mass noun. The ungrammaticalness is independent > of whether the word makes sense in the given context. For > example, the word "pencil" is also a count noun rather than > a mass noun: > > I got a flat (or puncture); the car needs more pencil. > > Besides being ungrammatical, the sentence doesn't make sense. > > Conversly, we can give a sentence that is grammatical but > nonsensical: > > I got a flat, so I need a new headlight. > > or another example: > > My car has a confidence problem; it needs more applause. > > Both of these last two are just fine in terms of grammar. > But for meaning (aka semantics), not so much. Yes, semantics enters into even the restricted sense of "grammar" in lots of ways (https://www.youtube.com/watch?v=IIAdHEwiAy8). But this dictionary seems to go further. "The whole system ... and sometime also ... semantics" seems to be usind the word semantics ina much more general way. Are you saying that, in your opinion, this dictionary is wrong? Or that I've just taken it to be saying something it isn't saying? I was certainly surprised to find such a general definition and I had to look at quite a few to find this one). My printed Shorter Oxford English Dictionary gives the more restricted definition. (Due to apparently endless cut-backs, my local library no longer subscribes to the online OED or I would have quoted that. At least I still have a local library!) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 22:24 -0800 |
| Message-ID | <864l8rcbjx.fsf@mailhub.linuxsc.com> |
| In reply to | #141385 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 11/02/2019 03:34, Ben Bacarisse wrote: >>> >>> <snip> >>> >>>>> 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. >>>> >>>> Malcolm is not using "grammar" in its broadest natural language >>>> sense - he is using it in a far broader sense than that. >>> >>> Hmm... I don't think so. The word has a meaning broad enough to >>> be the one he is using: >>> >>> "The whole system and structure of a language or of languages in >>> general, usually taken as consisting of syntax and morphology >>> (including inflections) and sometimes also phonology and semantics." >>> https://en.oxforddictionaries.com/definition/grammar >> >> Semantics enters into matters of grammar for things like the >> distinction between mass nouns and count nouns. For example, we >> might say >> >> My tank is almost empty; the car needs more gas. >> >> But we would not say >> >> I got a flat (or puncture); the car needs more tire. >> >> The second sentence is ungrammatical because "tire" is a count >> noun, not a mass noun. The ungrammaticalness is independent >> of whether the word makes sense in the given context. For >> example, the word "pencil" is also a count noun rather than >> a mass noun: >> >> I got a flat (or puncture); the car needs more pencil. >> >> Besides being ungrammatical, the sentence doesn't make sense. >> >> Conversly, we can give a sentence that is grammatical but >> nonsensical: >> >> I got a flat, so I need a new headlight. >> >> or another example: >> >> My car has a confidence problem; it needs more applause. >> >> Both of these last two are just fine in terms of grammar. >> But for meaning (aka semantics), not so much. > > Yes, semantics enters into even the restricted sense of "grammar" in > lots of ways (https://www.youtube.com/watch?v=IIAdHEwiAy8). I haven't had a chance to look at this yet but hope to soon. > But this dictionary seems to go further. "The whole system ... and > sometime also ... semantics" seems to be usind the word semantics ina > much more general way. Are you saying that, in your opinion, this > dictionary is wrong? Or that I've just taken it to be saying something > it isn't saying? I think I would say that what I think it's saying may be a bit different from you think it's saying (not that I know what that is exactly!). The phrase "sometimes also semantics" I read as though it were "some aspects of the meanings of words (or maybe, what some people would term 'semantics')". Under that reading I agree with the definition. I'm not sure exactly how you have taken it, or what the definition actually "does say" exactly, but certainly your reading does seem to be not quite the same as mine (which I hope I have explained adequately). I hope this answers your questions. By the way, in the course of writing this reply I discovered that "semantics" is a fairly recent word, perhaps only 150 years old (ie, in its current sense). To me that suggests that what it means may still be pretty fuzzy.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-26 14:25 +0000 |
| Message-ID | <87d0ne1v9x.fsf@bsb.me.uk> |
| In reply to | #141389 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: <cut> >>>> "The whole system and structure of a language or of languages in >>>> general, usually taken as consisting of syntax and morphology >>>> (including inflections) and sometimes also phonology and semantics." >>>> https://en.oxforddictionaries.com/definition/grammar <cut> >> But this dictionary seems to go further. "The whole system ... and >> sometime also ... semantics" seems to be usind the word semantics ina >> much more general way. Are you saying that, in your opinion, this >> dictionary is wrong? Or that I've just taken it to be saying something >> it isn't saying? > > I think I would say that what I think it's saying may be a bit > different from you think it's saying (not that I know what that > is exactly!). The phrase "sometimes also semantics" I read as > though it were "some aspects of the meanings of words (or maybe, > what some people would term 'semantics')". Under that reading > I agree with the definition. I'm not sure exactly how you have > taken it, or what the definition actually "does say" exactly, > but certainly your reading does seem to be not quite the same > as mine (which I hope I have explained adequately). I hope this > answers your questions. Yes, it does. I thought that was probably how you read it, but I think the whole entry is at least open to a wider interpretation. It's the "/whole/ system of a language or languages /in general/" that might also sometimes include semantics. Anyway, that semantics (to some extent) is involved in the wider linguistic meaning of "grammar" is not in dispute, and neither is the fact that the word it has a strict formal meaning in computing and in some other linguistic circles. I never planned to defend the existence of a dictionary entry that might, just might, support Malcolm's wider take on the word! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-06 08:50 -0800 |
| Message-ID | <865zswuetu.fsf@mailhub.linuxsc.com> |
| In reply to | #141431 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > <cut> > >>>>> "The whole system and structure of a language or of languages in >>>>> general, usually taken as consisting of syntax and morphology >>>>> (including inflections) and sometimes also phonology and semantics." >>>>> https://en.oxforddictionaries.com/definition/grammar > > <cut> > >>> But this dictionary seems to go further. "The whole system ... and >>> sometime also ... semantics" seems to be usind the word semantics ina >>> much more general way. Are you saying that, in your opinion, this >>> dictionary is wrong? Or that I've just taken it to be saying something >>> it isn't saying? >> >> I think I would say that what I think it's saying may be a bit >> different from you think it's saying (not that I know what that >> is exactly!). The phrase "sometimes also semantics" I read as >> though it were "some aspects of the meanings of words (or maybe, >> what some people would term 'semantics')". Under that reading >> I agree with the definition. I'm not sure exactly how you have >> taken it, or what the definition actually "does say" exactly, >> but certainly your reading does seem to be not quite the same >> as mine (which I hope I have explained adequately). I hope this >> answers your questions. > > Yes, it does. I thought that was probably how you read it, but I think > the whole entry is at least open to a wider interpretation. It's the > "/whole/ system of a language or languages /in general/" that might also > sometimes include semantics. I put a different emphasis on that. It is the whole /system and structure/ of a language that constitutes grammar. It is not all of a language that makes up grammar, only its system and structure. (Not claiming how I read it is the only interpretation possible, only that that is how I read it.) In any case I agree that it can be read in different ways. > Anyway, that semantics (to some extent) is involved in the wider > linguistic meaning of "grammar" is not in dispute, and neither is the > fact that the word it has a strict formal meaning in computing and in > some other linguistic circles. I never planned to defend the existence > of a dictionary entry that might, just might, support Malcolm's wider > take on the word! I didn't think you were, and I wasn't meaning to argue with that position. All I was trying to do is show how some parts of semantics could be part of grammar as described by the given definition, without having to draw in all of "meaning" under the same umbrella.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-11 01:48 -0800 |
| Message-ID | <75fe55ac-a651-454a-a1c4-5d63a290b1cb@googlegroups.com> |
| In reply to | #140845 |
On Monday, 11 February 2019 02:35:09 UTC, Ben Bacarisse wrote: > 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. > One characteristic of undefined behaviour in C is that the program text has an error in it. Of course we can call the program text "grammatical" if by that we mean "accepted by the C compiler", and that's a legitimate use of the word. But grammar separates meaning from non-meaning. If the executable can do anything, what meaning does it have? And can we devise rules? In the last analysis, no, because of the halting problem. But we can certainly have some rules. Otherwise no-one would be able to write a complex C program with defined behaviour. And in fact rules that warn about likely undefined behaviour are coded into many C compilers. > > > 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? > Take this int x, y; y = x; The C compiler has to accept that. But of course it is incorrect, and most compilers will warn about it. We could and often do declare warnings to be errors, then it's "ungrammatical". > > > 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? > Two must agree. An utterance must be produced by someone applying the grammatical rules, then accepted by someone else parsing with similar but never identical rules. As you say, meaning also depends on higher-level context. Whilst sentences have been well studied (though people don't speak in sentences normally, they write in them), work on valid connections between sentences is much more challenging. You're right, however. A program has data. Also, the C compiler doesn't throw C back at you. Computer languages are not quite like natural languages.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-11 13:53 +0100 |
| Message-ID | <q3rr7p$pq0$1@dont-email.me> |
| In reply to | #140851 |
On 11/02/2019 10:48, Malcolm McLean wrote:
> On Monday, 11 February 2019 02:35:09 UTC, Ben Bacarisse wrote:
>> 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.
>>
> One characteristic of undefined behaviour in C is that the program text
> has an error in it.
That is true of any mistake - there is nothing special about undefined
behaviour.
int add_two(int x) { return x + 3; }
The program text has an error in it (assuming, obviously, that the
function name and behaviour should match for correct code). No set of
grammar rules will rule out such code - but there is an error in the text.
int div(int x, int y) { return x / y; }
That program text is grammatically correct, and has no error (if used
correctly) - yet it will have undefined behaviour for some inputs.
> Of course we can call the program text "grammatical" if by that we mean
> "accepted by the C compiler", and that's a legitimate use of the word.
How about we use the word "grammar" to mean what the C standards take it
to mean? Or we could use it to mean the same as in natural language
grammar, as it amounts to roughly the same thing. It covers the types
of words (noun, verb, etc.) and how they are spelt (matching "A.1
Lexical elements" in the C standards), and how they fit together to make
sentences (matching "A.2 Phrase structure grammar").
Grammar has nothing to do with semantics, it covers syntax. In English,
the grammar rules do not tell you want a "ball" is, what the verb "to
jump" means, or what a "question" is - it tells you how to make the
grammatically correct sentence "The ball jumped the question". It is up
to the /semantics/ - the meaning of the words - to give a meaning to the
sentence.
> But grammar separates meaning from non-meaning.
No, it does not. Correct grammar is a prerequisite to being able to
talk about the meaning of the text - but grammar does not give any meaning.
> If the executable can
> do anything, what meaning does it have? And can we devise rules? In the
> last analysis, no, because of the halting problem. But we can certainly
> have some rules. Otherwise no-one would be able to write a complex
> C program with defined behaviour.
Sure you can have rules for meaning - indeed, you have to have rules so
that the programmer and the implementer agree on the requested
behaviour. Those are listed under "Semantics" in the C standard, while
the formal grammar rules are under "Syntax" and the less formal ones are
under "Constraints" (which also covers some run-time and semantic rules
as well as syntactic ones).
> And in fact rules that warn about likely undefined behaviour are coded
> into many C compilers.
Yes. This does not mean they are part of the grammar.
Many compilers also warn about code that is perfectly correct
grammatically but may be a problem - even if it has defined 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?
>>
> Take this
>
> int x, y;
>
> y = x;
>
> The C compiler has to accept that. But of course it is incorrect, and most
> compilers will warn about it. We could and often do declare warnings to
> be errors, then it's "ungrammatical".
I think you could reasonably say that if you have a compiler that gives
a fatal error and refuses to compile this code, then the compiler is
implementing an extended grammar beyond that of standard C and including
a rule prohibiting such assignments. As C code, it is grammatically
correct despite the undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-02-11 08:01 -0500 |
| Message-ID | <Gme8E.91356$G14.45088@fx29.iad> |
| In reply to | #140851 |
On 2/11/19 4:48 AM, Malcolm McLean wrote: > One characteristic of undefined behaviour in C is that the program text > has an error in it. In many cases, undefined behavior results not from the 'text' of the program, but on the values in the various objects being worked on, which may come from input that is beyond the reach of the compiler. A common thread among most things defined as Undefined Behavior, is that they can NOT be simply detected at compile time. There are a few things defined as Undefined Behavior because there were two (or more) ways to handle the case, there were popular implementations doing both, and it would be hard to document the choices. There are also some that with a bit of work, the compiler could possible detect some cases, but there are perhaps others that might be hard to detect. Things like i = i++; (A more general case of this might be *p = (*q)++; (UB if p == q, ok otherwise). Rather than define the level of work the compiler needs to perform to detect the problem, is just defined as UB, and the compiler is free to add warnings for those cases it can detect.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-11 17:01 +0000 |
| Message-ID | <87sgwumf7m.fsf@bsb.me.uk> |
| In reply to | #140851 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 11 February 2019 02:35:09 UTC, Ben Bacarisse wrote:
>> 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.
>>
> One characteristic of undefined behaviour in C is that the program text
> has an error in it.
That's flipping your claim. Where there is UB in the execution of a
program, it might be reasonable to say that there is an error in the
text (though it might sometimes be better to say that there is an error
in the build or with the run-time data). But the term "ungrammatical"
must be a property of the text alone, and you can't determine UB from
the text.
Let's not lose sight of what I was objecting to:
The grammar is the set of rules that distinguish meaningful from
non-meaningful "productions".
You never said if "productions" are just productions (that's often the
case -- you frequently don't address questions directly) so this needs
to be clarified. What do the rules that you envisage say about
#include <stdio.h>
int main(void) { int i; if (scanf("%d", &i) == 1) printf("%d\n", i); }
? Is this text the result of meaningful of non-meaningful
"productions".
> Of course we can call the program text "grammatical" if by that we mean
> "accepted by the C compiler", and that's a legitimate use of the word.
I disagree here too. A C compiler can accept any text (#error excepted)
provided it issues any required diagnostics. It can say
"prog.f77" line 1: I see you are using the Fortran extension...
and off it goes, compiling Fortran. Obviously the Fortran text should
be "grammatical" but it's a stretch to call this grammatical C.
> But grammar separates meaning from non-meaning.
Your use of the term does. The way the term should be used here is
different: grammatically correct C texts do not always have well-defined
meanings.
<cut>
>> > 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?
>>
> Take this
>
> int x, y;
>
> y = x;
>
> The C compiler has to accept that.
No, I don't think it does. Can you say why you think it must?
> But of course it is incorrect, and most
> compilers will warn about it. We could and often do declare warnings to
> be errors, then it's "ungrammatical".
That has not answered my question. You referred to a rule that the
standard prohibits from being programmed in the compiler on a
technicality. I wanted to know what that rule is, and what technicality
in the standard you are referring to.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-11 11:30 -0800 |
| Message-ID | <f3219965-db37-4944-ad92-630d02117217@googlegroups.com> |
| In reply to | #140859 |
On Monday, 11 February 2019 17:02:01 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> > One characteristic of undefined behaviour in C is that the program text
> > has an error in it.
>
> That's flipping your claim. Where there is UB in the execution of a
> program, it might be reasonable to say that there is an error in the
> text (though it might sometimes be better to say that there is an error
> in the build or with the run-time data). But the term "ungrammatical"
> must be a property of the text alone, and you can't determine UB from
> the text.
>
> Let's not lose sight of what I was objecting to:
>
> The grammar is the set of rules that distinguish meaningful from
> non-meaningful "productions".
>
> You never said if "productions" are just productions (that's often the
> case -- you frequently don't address questions directly) so this needs
> to be clarified. What do the rules that you envisage say about
>
The production is the result of someone applying the grammar or something
similar to the grammar to communicate his meaning. If he makes a mistake,
or if the grammars in producer and receiver don't match, the result
won't be accepted.
>
> #include <stdio.h>
> int main(void) { int i; if (scanf("%d", &i) == 1) printf("%d\n", i); }
>
> ? Is this text the result of meaningful of non-meaningful
> "productions".
>
The text is a production. You produced it from the C grammar rules in
your head. It's meaningful to me in that I can see the intention,
and it is meaningful to the compiler in that it describes an executable
the compiler can spit out (it's "accepted"). But of course there are two
problems with it. If user enters a long string of digits that overflows
the range of an int then I believe it is undefined behaviour. Then it
doesn't return an integer to the environment.
The last really should be a grammar rule of the C compiler, and functions
which don't return their return type shouldn't be accepted. But it
isn't. However there's no constraint over the behaviour, so the program
doesn't describe the executable, so we can say it isn't grammatical.
With scanf, behaviour is described except for extreme inputs, we might
know that we won't have such inputs. But that security is not present in
the text. Note "ungrammatical" doesn't mean "total gibberish". It means
the program is wrong, and the C standard says that it is wrong, but
it's only mildly wrong - in fact is is ridiculous that you can't use
scanf("%d", &i) in a correct program and most people would.
>
> > Of course we can call the program text "grammatical" if by that we mean
> > "accepted by the C compiler", and that's a legitimate use of the word.
>
> I disagree here too. A C compiler can accept any text (#error excepted)
> provided it issues any required diagnostics. It can say
>
> "prog.f77" line 1: I see you are using the Fortran extension...
>
> and off it goes, compiling Fortran. Obviously the Fortran text should
> be "grammatical" but it's a stretch to call this grammatical C.
>
There's a sort of "anything goes clause" which is that texts not matching
the grammar can, according to the standard, be accepted by something
calling itself a C compiler, and can mean anything. Is that a grammar rule?
It's a marginal case.
>
> > But grammar separates meaning from non-meaning.
>
> Your use of the term does. The way the term should be used here is
> different: grammatically correct C texts do not always have well-defined
> meanings.
>
So that's the difference between the rich understanding or what grammar
is and the more restrictive understanding.
>
> >
> > int x, y;
> >
> > y = x;
> >
> > The C compiler has to accept that.
>
> No, I don't think it does. Can you say why you think it must?
>
As far as I know, the C compiler can't refuse to emit an executable
because a uninitialised variable is used as a rvalue. Certainly real
compiler don't do so, though they usually warn.
>
> That has not answered my question. You referred to a rule that the
> standard prohibits from being programmed in the compiler on a
> technicality. I wanted to know what that rule is, and what technicality
> in the standard you are referring to.
>
If the compiler warns about the above code, and we run with warnings
as errors, then the text is not accepted, so it's ungrammatical. That's
the technicality.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-12 01:40 +0000 |
| Message-ID | <87mun1n5s4.fsf@bsb.me.uk> |
| In reply to | #140860 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 11 February 2019 17:02:01 UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> > One characteristic of undefined behaviour in C is that the program text
>> > has an error in it.
>>
>> That's flipping your claim. Where there is UB in the execution of a
>> program, it might be reasonable to say that there is an error in the
>> text (though it might sometimes be better to say that there is an error
>> in the build or with the run-time data). But the term "ungrammatical"
>> must be a property of the text alone, and you can't determine UB from
>> the text.
>>
>> Let's not lose sight of what I was objecting to:
>>
>> The grammar is the set of rules that distinguish meaningful from
>> non-meaningful "productions".
>>
>> You never said if "productions" are just productions (that's often the
>> case -- you frequently don't address questions directly) so this needs
>> to be clarified. What do the rules that you envisage say about
>>
> The production is the result of someone applying the grammar or something
> similar to the grammar to communicate his meaning. If he makes a mistake,
> or if the grammars in producer and receiver don't match, the result
> won't be accepted.
>>
>> #include <stdio.h>
>> int main(void) { int i; if (scanf("%d", &i) == 1) printf("%d\n", i); }
>>
>> ? Is this text the result of meaningful of non-meaningful
>> "productions".
>>
> The text is a production. You produced it from the C grammar rules in
> your head. It's meaningful to me in that I can see the intention,
> and it is meaningful to the compiler in that it describes an executable
> the compiler can spit out (it's "accepted"). But of course there are two
> problems with it. If user enters a long string of digits that overflows
> the range of an int then I believe it is undefined behaviour.
We are at an impasse now. Your meaningful and non-meaningful
productions were supposed to correlate to undefined behaviour but you
don't seem to see the problem with that.
> Then it
> doesn't return an integer to the environment.
Yes it does.
> [...] However there's no constraint over the behaviour, so the program
> doesn't describe the executable, so we can say it isn't grammatical.
So how does "ungrammatical" correlate with undefined behavour?
> With scanf, behaviour is described except for extreme inputs, we might
> know that we won't have such inputs. But that security is not present in
> the text. Note "ungrammatical" doesn't mean "total gibberish". It means
> the program is wrong, and the C standard says that it is wrong, but
> it's only mildly wrong - in fact is is ridiculous that you can't use
> scanf("%d", &i) in a correct program and most people would.
Surely you see this was an example of my general point that the vast
majority of undefined behaviour is not a property of the text alone
whereas grammatical and ungrammatical are?
>> > Of course we can call the program text "grammatical" if by that we mean
>> > "accepted by the C compiler", and that's a legitimate use of the word.
>>
>> I disagree here too. A C compiler can accept any text (#error excepted)
>> provided it issues any required diagnostics. It can say
>>
>> "prog.f77" line 1: I see you are using the Fortran extension...
>>
>> and off it goes, compiling Fortran. Obviously the Fortran text should
>> be "grammatical" but it's a stretch to call this grammatical C.
>>
> There's a sort of "anything goes clause" which is that texts not matching
> the grammar can, according to the standard, be accepted by something
> calling itself a C compiler, and can mean anything. Is that a grammar rule?
> It's a marginal case.
The point it that "grammatical" == "accepted by the C compiler" is
essentially vacuous.
>> > But grammar separates meaning from non-meaning.
>>
>> Your use of the term does. The way the term should be used here is
>> different: grammatically correct C texts do not always have well-defined
>> meanings.
>>
> So that's the difference between the rich understanding or what grammar
> is and the more restrictive understanding.
That's just spin. Your term is not rich but vague. The study of formal
grammars on the other hand has led to a rich and practical branch of
mathematics. (That's my spin, by the way, in case you think I am making
a technical point here.)
>> > int x, y;
>> >
>> > y = x;
>> >
>> > The C compiler has to accept that.
>>
>> No, I don't think it does. Can you say why you think it must?
>>
> As far as I know, the C compiler can't refuse to emit an executable
> because a uninitialised variable is used as a rvalue. Certainly real
> compiler don't do so, though they usually warn.
You mean, no, you can't say why you think it must.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-12 01:51 -0800 |
| Message-ID | <3a070eb4-bc4f-4e8f-bcc6-2ac10ff9dd93@googlegroups.com> |
| In reply to | #140865 |
On Tuesday, 12 February 2019 01:40:29 UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > The text is a production. You produced it from the C grammar rules in > > your head. It's meaningful to me in that I can see the intention, > > and it is meaningful to the compiler in that it describes an executable > > the compiler can spit out (it's "accepted"). But of course there are two > > problems with it. If user enters a long string of digits that overflows > > the range of an int then I believe it is undefined behaviour. > > We are at an impasse now. Your meaningful and non-meaningful > productions were supposed to correlate to undefined behaviour but you > don't seem to see the problem with that. > That's one definition of "meaningful". Program with defined behaviour. There are other definitions you can also use, such as "accepted by the C compiler", or "intelligible to a human programmer reading the program". Then "ungrammaticsl" doesn't mean "totally meaningless", at least usually. You seem to be stuck in a black and white world. > > > Then it > > doesn't return an integer to the environment. > > Yes it does. > > > [...] However there's no constraint over the behaviour, so the program > > doesn't describe the executable, so we can say it isn't grammatical. > > So how does "ungrammatical" correlate with undefined behavour? > If it's got UB, it violates one of the rules of C. Now admittedly this is where the C grammar breaks down. But if it violates a rule, we can say it's ungrammatical. > > Surely you see this was an example of my general point that the vast > majority of undefined behaviour is not a property of the text alone > whereas grammatical and ungrammatical are? > You have a valid point here. But normally we have to assume that data supplied to a program can be of any physically possible sequence of bytes. So it becomes a property of the text alone. > > The point it that "grammatical" == "accepted by the C compiler" is > essentially vacuous. > Of course it's a simple definition. > > That's just spin. Your term is not rich but vague. The study of formal > grammars on the other hand has led to a rich and practical branch of > mathematics. (That's my spin, by the way, in case you think I am making > a technical point here.) > Computers can't talk.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-12 12:13 +0100 |
| Message-ID | <q3u9ov$6p8$1@dont-email.me> |
| In reply to | #140869 |
On 12/02/2019 10:51, Malcolm McLean wrote:
> On Tuesday, 12 February 2019 01:40:29 UTC, Ben Bacarisse wrote:
>> So how does "ungrammatical" correlate with undefined behavour?
>>
> If it's got UB, it violates one of the rules of C. Now admittedly this
> is where the C grammar breaks down. But if it violates a rule, we can
> say it's ungrammatical.
What about run-time behaviour?
If I write a program that inputs two non-zero numbers, divides them, and
prints the result, then I can do it with fully defined behaviour - a
program that is correct according to both C grammar and Malcolm grammar.
If the user enters two zeros, the program will have undefined behaviour.
#include <stdio.h>
int main(void) {
int x, y;
scanf("%i %i", &x, &y);
printf("%i / %i = %i\n", x, y, x / y);
return 0;
}
It is the same program - it has the same text, and is therefore surely
as grammatically correct as before? Certainly it will be perfectly
correct as far as C grammar is concerned.
Are you trying to tell us that it is not Malcolm-grammatical because it
is possible to enter "1 0" and get undefined behaviour? Is the same
program Malcolm-grammatical when you enter "1 1" but ungrammatical when
you enter "1 0" ? Is the classification of grammatical or ungrammatical
dependent on the input?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-12 03:39 -0800 |
| Message-ID | <b1271339-e732-4f01-befe-7e1900a6455b@googlegroups.com> |
| In reply to | #140870 |
On Tuesday, 12 February 2019 11:13:45 UTC, David Brown wrote:
> On 12/02/2019 10:51, Malcolm McLean wrote:
> > On Tuesday, 12 February 2019 01:40:29 UTC, Ben Bacarisse wrote:
>
> >> So how does "ungrammatical" correlate with undefined behavour?
> >>
> > If it's got UB, it violates one of the rules of C. Now admittedly this
> > is where the C grammar breaks down. But if it violates a rule, we can
> > say it's ungrammatical.
> What about run-time behaviour?
>
> If I write a program that inputs two non-zero numbers, divides them, and
> prints the result, then I can do it with fully defined behaviour - a
> program that is correct according to both C grammar and Malcolm grammar.
> If the user enters two zeros, the program will have undefined behaviour.
>
> #include <stdio.h>
>
> int main(void) {
> int x, y;
> scanf("%i %i", &x, &y);
> printf("%i / %i = %i\n", x, y, x / y);
> return 0;
> }
>
>
> It is the same program - it has the same text, and is therefore surely
> as grammatically correct as before? Certainly it will be perfectly
> correct as far as C grammar is concerned.
>
> Are you trying to tell us that it is not Malcolm-grammatical because it
> is possible to enter "1 0" and get undefined behaviour? Is the same
> program Malcolm-grammatical when you enter "1 1" but ungrammatical when
> you enter "1 0" ? Is the classification of grammatical or ungrammatical
> dependent on the input?
>
Grammar separates meaning from non-meaning. However if something is
"ungrammatical" that doesn't usually mean it is "total gibberish".
The program is wrong because it is not checking for zero, and the C
standard explicitly says that it is wrong. But it must be accepted by
the compiler.
So it's grammatical in one sense (it is accepted according to the grammar
rules in the C compiler), but not in another sense - the text doesn't
totally describe the behaviour of the program for all inputs. If we
input 0,0 we can't say what the behaviour will be, so it's not meaningful.
Now let's say we know that the compiler is set up so that division by zero
creates a message "Error: division by zero". Now is it grammatical? Again
it depends what we mean. If we intend the message to appear, it is now
grammatical according to the grammar rules in the compiler. But the C
standard has a rule that relying on that is disallowed. So it's not
grammatical according to the C standard.
I've give you a further point. Let's say we add, as in a real program we must,
a line saying printf("Input numerator and denominator\n"). Now if user
inputs 0 for the denominator, he's made a disallowed input. So is
the error by the user or by the program? We could say it's by the user,
then we've got to say it's a grammar error by user, and we could say
that the program is relieved of the obligation to make an appropriate
response.
Finally, is the term "grammar" redundant? No, because an input 20, 100
when user means 100 / 20 is an error, but it's not a grammar error. It
means something, but it means the wrong thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-12 16:27 +0100 |
| Message-ID | <q3uolv$lu$1@dont-email.me> |
| In reply to | #140871 |
On 12/02/2019 12:39, Malcolm McLean wrote:
> On Tuesday, 12 February 2019 11:13:45 UTC, David Brown wrote:
>> On 12/02/2019 10:51, Malcolm McLean wrote:
>>> On Tuesday, 12 February 2019 01:40:29 UTC, Ben Bacarisse wrote:
>>
>>>> So how does "ungrammatical" correlate with undefined behavour?
>>>>
>>> If it's got UB, it violates one of the rules of C. Now admittedly this
>>> is where the C grammar breaks down. But if it violates a rule, we can
>>> say it's ungrammatical.
>> What about run-time behaviour?
>>
>> If I write a program that inputs two non-zero numbers, divides them, and
>> prints the result, then I can do it with fully defined behaviour - a
>> program that is correct according to both C grammar and Malcolm grammar.
>> If the user enters two zeros, the program will have undefined behaviour.
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> int x, y;
>> scanf("%i %i", &x, &y);
>> printf("%i / %i = %i\n", x, y, x / y);
>> return 0;
>> }
>>
>>
>> It is the same program - it has the same text, and is therefore surely
>> as grammatically correct as before? Certainly it will be perfectly
>> correct as far as C grammar is concerned.
>>
>> Are you trying to tell us that it is not Malcolm-grammatical because it
>> is possible to enter "1 0" and get undefined behaviour? Is the same
>> program Malcolm-grammatical when you enter "1 1" but ungrammatical when
>> you enter "1 0" ? Is the classification of grammatical or ungrammatical
>> dependent on the input?
>>
> Grammar separates meaning from non-meaning. However if something is
> "ungrammatical" that doesn't usually mean it is "total gibberish".
> The program is wrong because it is not checking for zero, and the C
> standard explicitly says that it is wrong. But it must be accepted by
> the compiler.
The program is not wrong if the task is "input two non-zero numbers,
divide them, and print the result".
This very basic software design - functions (or programs, or modules, or
whatever) have pre-conditions and post-conditions, and invariants (if
they have state). The function is "correct" if it ensures the
post-conditions are satisfied whenever the pre-conditions are satisfied
(with the invariant being kept true).
Colloquially, it's fine for programs to give you "garbage in, garbage
out" behaviour - this was established in Babbage's day, if not before.
>
> So it's grammatical in one sense (it is accepted according to the grammar
> rules in the C compiler), but not in another sense - the text doesn't
> totally describe the behaviour of the program for all inputs. If we
> input 0,0 we can't say what the behaviour will be, so it's not meaningful.
The program is not written to accept 0, 0. Given that, the program is
correct. So the baseline must surely be that even with Malcolm-grammar,
the program is grammatical. If that is not the case, then your personal
term "grammar" has no useful meaning.
However, if you enter 0, 0 - going against the pre-conditions of the
program, outside its specifications - you get undefined behaviour. My
question, which you have failed to address, is if you think changing the
/input/ to the program had now made the program "un-Malcolm-grammatical"?
>
> Now let's say we know that the compiler is set up so that division by zero
> creates a message "Error: division by zero". Now is it grammatical? Again
> it depends what we mean.
Everyone here, except you, knows what "grammatical" means in regards to
programming languages in general and C in particular. So let's be clear
- you are trying to figure out what "Malcolm-grammatical" might mean here.
> If we intend the message to appear, it is now
> grammatical according to the grammar rules in the compiler. But the C
> standard has a rule that relying on that is disallowed. So it's not
> grammatical according to the C standard.
C has no such rule. You are imagining things. Perhaps you don't
actually know what the term "undefined behaviour" means.
The program is perfectly grammatical according to the C standards. If
you think that is not the case, I urge you to read a bit of Annex A in
the standards - learn what C grammar is and means. We can try to
discuss what "Malcolm-grammar" might mean, but the meaning of C grammar
is clear.
>
> I've give you a further point. Let's say we add, as in a real program we must,
> a line saying printf("Input numerator and denominator\n").
We don't need to add any such thing. That was not part of the
specification of the program.
> Now if user
> inputs 0 for the denominator, he's made a disallowed input. So is
> the error by the user or by the program? We could say it's by the user,
> then we've got to say it's a grammar error by user, and we could say
> that the program is relieved of the obligation to make an appropriate
> response.
The program was specified for non-zero numbers. It has no specified
behaviour when the numbers are zero. (As specified, that includes a
numerator of 0 as well as the denominator.)
Thus giving the program a zero is a misuse of the program.
>
> Finally, is the term "grammar" redundant? No, because an input 20, 100
> when user means 100 / 20 is an error, but it's not a grammar error. It
> means something, but it means the wrong thing.
>
Your idea about "grammar" is so wide as to be redundant - if it has a
meaning at all, it merely means "correct".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-12 07:57 -0800 |
| Message-ID | <7e7d97f8-9bc8-444f-81f7-ef629c43a3bf@googlegroups.com> |
| In reply to | #140873 |
On Tuesday, 12 February 2019 15:28:12 UTC, David Brown wrote: > > Your idea about "grammar" is so wide as to be redundant - if it has a > meaning at all, it merely means "correct". > Just defining what the word actually means isn't very fruitful, though people have had huge difficulty with it. It means "allowed by the language". Which is a requirement for being correct. It's better to think in terms of meaningful versus non-meaningful.
[toc] | [prev] | [next] | [standalone]
Page 7 of 19 — ← Prev page 1 … 5 6 [7] 8 9 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web