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 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-10 14:49 +0000 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <0kovD.236192$RN2.22510@fx40.iad> |
| In reply to | #136537 |
Bart <bc@freeuk.com> writes: >On 10/10/2018 14:55, David Brown wrote: >The only downside of switch, is requiring that break, which is just a >very poor design choice in the language. lint(1) has been available for four decades. It's not a poor design choice, unless one doesn't understand the language, in which case they shouldn't be programming in it.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-10-10 14:59 +0000 |
| Subject | Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) |
| Message-ID | <ppl44d$6ac$4@news.xmission.com> |
| In reply to | #136541 |
In article <0kovD.236192$RN2.22510@fx40.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >Bart <bc@freeuk.com> writes: >>On 10/10/2018 14:55, David Brown wrote: > >>The only downside of switch, is requiring that break, which is just a >>very poor design choice in the language. > >lint(1) has been available for four decades. It's not a poor design >choice, unless one doesn't understand the language, in which case they >shouldn't be programming in it. Heh heh. I might agree with Bart that it was a "poor" design choice, but I think he overplayed his hand by adding in the "very". You should Google what Mark Twain had to say about the use of the word "very". Personally, I like the C way, since it allows for fall-through, which, although rare, does occasionally come in handy. Note that in classic Bourne shell, the 'case' statement doesn't have fall-through at all. Bash corrects this omission (adds a way to get fall-through when you want it). Maybe C should have been like that. I.e., no fall-through by default, but a way to get it if you want it. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Snicker
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-10 16:09 +0100 |
| Subject | Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) |
| Message-ID | <bDovD.16050$RM7.4286@fx24.am4> |
| In reply to | #136545 |
On 10/10/2018 15:59, Kenny McCormack wrote:
> In article <0kovD.236192$RN2.22510@fx40.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 10/10/2018 14:55, David Brown wrote:
>>
>>> The only downside of switch, is requiring that break, which is just a
>>> very poor design choice in the language.
>>
>> lint(1) has been available for four decades. It's not a poor design
>> choice, unless one doesn't understand the language, in which case they
>> shouldn't be programming in it.
>
> Heh heh. I might agree with Bart that it was a "poor" design choice, but
> I think he overplayed his hand by adding in the "very".
>
> You should Google what Mark Twain had to say about the use of the word "very".
>
> Personally, I like the C way, since it allows for fall-through, which,
> although rare, does occasionally come in handy. Note that in classic
> Bourne shell, the 'case' statement doesn't have fall-through at all. Bash
> corrects this omission (adds a way to get fall-through when you want it).
A poor feature I think (but not enough to be /very/ poor) (assume
implied break):
switch (x) {
case a:
s1;
case c:
s3;
fallthrough;
case b:
s2;
case d:
s4;
}
Somebody looks at this (imagine it's much busier), and decides it would
be better if the case labels and their respective blocks were ordered. So:
switch (x) {
case a:
s1;
case b:
s2;
case c:
s3;
fallthrough;
case d:
s4;
}
But now s3 is followed by s4 rather than s2.
A better way is to use:
fallthough b;
although now 'fallthrough' is not appropriate. So perhaps 'continue b'.
Now that statement is more immune from case-blocks being moved, deleted,
or inserted. if case b is deleted, there will be an error.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2018-10-10 17:29 +0000 |
| Subject | Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) |
| Message-ID | <5bbe366e.2040556250@news.xmission.com> |
| In reply to | #136547 |
On Wed, 10 Oct 2018 16:09:56 +0100, Bart <bc@freeuk.com> wrote: >But now s3 is followed by s4 rather than s2. > >A better way is to use: > > fallthough b; > >although now 'fallthrough' is not appropriate. So perhaps 'continue b'. >Now that statement is more immune from case-blocks being moved, deleted, >or inserted. if case b is deleted, there will be an error. Are you kidding? Positional dependency shoud be downright *trendy* these days. Hell, we've got a mainstream programming language whose very structural integrity relies wholly on not fucking up your tab stop settings!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-10 16:01 +0100 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <5vovD.8164$2T2.1152@fx42.am4> |
| In reply to | #136541 |
On 10/10/2018 15:49, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 10/10/2018 14:55, David Brown wrote: > >> The only downside of switch, is requiring that break, which is just a >> very poor design choice in the language. > > lint(1) has been available for four decades. It's not a poor design > choice, unless one doesn't understand the language, in which case they > shouldn't be programming in it. > So nothing is a poor design in a language provided you know how it works? The consensus I get from this group and elsewhere is that automatic fall-through was a bad idea. That 99% of the time you have to use 'break' because you don't want fall-through might also suggest that. (The 'fall-through' you have in the middle here: case 10: case 11: doesn't count.) That is bad enough. but if you want to use 'break' inside a loop, suddenly you find it doesn't work when 'break' happens to be inside a switch statement. It does work however if you happen to use an if/else chain instead of switch. So one more point against 'switch', both due to poor language design. The clash between 'break' for loops, and 'break' for switch, /is/ very poor and definitely amateurish. -- bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-10 17:29 +0200 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <ppl5s4$5sc$2@dont-email.me> |
| In reply to | #136541 |
On 10/10/18 16:49, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 10/10/2018 14:55, David Brown wrote: > >> The only downside of switch, is requiring that break, which is just a >> very poor design choice in the language. > > lint(1) has been available for four decades. It's not a poor design > choice, unless one doesn't understand the language, in which case they > shouldn't be programming in it. > I believe I have quite a good understanding of the language, and I strongly dislike the need for "break" in switch cases. I can see why it was there for the convenience of the early compilers - it is not a convenience for programmers (compared to an alternative positive "fallthrough" keyword, and allowing case clauses to have multiple alternatives). But I agree entirely that your tools should spot any missing "breaks". "break" is a source of ugliness in source code, not a source of errors.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-10 17:55 +0200 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <tvj19f-oef.ln1@gangtai.home.grep.be> |
| In reply to | #136554 |
On 10/10/18 17:29, David Brown wrote:
> On 10/10/18 16:49, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 10/10/2018 14:55, David Brown wrote:
>>
>>> The only downside of switch, is requiring that break, which is just a
>>> very poor design choice in the language.
>>
>> lint(1) has been available for four decades. It's not a poor design
>> choice, unless one doesn't understand the language, in which case they
>> shouldn't be programming in it.
>>
>
> I believe I have quite a good understanding of the language, and I
> strongly dislike the need for "break" in switch cases. I can see why it
> was there for the convenience of the early compilers - it is not a
> convenience for programmers (compared to an alternative positive
> "fallthrough" keyword, and allowing case clauses to have multiple
> alternatives).
I know why people dislike it, but I'd like to see how they'd see this
implemented:
switch(something) {
case INTERESTING_CASE_1:
...
break;
case INTERESTING_CASE_2:
...
break;
case EDGE_1:
case EDGE_2:
case EDGE_3:
case EDGE_4:
printf("edge case detected\n");
break;
default:
... // error handling
}
That is, have a switch with a few cases that are common (where you
handle things), a few cases that require some common handling (in this
case, log a message), and a "default" label for error handlign.
With a required "fallthrough" keyword, that would become:
case EDGE_1: fallthrough;
case EDGE_2: fallthrough;
case EDGE_3: fallthrough;
case EDGE_4: fallthrough;
which is much less readable, IMO, especially if the number of cases in
the "common" handling is not placed on separate lines for conciseness:
case EDGE_1: case EDGE_2: case EDGE_3: case EDGE_4:
printf("edge case detected\n");
break;
Given that (which is not as uncommon as a "regular" fallthrough
situation), that becomes fairly ugly, IMO.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-10 17:11 +0100 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <mxpvD.17870$Do.14278@fx31.am4> |
| In reply to | #136556 |
On 10/10/2018 16:55, Wouter Verhelst wrote:
> On 10/10/18 17:29, David Brown wrote:
>> I believe I have quite a good understanding of the language, and I
>> strongly dislike the need for "break" in switch cases. I can see why it
>> was there for the convenience of the early compilers - it is not a
>> convenience for programmers (compared to an alternative positive
>> "fallthrough" keyword, and allowing case clauses to have multiple
>> alternatives).
>
> I know why people dislike it, but I'd like to see how they'd see this
> implemented:
>
> switch(something) {
> case INTERESTING_CASE_1:
> ...
> break;
> case INTERESTING_CASE_2:
> ...
> break;
> case EDGE_1:
> case EDGE_2:
> case EDGE_3:
> case EDGE_4:
> printf("edge case detected\n");
> break;
> default:
> ... // error handling
> }
>
> That is, have a switch with a few cases that are common (where you
> handle things), a few cases that require some common handling (in this
> case, log a message), and a "default" label for error handlign.
>
> With a required "fallthrough" keyword, that would become:
>
> case EDGE_1: fallthrough;
> case EDGE_2: fallthrough;
> case EDGE_3: fallthrough;
> case EDGE_4: fallthrough;
The simply wouldn't happen. If the language designer had enough nous to
not require 'break', then it wouldn't require those fallthroughs either.
(In the syntax I use every day, your example is written:
switch something
when interesting_case_1 then
stmts
when interesting_case_2 then
stmts
when edge_1, edge_2, edge_3, edge_4 then
println "Edge case detected"
else
stmts
end switch
No 'break', no 'fallthrough' needed; magic.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-10 23:15 +0100 |
| Subject | Re: C idioms |
| Message-ID | <87d0shtpmj.fsf@bsb.me.uk> |
| In reply to | #136556 |
Wouter Verhelst <w@uter.be> writes:
> On 10/10/18 17:29, David Brown wrote:
<snip>
>> I believe I have quite a good understanding of the language, and I
>> strongly dislike the need for "break" in switch cases. I can see why it
>> was there for the convenience of the early compilers - it is not a
>> convenience for programmers (compared to an alternative positive
>> "fallthrough" keyword, and allowing case clauses to have multiple
>> alternatives).
>
> I know why people dislike it, but I'd like to see how they'd see this
> implemented:
>
> switch(something) {
> case INTERESTING_CASE_1:
> ...
> break;
> case INTERESTING_CASE_2:
> ...
> break;
> case EDGE_1:
> case EDGE_2:
> case EDGE_3:
> case EDGE_4:
> printf("edge case detected\n");
> break;
> default:
> ... // error handling
> }
>
> That is, have a switch with a few cases that are common (where you
> handle things), a few cases that require some common handling (in this
> case, log a message), and a "default" label for error handlign.
>
> With a required "fallthrough" keyword, that would become:
>
> case EDGE_1: fallthrough;
> case EDGE_2: fallthrough;
> case EDGE_3: fallthrough;
> case EDGE_4: fallthrough;
I don't think it would. If you look at the grammar,
case EDGE_1:
case EDGE_2:
case EDGE_3:
case EDGE_4:
printf(...);
is just one statement with four labels -- there is no implied
"fall-through" here at all, so there is not need to make it explicit if
the default behaviour were to change to a implied "break" just before
each case-labeled statement.
Of course, the proposal to a have an implied break, and to require an
explicit fallthrough, might include a change to the grammar that would
indeed require the example above to be written as you fear, but it need
not be so.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-11 00:16 +0200 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <ppltnc$ujo$1@dont-email.me> |
| In reply to | #136556 |
On 10/10/18 17:55, Wouter Verhelst wrote:
> On 10/10/18 17:29, David Brown wrote:
>> On 10/10/18 16:49, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 10/10/2018 14:55, David Brown wrote:
>>>
>>>> The only downside of switch, is requiring that break, which is just a
>>>> very poor design choice in the language.
>>>
>>> lint(1) has been available for four decades. It's not a poor design
>>> choice, unless one doesn't understand the language, in which case they
>>> shouldn't be programming in it.
>>>
>>
>> I believe I have quite a good understanding of the language, and I
>> strongly dislike the need for "break" in switch cases. I can see why it
>> was there for the convenience of the early compilers - it is not a
>> convenience for programmers (compared to an alternative positive
>> "fallthrough" keyword, and allowing case clauses to have multiple
>> alternatives).
>
> I know why people dislike it, but I'd like to see how they'd see this
> implemented:
>
> switch(something) {
> case INTERESTING_CASE_1:
> ...
> break;
> case INTERESTING_CASE_2:
> ...
> break;
> case EDGE_1:
> case EDGE_2:
> case EDGE_3:
> case EDGE_4:
> printf("edge case detected\n");
> break;
> default:
> ... // error handling
> }
>
> That is, have a switch with a few cases that are common (where you
> handle things), a few cases that require some common handling (in this
> case, log a message), and a "default" label for error handlign.
>
> With a required "fallthrough" keyword, that would become:
>
> case EDGE_1: fallthrough;
> case EDGE_2: fallthrough;
> case EDGE_3: fallthrough;
> case EDGE_4: fallthrough;
>
> which is much less readable, IMO, especially if the number of cases in
> the "common" handling is not placed on separate lines for conciseness:
>
> case EDGE_1: case EDGE_2: case EDGE_3: case EDGE_4:
> printf("edge case detected\n");
> break;
>
> Given that (which is not as uncommon as a "regular" fallthrough
> situation), that becomes fairly ugly, IMO.
>
It would have been far better if the language had allowed:
case EDGE_1, EDGE_2, EDGE_3, EDGE_4 :
Then there would be no need for the break, and you could have a
"fallthrough" for the /very/ occasional situation where it is needed for
something other than multiple cases that should be handled identically.
Yes, I know this syntax would clash with the comma operator - IMHO
(which is not unique here, but certainly not universal) the language
would have been better without the comma operator at all. It would have
left the comma available for situations like this.
Alternatively, the language could simply say that a "case" without a
statement defaults to "fallthrough".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-10 23:23 +0100 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <tZuvD.29396$aX1.14703@fx21.am4> |
| In reply to | #136587 |
On 10/10/2018 23:16, David Brown wrote: > It would have been far better if the language had allowed: > > case EDGE_1, EDGE_2, EDGE_3, EDGE_4 : > > Then there would be no need for the break, and you could have a > "fallthrough" for the /very/ occasional situation where it is needed for > something other than multiple cases that should be handled identically. > > Yes, I know this syntax would clash with the comma operator I don't think a comma operator is allowed here anyway. -- Bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-10 16:31 -0700 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <lnk1mpxtsj.fsf@kst-u.example.com> |
| In reply to | #136591 |
Bart <bc@freeuk.com> writes:
> On 10/10/2018 23:16, David Brown wrote:
>> It would have been far better if the language had allowed:
>>
>> case EDGE_1, EDGE_2, EDGE_3, EDGE_4 :
>>
>> Then there would be no need for the break, and you could have a
>> "fallthrough" for the /very/ occasional situation where it is needed for
>> something other than multiple cases that should be handled identically.
>>
>> Yes, I know this syntax would clash with the comma operator
>
> I don't think a comma operator is allowed here anyway.
You're right.
The syntax is:
case constant-expression : statement
where the definition of constant-expression (which I should have
checked earlier) is:
constant expression : conditional-expression
That means it can't have a comma or assignment operator at the top
level.
On top of that restriction:
Constant expressions shall not contain assignment, increment,
decrement, function-call, or comma operators, except when they
are contained within a subexpression that is not evaluated.
Each constant expression shall evaluate to a constant that is
in the range of representable values for its type.
So an extension to permit a comma-separated list of constant-expressions
wouldn't break anything (such a list is currently a syntax error).
Still, I don't think such a change is worthwhile. Writing
case EDGE_1: case EDGE_2: case EDGE_3: case EDGE_4:
isn't *that* bad, and allowing commas would cause confusion with the
comma operator for some readers (though of course it would be
unambiguous as far as the compiler is concerned).
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-10 15:32 -0700 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <lnwoqpxwiz.fsf@kst-u.example.com> |
| In reply to | #136587 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> It would have been far better if the language had allowed:
>
> case EDGE_1, EDGE_2, EDGE_3, EDGE_4 :
>
> Then there would be no need for the break, and you could have a
> "fallthrough" for the /very/ occasional situation where it is needed for
> something other than multiple cases that should be handled identically.
If the syntax were changed from
case constant-expression : statement
to
case assignment-expression : statement
then a comma operator at the top level would be a syntax error. (If you
need one, you can add parentheses.) You'd want a term for an
assignment-expression that's also a constant-expression
You could then allow a sequence of one or more such expressions
separated by commas.
I don't think it's worth the effort (though it might have been if
it had been defined that way from the beginning).
[...]
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-10 16:24 -0700 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <lno9c1xu5d.fsf@kst-u.example.com> |
| In reply to | #136595 |
Keith Thompson <kst-u@mib.org> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> It would have been far better if the language had allowed:
>>
>> case EDGE_1, EDGE_2, EDGE_3, EDGE_4 :
>>
>> Then there would be no need for the break, and you could have a
>> "fallthrough" for the /very/ occasional situation where it is needed for
>> something other than multiple cases that should be handled identically.
>
> If the syntax were changed from
> case constant-expression : statement
> to
> case assignment-expression : statement
>
> then a comma operator at the top level would be a syntax error. (If you
> need one, you can add parentheses.) You'd want a term for an
> assignment-expression that's also a constant-expression
>
> You could then allow a sequence of one or more such expressions
> separated by commas.
>
> I don't think it's worth the effort (though it might have been if
> it had been defined that way from the beginning).
>
> [...]
Please ignore the above. I didn't check the syntax of
"constant-expression". A comma operator is already disallowed.
--
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-11 10:52 +0200 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <ppn312$ub1$1@dont-email.me> |
| In reply to | #136595 |
On 11/10/18 00:32, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> It would have been far better if the language had allowed: >> >> case EDGE_1, EDGE_2, EDGE_3, EDGE_4 : >> >> Then there would be no need for the break, and you could have a >> "fallthrough" for the /very/ occasional situation where it is needed for >> something other than multiple cases that should be handled identically. > > If the syntax were changed from > case constant-expression : statement > to > case assignment-expression : statement > > then a comma operator at the top level would be a syntax error. (If you > need one, you can add parentheses.) You'd want a term for an > assignment-expression that's also a constant-expression > > You could then allow a sequence of one or more such expressions > separated by commas. > I haven't thought through the details of the grammar here fully - I was just at the "what would be convenient for the programmer" stage. > I don't think it's worth the effort (though it might have been if > it had been defined that way from the beginning). > Certainly it is far too late to change now. And it is not hard to write "case EDGE_1: case EDGE_2: case EDGE_3: " when you need to (on the same line or separate lines, according to taste). I think if it were simple to implement a comma separated list of case values in C, without any conflicts, and it were something people really wanted, then it would exist as a gcc extension. After all, gcc has allowed "case 1 ... 10 :" as an extension for a very long time - it is unlikely they did not also consider "case 1, 2, 3 :" at the same time.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2018-10-10 09:59 -0600 |
| Subject | Re: C idioms |
| Message-ID | <1bh8ht23p0.fsf@pfeifferfamily.net> |
| In reply to | #136541 |
scott@slp53.sl.home (Scott Lurndal) writes: > Bart <bc@freeuk.com> writes: >>On 10/10/2018 14:55, David Brown wrote: > >>The only downside of switch, is requiring that break, which is just a >>very poor design choice in the language. > > lint(1) has been available for four decades. It's not a poor design > choice, unless one doesn't understand the language, in which case they > shouldn't be programming in it. This is one where I'll agree with Bart (are those four horsemen I hear saddling up in the courtyard?) -- it is a poor choice. Fall-through is used very rarely, and most of them time when I've seen it used it was in "tricksy" code. Meanwhile, it is a trap for the unwary. Not any sort of deal-breaker, of course, but defining the cases in a switch to each be a single statement (where that statement could be compound, of course) would have been better IMHO.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-10 17:26 +0200 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <ppl5mr$5sc$1@dont-email.me> |
| In reply to | #136537 |
On 10/10/18 16:17, Bart wrote:
> On 10/10/2018 14:55, David Brown wrote:
>> On 10/10/18 14:56, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 09/10/18 22:50, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 09/10/18 17:23, Kenny McCormack wrote:
>>>>>>> In article <ppiei3$n9l$1@dont-email.me>,
>>>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>>> ...
>>>>>>>> I don't think the first version is unclear, but I don't see any...
>>>>>>>
>>>>>>> Because you're not a moron. You're many things, but a moron
>>>>>>> you're not.
>>>>>>>
>>>>>>
>>>>>> Why, thank you.
>>>>>>
>>>>>>>
>>>>>>>> is corrected to use "if" rather than "switch").
>>>>>>>
>>>>>>> No. Switch is better.
>>>>>>>
>>>>>>
>>>>>> A switch is better when a switch is appropriate. It won't work
>>>>>> here, so
>>>>>> it is not better. We are branching on a value being less than,
>>>>>> equal to
>>>>>> or greater than zero - a switch won't do that.
>>>>>>
>>>>>
>>>>> $ grep fork */cmd/*/*.c | grep switch
>>>>
>>>> These do not match the original code, which tested for pid being less
>>>> than, equal to or greater than 0. You can't do that with a switch. I
>>>> am not particularly familiar with the details of fork() - it is not a
>>>> standard C call, and for all I know it could return a range of negative
>>>> error values.
>>>>
>>>> I still see no advantage of "switch" over "if" for such code -
>>>> unless it
>>>> is viewed as such a common idiom that the familiarity is an advantage.
>>>>
>>>>
>>>> However, the point here was not "what is the best way to write a
>>>> call to
>>>> fork", but to look at where it might be useful to use the result of an
>>>> assignment expression, how the code code be re-structured to avoid it,
>>>> and whether one version is "better" than the other.
>>>>
>>>
>>> fork() returns three values:
>>>
>>> -1 (an error occurred)
>>> 0 (You are executing as the child)
>>> >0 (You are executing as the parent, and the return value is the
>>> child pid).
>>>
>>> switch is _perfect_ for this.
>>
>> So is "if". (Let's assume the "if" check is for -1, rather than < 0.)
>>
>> I have seen that people use "switch" in this case. I have seen people
>> claim that "switch" is perfect for the job, or that it is better than
>> "if". I have yet to see the slightest hint of an indication of /why/
>> "switch" would be better for the purpose.
>>
>> IMHO, "if" is clearer. It involves shorter source code, especially if
>> you have a bracketed scope for each branch/case. It avoids any risk of
>> forgetting the "break". It is likely that it gives at least as good, if
>> not better, object code.
>>
>> What am I missing? /Why/ do you think "switch" is better here?
>
> - Because the expression being tested is only evaluated once
That is also the case when you have a variable in the "if" statement.
>
> - Because to achieve that with if/else if, you may need to create a
> dummy variable to store the result of the control expression, which
> is the compiler's job not yours
The "pid" variable is often needed for forks, and it is no hardship to
add it. It is the compiler's job to ensure the run-time costs of the
variable are negligible.
>
> - Because if each branch is more than one statement, if/else NEEDS {...}
> (switch block are delimited by the next case)
Your switch blocks also need braces if you have local variables and
don't want them to outlive the block or crash with variables in the
other cases.
And your switch blocks need a "break" at the end - I much prefer { } as
delimiters than a "break" as an end delimiter.
>
> - Because if you need more cases, scale is more easily expanded
>
I fully agree with using switches in many situations. But we are
talking about a specific situation, which will not be scaled.
> - Because, even with the dummy variable, you have to write its name more
> than once, an extra source of errors if you were to mistype it
If you have trouble spelling "pid" more than once, I'd suggest that
using "switch" instead of "if" will not solve your problems.
>
> - Because with if/else if, you also have to write ==, <, <= etc, another
> thing that you can get wrong.
Again, this should not be an issue.
>
> The only downside of switch, is requiring that break, which is just a
> very poor design choice in the language.
>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-10 14:48 +0000 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <DiovD.236191$RN2.42671@fx40.iad> |
| In reply to | #136535 |
David Brown <david.brown@hesbynett.no> writes: >On 10/10/18 14:56, Scott Lurndal wrote: >> fork() returns three values: >> >> -1 (an error occurred) >> 0 (You are executing as the child) >> >0 (You are executing as the parent, and the return value is the child pid). >> >> switch is _perfect_ for this. > >So is "if". (Let's assume the "if" check is for -1, rather than < 0.) > >I have seen that people use "switch" in this case. I have seen people >claim that "switch" is perfect for the job, or that it is better than >"if". I have yet to see the slightest hint of an indication of /why/ >"switch" would be better for the purpose. Professor Pfeiffer said it best. "I generally prefer switches over chains of if...else if... else when possible because it more clearly says 'this is the set of possible alternatives' rather than 'try this, then this, then this...' (to my eye, anyway)." >> (as a nit, I really dislike code that tests for less than zero on >> interfaces that are defined to return -1 on error - which Bart's >> original example did). >> > >That is fair enough. Until someone pointed it out to me, I did not >realise that -1 was the only possible error result from fork() - I was >working purely from the original version of the code, with a total >disregard for whether the function was "fork" or "foo". > >Since fork() cannot return any negative value other than -1, the >semantics of the code will be the same with a check for -1 or < 0. But >checking for < 0 is perhaps an indication that the person writing the >code does not know exactly what fork() can return, and that's not good >when writing code that uses it. It lazy programming and also a bad habit; while the vast majority of unix and POSIX interfaces indicate error by returning -1 (with errno set), there are a couple that return -1, but the remaining range of integers are perfectly legal (lseek and mmap come directly to mind). This one bit me more than once when porting software to the motorola 88100 and to versions of unix that split the VA space 3:1 user:kernel on x86; both cases where legal user-mode virtual addresses may have the high-order address bit set (and there are cases where kernel trampolines or read-only data are exposed to userland using VA's with the high-order bit set, e.g. for gettimeofday()).
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-10-10 14:51 +0000 |
| Subject | Return values of fork() (Was: C idioms (Was: >< swap operator)) |
| Message-ID | <ppl3l0$6ac$1@news.xmission.com> |
| In reply to | #136527 |
In article <PFmvD.59808$un2.54146@fx14.iad>, Scott Lurndal <slp53@pacbell.net> wrote: ... >fork() returns (one of, Ed) three values: > > -1 (an error occurred) > 0 (You are executing as the child) > 0 (You are executing as the parent, and the return value is the child pid). > >switch is _perfect_ for this. Exactly. >(as a nit, I really dislike code that tests for less than zero on >interfaces that are defined to return -1 on error - which Bart's >original example did). Yup. As should be clear from my posts on this thread, I believe that one should go with the documentation. If the documentation says -1 is the error return, then you should check for -1. Alternatively, though, I can sorta see a rationale for the "check for less than zero" approach. That is, you can now say that the code handles all conceivable (*) values. There is no excluded case. Like, what if your code gets executed in some weird environment where fork() returns -6 to indicate that a total solar eclipse is currently occurring? (*) Note that I didn't say "all possible values"... -- If it seems like I'm not responding to some moronic criticism that you've posted in response to one of my posts, be aware that I do not debate with idiots. It doesn't mean you've won anything...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-10 15:20 +0000 |
| Subject | Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) |
| Message-ID | <eNovD.69863$nH2.10723@fx26.iad> |
| In reply to | #136542 |
gazelle@shell.xmission.com (Kenny McCormack) writes: >In article <PFmvD.59808$un2.54146@fx14.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >... >>fork() returns (one of, Ed) three values: >> >> -1 (an error occurred) >> 0 (You are executing as the child) >> 0 (You are executing as the parent, and the return value is the child pid). >> >>switch is _perfect_ for this. > >Exactly. > >>(as a nit, I really dislike code that tests for less than zero on >>interfaces that are defined to return -1 on error - which Bart's >>original example did). > >Yup. As should be clear from my posts on this thread, I believe that one >should go with the documentation. If the documentation says -1 is the >error return, then you should check for -1. > >Alternatively, though, I can sorta see a rationale for the "check for less >than zero" approach. That is, you can now say that the code handles all >conceivable (*) values. There is no excluded case. Like, what if your code >gets executed in some weird environment where fork() returns -6 to indicate >that a total solar eclipse is currently occurring? That version of fork() would not be compliant with the POSIX specification, now or in any conceivable future.
[toc] | [prev] | [next] | [standalone]
Page 7 of 18 — ← Prev page 1 … 5 6 [7] 8 9 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web