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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-06 21:12 -0600 |
| Message-ID | <1blfn8m1ke.fsf@pfeifferfamily.net> |
| In reply to | #151166 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> Ok, so what about indirect subroutines? Clearly qsort is a function >> and not a procedure. But what if someone slips a printf into the >> comparison function? Doesn't that break our rules? >> >> More about that later. > > Does anyone else care about the distinction you are making? But if you > come up with any references that support the idea that a routine that > does not do IO should be called a function and one the does, a > procedure, I'd be interested. It might answer the questions you have > not. Of course not. If anyone did, either there would be competing definitions of "function" and "procedure" (or, conceivably, the existing terms could match Malcolm's definitions), or there would be new terms based on the distinction.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-04-07 16:55 +0000 |
| Message-ID | <2g2jG.166546$xv4.74746@fx18.iad> |
| In reply to | #151167 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> Ok, so what about indirect subroutines? Clearly qsort is a function >>> and not a procedure. But what if someone slips a printf into the >>> comparison function? Doesn't that break our rules? >>> >>> More about that later. >> >> Does anyone else care about the distinction you are making? But if you >> come up with any references that support the idea that a routine that >> does not do IO should be called a function and one the does, a >> procedure, I'd be interested. It might answer the questions you have >> not. > >Of course not. If anyone did, either there would be competing >definitions of "function" and "procedure" (or, conceivably, the existing >terms could match Malcolm's definitions), or there would be new terms >based on the distinction. He's probably an old Pascal programmer, wherein there was a distinction between procedure and function.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-07 11:05 -0600 |
| Message-ID | <1bblo3mdkr.fsf@pfeifferfamily.net> |
| In reply to | #151195 |
scott@slp53.sl.home (Scott Lurndal) writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> Ok, so what about indirect subroutines? Clearly qsort is a function >>>> and not a procedure. But what if someone slips a printf into the >>>> comparison function? Doesn't that break our rules? >>>> >>>> More about that later. >>> >>> Does anyone else care about the distinction you are making? But if you >>> come up with any references that support the idea that a routine that >>> does not do IO should be called a function and one the does, a >>> procedure, I'd be interested. It might answer the questions you have >>> not. >> >>Of course not. If anyone did, either there would be competing >>definitions of "function" and "procedure" (or, conceivably, the existing >>terms could match Malcolm's definitions), or there would be new terms >>based on the distinction. > > He's probably an old Pascal programmer, wherein there was a distinction > between procedure and function. I thought about mentioning Pascal, but the distinction there isn't Malcolm's. Likewise Fortran functions and subroutines.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-07 20:39 +0200 |
| Message-ID | <r6ihcr$psd$2@dont-email.me> |
| In reply to | #151197 |
On 07/04/2020 19:05, Joe Pfeiffer wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> Ok, so what about indirect subroutines? Clearly qsort is a function >>>>> and not a procedure. But what if someone slips a printf into the >>>>> comparison function? Doesn't that break our rules? >>>>> >>>>> More about that later. >>>> >>>> Does anyone else care about the distinction you are making? But if you >>>> come up with any references that support the idea that a routine that >>>> does not do IO should be called a function and one the does, a >>>> procedure, I'd be interested. It might answer the questions you have >>>> not. >>> >>> Of course not. If anyone did, either there would be competing >>> definitions of "function" and "procedure" (or, conceivably, the existing >>> terms could match Malcolm's definitions), or there would be new terms >>> based on the distinction. >> >> He's probably an old Pascal programmer, wherein there was a distinction >> between procedure and function. > > I thought about mentioning Pascal, but the distinction there isn't > Malcolm's. Likewise Fortran functions and subroutines. > I /did/ mention Pascal - and as you say, its distinction between procedures and functions does not match Malcolm's.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 11:48 -0700 |
| Message-ID | <de0b717c-85eb-49b6-91b2-e2122a94bdea@googlegroups.com> |
| In reply to | #151206 |
On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > I /did/ mention Pascal - and as you say, its distinction between > procedures and functions does not match Malcolm's. > However C does make the distinction. With C, you can implement any mathematical function using just the language, within the limits of the computer's memory. However you can't implement a single one of what I call procedures, other than by knowing the hardware you are running on and writing to absolute memory addresses when that's the IO facility.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-07 21:21 -0600 |
| Message-ID | <1bftder7by.fsf@pfeifferfamily.net> |
| In reply to | #151208 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: >> >> I /did/ mention Pascal - and as you say, its distinction between >> procedures and functions does not match Malcolm's. >> > However C does make the distinction. With C, you can implement any > mathematical function using just the language, within the limits of > the computer's memory. However you can't implement a single one > of what I call procedures, other than by knowing the hardware you > are running on and writing to absolute memory addresses when that's > the IO facility. A very quick search doesn't find the word "procedure" in the standard at all, let alone make any distinction between procedures and functions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-07 20:40 -0700 |
| Message-ID | <097a50af-465c-4b1d-85e5-679dae8cf919@googlegroups.com> |
| In reply to | #151208 |
On Tuesday, April 7, 2020 at 2:48:21 PM UTC-4, Malcolm McLean wrote: > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > > > I /did/ mention Pascal - and as you say, its distinction between > > procedures and functions does not match Malcolm's. > > > However C does make the distinction. No, it does not. You cannot make a distinction between a procedure and a function without using both terms. The C standard only uses the term "function", never uses the term "procedure", and uses the term "function" to refer to things you call procedures, as is consistent with the C standard's definition for the term "function".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 01:41 -0700 |
| Message-ID | <bc551179-10ce-4249-bb22-7c421dfd765c@googlegroups.com> |
| In reply to | #151223 |
On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > On Tuesday, April 7, 2020 at 2:48:21 PM UTC-4, Malcolm McLean wrote: > > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > > > > > I /did/ mention Pascal - and as you say, its distinction between > > > procedures and functions does not match Malcolm's. > > > > > However C does make the distinction. > > No, it does not. You cannot make a distinction between a procedure and a > function without using both terms. The C standard only uses the term > "function", never uses the term "procedure", and uses the term > "function" to refer to things you call procedures, as is consistent with > the C standard's definition for the term "function". > In C, every "Malcolm function" if I must still use the term can be written using just the language, and none of the libraries. Not a single "Malcolm procedure" can be written using just the language, ubless IO is memory-mapped and you know the absolute address to which to write, in which case you are using a non-portable feature. So C does make the distinction I'm making. That's not necessarily true of other languages where IO is implememted by statements which are part of the language and always available.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 07:40 -0700 |
| Message-ID | <b2fd88f2-f146-4920-99ed-1ed1c38bcdae@googlegroups.com> |
| In reply to | #151227 |
On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: ... > > No, it does not. You cannot make a distinction between a procedure and a > > function without using both terms. The C standard only uses the term > > "function", never uses the term "procedure", and uses the term > > "function" to refer to things you call procedures, as is consistent with > > the C standard's definition for the term "function". > > > In C, every "Malcolm function" if I must still use the term can be written > using just the language, and none of the libraries. Not a single > "Malcolm procedure" can be written using just the language, ubless > IO is memory-mapped and you know the absolute address to which to write, > in which case you are using a non-portable feature. > > So C does make the distinction I'm making. So, Malcolm-"make a distinction" is yet another phrase that has a different meaning for you than it does in ordinary English. Using normal English, you could describe those facts by saying that C provides terminology that allows you to make the distinction, but C itself does not make the distinction. Even though C Malcolm-"makes a distinction" between a Malcolm-function and a Malcolm-procedure, C does not make a distinction between a function and a procedure.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 08:16 -0700 |
| Message-ID | <432104cf-304d-4cb6-b1a7-894c046a1607@googlegroups.com> |
| In reply to | #151232 |
On Wednesday, 8 April 2020 15:41:13 UTC+1, James Kuyper wrote: > On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > ... > > > No, it does not. You cannot make a distinction between a procedure and a > > > function without using both terms. The C standard only uses the term > > > "function", never uses the term "procedure", and uses the term > > > "function" to refer to things you call procedures, as is consistent with > > > the C standard's definition for the term "function". > > > > > In C, every "Malcolm function" if I must still use the term can be written > > using just the language, and none of the libraries. Not a single > > "Malcolm procedure" can be written using just the language, ubless > > IO is memory-mapped and you know the absolute address to which to write, > > in which case you are using a non-portable feature. > > > > So C does make the distinction I'm making. > > So, Malcolm-"make a distinction" is yet another phrase that has a > different meaning for you than it does in ordinary English. Using normal > English, you could describe those facts by saying that C provides > terminology that allows you to make the distinction, but C itself does > not make the distinction. Even though C Malcolm-"makes a distinction" > between a Malcolm-function and a Malcolm-procedure, C does not make a > distinction between a function and a procedure. > C is an abstract thing rather than a person or a text, so it can't actually "make a distinction". However the standard provides terminology that allows us to make the distiction - the "freestanding environment" and the "hosted enviornment". Every Malcolm function can be implemented in conforming C in a free standing enviornment, not a single Malcolm procedure can. And the C language provides facilities that allow us to enforce the distinction in the compiler. Basically remove all the includes and can the function still be implemented? So we've got the terminology and the language facilities in C to make the distinction. Happy?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 09:17 -0700 |
| Message-ID | <9c846fe9-50e0-4dff-a4e2-95a3c4de0481@googlegroups.com> |
| In reply to | #151233 |
On Wednesday, April 8, 2020 at 11:16:26 AM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 15:41:13 UTC+1, James Kuyper wrote: > > On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > > > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > > ... > > > > No, it does not. You cannot make a distinction between a procedure and a > > > > function without using both terms. The C standard only uses the term > > > > "function", never uses the term "procedure", and uses the term > > > > "function" to refer to things you call procedures, as is consistent with > > > > the C standard's definition for the term "function". > > > > > > > In C, every "Malcolm function" if I must still use the term can be written > > > using just the language, and none of the libraries. Not a single > > > "Malcolm procedure" can be written using just the language, ubless > > > IO is memory-mapped and you know the absolute address to which to write, > > > in which case you are using a non-portable feature. > > > > > > So C does make the distinction I'm making. > > > > So, Malcolm-"make a distinction" is yet another phrase that has a > > different meaning for you than it does in ordinary English. Using normal > > English, you could describe those facts by saying that C provides > > terminology that allows you to make the distinction, but C itself does > > not make the distinction. Even though C Malcolm-"makes a distinction" > > between a Malcolm-function and a Malcolm-procedure, C does not make a > > distinction between a function and a procedure. > > > C is an abstract thing rather than a person or a text, so it can't > actually "make a distinction". The C standard is a text. As such, it could have made the distinction you talk about: - it could have defined the term "function" to mean one thing, and it could have defined the term "procedure" to mean something different - but it doesn't. It doesn't even use the term "procedure" at and it gives a very different meaning than yours to the term "function". > ... However the standard provides terminology > that allows us to make the distiction - the "freestanding environment" > and the "hosted enviornment". Every Malcolm function can be implemented > in conforming C in a free standing enviornment, not a single Malcolm > procedure can. Every free-standing environment has to provide some way to do input/output. Not because the standard says so, but because a program that doesn't do any I/O can't do anything useful except consume CPU resources (which can, in a limited number of contexts, be a useful thing to do). The difference is that in a freestanding environment, the ways in which I/O can be performed are implementation-specific. For instance, in some environments, initializing a volatile-qualified pointer by conversion from a integer constant with the proper value will allow writes through that pointer to do output, or reads through that pointer to do input. There's also likely to be implementation-specific libraries of functions to help you with such things. Note also that in a freestanding environment you can't rely upon support for anything in, for example, <math.h>. I don't believe that use of most of those functions has anything to do with the distinction you're making. > ... And the C language provides facilities that allow us > to enforce the distinction in the compiler. Basically remove all the > includes and can the function still be implemented? > > So we've got the terminology and the language facilities in C to > make the distinction. Except that disallowing #includes would also preclude use of <float.h>, <limits.h>, <stdarg.h>, <stddef.h>, and <stdint.h>, all of which must be supported in a freestanding environment. They all allow you to do useful things that are irrelevant, as I understand it, to the distinction between Malcolm-functions and Malcom-procedures. Also, you can do I/O without using any #includes, through command line arguments, the exit status from the program, and through volatile- qualified pointers.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 09:46 -0700 |
| Message-ID | <bf9c278e-e2b0-4b18-8e81-21a066dec4c8@googlegroups.com> |
| In reply to | #151234 |
On Wednesday, 8 April 2020 17:18:14 UTC+1, James Kuyper wrote: > > Note also that in a freestanding environment you can't rely upon support > for anything in, for example, <math.h>. I don't believe that use of most > of those functions has anything to do with the distinction you're > making. > No, but you can supply the math.h functions. As in fact you often have to do, though you write faster and less accurate versions typically. > > Except that disallowing #includes would also preclude use of <float.h>, > <limits.h>, <stdarg.h>, <stddef.h>, and <stdint.h>, all of which must be > supported in a freestanding environment. They all allow you to do useful > things that are irrelevant, as I understand it, to the distinction > between Malcolm-functions and Malcom-procedures. > Yes, in reality these headers are useful and will always be supplied, so there's no reason to ban them. There is a bit of fuzziness of C types. Whilst i've spoken about a "mapping of bits to bits" to try to explain, first that Malcolm functions are just "functions" in the mathematical but not the C sense, in fact we normally specify functions in terms of C types. So sqrt takes a double in whatever representation the platform uses for doubles, and returns another douuble which is closest representation to the square root. It doesn't make sense to specify it in terms of exponent and mantissa bit patterns. That is slightly problematic, because whilst I've said that Malcolm functions are portable, for some extreme inputs sqrt may succeed on some implentations and fail on others. C isn't a bit-based language. > > Also, you can do I/O without using any #includes, through command line > arguments, the exit status from the program, and through volatile- > qualified pointers. > main() is a special function, and might not be available. As for volatile, it can't have any effect unless you use non-core language facilities, like interrupts. So you can't implement a Malcolm procedure with just "volatile". Malcolm functions shouldn't use the volatile keyword, of course.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 10:37 -0700 |
| Message-ID | <2edf2e71-9692-4d9a-a112-23f8ad6b50e1@googlegroups.com> |
| In reply to | #151235 |
On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: ... > As for volatile, it can't have any effect unless you use non-core > language facilities, like interrupts. volatile int *port1 = (volatile int*)0x12345678; The result of that conversion is implementation-defined, and a fully conforming freestanding implementation of C could define that the result of that conversion is a pointer through which you can do either input or output through a device. That code only involves core language facilities.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 10:48 -0700 |
| Message-ID | <895233b7-8933-44ca-a8e9-c5cc980ec876@googlegroups.com> |
| In reply to | #151236 |
On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: > On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: > ... > > As for volatile, it can't have any effect unless you use non-core > > language facilities, like interrupts. > > volatile int *port1 = (volatile int*)0x12345678; > > The result of that conversion is implementation-defined, and a fully > conforming freestanding implementation of C could define that the result > of that conversion is a pointer through which you can do either input or > output through a device. That code only involves core language facilities. > Yes, as I said earlier upstream. The code isn't compliant, portable C, though it could and probably is used to implement IO. It's got an absolute memory address.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-08 14:07 -0400 |
| Message-ID | <NpojG.347488$mJ2.332099@fx23.iad> |
| In reply to | #151237 |
On 4/8/20 1:48 PM, Malcolm McLean wrote: > On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: >> On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: >> ... >>> As for volatile, it can't have any effect unless you use non-core >>> language facilities, like interrupts. >> >> volatile int *port1 = (volatile int*)0x12345678; >> >> The result of that conversion is implementation-defined, and a fully >> conforming freestanding implementation of C could define that the result >> of that conversion is a pointer through which you can do either input or >> output through a device. That code only involves core language facilities. >> > Yes, as I said earlier upstream. > The code isn't compliant, portable C, though it could and probably is > used to implement IO. It's got an absolute memory address. > > Maybe the answer is that the whole concept of a compliant portable 'Malcolm-Procedure' is an oxymoron, as there is no such thing as a 100% portable I/O operation. You also see to ignore that the C standard library isn't just a bunch of functions, but IS part of the language. An implementation would be totally conforming even if none of the include files mentioned in the standard actually existed as files, but when the compiler say the include statements the compiler just adjusted it state to indicate that it had seen that header, and all the functions were directly implemented in some manner by the compiler. A printf statement in a program doesn't actually need to call a function with a name something like printf. Making the system header files be real files using the C syntax (maybe with some extensions) and the library largely written in C is just a convenience to the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 11:29 -0700 |
| Message-ID | <d8461fac-4536-4493-812e-0bdb02f3aa0e@googlegroups.com> |
| In reply to | #151238 |
On Wednesday, 8 April 2020 19:07:50 UTC+1, Richard Damon wrote:
>
> Maybe the answer is that the whole concept of a compliant portable
> 'Malcolm-Procedure' is an oxymoron, as there is no such thing as a 100%
> portable I/O operation.
>
Exactly. The common answer is to say provide IO facilities as
subroutines which are abstracted away behind the subroutine
call. When the enviornment changes, the subroutine is replaced
by one with equivalent functionality.
So printf() sends characters to a teletype in early programs,
addresses a memory mapped character raster in middle ones, and
sends a stream of characters to the operating system to redirect
to a second program in modern ones.
But that approach has stopped working. You can't in practice
guarantee that printf("Hello world\n") will send a message to
user, even though you have a better chance that the program
will compile and link.
>
> You also see to ignore that the C standard library isn't just a bunch of
> functions, but IS part of the language.
>
Not it's not. That's part of the reason for the success of C. Every
program must do IO of some sort to be useful. But often that's not
by opening files or printing out messages. The program might be
running a thermostat. Input is the room temperature, based on some
sensor, and the target temperature, maybe entred by user via a
dial attached to another sensor. Output is the valve setting to
control the supply of fuel to the boiler. All this could be written
in C on a small processor with no stanard library.
Now let's say that one of the reasons we are using an electronic
control rather than mechanical one is that we don't want the response
to be linear, we want it to be sigmoid. So for some reason it's
better to ramp up the value slowly when it is coming from the "off"
position, and we only want a small change when we are near are target
to avoid overshoot, in the middle, we change the valve setting quite
quickly.
The sigmoid calculating code can be made portable, it can be tested
and debugged on a PC with a C compiler. The code to input the room
temperature, the target temperature, and to control the value
can't be made portable, it's specific to our device. It might still
be written in C, but it will be platform-dependent C with absolute
memory addresses to access the devices.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 16:46 -0700 |
| Message-ID | <673b0629-b32e-4391-9e10-93a6e3b00ffe@googlegroups.com> |
| In reply to | #151237 |
On Wednesday, April 8, 2020 at 1:48:28 PM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: > > On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: > > ... > > > As for volatile, it can't have any effect unless you use non-core > > > language facilities, like interrupts. > > > > volatile int *port1 = (volatile int*)0x12345678; > > > > The result of that conversion is implementation-defined, and a fully > > conforming freestanding implementation of C could define that the result > > of that conversion is a pointer through which you can do either input or > > output through a device. That code only involves core language facilities. > > > Yes, as I said earlier upstream. What, precisely, is it you're claiming to have said "earlier upstream"? That it is in fact possible for "volatile" to have an effect in code that uses only core language facilities? That's what I'm saying, that you're responding "Yes" to. If so, the why did you follow up at a later time, by saying "volatile ... can't have any effect unless you use non-core language facilities"? > The code isn't compliant, portable C, though it could and probably is > used to implement IO. It's got an absolute memory address. I'm not sure what you mean when you say this code isn't compliant - the standard doesn't use any variant of the term "comply". Normal usage (something that I would never dare accuse you of) is to say that something does or does not comply with a requirement - which relevant requirement does this code fail to comply with? This code contains no syntax errors or constraint violations, and does not have undefined behavior. You're right that this code isn't portable. However, this code uses only core language facilities - it's failure to be portable is due entirely to the fact that those core language facilities have implementation- defined behavior, which means that it isn't strictly conforming code. However, essentially all useful programs fail to be strictly conforming. You said nothing about requiring the code to be strictly conforming. Keeping in mind that implementation-defined behavior is "unspecified behavior where each implementation documents how the choice is made" (3.4.1), a program containing such code could qualify as a "correct program", in which case it is required to "act in accordance with 5.1.2.3" (4p3).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-09 01:57 -0700 |
| Message-ID | <89841304-79c4-43a3-9bec-d5eab27c4a08@googlegroups.com> |
| In reply to | #151244 |
On Thursday, 9 April 2020 00:47:10 UTC+1, James Kuyper wrote:
> On Wednesday, April 8, 2020 at 1:48:28 PM UTC-4, Malcolm McLean wrote:
>
> What, precisely, is it you're claiming to have said "earlier upstream"?
>
I made the point that you can implement IO by using absolute addresses,
on some hardware.
>
> That it is in fact possible for "volatile" to have an effect in code
> that uses only core language facilities? That's what I'm saying, that
> you're responding "Yes" to.
> If so, the why did you follow up at a later time, by saying "volatile
> ... can't have any effect unless you use non-core language facilities"?
>
Volatile only has an effect if, for instance, we write a 'a' to the
volatile object, there's an interrupt that read it, then we write a
'b'. Ohterwise it's the same as non-volatile data. But we can't generate
the interrupt using just the core language, though we can probably set
an "interrupt routine" using an extension.
I suppose you could argue that this is doing IO.
void writebytes(volatile int *port)
{
volatile int busycounter;
*port = 'a';
for(busycouter = 0; busycounter < 100; busycounter++);
*port = 'b';
}
Then we call it
writebytes((volatile int *) 0x12345678);
And it's just using the core language because you are passing in the
absolute address rather than calculating it in the function, and
you rely on a non-portabe assumption about the characteristics of
the memory at that region.
That's another case of what I'm going to get onto. Parameterising
your IO rather than supplying it as subroutines.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-09 08:42 -0700 |
| Message-ID | <d4e22be3-b1ce-42ed-b768-98f98d2d07e9@googlegroups.com> |
| In reply to | #151247 |
On Thursday, April 9, 2020 at 4:58:09 AM UTC-4, Malcolm McLean wrote: > On Thursday, 9 April 2020 00:47:10 UTC+1, James Kuyper wrote: > > On Wednesday, April 8, 2020 at 1:48:28 PM UTC-4, Malcolm McLean wrote: > > > > What, precisely, is it you're claiming to have said "earlier upstream"? > > > I made the point that you can implement IO by using absolute addresses, > on some hardware. OK - that I missed. So my follow-up question remains: why did you follow up at a later time, by saying "volatile ... can't have any effect unless you use non-core language facilities"? I guess that the answer is your assumption, explained below, that interrupts must be invoked to make that happen: > > That it is in fact possible for "volatile" to have an effect in code > > that uses only core language facilities? That's what I'm saying, that > > you're responding "Yes" to. > > If so, the why did you follow up at a later time, by saying "volatile > > ... can't have any effect unless you use non-core language facilities"? > > > Volatile only has an effect if, for instance, we write a 'a' to the > volatile object, there's an interrupt that read it, then we write a > 'b'. Ohterwise it's the same as non-volatile data. But we can't generate > the interrupt using just the core language, though we can probably set > an "interrupt routine" using an extension. You might be talking about the way some particular implementations of C actually work. I'm talking about what's allowed by the standard. The standard imposes no such requirement. A conforming implementation of C is allowed to cause (input from/output to) a device as the immediate consequence of (reading from/writing to) a specific piece of memory through a volatile-qualified lvalue without requiring that the code use non-core language features to trigger an interrupt.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-09 08:56 -0700 |
| Message-ID | <fccb1674-e35e-4f8a-ba85-2296d9e6f638@googlegroups.com> |
| In reply to | #151265 |
On Thursday, 9 April 2020 16:42:13 UTC+1, James Kuyper wrote: > On Thursday, April 9, 2020 at 4:58:09 AM UTC-4, Malcolm McLean wrote: > > OK - that I missed. So my follow-up question remains: why did you > follow up at a later time, by saying "volatile ... can't have any > effect unless you use non-core language facilities"? I guess that > the answer is your assumption, explained below, that interrupts > must be invoked to make that happen: > Making data volatile means "something outside of the current thread may read / write this", or, in the case of a delay loop, "don't optimise this away". However using core C, there's no way to create the "something outside of the current thread". Even the delay loop can't be guaranteed because theres no requirement on how long any operation should take, though I suppose you could say you are guaranteed N instructions. Interrupts are an example of something that might access volatile memory. The interrupt service routine and the main routine can both be written in core C, but they can't be set up in that relationship. > > You might be talking about the way some particular > implementations of C actually work. I'm talking about what's > allowed by the standard. The standard imposes no such > requirement. A conforming implementation of C is allowed to cause > (input from/output to) a device as the immediate consequence of > (reading from/writing to) a specific piece of memory through a > volatile-qualified lvalue without requiring that the code use > non-core language features to trigger an interrupt. > Yes, but you need to obtain an address from somewhere to do memory mapped IO. You can't do that with the core language. It might be an absolute address, or it might be an address obtained from an operating system call, but that step has to occur somewhere.
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web