Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #133735 > unrolled thread
| Started by | skybuck2000@hotmail.com |
|---|---|
| First post | 2018-08-13 12:53 -0700 |
| Last post | 2018-10-10 18:24 -0700 |
| Articles | 20 on this page of 354 — 27 participants |
Back to article view | Back to comp.lang.c
>< swap operator skybuck2000@hotmail.com - 2018-08-13 12:53 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-08-13 16:05 -0400
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-13 13:46 -0700
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-08-14 11:19 +0300
Re: >< swap operator skybuck2000@hotmail.com - 2018-08-14 06:16 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 07:50 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 16:59 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 10:46 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 20:03 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 11:37 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 21:16 +0200
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-14 11:32 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 16:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-15 11:32 +0200
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-01 07:46 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 05:20 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 13:58 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 14:08 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-02 15:35 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:43 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:51 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:08 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 10:52 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 17:57 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 13:27 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 11:52 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 20:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 15:56 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:05 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:26 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:36 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:47 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:14 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:37 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:02 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:25 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 10:52 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 14:29 +0200
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:52 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:31 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 16:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:43 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 04:25 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 20:44 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 11:53 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 05:15 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 10:56 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:47 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:01 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-04 22:15 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 16:19 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 21:42 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 15:01 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 23:59 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:54 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 18:03 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 21:08 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 20:31 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-05 15:59 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 21:18 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 12:19 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 19:49 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 12:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 14:19 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 06:56 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:30 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-09 13:17 +0200
C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:07 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 14:27 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 00:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-10 02:03 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 01:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 02:09 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 12:39 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 16:24 +0100
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 15:55 +0000
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 09:42 -0700
Re: C idioms Wouter Verhelst <w@uter.be> - 2018-10-11 19:23 +0200
Re: C idioms jameskuyper@alumni.caltech.edu - 2018-10-11 11:11 -0700
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 12:05 -0700
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 17:53 +0100
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 10:38 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-12 00:14 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 19:26 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 16:38 +0200
Re: C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 15:23 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 20:31 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 20:18 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:11 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-09 20:50 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:58 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 22:34 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:10 +0200
Re: C idioms (Was: >< swap operator) jameskuyper@alumni.caltech.edu - 2018-10-09 14:45 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:07 +0200
Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 07:56 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 10:32 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Ike Naar <ike@iceland.freeshell.org> - 2018-10-10 13:44 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:52 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Wouter Verhelst <w@uter.be> - 2018-10-10 17:47 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:18 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:22 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 23:58 +0200
Re: Hmmm... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 07:51 -0600
Re: Hmmm... gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:53 +0000
Re: Hmmm... David Brown <david.brown@hesbynett.no> - 2018-10-10 17:21 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:57 +0000
Re: C idioms (Was: >< swap operator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-10 12:29 -0400
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:07 +0200
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-09 14:50 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:13 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:56 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 15:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 15:17 +0100
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:49 +0000
Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:59 +0000
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) Bart <bc@freeuk.com> - 2018-10-10 16:09 +0100
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) nobody@example.org (Scott) - 2018-10-10 17:29 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 16:01 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:29 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-10 17:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 17:11 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 23:15 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:16 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 23:23 +0100
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:31 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 15:32 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:24 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 10:52 +0200
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 09:59 -0600
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:26 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:48 +0000
Return values of fork() (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:51 +0000
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 15:20 +0000
You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:28 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:23 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:22 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 15:58 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:17 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 16:42 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) Wouter Verhelst <w@uter.be> - 2018-10-11 16:53 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 20:11 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:20 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:15 -0700
Re: Return values of fork() Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-11 14:42 -0600
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-09 16:18 -0600
Re: C idioms gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 22:28 +0000
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:58 +0000
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 07:48 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 16:42 +0100
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:40 +0200
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 12:38 -0700
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 23:41 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:38 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 15:04 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:37 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 16:58 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 12:17 -0400
Grammar police! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 20:37 +0000
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 09:31 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 18:09 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 14:05 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 22:35 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:56 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-08 10:48 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 12:09 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 16:00 +0000
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:44 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:39 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 20:08 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:22 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-09 09:25 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 20:43 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 20:15 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 22:26 +0200
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 21:09 +0000
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 15:18 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 07:55 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:24 +0200
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:19 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 16:26 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-10 10:59 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 19:53 +0100
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 18:00 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:10 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 11:29 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-08 04:41 -0700
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:56 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 08:36 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:34 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 21:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 22:00 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 00:47 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 01:11 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 02:47 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-09 00:49 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 11:28 +0100
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:00 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:28 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:49 -0700
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 20:00 -0600
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:07 -0700
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 23:35 +0000
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:49 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-06 16:18 +0200
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-06 14:48 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 12:53 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:38 +0000
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 15:56 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 16:53 -0700
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-07 17:07 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:24 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:30 +0100
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 19:12 -0600
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 18:26 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 19:41 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:05 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 02:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-07 12:41 +0200
100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 00:22 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 01:55 +0100
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:58 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 11:51 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 13:09 +0100
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 05:26 -0700
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 05:40 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:49 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 06:27 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 12:47 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 09:03 -0400
Re: 100% of the user base... (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:47 +0000
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 10:17 +0200
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:20 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 10:58 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 12:09 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 03:11 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 07:56 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 14:25 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 08:39 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:47 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:30 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:41 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:56 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:00 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 12:34 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:48 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 13:55 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-05 11:20 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:45 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 21:39 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 08:51 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-25 14:18 -0800
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 15:46 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:05 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:16 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:09 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:18 -0400
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:32 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:34 -0400
Of course it is crazy! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:17 +0000
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 18:30 +0000
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:48 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 15:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 13:55 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:14 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 16:18 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 17:27 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:28 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 14:46 +0000
When pigs fly... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 16:10 +0000
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:35 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:46 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:15 +0000
6K years??? (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 13:20 +0000
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:28 -0400
Re: 6K years??? (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-05 17:53 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:56 -0400
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:17 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:21 -0700
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:50 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:52 -0400
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 13:05 -0400
Re: 6K years??? (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:42 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 15:59 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:45 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-04 11:22 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 20:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:28 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:59 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-04 09:56 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 06:03 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 14:37 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 09:51 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 15:39 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:05 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:09 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 16:22 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:29 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 20:52 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 14:57 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 16:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 00:09 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 19:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:21 +0200
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:43 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:01 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 14:29 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:37 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:07 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:01 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:45 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:09 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:11 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:22 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:17 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:24 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 15:04 +0000
Re: >< swap operator Niles Rogoff <eternal-september@niles.xyz> - 2018-10-03 18:28 +0000
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-08-14 11:50 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-14 17:07 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:22 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:34 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:09 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:24 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 04:51 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 05:06 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-15 04:21 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-08-15 14:43 +0100
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 07:08 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-08-15 16:52 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-08-15 15:51 +0000
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-01 14:59 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-02 03:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 11:43 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-02 07:27 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:43 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 11:01 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:54 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 12:39 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:10 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:24 -0700
Page 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-09 22:26 +0200 |
| Message-ID | <ppj2u1$vfv$1@dont-email.me> |
| In reply to | #136500 |
On 09/10/18 21:15, Bart wrote:
> On 09/10/2018 19:43, David Brown wrote:
>> On 09/10/18 18:25, Keith Thompson wrote:
>
>>> Not really. How would you enforce the prohibition on
>>> x = 42;
>>> where x is defined as "const" or is an enumeration constant using just
>>> syntax rules?
>>>
>>
>> I am reasonably sure it would be possible - but it would involve a
>> good deal more complex syntax grammar.
>
> Much more complex. I think the Algol68 spec tried to do something along
> these lines, with a result that is inaccessible with few people being
> able to understand it.
>
> You'd have to have something
>> equivalent to "modifiable lvalues" as a type of term ("non-terminal"
>> may be the right word in BNF parlance) that is distinct from
>> "unary-expression" as defined in the C standards. Perhaps it would
>> easier if you did away with "const" - some people (for reasons I can't
>> fathom) don't like it anyway.
>
>> How would I do this? I don't think I would - I think the way the C
>> standard defines the language is a reasonable compromise between
>> BNF-style syntax rules and descriptive constraints.
>
> I really can't see the point. For example, take this simple piece of code:
> A = B;
>
> The syntax tells you this has a valid 'shape' for a statement. But
> you're talking here about a syntax that would somehow require that A is
> a modifiable lvalue.
>
> But what about the fact that A has to have been defined, and be in a
> visible scope?
>
> Or what about the fact that A and B need to be of compatible types? For
> example, this won't work when A and B are both arrays.
>
> On the other hand, syntax /can/ be used to enforce some things that
> would make coding safer and less error prone. For example, this could be
> made illegal:
>
> A == B;
Yes, but a constraint would make that much easier - "An expression
statement shall either make an assignment to a modifiable lvalue, or
consist of a function call whose result is discarded. No more than one
assignment may be made in a single expression statement". Modify it to
suit your tastes.
>
> So could this:
>
> int const const const typedef T,U,V(int,int),*W;
>
> So much low-hanging fruit, but you disregard all those possibilities by
> choosing to keep all that complexity in the set of legal programs, and
> suggest adding even more complexity in the grammar.
>
I am not disregarding any possibilities - I have said absolutely nothing
about this sort of thing. You said that the C grammar allowed odd
things like "(2 + 2) = 3" - I said the syntax rules allow it, but the
constraints disallow it, and both are needed to define the C language.
And I said that I think it would be possible to have syntax rules that
disallow such things - without any comment as to whether that would be a
good idea. How can you possibly leap from that to thinking I approve of
the kind of monstrosities that you enjoy pulling out as though C
programmers write code like that?
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-10-08 21:09 +0000 |
| Message-ID | <slrn3jpgprnhrn.ms3.ike@iceland.freeshell.org> |
| In reply to | #136431 |
On 2018-10-08, Bart <bc@freeuk.com> wrote:
> On 08/10/2018 17:00, Ike Naar wrote:
>> term can be (2+2), and expr can be 3, so the grammar allows
>
> Actually, term can't be something+something, only expr can be.
That is true, but term can be (something+something),
that is, a parenthesized something+something.
The grammar has
term = '(' expr ')'
and expr can be 2+2, so it looks like term can be (2+2).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2018-10-08 15:18 -0700 |
| Message-ID | <72ff4541-b5db-4c94-acc5-118b252470ff@googlegroups.com> |
| In reply to | #136443 |
On Monday, October 8, 2018 at 2:09:25 PM UTC-7, Ike Naar wrote:
> On 2018-10-08, Bart <bc@freeuk.com> wrote:
> > On 08/10/2018 17:00, Ike Naar wrote:
> >> term can be (2+2), and expr can be 3, so the grammar allows
> >
> > Actually, term can't be something+something, only expr can be.
>
> That is true, but term can be (something+something),
> that is, a parenthesized something+something.
>
> The grammar has
>
> term = '(' expr ')'
>
> and expr can be 2+2, so it looks like term can be (2+2).
You can write (2+2) but the first thing a compiler will
so is make than (4).
4;
is a no-op (might as well be ;).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-08 07:55 -0700 |
| Message-ID | <lnzhvozdvv.fsf@kst-u.example.com> |
| In reply to | #136418 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> C has a number of types of statement. These include "return"
> statements, "for" statements, and so on. All statement types either end
> in a semicolon as part of the statement itself, or are immediately
> followed by another statement.
Not quite. A compound statement does not end in a semicolon and need
not be immediately followed by another statement.
And I think you may have misstated that last clause. For example, in
if (condition) x = 42;
the statement `x = 42;` doesn't follow the if statement. It's part of
the if statement.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-09 11:24 +0200 |
| Message-ID | <pphs3j$4pk$2@dont-email.me> |
| In reply to | #136424 |
On 08/10/18 16:55, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> C has a number of types of statement. These include "return" >> statements, "for" statements, and so on. All statement types either end >> in a semicolon as part of the statement itself, or are immediately >> followed by another statement. > > Not quite. A compound statement does not end in a semicolon and need > not be immediately followed by another statement. Yes, you are correct. > > And I think you may have misstated that last clause. For example, in > > if (condition) x = 42; > > the statement `x = 42;` doesn't follow the if statement. It's part of > the if statement. > Thanks for the correction.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-10-08 07:19 -0700 |
| Message-ID | <9a94884e-c237-4675-b988-35efc9e938c9@googlegroups.com> |
| In reply to | #136401 |
On Sunday, October 7, 2018 at 5:35:26 PM UTC-4, Bart wrote:
> On 07/10/2018 22:05, jameskuyper@alumni.caltech.edu wrote:
> > On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote:
>
> >> If it does, then the separation from expression to statement is weak.
> >
> > I can't figure out the point of your objection. Would you feel happier
> > if the syntax for an expression-statement was more obtrusive?:
> >
> > _Begin_Statement newline tab a = b + c newline _End_Statement
>
> Maybe.
Why? Looking at your examples below, every single one could be converted
to use the above syntax, and it would still be an expression-statement
with the same exact problems.
> I can see from the rest of your post that you don't understand what it
> is that I'm talking about.
That's because the words you chose to explain it were wrong described a
non-existent problem rather than the problems that were actually
bothering you.
> So let's try a different tack. I don't like
> being able to write lines like the following at statement level:
Would you be any happier with any of the expressions in those
expression-statements if they were the left operand of a comma
expression? If so, why?
If not, the problem is NOT that an expression can be converted to an
expression-statement by adding a ';' - the problem is with the
expressions themselves.
> cond ? f() : g();
I have no idea what you find objectionable about that. It could also be
written as an if statment, but this approach is simpler. I wouldn't use
that method, but I don't see anything especially wrong with it.
> 1234;
> "abcd";
> a + b;
[out of sequence, because they're covered by the same solution]
> A[i];
> a == b;
Those could all be covered by adding the following constraint:
"The expression in an expression-statement must have side-effects."
> puts("one") + puts("two");
That could be covered by adding a constraint:
"Two expressions with observable behavior shall not be indeterminately
sequenced."
That comes very close to requiring that all programs be strictly
conforming, and would seriously restrict multi-threaded code.
> f()+1;
Assuming that f() might have side-effects, I see no easy way to word a
constraint to cover that case
> 10,20,30,40;
That could be covered by a constraint:
"The left operand of a comma expression shall have side-effects."
Let me make it clear: I am not proposing that any of the above
constraints be added to the standard. I'm mentioning them to point out
that you want to disallow such code, the fix has nothing to do with
conversions from expressions to expression statements.
I believe that some people who write automatic code generators might
find these constraints inconvenient - they'd have to add special case
code to suppression generation of lines that violate those constraints.
Such codes is currently counting on the compiler to eliminate the
unnecessary code; and if it doesn't, the unnecessary code should still
take very little time to execute.
> puts("three"), puts("four"), puts(five");
Again, I have no idea what bothers you about that. The commas could be
replaced by semicolons without changing the meaning of the code, but
there's nothing intrinsically wrong with having multiple ways of doing
something. It would unnecessarily complicate the standard to add wording
that would prohibit such uses.
> These are all expressions followed by a semicolon. They count as
> expressions because if you take each line, and remove the semicolon, it
> can be used anywhere an expression is expected.
They don't count as expressions until you remove the semicolon.
And those facts have nothing to do with why you dislike those statements.
> The reason I don't like them is partly that some just don't make sense,
> as they work out a value that is then discarded. And therefore are a
> likely a mistake.
>
> And partly because I think they some are bad form to use as statements,
> for example using ?: instead of if-else, or comma operators instead of
> semicolons.
>
> But C makes it just too easy to do it. To turn any arbitrary expression
> as a statement like this, you just write it. And follow it with
> semicolon, or a comma if you want a list of them.
That's incorrect. The following rewrite is closer to the truth:
To turn any arbitrary expression into a statement, you just write it
followed by a semicolon.
It's not a statement until you add that semicolon, and putting a comma
rather than a semicolon does not make it a statement, it makes it the
left operand of a comma expression.
> So, what is there in C that would stop you doing that?
>
> If the answer is Nothing, (other than some compilers may say something)
> then that's what I call a weak demarcation.
And that's what I call misleading terminology, since the problems have
nothing to do with the ability to convert expressions into expression
statements. As indicated by the solutions I listed above, they can be
solved without any reference to that issue.
...
> >> Take a working program. Find a place where a semicolon follows what
> >> could be used as an expression in an expression context. Now remove the
> >> semicolon. If it still compiles,
> >
> > That will never happen. There is no grammar rules that permit two
> > consecutive expressions to occur with nothing in between them. The
> > closest you can get is the comma operator.
>
> Take these two statements:
>
> a = b;(c+b);
>
> if you remove the first semicolon, you get this:
>
> a = b(c+d);
>
> which is syntactically sound,
Only if a is a function pointer and b is either a function or a function
pointer. Please note that resulting combination does not in any sense
contain the first expression. 'b' has been converted to be the left
operand of a function call expression.
> ... and might still compile if the types of
> everything involved are suitable.
>
> Or a simpler example:
>
> "abc"; "def";
>
> becomes:
>
> "abc" "def";
>
> which is now one term.
Yes, and neither expression survived the merger. Where before you had
pointers to two different strings, you now have a single pointer to a
larger string.
> > I can't. "expression" (6.5.17p1) and "statement" (6.8p1) are key
>
> I'm not interested in grammar. Only in what it means in making it easier
> to write nonsense code, as I showed in my examples.
But you expressed your objections to that nonsense code by making
irrelevant and incorrect statements about elements of the C grammar.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 16:26 +0100 |
| Message-ID | <OGKuD.4287$RM7.4127@fx24.am4> |
| In reply to | #136423 |
On 08/10/2018 15:19, jameskuyper@alumni.caltech.edu wrote:
> On Sunday, October 7, 2018 at 5:35:26 PM UTC-4, Bart wrote:
>> cond ? f() : g();
>
> I have no idea what you find objectionable about that.
Have you seen the abuse to which this is put?
For example, people use ?: to avoid writing 'if', but if they have no
need for 'else', then they will just have a dummy '0' in the code,
sometimes disguised via a macro, for no reason other than to satisfy the
requirements of ?:.
If you have to have a conditional statement, then you use the 'if'
statement.
I have no idea what /you/ find objectionable about that.
(Actually that's not true; I suspect you /can't/ find it objectionable
simply because C's grammar allows it. And you're unwilling to entertain
any criticisms about it.)
It could also be
> written as an if statment, but this approach is simpler. I wouldn't use
> that method, but I don't see anything especially wrong with it.
I wrote the above before I read this. This approach is just
inappropriate. ?: has compact for suitable for use in expressions. It is
unsuitable for use as a statement. It would be like driving a Sinclair
C5 (a tiny electric car) amongst trucks on the highway, if you have code
where you mix regular if-else with ?: at the same block level.
>> puts("one") + puts("two");
>
> That could be covered by adding a constraint:
> "Two expressions with observable behavior shall not be indeterminately
> sequenced."
Then you're banning instances of f()+g(), not just as standalone
statements, but everywhere.
>> puts("three"), puts("four"), puts(five");
>
> Again, I have no idea what bothers you about that. The commas could be
> replaced by semicolons without changing the meaning of the code, but
> there's nothing intrinsically wrong with having multiple ways of doing
> something.
No? People are bypassing the normal style of enclosing multiple
statements within {...}, by making sneaky use of the comma operator, for
the special case of when all the statements are also expressions.
There's nothing sloppy about that?
> It would unnecessarily complicate the standard to add wording
> that would prohibit such uses.
The standard, or the grammar?
>> These are all expressions followed by a semicolon. They count as
>> expressions because if you take each line, and remove the semicolon, it
>> can be used anywhere an expression is expected.
>
> They don't count as expressions until you remove the semicolon.
> And those facts have nothing to do with why you dislike those statements.
It doesn't have anything to do with anything else either.
Let's have a go this, turning ordinary code like:
if (cond1) {
stmt1;
stmt2;
} else if (cond2) {
stmt3;
stmt4;
}
into:
cond1 ? stmt1, stmt2 : cond2 ? stmt3, stmt3 : 0;
That's a first draft, when I realise I have no idea about precedences of
?: and comma, or even between ?: and another ?:. If I add brackets:
(cond ? (stmt, stmt2) : (cond2 ? (stmt3, stmt4) : 0));
Then it looks naff. If I remove the unnecessary ones, then it requires
that everyone else is familiar with the precedences to make sense of it.
And there's that funny 0 at the end.
And /this/ is toy code with everything very tidy; imagine what it's like
with real code where ?s and :s will be lost in the noise.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-10-10 10:59 -0700 |
| Message-ID | <8aa18876-b5ad-43f1-978d-a628ec577c87@googlegroups.com> |
| In reply to | #136426 |
On Monday, October 8, 2018 at 11:26:48 AM UTC-4, Bart wrote:
> On 08/10/2018 15:19, jameskuyper@alumni.caltech.edu wrote:
> > On Sunday, October 7, 2018 at 5:35:26 PM UTC-4, Bart wrote:
...
> >> puts("one") + puts("two");
> >
> > That could be covered by adding a constraint:
> > "Two expressions with observable behavior shall not be indeterminately
> > sequenced."
>
> Then you're banning instances of f()+g(), not just as standalone
> statements, but everywhere.
Well, yes. What do you find objectionable about puts("one") + puts("two"), that wouldn't be equally objectionable if the two puts() calls occurred in two different functions whose evaluation was indeterminately sequenced? Either way, you can get either "one\ntwo\n" or "two\none\n". If that ambiguity wasn't the point of your objection, what was?
...
> > It would unnecessarily complicate the standard to add wording
> > that would prohibit such uses.
>
> The standard, or the grammar?
Every case where I thought I understood your complaint, it is more easily addressed by a constraint than by a syntax rule. It could easily take thousands of extra rules to express, in the grammar, restrictions that can be easily expressed in just a few words as constraints.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 19:53 +0100 |
| Message-ID | <8JNuD.7499$NF7.4452@fx14.am4> |
| In reply to | #136423 |
On 08/10/2018 15:19, jameskuyper@alumni.caltech.edu wrote:
> On Sunday, October 7, 2018 at 5:35:26 PM UTC-4, Bart wrote:
> Those could all be covered by adding the following constraint:
> "The expression in an expression-statement must have side-effects."
>
>> puts("one") + puts("two");
>
> That could be covered by adding a constraint:
> "Two expressions with observable behavior shall not be indeterminately
> sequenced."
> That comes very close to requiring that all programs be strictly
> conforming, and would seriously restrict multi-threaded code.
>
>> f()+1;
>
> Assuming that f() might have side-effects, I see no easy way to word a
> constraint to cover that case
>
>> 10,20,30,40;
>
> That could be covered by a constraint:
> "The left operand of a comma expression shall have side-effects."
I've just made a 15-minute mod to my C compiler to disallow all the
constructs I objected to. All those examples I posted are rejected.
Normal code isn't.
It really isn't very difficult: after reading a statement, if the AST
node is in a prohibited list of node types, then it's an error. I can't
see that wording in the standard to the same effect is much harder.
Of course that's not practical to apply to the language because probably
most programs will stop working. But you gave the impression that this
was somehow hard to do.
(The method I used is not efficient as it involves a linear search. With
20 minutes more, I can store a flag for each type of node indicating if
it's an allowed expression when reading statements. Then the check after
reading a statement-expression, in C syntax, would be:
if (prohibited[p->tag]) ...
)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2018-10-07 18:00 -0400 |
| Message-ID | <ppdvl7$5qv$1@dont-email.me> |
| In reply to | #136400 |
On 10/07/2018 05:05 PM, jameskuyper@alumni.caltech.edu wrote:
...
> The C standard distinguishes 12 kinds of statements. The expression-
> statement, null-statement, and the 4 kinds of just statement must end
"just" should have been "jump".
I should have included the do-while() statement.
> with a semicolon. The other 6 do not.
And as a result, 6 should be 5.
I should have said "do not have to end in a semicolon." In four of those
five statement types, the last element of the statement is sub-statement
- if that statement ends in a semicolon, then so will the whole
statement. But if it's a compound statement, it won't.
The only statement type that can never end in a semicolon is a compound
statement.
...
> That will never happen. There is no grammar rules that permit two
"There are ..."
> So, I can replace the statement "a+b+c;" in the following code:
That should have been "a = b+c;".
> if(error) a = b+c;
> else printf("Success\n");
>
> and replace it with the expression "d > f"? When I tried it, my compiler objected:
"and replace it" should have been cut from that line.
> syntactically correct C code. Try it: convert anything that the C
SB "convert anything in a C program that the C grammar"
Sorry - I had a 3-year-old on my lap trying to get my attention. I tried
to finish it as soon as possible, as a result I left in some errors I
would have removed if I spent more time polishing it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-07 17:10 -0700 |
| Message-ID | <lnefd11eod.fsf@kst-u.example.com> |
| In reply to | #136400 |
jameskuyper@alumni.caltech.edu writes:
> On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote:
[...]
>> Take a working program. Find a place where a semicolon follows what
>> could be used as an expression in an expression context. Now remove the
>> semicolon. If it still compiles,
>
> That will never happen. There is no grammar rules that permit two
> consecutive expressions to occur with nothing in between them. The
> closest you can get is the comma operator.
There are some cases. For example:
a + b;
+c;
and
a + b;
*c;
Of course these cases have no relevance to whatever point Bart is
failing to make. They depend on two different operators using the
same symbol. In both cases, the expression (part of an expression
statement) on the second line is no longer an expression after the
semicolon is removed. (C's grammar happens to be what I think of as
"dense", meaning roughly that it's relatively easy for arbitrary
sequences of token to be syntactically valid.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 01:25 +0100 |
| Message-ID | <duxuD.13048$e55.429@fx39.am4> |
| In reply to | #136408 |
On 08/10/2018 01:10, Keith Thompson wrote: > jameskuyper@alumni.caltech.edu writes: >> On Sunday, October 7, 2018 at 1:10:01 PM UTC-4, Bart wrote: > [...] >>> Take a working program. Find a place where a semicolon follows what >>> could be used as an expression in an expression context. Now remove the >>> semicolon. If it still compiles, >> >> That will never happen. There is no grammar rules that permit two >> consecutive expressions to occur with nothing in between them. The >> closest you can get is the comma operator. > > There are some cases. For example: > a + b; > +c; > and > a + b; > *c; > > Of course these cases have no relevance to whatever point Bart is > failing to make. Or others are failing to understand, being hung up on the exact grammar used to define expressions and statements. The fact is that most expressions you will write, are either meaningless as statements, or are ill-advised as statements, but C will let you write them anyway. Let's try once more: think of a Venn diagram, one circle with all expressions, another with statements (other statement-expressions). And the overlapping part contains all those expressions that can meaningfully be written as standalone statements (namely assignment; augmented-assignment; increment; and function call). This is how /I/ would demarcate them (and do so elsewhere). Except that C allows ALL of those expressions to overlap with statements. There is no demarcation of expressions that would be nonsensical as statements, from statements. (What the original point was about where this came up, I've long forgotten.) -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-08 02:51 +0100 |
| Message-ID | <87zhvpfbob.fsf@bsb.me.uk> |
| In reply to | #136410 |
Bart <bc@freeuk.com> writes: > Let's try once more: think of a Venn diagram, one circle with all > expressions, another with statements (other statement-expressions). > > And the overlapping part contains all those expressions that can > meaningfully be written as standalone statements (namely assignment; > augmented-assignment; increment; and function call). There are none in C -- no expressions can be written as standalone statements. Ironically, there are some in your language in that I think you said that ++x is a statement but it is also an expression. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 11:29 +0100 |
| Message-ID | <tkGuD.4830$xH4.1977@fx33.am4> |
| In reply to | #136413 |
On 08/10/2018 02:51, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Let's try once more: think of a Venn diagram, one circle with all
>> expressions, another with statements (other statement-expressions).
>>
>> And the overlapping part contains all those expressions that can
>> meaningfully be written as standalone statements (namely assignment;
>> augmented-assignment; increment; and function call).
>
> There are none in C -- no expressions can be written as standalone
> statements.
So if I take the expression "a[i+1]" which I can use like this inside
the argument list here:
f(a[i+1]);
you say I can't take the same expression and write it as a standalone
statement like this:
a[i+1];
Even though, actually, I can.
OK. Obviously you have something in mind, which I'm not getting (either
an elaborate wind-up, or playing the C-Standards minutiae game), so I'm
going to bail out here.
> Ironically, there are some in your language in that I think
> you said that ++x is a statement but it is also an expression.
(A more obvious example, because different syntax is needed, is ?: and
if-else:
In an expression I must write '(a | b() | c())'. All operands are
expressions. The 'else' part is mandatory.
In a statement I must write 'if a then b() else c() fi'. Last two
branches must be statements. The 'else' part is optional.
The first uses an AST node id of 'j_ifx', the second has 'j_if'.
(Originally, both were interchangeable, but the usage pattern was mostly
as I have it now, so that was a facility that was rarely used.)
In the case of ++x or x++ the AST id is j_preincr or j_postincr when
used in an expression, or j_incr for both when used a statement by itself.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-10-08 04:41 -0700 |
| Message-ID | <1ffa6f1d-5656-47e3-bb22-9f2cf1b1a813@googlegroups.com> |
| In reply to | #136419 |
On Monday, 8 October 2018 11:29:55 UTC+1, Bart wrote: > OK. Obviously you have something in mind, which I'm not getting (either > an elaborate wind-up, or playing the C-Standards minutiae game), so I'm > going to bail out here. If a programming language has defined meanings for terms, it's not a game to suggest that discussion of the language uses those terms accurately.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-10-08 07:56 -0700 |
| Message-ID | <91fc8f50-bd5b-464e-9f50-3cb6331b1e63@googlegroups.com> |
| In reply to | #136419 |
On Monday, October 8, 2018 at 6:29:55 AM UTC-4, Bart wrote:
> On 08/10/2018 02:51, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> Let's try once more: think of a Venn diagram, one circle with all
> >> expressions, another with statements (other statement-expressions).
> >>
> >> And the overlapping part contains all those expressions that can
> >> meaningfully be written as standalone statements (namely assignment;
> >> augmented-assignment; increment; and function call).
> >
> > There are none in C -- no expressions can be written as standalone
> > statements.
>
> So if I take the expression "a[i+1]" which I can use like this inside
> the argument list here:
>
> f(a[i+1]);
>
> you say I can't take the same expression and write it as a standalone
> statement like this:
>
> a[i+1];
No, we're saying that in order to write in standalone form like that, it must be part of an expression-statement terminated by a semicolon. That expression-statement is NOT an expression (and is, in particular, not the original expression) because expressions are not allowed to have semicolons on their ends.
>
> Even though, actually, I can.
You added a semi-colon, converting it into an expression statement. Yes, you can do that. You cannot use the expression by itself as a statement without adding that semicolon. Give it a try:
A[i+1]
printf("Hello! World.\n");
> OK. Obviously you have something in mind, which I'm not getting (either
> an elaborate wind-up, or playing the C-Standards minutiae game),
123456789012345678901234567890123456789012345678901234567890123456789012
The difference between an expression and an expression-statement is a
single semi-colon. You might consider that a piece of minutia, but it's
minutia you absolutely need to understand to write valid C code. Write
an expression-statement in a location where an expression is required,
it won't work. Write an expression in a context where an expression-
statement would be legal will occasionally work, but only at the cost of
radically changing the meaning of the expression (such changing b from a
function pointer to a function call using that pointer, as shown in an
example you gave earlier).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-08 08:36 -0700 |
| Message-ID | <lnva6czc03.fsf@kst-u.example.com> |
| In reply to | #136419 |
Bart <bc@freeuk.com> writes:
[...]
> So if I take the expression "a[i+1]" which I can use like this inside
> the argument list here:
>
> f(a[i+1]);
>
> you say I can't take the same expression and write it as a standalone
> statement like this:
>
> a[i+1];
>
> Even though, actually, I can.
This will be my last attempt to explain this to you. I'm almost
certainly wasting my time.
To avoid any confusion, I'm using `...` to separate C code from English
text.
`a[i+1]` is an expression. It is not, and cannot be, a statement.
`a[i+1];` is a statement. It is not, and cannot be, an expression.
You cannot use `a[i+1]` as a statement. You can turn it into a
statement by adding a semicolon.
It is the semicolon that makes the difference, your insistence on
minimizing it or ignoring it notwithstanding.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 17:34 +0100 |
| Message-ID | <4GLuD.5373$Do.2586@fx31.am4> |
| In reply to | #136427 |
On 08/10/2018 16:36, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> So if I take the expression "a[i+1]" which I can use like this inside
>> the argument list here:
>>
>> f(a[i+1]);
>>
>> you say I can't take the same expression and write it as a standalone
>> statement like this:
>>
>> a[i+1];
>>
>> Even though, actually, I can.
>
> This will be my last attempt to explain this to you. I'm almost
> certainly wasting my time.
>
> To avoid any confusion, I'm using `...` to separate C code from English
> text.
>
> `a[i+1]` is an expression. It is not, and cannot be, a statement.
>
> `a[i+1];` is a statement. It is not, and cannot be, an expression.
>
> You cannot use `a[i+1]` as a statement. You can turn it into a
> statement by adding a semicolon.
>
> It is the semicolon that makes the difference, your insistence on
> minimizing it or ignoring it notwithstanding.
But, so what? Why is this such a big deal?
Yes, statements need ";" at the end. And?
The fact is, if someon wants to evaluate a[i+1] and then discard the
result, they just write:
a[i+1];
Yes, with a semicolon, but why is that even a issue?
Yet Ben said this:
" There are none in C -- no expressions can be written as standalone
statements."
Which is completely misleading. Is it completely impossible to write
a[i+1] as a standalone statement, or not? That remark suggests it is not
possible, yet you can do it.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-08 21:35 +0100 |
| Message-ID | <87o9c4w50v.fsf@bsb.me.uk> |
| In reply to | #136430 |
Bart <bc@freeuk.com> writes:
> Yet Ben said this:
>
> " There are none in C -- no expressions can be written as standalone
> statements."
>
> Which is completely misleading. Is it completely impossible to write
> a[i+1] as a standalone statement, or not? That remark suggests it is
> not possible, yet you can do it.
Why do you object to all the accurate wordings, such as "any expression
can be turned into a statement by appending a semicolon"? Does that
wording somehow not allow you state your latest gripe about C?
This is why I've said you appear to argue like a politician. Whatever
your technical point is (I think it's that C allows pointless statements
by permitting all expression forms to appear in an expression
statement), it has become completely lost in your desire to push a turn
of phrase which puts, for you, the right spin on the issue.
I see no reason at all that we could all agree on these facts:
(a) C's grammar defines syntactic entities for expressions and for
statements.
(b) No token sequence that will parse as an expression will also parse
as a statement -- and vice versa.
(c) If E is a token sequence that parses as an expression, E ; parses as
a statement (often called a statement expression).
(d) Many syntactically valid expression statements are pointless because
they can have no effect on the program's execution.
Do you really insist on some other way of stating these facts, or do you
actually dispute that they are facts?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-08 22:00 +0100 |
| Message-ID | <%zPuD.4831$xE.4383@fx22.am4> |
| In reply to | #136441 |
On 08/10/2018 21:35, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Yet Ben said this:
>>
>> " There are none in C -- no expressions can be written as standalone
>> statements."
>>
>> Which is completely misleading. Is it completely impossible to write
>> a[i+1] as a standalone statement, or not? That remark suggests it is
>> not possible, yet you can do it.
>
> Why do you object to all the accurate wordings, such as "any expression
> can be turned into a statement by appending a semicolon"?
I object to this whole line of debate since I can't see what the need
for a semicolon brings to it or how it is relevant.
But as it happens, it's not accurate - you can't locate any expression
in a program, and add a semicolon to it.
You can only have such expressions where a regular statement can legally
go. Most such statements (exceptions include labels and {}) will
necessarily end with semicolon. So its presence there following an
expression is no surprise.
Does that
> wording somehow not allow you state your latest gripe about C?
>
> This is why I've said you appear to argue like a politician. Whatever
> your technical point is (I think it's that C allows pointless statements
> by permitting all expression forms to appear in an expression
> statement), it has become completely lost in your desire to push a turn
> of phrase which puts, for you, the right spin on the issue.
>
> I see no reason at all that we could all agree on these facts:
>
> (a) C's grammar defines syntactic entities for expressions and for
> statements.
>
> (b) No token sequence that will parse as an expression will also parse
> as a statement -- and vice versa.
>
> (c) If E is a token sequence that parses as an expression, E ; parses as
> a statement (often called a statement expression).
>
> (d) Many syntactically valid expression statements are pointless because
> they can have no effect on the program's execution.
>
> Do you really insist on some other way of stating these facts, or do you
> actually dispute that they are facts?
I might agree on (a) and (d). But I disagree with (b) and (c). Regarding
(b):
For the 'i+1' part of 'a[i+1]', my implementation makes a call to a
function called readexpression().
For the 'i+1' part of 'i+1;', my implementation also makes a call to
readexpression().
(For the 'i+1' part of 'f(i+1)' a different function 'readassignexpr()'
is called, as comma operators are not allowed here. readexpression()
calls readassignexpr().)
In both those cases, the caller of readexpression might need to do
something with the token that terminated the expression. For 'a[i+1]',
it will check that it is ']'. For 'a+1', it will check that it is ';'.
Otherwise there is nothing inherently different.
Regarding (c), if I turn a[i+1] into a[i+1;] then that's not going to work.
Now you're going to tell me how I'm wrong because the standard says
something different, and only one of us can be right.
--
bart
[toc] | [prev] | [next] | [standalone]
Page 10 of 18 — ← Prev page 1 … 8 9 [10] 11 12 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web