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 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-07 07:59 +1300 |
| Message-ID | <gc0p4jFgcocU3@mid.individual.net> |
| In reply to | #140648 |
On 07/02/2019 06:39, Scott wrote: > On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> How is const, in the C subset of C++, any different? > > Is that what they're teaching nowadays? > > C is not a subset of C++. C came first, C++ was derived from it, and > the two have diverged a good deal since then. It's trivial to write a > correct C program that is a very, very wrong C++ program. I wrote "the C subset of C++" not "C is a subset of C++" -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 12:07 +0100 |
| Message-ID | <q3ef5e$olr$1@dont-email.me> |
| In reply to | #140601 |
On 06/02/2019 10:42, Malcolm McLean wrote:
> On Tuesday, 5 February 2019 21:14:28 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote:
>>>> You are being willfully obtuse, const in C++ is a significant
>>>> improvement over const in C.
>>>>
>>> It's significantly more complex.
>>>
>>> It's no longer true, as it is in C, that a correct program cannot
>>> be turned into an incorrect program by const-qualifying or const-
>>> dequalifying identifiers.
>>
>> Can you clarify what you mean by that?
>>
>> I can turn this correct program:
>>
>> int main(void) {
>> int n = 10;
>> n = 20;
>> }
>>
>> into an incorrect program by const-qualifying n.
>>
> What I (actually Dennis Ritchie) meant is this.
>
> We have
>
> double total_salaries(const Employee *emp, int N);
>
> The function works, and it doesn't corrupt the employee array.
> Now we can take the const away, and the function must still work
> correctly. We can add it again, and it still works correctly.
>
So what you meant to say is that any program that is correct in C with
"const", will remain correct when "const" is removed entirely?
Adding "const" to a correct C program is unlikely to result in a correct
program - you don't get to count "restoring the const you took away" as
adding "const".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 03:42 -0800 |
| Message-ID | <0953b1d5-c0c3-4d49-82a3-ecc516b1b19a@googlegroups.com> |
| In reply to | #140608 |
On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: > > So what you meant to say is that any program that is correct in C with > "const", will remain correct when "const" is removed entirely? > > Adding "const" to a correct C program is unlikely to result in a correct > program - you don't get to count "restoring the const you took away" as > adding "const". > "Correct" means "with correct behaviour". It assumes "grammatical".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 13:36 +0100 |
| Message-ID | <q3ekc6$lnf$1@dont-email.me> |
| In reply to | #140610 |
On 06/02/2019 12:42, Malcolm McLean wrote: > On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: >> >> So what you meant to say is that any program that is correct in C with >> "const", will remain correct when "const" is removed entirely? >> >> Adding "const" to a correct C program is unlikely to result in a correct >> program - you don't get to count "restoring the const you took away" as >> adding "const". >> > "Correct" means "with correct behaviour". It assumes "grammatical". > Yes - so what? Adding "const" to a correct C program is unlikely to result in a correct program - one that will compile and do the same job as before. Keith gave a simple example. Do you agree with that? (Please answer yes or no, rather than posting more pointless tangents.) You said that in C (but not C++) adding "const" qualifiers to a correct program does not make it incorrect. Again, answer yes or no - remembering that your post was made in public.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 04:44 -0800 |
| Message-ID | <fa802f39-ec39-458e-8bf3-c008e48cef14@googlegroups.com> |
| In reply to | #140612 |
On Wednesday, 6 February 2019 12:36:31 UTC, David Brown wrote: > On 06/02/2019 12:42, Malcolm McLean wrote: > > On Wednesday, 6 February 2019 11:07:35 UTC, David Brown wrote: > >> > >> So what you meant to say is that any program that is correct in C with > >> "const", will remain correct when "const" is removed entirely? > >> > >> Adding "const" to a correct C program is unlikely to result in a correct > >> program - you don't get to count "restoring the const you took away" as > >> adding "const". > >> > > "Correct" means "with correct behaviour". It assumes "grammatical". > > > > Yes - so what? > > Adding "const" to a correct C program is unlikely to result in a correct > program - one that will compile and do the same job as before. Keith > gave a simple example. Do you agree with that? (Please answer yes or > no, rather than posting more pointless tangents.) > > You said that in C (but not C++) adding "const" qualifiers to a correct > program does not make it incorrect. Again, answer yes or no - > remembering that your post was made in public. > Take these 3 sentences 1) "Water is an element" 2) "Water is composed of hydrogen and oxygen" 3) "Composed hydrogen water oxygen" 1) is incorrect. 2) is correct. 3) is neither correct not incorrect. It's not grammatical English, it can't communicate false or true information at all. Now adding const to a program cannot make it incorrect. It can make it non-grammatical (uncompileable). Then the program is neither correct nor incorrect, it can't have any behaviour.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-06 05:40 -0800 |
| Message-ID | <30065f8f-0b5b-4d17-846f-4fa63051cd0e@googlegroups.com> |
| In reply to | #140614 |
On Wednesday, February 6, 2019 at 7:44:24 AM UTC-5, Malcolm McLean wrote:
...
> Now adding const to a program cannot make it incorrect.
Keith has shown a counter-example.
> It can make
> it non-grammatical (uncompileable).
Equating non-grammatical with uncompilable is nonsense. A grammatical
program can fail to compile, for instance because of a constraint
violation. An implementation is also free to compile a program despite
the fact that it contains a grammar error (after generating the
mandatory diagnostic).
Keith's counter-example, with "const" added, remains fully compatible
with the C grammar. It's a constraint violation, which means that a
diagnostic is required. An implementation is not required to complete
translation of such a program, but neither is it prohibited from doing
so. If it does complete translation of such a program, and you choose to
execute that program, the behavior is undefined. That doesn't make the
program ungrammatical. It doesn't even guarantee that it's uncompilable.
Furthermore, it's trivial to create an example of a correct program that
has undefined behavior if you add "const", without containing any
constraint violations or syntax errors:
i.c:
#include <stdlib.h>
int *geti(void)
{
static /* const */ int i = EXIT_FAILURE;
return (int *)&i;
}
main.c:
#include <stdlib.h>
extern int *geti(void);
int main(void)
{
*geti() = EXIT_SUCCESS;
return *geti();
}
Add "const" before the second "int" in i.c, and the resulting program
remains grammatically correct, containing no syntax errors and no
constraint violations. Neither i.c nor main.c contain any feature that a
compiler could point to in order to justify refusing compilation.
However, the combined program has undefined behavior (6.7.3p6). On my
system, that program compiled and executed with the return status of 0,
which is one of the options permitted when the behavior is undefined.
> Then the program is neither correct
> nor incorrect, it can't have any behaviour.
In the case of both my example and Keith's, the behavior is undefined,
which means that ANY behavior is permitted.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 05:50 -0800 |
| Message-ID | <cf9e4199-c23c-47e3-abe1-79dd713d484e@googlegroups.com> |
| In reply to | #140620 |
On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote: > On Wednesday, February 6, 2019 at 7:44:24 AM UTC-5, Malcolm McLean wrote: > ... > > Now adding const to a program cannot make it incorrect. > > Keith has shown a counter-example. > > > It can make > > it non-grammatical (uncompileable). > > Equating non-grammatical with uncompilable is nonsense. A grammatical > program can fail to compile, for instance because of a constraint > violation. > What's the constraint upon?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-06 06:03 -0800 |
| Message-ID | <55932be0-42ab-4f5d-89b9-ff9d595d4596@googlegroups.com> |
| In reply to | #140623 |
On Wednesday, February 6, 2019 at 8:50:40 AM UTC-5, Malcolm McLean wrote: > On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote: > > On Wednesday, February 6, 2019 at 7:44:24 AM UTC-5, Malcolm McLean wrote: > > ... > > > Now adding const to a program cannot make it incorrect. > > > > Keith has shown a counter-example. > > > > > It can make > > > it non-grammatical (uncompileable). > > > > Equating non-grammatical with uncompilable is nonsense. A grammatical > > program can fail to compile, for instance because of a constraint > > violation. > > > What's the constraint upon? It's a constraint upon C programs, which must be satisfied in order to guarantee acceptance with defined behavior and without a diagnostic message when translated by a conforming implementation of C. Some constraints could be replaced with grammar rules, but only at the expense of making the grammar far more complicated - that does't make them grammar rules. And many constraints have to do with the semantics of the program, rather than it's syntax.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 06:22 -0800 |
| Message-ID | <1cf079e1-2356-45f7-88d5-6e2e3b2c3c64@googlegroups.com> |
| In reply to | #140627 |
On Wednesday, 6 February 2019 14:04:05 UTC, James Kuyper wrote: > On Wednesday, February 6, 2019 at 8:50:40 AM UTC-5, Malcolm McLean wrote: > > On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote: > > > On Wednesday, February 6, 2019 at 7:44:24 AM UTC-5, Malcolm McLean wrote: > > > ... > > > > Now adding const to a program cannot make it incorrect. > > > > > > Keith has shown a counter-example. > > > > > > > It can make > > > > it non-grammatical (uncompileable). > > > > > > Equating non-grammatical with uncompilable is nonsense. A grammatical > > > program can fail to compile, for instance because of a constraint > > > violation. > > > > > What's the constraint upon? > > It's a constraint upon C programs, which must be satisfied in order to > guarantee acceptance with defined behavior and without a diagnostic > message when translated by a conforming implementation of C. Some > constraints could be replaced with grammar rules, but only at the > expense of making the grammar far more complicated - that does't make > them grammar rules. And many constraints have to do with the semantics > of the program, rather than it's syntax. > It's a constraint on the C program. So a constraint on the grammar. That makes the constraints grammar rules. As you say, they could be replaced by "grammar rules", meaning the rules you feed to the low-level parser, at a cost of making the low level parser more complicated. "Grammar" has quite a broad meaning. I was obviously using it in the broader sense rather than in the more restrictive sense it's sometimes used in.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 15:54 +0100 |
| Message-ID | <q3esfv$54v$1@dont-email.me> |
| In reply to | #140629 |
On 06/02/2019 15:22, Malcolm McLean wrote: > On Wednesday, 6 February 2019 14:04:05 UTC, James Kuyper wrote: >> On Wednesday, February 6, 2019 at 8:50:40 AM UTC-5, Malcolm McLean wrote: >>> On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote: >>>> On Wednesday, February 6, 2019 at 7:44:24 AM UTC-5, Malcolm McLean wrote: >>>> ... >>>>> Now adding const to a program cannot make it incorrect. >>>> >>>> Keith has shown a counter-example. >>>> >>>>> It can make >>>>> it non-grammatical (uncompileable). >>>> >>>> Equating non-grammatical with uncompilable is nonsense. A grammatical >>>> program can fail to compile, for instance because of a constraint >>>> violation. >>>> >>> What's the constraint upon? >> >> It's a constraint upon C programs, which must be satisfied in order to >> guarantee acceptance with defined behavior and without a diagnostic >> message when translated by a conforming implementation of C. Some >> constraints could be replaced with grammar rules, but only at the >> expense of making the grammar far more complicated - that does't make >> them grammar rules. And many constraints have to do with the semantics >> of the program, rather than it's syntax. >> > It's a constraint on the C program. Yes. > So a constraint on the grammar. No. >That > makes the constraints grammar rules. And therefore, no. > As you say, they could be replaced > by "grammar rules", meaning the rules you feed to the low-level parser, > at a cost of making the low level parser more complicated. No. That is not close to what James wrote. Why don't you try reading his post again, and /concentrating/ this time? Try to understand the words James used instead of pretending they say what you want them to say. > "Grammar" has quite a broad meaning. I was obviously using it in the > broader sense rather than in the more restrictive sense it's sometimes > used in. > You seem to be misunderstanding one of the key aspects of communication - you need to use the same terms with the same meaning as other people. If you are going to make up your own concepts as you go along, changing the meaning of your words to try to wriggle out of your mistakes, then there is little point in making posts in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 10:40 -0800 |
| Message-ID | <ln36ozv3vw.fsf@kst-u.example.com> |
| In reply to | #140629 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It's a constraint on the C program. So a constraint on the grammar. That
> makes the constraints grammar rules. As you say, they could be replaced
> by "grammar rules", meaning the rules you feed to the low-level parser,
> at a cost of making the low level parser more complicated.
> "Grammar" has quite a broad meaning. I was obviously using it in the
> broader sense rather than in the more restrictive sense it's sometimes
> used in.
You were using the word "grammar" incorrectly.
Do we need to define a new term "Malcolm-grammar"? Or would you prefer
to use words the way the rest of us do, at least when you're trying to
communicate?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 05:56 -0800 |
| Message-ID | <9d6896dc-a369-4eb0-a93c-c0317a19908e@googlegroups.com> |
| In reply to | #140620 |
On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote:
>
> Furthermore, it's trivial to create an example of a correct program that
> has undefined behavior if you add "const", without containing any
> constraint violations or syntax errors:
>
> i.c:
> #include <stdlib.h>
> int *geti(void)
> {
> static /* const */ int i = EXIT_FAILURE;
> return (int *)&i;
> }
>
>
> main.c:
> #include <stdlib.h>
> extern int *geti(void);
>
> int main(void)
> {
> *geti() = EXIT_SUCCESS;
> return *geti();
> }
>
>
> Add "const" before the second "int" in i.c, and the resulting program
> remains grammatically correct, containing no syntax errors and no
> constraint violations. Neither i.c nor main.c contain any feature that a
> compiler could point to in order to justify refusing compilation.
> However, the combined program has undefined behavior (6.7.3p6). On my
> system, that program compiled and executed with the return status of 0,
> which is one of the options permitted when the behavior is undefined.
>
No, a program with UB is not "grammatical". The C grammar breaks down
and fails to describe the behaviour.
However you do make the program UB by adding the "const", so it is a kind
of counter-example.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 16:04 +0100 |
| Message-ID | <q3et1h$8nj$1@dont-email.me> |
| In reply to | #140626 |
On 06/02/2019 14:56, Malcolm McLean wrote:
> On Wednesday, 6 February 2019 13:40:47 UTC, James Kuyper wrote:
>>
>> Furthermore, it's trivial to create an example of a correct program that
>> has undefined behavior if you add "const", without containing any
>> constraint violations or syntax errors:
>>
>> i.c:
>> #include <stdlib.h>
>> int *geti(void)
>> {
>> static /* const */ int i = EXIT_FAILURE;
>> return (int *)&i;
>> }
>>
>>
>> main.c:
>> #include <stdlib.h>
>> extern int *geti(void);
>>
>> int main(void)
>> {
>> *geti() = EXIT_SUCCESS;
>> return *geti();
>> }
>>
>>
>> Add "const" before the second "int" in i.c, and the resulting program
>> remains grammatically correct, containing no syntax errors and no
>> constraint violations. Neither i.c nor main.c contain any feature that a
>> compiler could point to in order to justify refusing compilation.
>> However, the combined program has undefined behavior (6.7.3p6). On my
>> system, that program compiled and executed with the return status of 0,
>> which is one of the options permitted when the behavior is undefined.
(A C implementation could do a whole-program analysis at link time, note
that undefined behaviour is inevitable if the program is run, and reject
it at that point.)
>>
> No, a program with UB is not "grammatical". The C grammar breaks down
> and fails to describe the behaviour.
There are some kinds of UB that could be handled by a more complex
grammar describing the C language. The grammar rules of C /could/ have
precluded invalid multi-byte characters in the source code, or
converting a pointer to something other than an integer or pointer type.
But they don't preclude them. If they had, then there would be no need
to call them "undefined behaviour" - the code would simply not be
syntactically valid C.
Most types of undefined behaviour, however, have nothing to do with the
grammar. There is nothing grammatically wrong with "x = y / z;", but if
"z" is zero than there is undefined behaviour.
> However you do make the program UB by adding the "const", so it is a kind
> of counter-example.
>
It is a counter-example to your misconceptions, yes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-07 00:26 +0000 |
| Message-ID | <87h8dgh2ao.fsf@bsb.me.uk> |
| In reply to | #140635 |
David Brown <david.brown@hesbynett.no> writes:
> On 06/02/2019 14:56, Malcolm McLean wrote:
<snip C example>
>> No, a program with UB is not "grammatical". The C grammar breaks down
>> and fails to describe the behaviour.
>
> There are some kinds of UB that could be handled by a more complex
> grammar describing the C language. The grammar rules of C /could/ have
> precluded invalid multi-byte characters in the source code, or
> converting a pointer to something other than an integer or pointer type.
> But they don't preclude them. If they had, then there would be no need
> to call them "undefined behaviour" - the code would simply not be
> syntactically valid C.
>
> Most types of undefined behaviour, however, have nothing to do with the
> grammar. There is nothing grammatically wrong with "x = y / z;", but if
> "z" is zero than there is undefined behaviour.
>
>> However you do make the program UB by adding the "const", so it is a kind
>> of counter-example.
>
> It is a counter-example to your misconceptions, yes.
This thread is heading towards a Humpty Dumpty discussion where
"grammatical" means what any poster wants it to mean, no more and no
less.
But for fun, here is a program that is made "incorrect" by adding const.
Neither the const-free nor the const-qualified version have any
undefined behaviour, nor do either contain any constraint violations or
grammatical errors. It is simply a program to print "Hello world!", but
it goes wrong when a single const is added. In case anyone likes this
sort of puzzle (I don't) I've put it after some spoiler space, and used
rot 13:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
#vapyhqr <fgqvb.u>
vag znva(ibvq)
{
pune *f = "jbeyq", **c = &f;
cevags("Uryyb %f!\a", _Trarevp(c, pune **: *c, qrsnhyg: "fnvybe"));
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-07 09:39 +0100 |
| Message-ID | <q3gqsb$md2$1@dont-email.me> |
| In reply to | #140671 |
On 07/02/2019 01:26, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 06/02/2019 14:56, Malcolm McLean wrote: > <snip C example> >>> No, a program with UB is not "grammatical". The C grammar breaks down >>> and fails to describe the behaviour. >> >> There are some kinds of UB that could be handled by a more complex >> grammar describing the C language. The grammar rules of C /could/ have >> precluded invalid multi-byte characters in the source code, or >> converting a pointer to something other than an integer or pointer type. >> But they don't preclude them. If they had, then there would be no need >> to call them "undefined behaviour" - the code would simply not be >> syntactically valid C. >> >> Most types of undefined behaviour, however, have nothing to do with the >> grammar. There is nothing grammatically wrong with "x = y / z;", but if >> "z" is zero than there is undefined behaviour. >> >>> However you do make the program UB by adding the "const", so it is a kind >>> of counter-example. >> >> It is a counter-example to your misconceptions, yes. > > This thread is heading towards a Humpty Dumpty discussion where > "grammatical" means what any poster wants it to mean, no more and no > less. Agreed. I am wary of continuing - we may end up trying to figure out how the Malcolm-grammar of Malcolm-C relates to the grammar of C, and I'm not sure there is much to be gained down that path. > > But for fun, here is a program that is made "incorrect" by adding const. > Neither the const-free nor the const-qualified version have any > undefined behaviour, nor do either contain any constraint violations or > grammatical errors. It is simply a program to print "Hello world!", but > it goes wrong when a single const is added. In case anyone likes this > sort of puzzle (I don't) I've put it after some spoiler space, and used > rot 13: > More interestingly, you have shown that with C11 it is no longer the case that removing all "const" keywords from a correct, working C program will result in an equally correct C program with the same functionality. If you have a _Generic that distinguishes between a const and a non-const version of a type, then removing "const" will change the program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 10:57 -0800 |
| Message-ID | <lntvhftojn.fsf@kst-u.example.com> |
| In reply to | #140635 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> There are some kinds of UB that could be handled by a more complex
> grammar describing the C language. The grammar rules of C /could/ have
> precluded invalid multi-byte characters in the source code, or
> converting a pointer to something other than an integer or pointer type.
> But they don't preclude them. If they had, then there would be no need
> to call them "undefined behaviour" - the code would simply not be
> syntactically valid C.
[...]
I don't think pointer conversion is an example of what you're talking
about. Converting a pointer to something other than an integer or
pointer type is a constraint violation. I don't see how that could be
enforced in the grammar. Given:
some_type x = (some_other_type)y;
we can't tell whether the constraint is violated without knowing how
some_time and some_other_type are defined.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-07 19:55 +0000 |
| Message-ID | <87tvhfe5ls.fsf@bsb.me.uk> |
| In reply to | #140742 |
Keith Thompson <kst-u@mib.org> writes: > David Brown <david.brown@hesbynett.no> writes: > [...] >> There are some kinds of UB that could be handled by a more complex >> grammar describing the C language. The grammar rules of C /could/ have >> precluded invalid multi-byte characters in the source code, or >> converting a pointer to something other than an integer or pointer type. >> But they don't preclude them. If they had, then there would be no need >> to call them "undefined behaviour" - the code would simply not be >> syntactically valid C. > [...] > > I don't think pointer conversion is an example of what you're talking > about. Converting a pointer to something other than an integer or > pointer type is a constraint violation. I don't see how that could be > enforced in the grammar. Given: > > some_type x = (some_other_type)y; > > we can't tell whether the constraint is violated without knowing how > some_time and some_other_type are defined. Since every constraint violation is checkable at compile time, there will be some grammar that will only parse C programs with no such violations. It will almost certainly be impractical, not context-free and require an exponential-time algorithm to parse, but I think I am right in saying that such a grammar exists. Even so, as I think you will agree, talking about grammars for C that are not what's in Appendix A of the standard is just going to sow confusion. And MM's more general remark that a program with UB being "ungrammatical" (the scare quotes are his and note worthy) is just baffling. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-07 23:27 +0100 |
| Message-ID | <q3ibbs$18f$2@dont-email.me> |
| In reply to | #140743 |
On 07/02/2019 20:55, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> There are some kinds of UB that could be handled by a more complex >>> grammar describing the C language. The grammar rules of C /could/ have >>> precluded invalid multi-byte characters in the source code, or >>> converting a pointer to something other than an integer or pointer type. >>> But they don't preclude them. If they had, then there would be no need >>> to call them "undefined behaviour" - the code would simply not be >>> syntactically valid C. >> [...] >> >> I don't think pointer conversion is an example of what you're talking >> about. Converting a pointer to something other than an integer or >> pointer type is a constraint violation. I don't see how that could be >> enforced in the grammar. Given: >> >> some_type x = (some_other_type)y; >> >> we can't tell whether the constraint is violated without knowing how >> some_time and some_other_type are defined. > > Since every constraint violation is checkable at compile time, there > will be some grammar that will only parse C programs with no such > violations. It will almost certainly be impractical, not context-free > and require an exponential-time algorithm to parse, but I think I am > right in saying that such a grammar exists. > That is the point I was trying to make - but made much better. Thank you. > Even so, as I think you will agree, talking about grammars for C that > are not what's in Appendix A of the standard is just going to sow > confusion. And MM's more general remark that a program with UB being > "ungrammatical" (the scare quotes are his and note worthy) is just > baffling. > Indeed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-07 16:35 -0800 |
| Message-ID | <lnpns3t8us.fsf@kst-u.example.com> |
| In reply to | #140743 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> There are some kinds of UB that could be handled by a more complex
>>> grammar describing the C language. The grammar rules of C /could/ have
>>> precluded invalid multi-byte characters in the source code, or
>>> converting a pointer to something other than an integer or pointer type.
>>> But they don't preclude them. If they had, then there would be no need
>>> to call them "undefined behaviour" - the code would simply not be
>>> syntactically valid C.
>> [...]
>>
>> I don't think pointer conversion is an example of what you're talking
>> about. Converting a pointer to something other than an integer or
>> pointer type is a constraint violation. I don't see how that could be
>> enforced in the grammar. Given:
>>
>> some_type x = (some_other_type)y;
>>
>> we can't tell whether the constraint is violated without knowing how
>> some_time and some_other_type are defined.
>
> Since every constraint violation is checkable at compile time, there
> will be some grammar that will only parse C programs with no such
> violations. It will almost certainly be impractical, not context-free
> and require an exponential-time algorithm to parse, but I think I am
> right in saying that such a grammar exists.
Hmm, perhaps my concept of "grammar" is too narrow. Certainly the
grammar in Annex A of the standard couldn't resolve whether the above
assignment is type-consistent. (And as others have pointed out,
typedefs introduce some conceptual problems.) Are you thinking of an
"attribute grammar"?
https://en.wikipedia.org/wiki/Attribute_grammar
> Even so, as I think you will agree, talking about grammars for C that
> are not what's in Appendix A of the standard is just going to sow
> confusion. And MM's more general remark that a program with UB being
> "ungrammatical" (the scare quotes are his and note worthy) is just
> baffling.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-08 02:02 +0000 |
| Message-ID | <87a7j7ca13.fsf@bsb.me.uk> |
| In reply to | #140753 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Keith Thompson <kst-u@mib.org> writes: >> >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> There are some kinds of UB that could be handled by a more complex >>>> grammar describing the C language. The grammar rules of C /could/ have >>>> precluded invalid multi-byte characters in the source code, or >>>> converting a pointer to something other than an integer or pointer type. >>>> But they don't preclude them. If they had, then there would be no need >>>> to call them "undefined behaviour" - the code would simply not be >>>> syntactically valid C. >>> [...] >>> >>> I don't think pointer conversion is an example of what you're talking >>> about. Converting a pointer to something other than an integer or >>> pointer type is a constraint violation. I don't see how that could be >>> enforced in the grammar. Given: >>> >>> some_type x = (some_other_type)y; >>> >>> we can't tell whether the constraint is violated without knowing how >>> some_time and some_other_type are defined. >> >> Since every constraint violation is checkable at compile time, there >> will be some grammar that will only parse C programs with no such >> violations. It will almost certainly be impractical, not context-free >> and require an exponential-time algorithm to parse, but I think I am >> right in saying that such a grammar exists. > > Hmm, perhaps my concept of "grammar" is too narrow. Certainly the > grammar in Annex A of the standard couldn't resolve whether the above > assignment is type-consistent. (And as others have pointed out, > typedefs introduce some conceptual problems.) Are you thinking of an > "attribute grammar"? > > https://en.wikipedia.org/wiki/Attribute_grammar It might be possible with an attribute grammar but I don't recall enough details. (I did once describe C with one -- old C -- and it could easily handle the typedef issue.) But my confidence comes from that fact that the most general, type-0 grammars, are in some rather hand-wavy way, "Turing complete". They can describe any recursively enumerable language, even undeciable ones like the set of C programs that terminate. Somewhere along the line from trivial regular grammars to type-0 grammars that have unrestricted production rules is one that can capture C programs that have no constraint violations. (I admit I was hoping not to have to back this up since I can't do much more than the above.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web