Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #149088 > unrolled thread
| Started by | T <T@invalid.invalid> |
|---|---|
| First post | 2020-01-14 09:22 -0800 |
| Last post | 2020-01-22 18:44 +0100 |
| Articles | 20 on this page of 262 — 29 participants |
Back to article view | Back to comp.lang.c
C String terminator T <T@invalid.invalid> - 2020-01-14 09:22 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:32 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-14 09:43 -0800
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 17:53 +0000
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-14 20:17 +0100
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-14 20:01 +0000
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-14 09:57 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 11:37 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:02 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
Re: C String terminator Manfred <noname@add.invalid> - 2020-01-14 20:48 +0100
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-15 05:43 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 07:12 -0800
Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:35 +0000
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-19 06:20 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:52 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 12:52 -0800
Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 20:56 +0000
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:17 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 21:54 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:07 -0800
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 02:45 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 08:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-16 08:03 -0800
Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-16 09:06 -0800
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-16 11:29 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:01 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 23:02 -0500
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-01-16 11:15 +0100
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:07 +0000
Re: C String terminator Manfred <noname@add.invalid> - 2020-01-17 18:43 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:00 -0800
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:00 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 12:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 12:05 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-14 13:54 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 15:03 -0800
Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 04:55 -0800
Re: C String terminator Guillaume <message@bottle.org> - 2020-01-15 20:49 +0100
Re: C String terminator Thiago Adams <thiago.adams@gmail.com> - 2020-01-15 12:55 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-14 21:31 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:28 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:38 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-15 10:50 -0700
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:17 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:53 -0800
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-01-14 21:43 -0500
Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:52 -0800
Re: C String terminator "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 22:54 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 02:00 -0800
Re: C String terminator gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-15 10:47 +0000
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-15 03:02 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:19 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 11:33 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 12:03 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:30 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:17 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:44 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 20:33 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-16 02:26 -0800
Re: C String terminator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-15 15:11 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 09:32 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 10:47 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:58 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 01:39 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 18:27 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:03 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 03:28 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:33 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 19:38 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 13:31 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 09:09 -0800
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-01-16 10:27 -0700
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:54 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:59 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:11 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:17 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:14 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 23:45 +0000
Yes, Ben makes house calls (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-16 23:57 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:28 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-17 20:46 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:48 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 12:54 -0800
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:02 +0000
Re: C String terminator Bart <bc@freeuk.com> - 2020-01-17 21:21 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:35 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:44 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:03 -0800
Re: C String terminator fir <profesor.fir@gmail.com> - 2020-01-17 15:06 -0800
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-01-18 07:30 +0000
Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:06 -0500
Re: C String terminator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-17 16:23 -0500
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 13:37 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 04:10 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 10:41 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 02:25 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-16 14:24 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:13 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-22 09:05 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:58 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-27 23:26 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 09:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 09:54 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 11:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 13:12 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 13:28 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:17 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 09:47 +0200
Re: C String terminator already5chosen@yahoo.com - 2020-04-03 08:03 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 17:34 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 12:39 -0400
Re: C String terminator Bart <bc@freeuk.com> - 2020-04-03 18:05 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 10:18 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:13 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 14:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 16:18 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 01:43 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:23 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 11:18 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:02 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-05 21:54 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 13:59 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-06 09:07 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 02:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 11:43 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:56 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 16:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 10:30 -0700
Re: C String terminator richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-04-06 17:50 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 11:31 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 12:04 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 21:51 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:34 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 14:39 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:52 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 15:31 -0700
Re: C String terminator jameskuyper@stellarscience.com - 2020-04-06 16:05 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 03:08 +0100
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-06 21:12 -0600
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 16:55 +0000
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 11:05 -0600
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-07 20:39 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:48 -0700
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 21:21 -0600
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 20:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 01:41 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 07:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 08:16 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 09:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 09:46 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 10:37 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 10:48 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-08 14:07 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 11:29 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 16:46 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 01:57 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 08:56 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 12:42 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 10:12 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 15:51 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 13:02 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 13:06 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 14:49 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 19:05 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 02:25 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 04:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 05:21 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 07:13 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 11:38 -0700
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-11 17:38 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:04 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-11 15:16 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-11 21:45 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 04:39 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-12 21:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 14:38 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-13 11:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-13 08:24 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:08 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 09:53 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:35 -0400
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-06 21:04 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 01:16 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 02:08 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 02:19 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 10:39 -0700
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 17:45 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:40 -0400
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 11:03 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 12:19 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:02 +0100
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 06:27 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 07:44 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 08:30 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 00:27 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:50 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 05:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 23:52 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 03:15 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 21:28 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 15:40 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-09 00:31 +0100
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-07 21:40 +0000
Re: C String terminator luser droog <luser.droog@gmail.com> - 2020-04-06 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 12:46 -0700
Re: C String terminator Guillaume <message@bottle.org> - 2020-04-07 17:17 +0200
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:23 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-04 22:32 +0100
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 21:59 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:48 -0400
Jared Kushner would be proud... (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-04 09:00 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 02:45 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-04 10:24 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 03:55 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:27 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 13:52 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:03 -0700
Re: Jared Kushner would be proud... Richard Damon <Richard@Damon-Family.org> - 2020-04-04 18:46 -0400
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 01:53 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 02:33 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 06:43 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 19:48 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 06:37 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:36 +0200
Re: C String terminator dave_thompson_2@comcast.net - 2020-05-02 15:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 10:33 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 11:34 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:48 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 12:10 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 13:24 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:59 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:05 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 20:34 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 02:05 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:35 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 07:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-17 01:55 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-17 09:52 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-17 11:29 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 18:21 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 10:50 -0800
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 20:50 +0000
Re: C String terminator T <T@invalid.invalid> - 2020-01-16 14:17 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-15 09:59 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-15 10:15 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-18 21:42 -0800
Re: C String terminator T <T@invalid.invalid> - 2020-01-19 22:13 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-21 19:49 +0100
Re: C String terminator John Bode <jfbode1029@gmail.com> - 2020-01-21 15:33 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-21 23:19 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:39 +0100
Re: C String terminator chad <cdalten@gmail.com> - 2020-01-22 06:59 -0800
Re: C String terminator Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 18:44 +0100
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-22 09:05 -0800 |
| Message-ID | <87blpqa6y6.fsf@nosuchdomain.example.com> |
| In reply to | #150148 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>
>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>> standard says so only indirectly.
[...]
> I need to add though that 'char' is not really accurate. The Standard
> says "character type" and I think it means that, not just 'char'.
> Furthermore if an 'l' length modifier is present then the array
> elements are assumed to be of type 'wchar_t'. Both the regular
> character types and wchar_t fall under the common umbrella of
> "character type".
When I wrote "%s" directive, I meant "%s" directive.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-03-27 19:58 -0700 |
| Message-ID | <867dz589t3.fsf@linuxsc.com> |
| In reply to | #150153 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>> [...] >>> >>>>> A pointer to a string *is* required for a "%s" directive, but the >>>>> standard says so only indirectly. > > [...] > >> I need to add though that 'char' is not really accurate. The Standard >> says "character type" and I think it means that, not just 'char'. >> Furthermore if an 'l' length modifier is present then the array >> elements are assumed to be of type 'wchar_t'. Both the regular >> character types and wchar_t fall under the common umbrella of >> "character type". > > When I wrote "%s" directive, I meant "%s" directive. Sorry, I thought we were talking about things the Standard actually discusses. The Standard makes no statements about '"%s" directives', unless you want to count examples that happen to have a %s as part of a format string.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-03-27 23:26 -0700 |
| Message-ID | <875zepvvu1.fsf@nosuchdomain.example.com> |
| In reply to | #150867 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>>>> standard says so only indirectly.
>>
>> [...]
>>
>>> I need to add though that 'char' is not really accurate. The Standard
>>> says "character type" and I think it means that, not just 'char'.
You're right. (Note that that was in response to text that was later
snipped.) Still, I believe "pointer to a string" is correct, though the
elements of a string may be of type char, signed char, or unsigned char.
(It's possible the standard's definition of "character" leaves some
additional wiggle room.)
>>> Furthermore if an 'l' length modifier is present then the array
>>> elements are assumed to be of type 'wchar_t'. Both the regular
>>> character types and wchar_t fall under the common umbrella of
>>> "character type".
>>
>> When I wrote "%s" directive, I meant "%s" directive.
>
> Sorry, I thought we were talking about things the Standard
> actually discusses.
I don't know (and I'm not asking) why you thought that. If I were
talking about "things the Standard actually discusses", I wouldn't
have written "... but the standard says so only indirectly".
> The Standard makes no statements about
> '"%s" directives', unless you want to count examples that
> happen to have a %s as part of a format string.
My statement was precisely about a directive consisting only of
the character sequence "%s". If by 'a "%s" directive' I had meant
"a directive containing an 's' conversion specifier" you could
have rightly criticized me for being imprecise. I observed, as a
mildly interesting point, that the requirements for the argument
corresponding to a "%s" specifier are equivalent to requiring a
pointer to a string, though the standard doesn't state it in those
terms (and I do not suggest that it should).
Regarding a point I raised above, 3.7.1 defines a "character"
as a "bit representation that fits in a byte", and 7.1.1 defines
a "string" as a sequence of characters -- but "%s" specifically
requires a pointer to the initial element of an array of character
type, i.e., one of char, signed char, or unsigned char. I see
no requirement that a "character" must be of "character type".
Possibly the standard's definition of "character" is incomplete
and/or does not fully convey the intent.
An implementation could have an extended integer type (say, "_Byte")
with a size of 1 byte that is not a character type. A pointer value
of type _Byte* might meet the definition of "a pointer to a string",
but would not be valid as an argument corresponding to "%s". I doubt
that this is relevant for any real-world implementation, but my
original statement might not be correct for all possible conforming
implementations, assuming we take the standard's definitions literally.
Single-byte enums might also raise some issues (they could be
*compatible* with a character type without *being* a character type).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 09:21 -0700 |
| Message-ID | <86sghl6eop.fsf@linuxsc.com> |
| In reply to | #150871 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>>>>> standard says so only indirectly.
>>>
>>> [...]
>>>
>>>> I need to add though that 'char' is not really accurate. The Standard
>>>> says "character type" and I think it means that, not just 'char'.
>
> You're right. (Note that that was in response to text that was later
> snipped.) Still, I believe "pointer to a string" is correct, though the
> elements of a string may be of type char, signed char, or unsigned char.
> (It's possible the standard's definition of "character" leaves some
> additional wiggle room.)
>
>>>> Furthermore if an 'l' length modifier is present then the array
>>>> elements are assumed to be of type 'wchar_t'. Both the regular
>>>> character types and wchar_t fall under the common umbrella of
>>>> "character type".
>>>
>>> When I wrote "%s" directive, I meant "%s" directive.
>>
>> Sorry, I thought we were talking about things the Standard
>> actually discusses.
>
> I don't know (and I'm not asking) why you thought that. If I were
> talking about "things the Standard actually discusses", I wouldn't
> have written "... but the standard says so only indirectly".
My original response to Lew Pitcher referred to "a %s conversion
specifier". Perhaps this came across as a '"%s" conversion
sequence' (which is also a directive), but I meant in particular
's' as a conversion specifier, not a conversion sequence. In
your responses to that you started using '"%s" directive', but
I didn't notice the change right away.
>> The Standard makes no statements about
>> '"%s" directives', unless you want to count examples that
>> happen to have a %s as part of a format string.
>
> My statement was precisely about a directive consisting only of
> the character sequence "%s". If by 'a "%s" directive' I had meant
> "a directive containing an 's' conversion specifier" you could
> have rightly criticized me for being imprecise. I observed, as a
> mildly interesting point, that the requirements for the argument
> corresponding to a "%s" specifier are equivalent to requiring a
> pointer to a string, though the standard doesn't state it in those
> terms (and I do not suggest that it should).
>
> Regarding a point I raised above, 3.7.1 defines a "character"
> as a "bit representation that fits in a byte", and 7.1.1 defines
> a "string" as a sequence of characters -- but "%s" specifically
> requires a pointer to the initial element of an array of character
> type, i.e., one of char, signed char, or unsigned char. I see
> no requirement that a "character" must be of "character type".
> Possibly the standard's definition of "character" is incomplete
> and/or does not fully convey the intent.
The term "character" is a restriction on values, not types. The
constant 's' is a character, but has type int.
> An implementation could have an extended integer type (say, "_Byte")
> with a size of 1 byte that is not a character type. A pointer value
> of type _Byte* might meet the definition of "a pointer to a string",
> but would not be valid as an argument corresponding to "%s". I doubt
> that this is relevant for any real-world implementation, but my
> original statement might not be correct for all possible conforming
> implementations, assuming we take the standard's definitions literally.
> Single-byte enums might also raise some issues (they could be
> *compatible* with a character type without *being* a character type).
Surely the definition in 7.1.1 is meant to refer to elements of
an array of character type. The array
int blah[4] = { 'a', 'b', 'c' };
is a sequence of characters, and terminated with a zero (which is
also a character value) but surely is not meant to be a "string"
in the sense of 7.1.1. For another example, the type uint8_t is a
single, 8-bit type, and may be a distinct type (more specifically,
not the same as char, unsigned char, or signed char). Because in
that situation uint8_t is not compatible with any character type,
a uint8_t * could have a different representation than a char *.
I haven't checked this, but I feel confident the Standard avoids
all of these problems by, eg, using parameter types such as 'char *'
so there is no question about what type is being referred to, or
by doing what is done for printf, namely, giving the specification
so it references "an array of character type".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-02 09:54 -0700 |
| Message-ID | <61f8fb26-45fb-46c4-8bf4-d85d8fb94a8d@googlegroups.com> |
| In reply to | #150960 |
On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > > > Regarding a point I raised above, 3.7.1 defines a "character" > > as a "bit representation that fits in a byte", and 7.1.1 defines > > a "string" as a sequence of characters -- but "%s" specifically > > requires a pointer to the initial element of an array of character > > type, i.e., one of char, signed char, or unsigned char. I see > > no requirement that a "character" must be of "character type". > > Possibly the standard's definition of "character" is incomplete > > and/or does not fully convey the intent. > > The term "character" is a restriction on values, not types. The > constant 's' is a character, but has type int. > That's so that EOF can be coded as -1, and is not a "character". >. > I haven't checked this, but I feel confident the Standard avoids > all of these problems by, eg, using parameter types such as 'char *' > so there is no question about what type is being referred to, or > by doing what is done for printf, namely, giving the specification > so it references "an array of character type". > The "%s" format specifier can take char *, unsigned char *, or signed char *. That's quite a mouthful, so "array of character type" is used as shorthand.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-02 11:17 -0700 |
| Message-ID | <87r1x5sqfa.fsf@nosuchdomain.example.com> |
| In reply to | #150961 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote:
[...]
>> The term "character" is a restriction on values, not types. The
>> constant 's' is a character, but has type int.
>>
> That's so that EOF can be coded as -1, and is not a "character".
No, fgetc(), getc(), and getchar() return int so that EOF can be
coded as -1. Character constants are of type int for historical
reasons. In C++, 's' is of type char, but EOF is still -1.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-02 13:12 -0700 |
| Message-ID | <4ea45dd6-d0b6-4f24-a846-3b62d265f3ed@googlegroups.com> |
| In reply to | #150962 |
On Thursday, 2 April 2020 19:17:39 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > [...] > >> The term "character" is a restriction on values, not types. The > >> constant 's' is a character, but has type int. > >> > > That's so that EOF can be coded as -1, and is not a "character". > > No, fgetc(), getc(), and getchar() return int so that EOF can be > coded as -1. Character constants are of type int for historical > reasons. In C++, 's' is of type char, but EOF is still -1. > And functions like strchr() take an int as the character argument. It's a general principle in standard C that a single character variable is of type int.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-02 13:28 -0700 |
| Message-ID | <87eet5skd8.fsf@nosuchdomain.example.com> |
| In reply to | #150964 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 2 April 2020 19:17:39 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote:
>> [...]
>> >> The term "character" is a restriction on values, not types. The
>> >> constant 's' is a character, but has type int.
>> >>
>> > That's so that EOF can be coded as -1, and is not a "character".
>>
>> No, fgetc(), getc(), and getchar() return int so that EOF can be
>> coded as -1. Character constants are of type int for historical
>> reasons. In C++, 's' is of type char, but EOF is still -1.
>>
> And functions like strchr() take an int as the character argument.
Yes.
> It's a general principle in standard C that a single character variable
> is of type int.
No, a single character variable is very often of type char if it doesn't
need to hold the value EOF.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 19:17 -0700 |
| Message-ID | <86a73tpb20.fsf@linuxsc.com> |
| In reply to | #150961 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > >>> Regarding a point I raised above, 3.7.1 defines a "character" >>> as a "bit representation that fits in a byte", and 7.1.1 defines >>> a "string" as a sequence of characters -- but "%s" specifically >>> requires a pointer to the initial element of an array of character >>> type, i.e., one of char, signed char, or unsigned char. I see >>> no requirement that a "character" must be of "character type". >>> Possibly the standard's definition of "character" is incomplete >>> and/or does not fully convey the intent. >> >> The term "character" is a restriction on values, not types. The >> constant 's' is a character, but has type int. > > That's so that EOF can be coded as -1, and is not a "character". > >> . >> I haven't checked this, but I feel confident the Standard avoids >> all of these problems by, eg, using parameter types such as 'char *' >> so there is no question about what type is being referred to, or >> by doing what is done for printf, namely, giving the specification >> so it references "an array of character type". > > The "%s" format specifier can take char *, unsigned char *, or signed char *. > That's quite a mouthful, so "array of character type" is used as shorthand. The depth of your understanding truly defies my ability to describe it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-03 09:47 +0200 |
| Message-ID | <r66pnf$g1k$1@dont-email.me> |
| In reply to | #150967 |
On 03/04/2020 04:17, Tim Rentsch wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: >> >>>> Regarding a point I raised above, 3.7.1 defines a "character" >>>> as a "bit representation that fits in a byte", and 7.1.1 defines >>>> a "string" as a sequence of characters -- but "%s" specifically >>>> requires a pointer to the initial element of an array of character >>>> type, i.e., one of char, signed char, or unsigned char. I see >>>> no requirement that a "character" must be of "character type". >>>> Possibly the standard's definition of "character" is incomplete >>>> and/or does not fully convey the intent. >>> >>> The term "character" is a restriction on values, not types. The >>> constant 's' is a character, but has type int. >> >> That's so that EOF can be coded as -1, and is not a "character". >> >>> . >>> I haven't checked this, but I feel confident the Standard avoids >>> all of these problems by, eg, using parameter types such as 'char *' >>> so there is no question about what type is being referred to, or >>> by doing what is done for printf, namely, giving the specification >>> so it references "an array of character type". >> >> The "%s" format specifier can take char *, unsigned char *, or signed char *. >> That's quite a mouthful, so "array of character type" is used as shorthand. > > The depth of your understanding truly defies my > ability to describe it. > And yet you cannot resist the urge to try. If you want to correct Malcolm, do so - plenty of people correct his posts, and he does not seem to mind. Sarcastic mockery from your ivory tower, on the other hand, is not helpful to anyone.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2020-04-03 08:03 -0700 |
| Message-ID | <2a770f28-0124-4b7e-8da3-24c05dd75636@googlegroups.com> |
| In reply to | #150973 |
On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: > On 03/04/2020 04:17, Tim Rentsch wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > >> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > >> > >>>> Regarding a point I raised above, 3.7.1 defines a "character" > >>>> as a "bit representation that fits in a byte", and 7.1.1 defines > >>>> a "string" as a sequence of characters -- but "%s" specifically > >>>> requires a pointer to the initial element of an array of character > >>>> type, i.e., one of char, signed char, or unsigned char. I see > >>>> no requirement that a "character" must be of "character type". > >>>> Possibly the standard's definition of "character" is incomplete > >>>> and/or does not fully convey the intent. > >>> > >>> The term "character" is a restriction on values, not types. The > >>> constant 's' is a character, but has type int. > >> > >> That's so that EOF can be coded as -1, and is not a "character". > >> > >>> . > >>> I haven't checked this, but I feel confident the Standard avoids > >>> all of these problems by, eg, using parameter types such as 'char *' > >>> so there is no question about what type is being referred to, or > >>> by doing what is done for printf, namely, giving the specification > >>> so it references "an array of character type". > >> > >> The "%s" format specifier can take char *, unsigned char *, or signed char *. > >> That's quite a mouthful, so "array of character type" is used as shorthand. > > > > The depth of your understanding truly defies my > > ability to describe it. > > > > And yet you cannot resist the urge to try. If you want to correct > Malcolm, do so - plenty of people correct his posts, and he does not > seem to mind. Sarcastic mockery from your ivory tower, on the other > hand, is not helpful to anyone. The point is *not* to correct any specific mistake of Malcolm McLean> but to persuade him to stop taking part in discussions in-between High Priesthood. Which I consider not a bad advice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-03 17:34 +0200 |
| Message-ID | <r67l1c$v4t$1@dont-email.me> |
| In reply to | #150979 |
On 03/04/2020 17:03, already5chosen@yahoo.com wrote: > On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: >> On 03/04/2020 04:17, Tim Rentsch wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: >>>> >>>>>> Regarding a point I raised above, 3.7.1 defines a >>>>>> "character" as a "bit representation that fits in a byte", >>>>>> and 7.1.1 defines a "string" as a sequence of characters -- >>>>>> but "%s" specifically requires a pointer to the initial >>>>>> element of an array of character type, i.e., one of char, >>>>>> signed char, or unsigned char. I see no requirement that a >>>>>> "character" must be of "character type". Possibly the >>>>>> standard's definition of "character" is incomplete and/or >>>>>> does not fully convey the intent. >>>>> >>>>> The term "character" is a restriction on values, not types. >>>>> The constant 's' is a character, but has type int. >>>> >>>> That's so that EOF can be coded as -1, and is not a >>>> "character". >>>> >>>>> . I haven't checked this, but I feel confident the Standard >>>>> avoids all of these problems by, eg, using parameter types >>>>> such as 'char *' so there is no question about what type is >>>>> being referred to, or by doing what is done for printf, >>>>> namely, giving the specification so it references "an array >>>>> of character type". >>>> >>>> The "%s" format specifier can take char *, unsigned char *, or >>>> signed char *. That's quite a mouthful, so "array of character >>>> type" is used as shorthand. >>> >>> The depth of your understanding truly defies my ability to >>> describe it. >>> >> >> And yet you cannot resist the urge to try. If you want to correct >> Malcolm, do so - plenty of people correct his posts, and he does >> not seem to mind. Sarcastic mockery from your ivory tower, on the >> other hand, is not helpful to anyone. > > The point is *not* to correct any specific mistake of Malcolm McLean> > but to persuade him to stop taking part in discussions in-between > High Priesthood. Which I consider not a bad advice. > It is good advice for most people not to get involved in some of these discussions about the small details in the wording of the standards - the details are not easy to get right, and their influence in real-world practical programming is usually very small. (It can, however, be useful for the rest of us that /someone/ has read and understood them.) But do you think Tim was giving advice like that? Do you think Malcolm would take such advice, if it were clearly given? Do you think Tim made his post in the sincere belief that Malcolm might read it as such advice, and take the advice? Or do you think (as I) that the post was self-promotion through insult, fitting with Tim's "holier than thou" attitude to C and "I am the master, you are the student - I give hints and leave the rest as a homework exercise for my disciples" posting style? (These are clearly highly speculative and very leading questions, not intended to be answered.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-03 12:39 -0400 |
| Message-ID | <r67oso$smn$1@dont-email.me> |
| In reply to | #150980 |
On 4/3/20 11:34 AM, David Brown wrote: > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: >> On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: ... >>> And yet you cannot resist the urge to try. If you want to correct >>> Malcolm, do so - plenty of people correct his posts, and he does >>> not seem to mind. Sarcastic mockery from your ivory tower, on the >>> other hand, is not helpful to anyone. I think that it probably does help Tim feel better about himself. >> The point is *not* to correct any specific mistake of Malcolm McLean> >> but to persuade him to stop taking part in discussions in-between >> High Priesthood. Which I consider not a bad advice. Nonsense - there's no "High Priesthood" of clc, and no one who should avoid participating in a conversation here just because of being "unworthy". There are other reasons why Malcolm shouldn't post, such as usually not making sense, and routinely using words and phrases with special Malcolm-meanings that are different from both conventional usage and the definitions of those terms as they are defined in the C standard. However, not being "worthy" to participate isn't one of those reasons. > But do you think Tim was giving advice like that? Do you think Malcolm > would take such advice, if it were clearly given? Do you think Tim made > his post in the sincere belief that Malcolm might read it as such > advice, and take the advice? Or do you think (as I) that the post was > self-promotion through insult, fitting with Tim's "holier than thou" > attitude to C and "I am the master, you are the student - I give hints > and leave the rest as a homework exercise for my disciples" posting style? You said what I was going to say, and you said it better than I was planning to.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-04-03 18:05 +0100 |
| Message-ID | <f1KhG.92394$Oi.36768@fx29.am4> |
| In reply to | #150980 |
On 03/04/2020 16:34, David Brown wrote: > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: >> The point is *not* to correct any specific mistake of Malcolm McLean> >> but to persuade him to stop taking part in discussions in-between >> High Priesthood. Which I consider not a bad advice. >> > > It is good advice for most people not to get involved in some of these > discussions about the small details in the wording of the standards - > the details are not easy to get right, and their influence in real-world > practical programming is usually very small. (It can, however, be > useful for the rest of us that /someone/ has read and understood them.) Or, possibly, not understand them. It's useful to know that even 'high priests' can't agree about some of that stuff.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-03 10:18 -0700 |
| Message-ID | <5f11e9cb-67df-4c87-bab1-c7272ccf3ebc@googlegroups.com> |
| In reply to | #150984 |
On Friday, 3 April 2020 18:05:26 UTC+1, Bart wrote: > On 03/04/2020 16:34, David Brown wrote: > > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: > > >> The point is *not* to correct any specific mistake of Malcolm McLean> > >> but to persuade him to stop taking part in discussions in-between > >> High Priesthood. Which I consider not a bad advice. > >> > > > > It is good advice for most people not to get involved in some of these > > discussions about the small details in the wording of the standards - > > the details are not easy to get right, and their influence in real-world > > practical programming is usually very small. (It can, however, be > > useful for the rest of us that /someone/ has read and understood them.) > > Or, possibly, not understand them. > > It's useful to know that even 'high priests' can't agree about some of > that stuff. > With the "day one" versus "the first day" argument in Genesis, you can argue that God guided the hand of the scribe to make him write something significant. Some people believe that the text was dictated verbatim to Moses on Mt Sinai. But when it's "character" in the C standard, we know that this a purely human document. Doubtless I'll be accused of inventing "Malcolm-characters" just I was accused of inventing "Malcolm functions" (a "Malcolm function" is a mapping of input bits to output bits, so I'm not too unhappy to have this concept named after me). "Character" can mean several things, one of which, in the context of C, is the full word for the abbreviation "char". But that's only one meaning. Characters are usually passed about as ints. Early C didn't have any prototypes, so there were problems specifying functions which took the non-register or non-double types. The other reason was to encode EOF.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-03 22:13 +0100 |
| Message-ID | <874ku09ssw.fsf@bsb.me.uk> |
| In reply to | #150985 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > ... I was accused of inventing "Malcolm functions" (a "Malcolm function" is > a mapping of input bits to output bits, Is it? I thought a key feature of Malcolm-functions is that they don't do input or output. Or do you mean Malcolm-input and Malcolm-output? > so I'm not too unhappy to have this concept named after me). Only in comp.lang.c. You would have to use "function" to mean "a formal celebratory gathering" in sci.math for that meaning to be named after you there. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-03 14:36 -0700 |
| Message-ID | <6bf35dde-de1f-4635-a69d-4d4860d84a29@googlegroups.com> |
| In reply to | #150998 |
On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > ... I was accused of inventing "Malcolm functions" (a "Malcolm function" is > > a mapping of input bits to output bits, > > Is it? I thought a key feature of Malcolm-functions is that they don't > do input or output. Or do you mean Malcolm-input and Malcolm-output? > Really the key feature is that they are not specified to do IO in the interface description. So you can always eliminate the IO whilst maintaining correct behaviour for a compliant caller. That's not just a quibble, often you want to add white box diagnostics to a Malcolm function to debug it. So yes, Malcolm-input and Malcolm-output. The key reason for defining the Malcolm function is not to teach people what the word "function" normally means outside of C, but to separate the portions of the program which are inherently portable and (except for running out of memory) failure free, from those which are inherently hardware bound and can fail if the device they are attached to fails. > > > so I'm not too unhappy to have this concept named after me). > > Only in comp.lang.c. You would have to use "function" to mean "a formal > celebratory gathering" in sci.math for that meaning to be named after > you there. > If I distinguished "function" from "workction" then I might get "Malcolm function" named after me, even on sci.math. But only if I actually held one, and currently we're on lockdown so that's not going to happen.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-03 16:18 -0700 |
| Message-ID | <877dywqhtv.fsf@nosuchdomain.example.com> |
| In reply to | #151000 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> > ... I was accused of inventing "Malcolm functions" (a "Malcolm
>> > function" is a mapping of input bits to output bits,
>>
>> Is it? I thought a key feature of Malcolm-functions is that they don't
>> do input or output. Or do you mean Malcolm-input and Malcolm-output?
>>
> Really the key feature is that they are not specified to do IO in
> the interface description. So you can always eliminate the IO whilst
> maintaining correct behaviour for a compliant caller. That's not just a
> quibble, often you want to add white box diagnostics to a Malcolm function
> to debug it.
> So yes, Malcolm-input and Malcolm-output. The key reason for defining
> the Malcolm function is not to teach people what the word "function"
> normally means outside of C, but to separate the portions of the program
> which are inherently portable and (except for running out of memory)
> failure free, from those which are inherently hardware bound and can
> fail if the device they are attached to fails.
*sigh*
I believe the point Ben was making is that you used the terms
"input" and "output" (which are used in the C standard to refer
to operations like those done by functions declared in <stdio.h>)
to refer to the values given to and returned by a function call.
There are already perfectly good terms for those: argument values
and return values. I presume Ben knew what you *meant* by "input"
and "output", but was unwilling to accept your use of those terms.
What we seem to be calling a "Malcolm-function" is, I believe,
what is often called a "pure function" -- basically a function
without side effects, which includes not performing any I/O.
The C standard doesn't define the term "pure function", and it
has a commonly accepted meaning. gcc even lets you use a compiler
extension to assert that a function is "pure".
Calling a pure function a "Malcolm-function" is only slightly
better than calling it a "function" and assuming everyone knows
what you mean.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 01:43 -0700 |
| Message-ID | <13e81aac-375b-45ba-9261-8153c406368c@googlegroups.com> |
| In reply to | #151001 |
On Saturday, 4 April 2020 00:18:30 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> > >> > ... I was accused of inventing "Malcolm functions" (a "Malcolm > >> > function" is a mapping of input bits to output bits, > >> > >> Is it? I thought a key feature of Malcolm-functions is that they don't > >> do input or output. Or do you mean Malcolm-input and Malcolm-output? > >> > > Really the key feature is that they are not specified to do IO in > > the interface description. So you can always eliminate the IO whilst > > maintaining correct behaviour for a compliant caller. That's not just a > > quibble, often you want to add white box diagnostics to a Malcolm function > > to debug it. > > So yes, Malcolm-input and Malcolm-output. The key reason for defining > > the Malcolm function is not to teach people what the word "function" > > normally means outside of C, but to separate the portions of the program > > which are inherently portable and (except for running out of memory) > > failure free, from those which are inherently hardware bound and can > > fail if the device they are attached to fails. > > *sigh* > > I believe the point Ben was making is that you used the terms > "input" and "output" (which are used in the C standard to refer > to operations like those done by functions declared in <stdio.h>) > to refer to the values given to and returned by a function call. > There are already perfectly good terms for those: argument values > and return values. I presume Ben knew what you *meant* by "input" > and "output", but was unwilling to accept your use of those terms. > No. I don't think this was the case at all. But don't you see the problem here? Now we can't use the word "input" except as defined by the C standard. Too many words are hijacked and given privileged meanings. The terms "function" and "procedure" are the best terms used to describe "Malcolm functions" and "Malcolm procedures". I could of course try to invent my own terms, and actually there is a case for "bit shuffling functions", but that actually implies a level of invention that I can't own. However in many languages, a function returns a value, whilst a procedure doesn't. That's important for the grammar of the language, because you can write if (function() == x) but not if (procedure() == x) However, in C, that difference isn't capturing anything very important. That's because C subroutines can take pointers. so we might have double getx(); or void getx(double *retval); it doesn't really matter which we use from a software engineering persepctive. > > What we seem to be calling a "Malcolm-function" is, I believe, > what is often called a "pure function" -- basically a function > without side effects, which includes not performing any I/O. > The C standard doesn't define the term "pure function", and it > has a commonly accepted meaning. gcc even lets you use a compiler > extension to assert that a function is "pure". > > Calling a pure function a "Malcolm-function" is only slightly > better than calling it a "function" and assuming everyone knows > what you mean. > rand() isn't a "pure function", but it is a "Malcolm function". It keeps state, but it doesn't do IO. Therefore it can be written portably, with no dependencies, and it can't fail unless there is an internal bug or it runs out of memory - the last can only happen if the program reaches the end of its stack because in fact it won't allocate any memory.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-04 18:23 +0200 |
| Message-ID | <r6ac9d$5vi$1@dont-email.me> |
| In reply to | #151005 |
On 04/04/2020 10:43, Malcolm McLean wrote: > On Saturday, 4 April 2020 00:18:30 UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> ... I was accused of inventing "Malcolm functions" (a "Malcolm >>>>> function" is a mapping of input bits to output bits, >>>> >>>> Is it? I thought a key feature of Malcolm-functions is that they don't >>>> do input or output. Or do you mean Malcolm-input and Malcolm-output? >>>> >>> Really the key feature is that they are not specified to do IO in >>> the interface description. So you can always eliminate the IO whilst >>> maintaining correct behaviour for a compliant caller. That's not just a >>> quibble, often you want to add white box diagnostics to a Malcolm function >>> to debug it. >>> So yes, Malcolm-input and Malcolm-output. The key reason for defining >>> the Malcolm function is not to teach people what the word "function" >>> normally means outside of C, but to separate the portions of the program >>> which are inherently portable and (except for running out of memory) >>> failure free, from those which are inherently hardware bound and can >>> fail if the device they are attached to fails. >> >> *sigh* >> >> I believe the point Ben was making is that you used the terms >> "input" and "output" (which are used in the C standard to refer >> to operations like those done by functions declared in <stdio.h>) >> to refer to the values given to and returned by a function call. >> There are already perfectly good terms for those: argument values >> and return values. I presume Ben knew what you *meant* by "input" >> and "output", but was unwilling to accept your use of those terms. >> > No. I don't think this was the case at all. I interpreted Ben's post in the same way Keith did. But only Ben can say if that was how he intended it. > But don't you see the problem > here? Now we can't use the word "input" except as defined by the C > standard. Too many words are hijacked and given privileged meanings. The English language is limited. Nothing new here - and nothing C specific. Words are /always/ context sensitive. This is a C newsgroup - if there is not context in a post or thread that overrides the meaning of a word, then any word defined in the C standards will be assumed to have that meaning. On its own, "function" therefore means "C function" in this group. The problem here is that you want to have your own private meanings for a lot of words that are different from the C standards, and not at all obvious from the posts or threads. You combine that with a determination to avoid alternatives that /are/ clearly defined in the context of C (such as "return values" and "function arguments" in this case). It is not the C standards that are the problem - it is your sloppy writing. > > The terms "function" and "procedure" are the best terms used to describe > "Malcolm functions" and "Malcolm procedures". I could of course try to > invent my own terms, and actually there is a case for "bit shuffling > functions", but that actually implies a level of invention that I > can't own. Please - don't invent new terms, and don't abuse existing terms. Use the appropriate terms for a C discussion, or elaborate on them to make them clear. "Pure function" seems a reasonable choice for "a function with no observable side-effects and whose return value depends solely on its arguments". Even that, however, is not entirely precise as there are various additional considerations. Can such a function depend on unchanging data from the environment (such as data declared "const")? A gcc "const" function may do so. Can such a function depend on reading changeable data (i.e., it depends on the observable state of the program, but can't change it)? A gcc "pure" function may do so. Can such a function depend on implementation-dependent behaviour? That has important ramifications for portability. As you can see, dividing functions into different categories is not as simple as you would like to think. > However in many languages, a function returns a value, whilst a procedure > doesn't. That's important for the grammar of the language, because you can > write > > if (function() == x) > > but not > > if (procedure() == x) > This is different from the distinction you usually make between Malcolm-functions and Malcolm-procedures. In Pascal, for example, a "function" is directly equivalent to a C function with non-void return type, while a "procedure" is directly equivalent to a C function with void return type. Both Pascal functions and Pascal procedures can have side-effects. A function could, for example, send data from its arguments out to the screen and return the number of characters written. > However, in C, that difference isn't capturing anything very important. > That's because C subroutines can take pointers. /Why/ would you feel the need to introduce another invented term here? Let's pretend you wrote "That's because C functions can take pointers" instead. You are wrong, of course. The distinction between : T foo1(args...) and void foo2(T* returnval, args...) is a matter of user convenience and ABI optimisation rather than anything fundamental. (Indeed, for types that are too large to fit in the ABI's choice of return register, the compiler will turn "foo1" into the form of "foo2" automatically.) This applies to all imperative programming languages that support pointers or some alternative form of output parameters. It is not only for C. > so we might have > > double getx(); > > or > > void getx(double *retval); > > it doesn't really matter which we use from a software engineering > persepctive. >> >> What we seem to be calling a "Malcolm-function" is, I believe, >> what is often called a "pure function" -- basically a function >> without side effects, which includes not performing any I/O. >> The C standard doesn't define the term "pure function", and it >> has a commonly accepted meaning. gcc even lets you use a compiler >> extension to assert that a function is "pure". >> >> Calling a pure function a "Malcolm-function" is only slightly >> better than calling it a "function" and assuming everyone knows >> what you mean. >> > rand() isn't a "pure function", but it is a "Malcolm function". It > keeps state, but it doesn't do IO. That is another nonsensical distinction that is private to your own imagination. To make this clear, let's work with a function "random()" that will return a random number, without being as tied-down as the standard library function rand(). A call to "random()" might involve reading a file "/dev/random", in which case it is certainly doing IO. Or it might be a pseudo-random algorithm and keep an internal state. Or it might use a processor-specific assembly instruction giving a "true" random number result. Or it might self-seed based on the time on the machine. Some of these implementations you might classify as "Malcolm-functions", others not - but the distinction is totally useless to both the programmer and the compiler. > Therefore it can be written > portably, Not necessarily true - the implementation may depend on things like the size of "int" or "long". > with no dependencies, Not necessarily, depending on the requirements of the function. > and it can't fail unless there is > an internal bug or it runs out of memory - the last can only happen > if the program reaches the end of its stack because in fact it > won't allocate any memory. > No function can fail if it is specified properly, implemented correctly, used within the specifications, and run on a system that supports the semantics for the language. (This last one is somewhat hypothetical - the C abstract machine requires the equivalent of an unlimited stack.)
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web