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 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-09 12:42 -0400 |
| Message-ID | <3gIjG.348315$mJ2.342434@fx23.iad> |
| In reply to | #151266 |
On 4/9/20 11:56 AM, Malcolm McLean wrote: > 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 may not be able to do it portably, but you CAN do it (on some machines) using just the core features of C. Without using extensions, you need a machine with the right characteristics, like the address of the ISR needs to be able to be written into the memory mapped control register of the interrupt controller. Of course, the mere mention of interrupts means we are dealing in a non-portable space, because machines do interrupts in very different manners (including not having them at all). >> 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. > What is non-core about *(volatile unsigned char*)(0x1234) = 5; Yes, it isn't portable, but by DEFINITION I/O will involve non-portablility, as machines differ. The only way to make I/O portable is to greatly restrict the machines you will support, which when talking portability is sort of cheating.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-09 10:12 -0700 |
| Message-ID | <730c5155-f371-4c0d-985d-ca0e845878d4@googlegroups.com> |
| In reply to | #151268 |
On Thursday, 9 April 2020 17:42:48 UTC+1, Richard Damon wrote: > On 4/9/20 11:56 AM, Malcolm McLean wrote: > > What is non-core about > > *(volatile unsigned char*)(0x1234) = 5; > > Yes, it isn't portable, but by DEFINITION I/O will involve > non-portablility, as machines differ. The only way to make I/O portable > is to greatly restrict the machines you will support, which when talking > portability is sort of cheating. > Exactly. So saying "does IO vs does not do IO" is almost exactly the same thing as saying "non-portable vs can be made portable". They're two different ways of looking at the same distinction.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-09 15:51 -0400 |
| Message-ID | <e1LjG.138235$UC6.74102@fx09.iad> |
| In reply to | #151270 |
On 4/9/20 1:12 PM, Malcolm McLean wrote: > On Thursday, 9 April 2020 17:42:48 UTC+1, Richard Damon wrote: >> On 4/9/20 11:56 AM, Malcolm McLean wrote: >> >> What is non-core about >> >> *(volatile unsigned char*)(0x1234) = 5; >> >> Yes, it isn't portable, but by DEFINITION I/O will involve >> non-portablility, as machines differ. The only way to make I/O portable >> is to greatly restrict the machines you will support, which when talking >> portability is sort of cheating. >> > Exactly. So saying "does IO vs does not do IO" is almost exactly > the same thing as saying "non-portable vs can be made portable". > > They're two different ways of looking at the same distinction. > Except that not all non-I/O operations are portable.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-09 13:02 -0700 |
| Message-ID | <ee592c58-16a0-44dc-b7b5-6814e3775343@googlegroups.com> |
| In reply to | #151276 |
On Thursday, 9 April 2020 20:51:50 UTC+1, Richard Damon wrote: > On 4/9/20 1:12 PM, Malcolm McLean wrote: > > On Thursday, 9 April 2020 17:42:48 UTC+1, Richard Damon wrote: > >> On 4/9/20 11:56 AM, Malcolm McLean wrote: > >> > >> What is non-core about > >> > >> *(volatile unsigned char*)(0x1234) = 5; > >> > >> Yes, it isn't portable, but by DEFINITION I/O will involve > >> non-portablility, as machines differ. The only way to make I/O portable > >> is to greatly restrict the machines you will support, which when talking > >> portability is sort of cheating. > >> > > Exactly. So saying "does IO vs does not do IO" is almost exactly > > the same thing as saying "non-portable vs can be made portable". > > > > They're two different ways of looking at the same distinction. > > > > Except that not all non-I/O operations are portable. > Like clearing the cache, for example. So it's only "almost exactly the same thing". Not a tautology.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-09 13:06 -0700 |
| Message-ID | <3aaa1e27-88f4-4134-bd9c-539f7a72fb8e@googlegroups.com> |
| In reply to | #151270 |
On Thursday, April 9, 2020 at 1:12:39 PM UTC-4, Malcolm McLean wrote: > On Thursday, 9 April 2020 17:42:48 UTC+1, Richard Damon wrote: > > On 4/9/20 11:56 AM, Malcolm McLean wrote: > > > > What is non-core about > > > > *(volatile unsigned char*)(0x1234) = 5; > > > > Yes, it isn't portable, but by DEFINITION I/O will involve > > non-portablility, as machines differ. The only way to make I/O portable > > is to greatly restrict the machines you will support, which when talking > > portability is sort of cheating. > > > Exactly. So saying "does IO vs does not do IO" is almost exactly > the same thing as saying "non-portable vs can be made portable". It's impossible to do I/O without involving something non-portable. All C I/O has behavior that is defined in terms of reading/writing bytes, and the size of a byte is implementation-defined. There's lots of other I/O portability issues (including just about every detail of the representation of types and the encoding of characters), but byte size is one that's guaranteed to apply to any program that does I/O. However it doesn't work the other way. There's lots of ways in which code can be non-portable that don't involve I/O in any way, shape, or form. Annex J is titled "Portability Issues", is 28 pages long, and most of the issues listed there have nothing to do with I/O. In particular, the byte size, type representation, and character encoding issues I mentioned above can all cause portability issues for a program that doesn't do any I/O at all.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-09 14:49 -0700 |
| Message-ID | <ca367c35-c5a6-4f02-843c-39ac48feb5f3@googlegroups.com> |
| In reply to | #151278 |
On Thursday, 9 April 2020 21:06:25 UTC+1, James Kuyper wrote: > On Thursday, April 9, 2020 at 1:12:39 PM UTC-4, Malcolm McLean wrote: > > > It's impossible to do I/O without involving something non-portable. All > C I/O has behavior that is defined in terms of reading/writing bytes, > and the size of a byte is implementation-defined. There's lots of other > I/O portability issues (including just about every detail of the > representation of types and the encoding of characters), but byte size > is one that's guaranteed to apply to any program that does I/O. > That is a gotcha, though unlikely to be an issue in practice. > > However it doesn't work the other way. There's lots of ways in which > code can be non-portable that don't involve I/O in any way, shape, or > form. Annex J is titled "Portability Issues", is 28 pages long, and > most of the issues listed there have nothing to do with I/O. In > particular, the byte size, type representation, and character encoding > issues I mentioned above can all cause portability issues for a program > that doesn't do any I/O at all. > You certainly can have "portability issues". But you can overcome most of them. Sometimes you have to define operations in terms of C types rather than bits for practical and efficiency reasons, and sometimes that causes genuine real world problems which can't be overcome. But minimising those situations is one of the points of all of this.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-09 19:05 -0400 |
| Message-ID | <zSNjG.610250$db6.414807@fx33.iad> |
| In reply to | #151281 |
On 4/9/20 5:49 PM, Malcolm McLean wrote: > On Thursday, 9 April 2020 21:06:25 UTC+1, James Kuyper wrote: >> On Thursday, April 9, 2020 at 1:12:39 PM UTC-4, Malcolm McLean wrote: >>> >> It's impossible to do I/O without involving something non-portable. All >> C I/O has behavior that is defined in terms of reading/writing bytes, >> and the size of a byte is implementation-defined. There's lots of other >> I/O portability issues (including just about every detail of the >> representation of types and the encoding of characters), but byte size >> is one that's guaranteed to apply to any program that does I/O. >> > That is a gotcha, though unlikely to be an issue in practice. >> >> However it doesn't work the other way. There's lots of ways in which >> code can be non-portable that don't involve I/O in any way, shape, or >> form. Annex J is titled "Portability Issues", is 28 pages long, and >> most of the issues listed there have nothing to do with I/O. In >> particular, the byte size, type representation, and character encoding >> issues I mentioned above can all cause portability issues for a program >> that doesn't do any I/O at all. >> > You certainly can have "portability issues". But you can overcome > most of them. Sometimes you have to define operations in terms of > C types rather than bits for practical and efficiency reasons, and > sometimes that causes genuine real world problems which can't be > overcome. But minimising those situations is one of the points of > all of this. > But getting back to your original thesis, that there was something important about distinguishing between your definition of a function and a procedure that was so important, you wanted to confusingly use a word with a very standard meaning in the C programming community. That somehow it is important to distinguish between routines that include doing I/O in there operation, and those that don't, as if there is something fundamentally different. A question, Does a function suddenly become a procedure if the memory it writes to becomes visible, like in a display buffer of a video card? How about if the memory it is writing to isn't directly the display buffer, but something has setup a DMA channel to periodically copy the memory to a display buffer? If the difference intentional or not, does it need to know that it is doing I/O to be a procedure? How about a program specially crafted to generate EMI that can be heard on a radio, is that a function or a procedure? How about if the EMI isn't intentional but someone is using it to try to reverse engineer something about the program? Suddenly I don't see a whole lot of ground to use to draw a line between your functions and procedures, there is a lot of muddled ground in between.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-10 02:25 -0700 |
| Message-ID | <9c2efce8-e36e-477d-b768-c412d658b6fa@googlegroups.com> |
| In reply to | #151282 |
On Friday, 10 April 2020 00:05:12 UTC+1, Richard Damon wrote: > > But getting back to your original thesis, that there was something > important about distinguishing between your definition of a function and > a procedure that was so important, you wanted to confusingly use a word > with a very standard meaning in the C programming community. That > somehow it is important to distinguish between routines that include > doing I/O in there operation, and those that don't, as if there is > something fundamentally different. > We can't just say "IO versus not IO" or "portable verus non-portable" without a lot of qualification, because of these problems. > > A question, Does a function suddenly become a procedure if the memory it > writes to becomes visible, like in a display buffer of a video card? > > How about if the memory it is writing to isn't directly the display > buffer, but something has setup a DMA channel to periodically copy the > memory to a display buffer? > > If the difference intentional or not, does it need to know that it is > doing I/O to be a procedure? > > How about a program specially crafted to generate EMI that can be heard > on a radio, is that a function or a procedure? How about if the EMI > isn't intentional but someone is using it to try to reverse engineer > something about the program? > > Suddenly I don't see a whole lot of ground to use to draw a line between > your functions and procedures, there is a lot of muddled ground in between. > Firstly, there's this idea that words denote mathematical sets, or they are useless. That's of course untrue. If we say "tall" there's not a set of men who are tall versus a set of men who are non-tall, instead we have some men who are clearly tall, some who are clearly non-tall, and some who are marginal. Similarly, the vast majority of code that people writes either "does something" or "calculates something". The distinction is usually completely unproblematic. But now we have these marginal cases. What if you pass a display buffer to a function? Is it a "calculating" or "doing". After all, it's mapping one set of bits to another set of bits, so it meets the definition of "a mathematical function" does it not? So maybe we need some sort of fancy defintion to state that all bits must be equivalent. We can't use a loose term like "their location must not matter" because we allow globals. Truth is it really doesn't matter, because if you are writing directly to a disply buffer, your fucntion is unlikely to be useful outside of that specific platform, even if it can in theory be written enitely portable, because it is agnostic about the actual location of the buffer. So it doesn't really matter how you classify it, it could reasonably go in both and not much is lost. However what does blow the thing wide open is "what happens when you parameterise your IO?". What happens id you perform IO via an indirect call verus a direct call? However don't lose sight of the fact that you can do an awful lot by simply mapping bits to bits.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-10 04:38 -0700 |
| Message-ID | <bfcc2697-013d-4478-a27d-ccf637fca746@googlegroups.com> |
| In reply to | #151285 |
On Friday, 10 April 2020 12:25:42 UTC+3, Malcolm McLean wrote: > On Friday, 10 April 2020 00:05:12 UTC+1, Richard Damon wrote: > > > > But getting back to your original thesis, that there was something > > important about distinguishing between your definition of a function and > > a procedure that was so important, you wanted to confusingly use a word > > with a very standard meaning in the C programming community. That > > somehow it is important to distinguish between routines that include > > doing I/O in there operation, and those that don't, as if there is > > something fundamentally different. > > > We can't just say "IO versus not IO" or "portable verus non-portable" > without a lot of qualification, because of these problems. > > > > A question, Does a function suddenly become a procedure if the memory it > > writes to becomes visible, like in a display buffer of a video card? > > > > How about if the memory it is writing to isn't directly the display > > buffer, but something has setup a DMA channel to periodically copy the > > memory to a display buffer? > > > > If the difference intentional or not, does it need to know that it is > > doing I/O to be a procedure? > > > > How about a program specially crafted to generate EMI that can be heard > > on a radio, is that a function or a procedure? How about if the EMI > > isn't intentional but someone is using it to try to reverse engineer > > something about the program? > > > > Suddenly I don't see a whole lot of ground to use to draw a line between > > your functions and procedures, there is a lot of muddled ground in between. > > > Firstly, there's this idea that words denote mathematical sets, or they > are useless. That's of course untrue. If we say "tall" there's not a > set of men who are tall versus a set of men who are non-tall, instead > we have some men who are clearly tall, some who are clearly non-tall, > and some who are marginal. > > Similarly, the vast majority of code that people writes either "does > something" or "calculates something". The distinction is usually > completely unproblematic. But now we have these marginal cases. > > What if you pass a display buffer to a function? Is it a "calculating" > or "doing". After all, it's mapping one set of bits to another set > of bits, so it meets the definition of "a mathematical function" > does it not? So maybe we need some sort of fancy defintion to state > that all bits must be equivalent. We can't use a loose term like > "their location must not matter" because we allow globals. > > Truth is it really doesn't matter, because if you are writing directly > to a disply buffer, your fucntion is unlikely to be useful outside > of that specific platform, even if it can in theory be written > enitely portable, because it is agnostic about the actual location > of the buffer. So it doesn't really matter how you classify it, it > could reasonably go in both and not much is lost. Is portability to other platforms the only reason why those "Malcolm functions" and "Malcolm procedures" are alleged to be useful distinction? If to look at portable frameworks then that does not seem to be case as those often do lot of I/O. > However what does blow the thing wide open is "what happens when > you parameterise your IO?". What happens id you perform IO via > an indirect call verus a direct call? What that typically means is that we have some kind of filters, checkers, correctors, converters and/or the like integrated into or layered between doing I/O. An what happens is that some kind of common filtering, checking, conversion and/or the like is done during I/O and so usually making it simpler and more robust to use. What did blow wide open? > However don't lose sight of the fact that you can do an awful lot > by simply mapping bits to bits. That is true therefore pure functions are useful distinction. That has not much to do with portability. Pure functions are just simpler for people to reason about and also for tools to analyze, validate and optimize. So keeping the parts of program that are possible to write as pure free of impurities herds the complications into fewer locations in code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-10 05:21 -0700 |
| Message-ID | <e0024275-6d30-47ec-ae6c-e8a6bd9c291a@googlegroups.com> |
| In reply to | #151286 |
On Friday, 10 April 2020 12:38:17 UTC+1, Öö Tiib wrote: > On Friday, 10 April 2020 12:25:42 UTC+3, Malcolm McLean wrote: > > Is portability to other platforms the only reason why those > "Malcolm functions" and "Malcolm procedures" are alleged > to be useful distinction? If to look at portable frameworks > then that does not seem to be case as those often do lot of I/O. > No, it's also an attempt to improve the logical structure and arragement of programs. Portability is a bonus. > > > However what does blow the thing wide open is "what happens when > > you parameterise your IO?". What happens id you perform IO via > > an indirect call verus a direct call? > > What that typically means is that we have some kind of > filters, checkers, correctors, converters and/or the like > integrated into or layered between doing I/O. An what happens > is that some kind of common filtering, checking, conversion > and/or the like is done during I/O and so usually making it > simpler and more robust to use. What did blow wide open? > If you don't allow parameterised IO, then you can ask "does this code do IO or doesn't it?" and get a clear distinction, once you've decided exactly what you call "IO". Once you parameterise IO, you can always make the IO routine in fact read and write from memory, and sometimes it makes sense to do that. > > However don't lose sight of the fact that you can do an awful lot > > by simply mapping bits to bits. > > That is true therefore pure functions are useful distinction. > That has not much to do with portability. Pure functions are > just simpler for people to reason about and also for tools > to analyze, validate and optimize. So keeping the parts of > program that are possible to write as pure free of impurities > herds the complications into fewer locations in code. > The distinction between pure functions and non-pure functions is certainly useful and that is generally accepted. I'm saying the the distinction between functions that calculate things and functions that do things is also useful. I'm not saying that when you make this distinction, it is no longer useful to make a disnction between pure and impure functions within the "functions that calculate things".
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-10 07:13 -0700 |
| Message-ID | <4b9b90a0-0393-41de-8857-1f8e379e4d79@googlegroups.com> |
| In reply to | #151287 |
On Friday, 10 April 2020 15:22:06 UTC+3, Malcolm McLean wrote: > On Friday, 10 April 2020 12:38:17 UTC+1, Öö Tiib wrote: > > On Friday, 10 April 2020 12:25:42 UTC+3, Malcolm McLean wrote: > > > > Is portability to other platforms the only reason why those > > "Malcolm functions" and "Malcolm procedures" are alleged > > to be useful distinction? If to look at portable frameworks > > then that does not seem to be case as those often do lot of I/O. > > > No, it's also an attempt to improve the logical structure and > arragement of programs. Portability is a bonus. I was asking because you were seemingly claiming that when some used bits are originating from memory mapped input and/or some altered bits go into memory mapped output then it somehow does not matter because the code is likely platform specific. However purity and portability seem to be orthogonal properties of code and correlation seems incidental. > > > > > However what does blow the thing wide open is "what happens when > > > you parameterise your IO?". What happens id you perform IO via > > > an indirect call verus a direct call? > > > > What that typically means is that we have some kind of > > filters, checkers, correctors, converters and/or the like > > integrated into or layered between doing I/O. An what happens > > is that some kind of common filtering, checking, conversion > > and/or the like is done during I/O and so usually making it > > simpler and more robust to use. What did blow wide open? > > > If you don't allow parameterised IO, then you can ask "does > this code do IO or doesn't it?" and get a clear distinction, once > you've decided exactly what you call "IO". Once you parameterise > IO, you can always make the IO routine in fact read and write > from memory, and sometimes it makes sense to do that. All meaningful software has input and output. Basically most software can be described like input -> processing -> output. Input can come from multiple, possibly unrelated sources and output can go to multiple, possibly also unrelated targets but that it generally is. So when function uses only its parameters (only) for input and only its return value for output then it is pure. It does not matter if its parameters did come from some (possibly platform specific) external source or return value is sent to external target it still keeps being pure. The complications arise from side-effects. Side effects may result with different output and behavior to same input. Such complication makes functions harder to test, analyze optimize and reason about. > > > > However don't lose sight of the fact that you can do an awful lot > > > by simply mapping bits to bits. > > > > That is true therefore pure functions are useful distinction. > > That has not much to do with portability. Pure functions are > > just simpler for people to reason about and also for tools > > to analyze, validate and optimize. So keeping the parts of > > program that are possible to write as pure free of impurities > > herds the complications into fewer locations in code. > > > The distinction between pure functions and non-pure functions > is certainly useful and that is generally accepted. I'm saying > the the distinction between functions that calculate things and > functions that do things is also useful. I'm not saying that when > you make this distinction, it is no longer useful to make a > disnction between pure and impure functions within the "functions > that calculate things". And I am saying that only functions that are pure calculate things, and impure potentially do something or are potentially distracted by something unrelated to that calculation and so are more difficult to reason about. ;)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-10 11:38 -0700 |
| Message-ID | <cc8db103-9023-4756-b19d-158077333c30@googlegroups.com> |
| In reply to | #151290 |
On Friday, 10 April 2020 15:13:20 UTC+1, Öö Tiib wrote: > > I was asking because you were seemingly claiming that when > some used bits are originating from memory mapped input and/or > some altered bits go into memory mapped output then it somehow > does not matter because the code is likely platform specific. > However purity and portability seem to be orthogonal properties > of code and correlation seems incidental. > Pure functions can always be written portably. Functions which take buffers which happen to be memory mapped can also be written portably, but aren't pure functions. Functions which originate the addresses of memory-mapped buffers must be in some way non-portable, though it might be a single line. e.g. unsigned char *raster = 0x80000000; /* screen start address */ However whilst the code that writes into the buffer may be portable, it's unlikely to be of much use unless a compatible dispaly device is attached to the computer. > > So when function uses only its parameters (only) for input > and only its return value for output then it is pure. > It does not matter if its parameters did come from some > (possibly platform specific) external source or return value > is sent to external target it still keeps being pure. > > The complications arise from side-effects. Side effects > may result with different output and behavior to same input. > Such complication makes functions harder to test, analyze > optimize and reason about. > I'm not opposed to pure functions. But I'm distinguishing different types of "side effects". Which I do by defining the function's domain in a different way. > > And I am saying that only functions that are pure calculate things, > and impure potentially do something or are potentially distracted > by something unrelated to that calculation and so are more difficult > to reason about. ;) > A pure function requires that input and output bits be physically distinct, and that input bits be described at the point of invocation, and that output bits be returned to the point of invocation and nowhere else. However if you relax these requirements you don't get "just anything". You get a superset of pure functions, but still quite a narrow one. rand() is now included, for example, but not printf(). You are making your functions harder to reason about by not insisting that every function be pure, I'll agree.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2020-04-11 17:38 +0000 |
| Message-ID | <slrn3losr94040.61j.ike@sdf.lonestar.org> |
| In reply to | #151291 |
On 2020-04-10, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > A pure function requires that input and output bits be physically > distinct, and that input bits be described at the point of invocation, > and that output bits be returned to the point of invocation and > nowhere else. I don't follow. Let int pure(int arg); be a pure function, and let int var; be a variable that holds a value such that pure(var) is well-defined. Are you saying that, if we call the function as follows: var = pure(var); that now suddenly the function is no longer pure because its input bits and output bits are not distinct? (both are the bits of 'var').
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-11 15:04 -0700 |
| Message-ID | <87h7xpk7c2.fsf@nosuchdomain.example.com> |
| In reply to | #151292 |
Ike Naar <ike@sdf.lonestar.org> writes:
> On 2020-04-10, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> A pure function requires that input and output bits be physically
>> distinct, and that input bits be described at the point of invocation,
>> and that output bits be returned to the point of invocation and
>> nowhere else.
>
> I don't follow. Let
>
> int pure(int arg);
>
> be a pure function, and let
>
> int var;
>
> be a variable that holds a value such that pure(var) is well-defined.
> Are you saying that, if we call the function as follows:
>
> var = pure(var);
>
> that now suddenly the function is no longer pure because its
> input bits and output bits are not distinct? (both are the bits of 'var').
I don't think so, and though I can only speculate I don't think
Malcolm thinks so either.
The "input bits" for that call are (the representation of) the
current *value* of var, not the object var. That value is obtained
via the *lvalue conversion* described in N1570 6.3.2.1p2 before the
function is called. The "output bits" are (the representation of)
the function's return value. The storage of those bits in var is
done by the assignment, not by the function call.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-11 15:16 -0400 |
| Message-ID | <2IokG.1296436$ek.27835@fx48.iad> |
| In reply to | #151291 |
On 4/10/20 2:38 PM, Malcolm McLean wrote: > On Friday, 10 April 2020 15:13:20 UTC+1, Öö Tiib wrote: >> >> I was asking because you were seemingly claiming that when >> some used bits are originating from memory mapped input and/or >> some altered bits go into memory mapped output then it somehow >> does not matter because the code is likely platform specific. >> However purity and portability seem to be orthogonal properties >> of code and correlation seems incidental. >> > Pure functions can always be written portably. Disagree here. The ONLY way you can make such a claim is to restrict your machine definition to something that isn't efficient. Either you need to define that all math is to be done in infinite precision arithmetic (which is inefficient on most machines), has a language defined precision (sort of like what Java does so that it is inefficient on any machine that doesn't well match the language specification) or you get non-portable answers. C was designed for efficiency over portability, which is one reason it did succeed in its designed market. This simple question of what is the natural result of 20,000 + 20,000 has two possible answers on common current machines, 40,000 and -25,536 (on a machine with 16 bit integers). Unless you restrict you class of problems to only those stated so that they require a portable answer, you have non-portable functions. Then you get the non-portable functions due to the need for the results to be suitable for I/O, and you bring in a whole host of other non-portable conditions (or does the fact that we are thinking about I/O cross the line and make them procedures?) > > Functions which take buffers which happen to be memory mapped can > also be written portably, but aren't pure functions. > > Functions which originate the addresses of memory-mapped buffers > must be in some way non-portable, though it might be a single line. > > e.g. > unsigned char *raster = 0x80000000; /* screen start address */ > > However whilst the code that writes into the buffer may be portable, > it's unlikely to be of much use unless a compatible dispaly device > is attached to the computer. But by your definition, when we call some function with that parameter, whether that function actually is a 'function' or a 'procedure' is now dependent of if that address is an ordinary block of ram, or a display buffer. >> >> So when function uses only its parameters (only) for input >> and only its return value for output then it is pure. >> It does not matter if its parameters did come from some >> (possibly platform specific) external source or return value >> is sent to external target it still keeps being pure. >> >> The complications arise from side-effects. Side effects >> may result with different output and behavior to same input. >> Such complication makes functions harder to test, analyze >> optimize and reason about. >> > I'm not opposed to pure functions. But I'm distinguishing > different types of "side effects". Which I do by defining the > function's domain in a different way. >> >> And I am saying that only functions that are pure calculate things, >> and impure potentially do something or are potentially distracted >> by something unrelated to that calculation and so are more difficult >> to reason about. ;) >> > A pure function requires that input and output bits be physically > distinct, and that input bits be described at the point of invocation, > and that output bits be returned to the point of invocation and > nowhere else. > However if you relax these requirements you don't get "just anything". > You get a superset of pure functions, but still quite a narrow one. > rand() is now included, for example, but not printf(). > You are making your functions harder to reason about by not insisting > that every function be pure, I'll agree. > > Again, we come to the point, does this class of routines, that you want to 'hijack' the well defined (in C) definition of a function, to use that same label, and cause all the confusion. Since this class of functions can access and create all sorts of side effects (as long as it isn't 'I/O') there is little that an implementation can do based on knowing that a given routine is or is not a function of this type. 'Pure functions' can have an important use, as since given exactly the same parameters they will produce always the exact same output means that they become available to have their usage optimized, and redundant calls removed. I will have to say that I can't recall any significant mentioning by anyone else of this type of distinction.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-11 21:45 +0100 |
| Message-ID | <87h7xpn44g.fsf@bsb.me.uk> |
| In reply to | #151293 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 4/10/20 2:38 PM, Malcolm McLean wrote:
>> On Friday, 10 April 2020 15:13:20 UTC+1, Öö Tiib wrote:
>>>
>>> I was asking because you were seemingly claiming that when
>>> some used bits are originating from memory mapped input and/or
>>> some altered bits go into memory mapped output then it somehow
>>> does not matter because the code is likely platform specific.
>>> However purity and portability seem to be orthogonal properties
>>> of code and correlation seems incidental.
>>>
>> Pure functions can always be written portably.
>
> Disagree here. The ONLY way you can make such a claim is to restrict
> your machine definition to something that isn't efficient. Either you
> need to define that all math is to be done in infinite precision
> arithmetic (which is inefficient on most machines), has a language
> defined precision (sort of like what Java does so that it is inefficient
> on any machine that doesn't well match the language specification) or
> you get non-portable answers. C was designed for efficiency over
> portability, which is one reason it did succeed in its designed market.
I was debating whether to make this point as well. MM is a broad-brush
kind of person and I am sure there is some meaning (possibly along the
lines you paint here) that is what was really meant. Anyway, for what
it's worth, my example was going to be
unsigned long long bit_set(void)
{
return 0x800008000200000020000000800A20AC;
}
where the author clearly knew that unsigned long long was 128 bits wide.
This function can't be written portably (in the usual sense of the word)
because not all implementations have an 128-bit unsigned type. The
whole program would need to be re-engineered (quite possible including
some of the I/O library) to use an invented fake 128-bit integer type.
And even that counts as "portable", it's likely that a total re-design
of affected parts would be an better option.
The fact that this function is pure is, to put is mildly, secondary to
the fact that it is very much not portable.
<cut>
> I will have to say that I can't recall any significant mentioning by
> anyone else of this type of distinction.
Me neither. I'm still baffled why Malcolm thinks it is so important.
(Yes, I know the /stated/ reasons.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-12 04:39 -0700 |
| Message-ID | <c6ecfa15-23a6-419a-8bbc-e5f9175373b4@googlegroups.com> |
| In reply to | #151294 |
On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
> > On 4/10/20 2:38 PM, Malcolm McLean wrote:
> >> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
> >>>
> >>> I was asking because you were seemingly claiming that when
> >>> some used bits are originating from memory mapped input and/or
> >>> some altered bits go into memory mapped output then it somehow
> >>> does not matter because the code is likely platform specific.
> >>> However purity and portability seem to be orthogonal properties
> >>> of code and correlation seems incidental.
> >>>
> >> Pure functions can always be written portably.
> >
> > Disagree here. The ONLY way you can make such a claim is to restrict
> > your machine definition to something that isn't efficient. Either you
> > need to define that all math is to be done in infinite precision
> > arithmetic (which is inefficient on most machines), has a language
> > defined precision (sort of like what Java does so that it is inefficient
> > on any machine that doesn't well match the language specification) or
> > you get non-portable answers. C was designed for efficiency over
> > portability, which is one reason it did succeed in its designed market.
>
> I was debating whether to make this point as well. MM is a broad-brush
> kind of person and I am sure there is some meaning (possibly along the
> lines you paint here) that is what was really meant. Anyway, for what
> it's worth, my example was going to be
>
> unsigned long long bit_set(void)
> {
> return 0x800008000200000020000000800A20AC;
> }
>
> where the author clearly knew that unsigned long long was 128 bits wide.
>
> This function can't be written portably (in the usual sense of the word)
> because not all implementations have an 128-bit unsigned type. The
> whole program would need to be re-engineered (quite possible including
> some of the I/O library) to use an invented fake 128-bit integer type.
> And even that counts as "portable", it's likely that a total re-design
> of affected parts would be an better option.
>
> The fact that this function is pure is, to put is mildly, secondary to
> the fact that it is very much not portable.
>
A function maps bits on entry to bits on exit, and if you want to be
100% portable you have to specify it in terms of bits. So yes, you
need to fake up a 128 bit type if you need 128 bit computations. But
you can do that.
Instead of saying "this function must return a C unsigned long that
holds the value 0x800008000200000020000000800A20AC, which is clearly
impossible to achieve portably, we need to say
"this function must map the unit set (an empty list of bits in), to
the set of bits that represent values, choosing the member that
represents the value 0x800008000200000020000000800A20AC".
You then have to provide "the set of bits that represent values", which
depends on the rest of the program.
There's the human-meaningful function you are trying to model, then
there's the C type. Sometimes, though rarely, the C types won't be
up to the task of modelling the human-meaningful function, so you
have to drop down to bits.
To give another example, consider the fucntion "cosine". We could say
the human meaningful function is "this function shall a reasonable
approximation to the cosine of theta, as long as theta is reasonably
close to the range +/- 2 * PI". Or we could say, "this function shall
return the cosine of theta, adhering exactly to important body standard
this and that".
You can reasonably want either, but if the higher ups demand the second,
we have a portablity headache. However that won't daunt us. We'll just
download some floating point routines from github, and build the
function on top of integer operations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-12 21:34 +0100 |
| Message-ID | <87zhbgl9yd.fsf@bsb.me.uk> |
| In reply to | #151298 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>> > On 4/10/20 2:38 PM, Malcolm McLean wrote:
>> >> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
>> >>>
>> >>> I was asking because you were seemingly claiming that when
>> >>> some used bits are originating from memory mapped input and/or
>> >>> some altered bits go into memory mapped output then it somehow
>> >>> does not matter because the code is likely platform specific.
>> >>> However purity and portability seem to be orthogonal properties
>> >>> of code and correlation seems incidental.
>> >>>
>> >> Pure functions can always be written portably.
>> >
>> > Disagree here. The ONLY way you can make such a claim is to restrict
>> > your machine definition to something that isn't efficient. Either you
>> > need to define that all math is to be done in infinite precision
>> > arithmetic (which is inefficient on most machines), has a language
>> > defined precision (sort of like what Java does so that it is inefficient
>> > on any machine that doesn't well match the language specification) or
>> > you get non-portable answers. C was designed for efficiency over
>> > portability, which is one reason it did succeed in its designed market.
>>
>> I was debating whether to make this point as well. MM is a broad-brush
>> kind of person and I am sure there is some meaning (possibly along the
>> lines you paint here) that is what was really meant. Anyway, for what
>> it's worth, my example was going to be
>>
>> unsigned long long bit_set(void)
>> {
>> return 0x800008000200000020000000800A20AC;
>> }
>>
>> where the author clearly knew that unsigned long long was 128 bits wide.
>>
>> This function can't be written portably (in the usual sense of the word)
>> because not all implementations have an 128-bit unsigned type. The
>> whole program would need to be re-engineered (quite possible including
>> some of the I/O library) to use an invented fake 128-bit integer type.
>> And even that counts as "portable", it's likely that a total re-design
>> of affected parts would be an better option.
>>
>> The fact that this function is pure is, to put is mildly, secondary to
>> the fact that it is very much not portable.
>>
> A function maps bits on entry to bits on exit, and if you want to be
> 100% portable you have to specify it in terms of bits. So yes, you
> need to fake up a 128 bit type if you need 128 bit computations. But
> you can do that.
You appeared to want your odd distinction for "structuring" the code
with, unless I misunderstood, portability in mind. The point of these
examples is that a few Malcolm functions might well be the portability
headaches, and not any of the Malcolm procedures.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-12 14:38 -0700 |
| Message-ID | <35f04e61-0297-4ce4-912b-10831fc16cac@googlegroups.com> |
| In reply to | #151301 |
On Sunday, 12 April 2020 21:34:50 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> > On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>
> >> > On 4/10/20 2:38 PM, Malcolm McLean wrote:
> >> >> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
> >> >>>
> >> >>> I was asking because you were seemingly claiming that when
> >> >>> some used bits are originating from memory mapped input and/or
> >> >>> some altered bits go into memory mapped output then it somehow
> >> >>> does not matter because the code is likely platform specific.
> >> >>> However purity and portability seem to be orthogonal properties
> >> >>> of code and correlation seems incidental.
> >> >>>
> >> >> Pure functions can always be written portably.
> >> >
> >> > Disagree here. The ONLY way you can make such a claim is to restrict
> >> > your machine definition to something that isn't efficient. Either you
> >> > need to define that all math is to be done in infinite precision
> >> > arithmetic (which is inefficient on most machines), has a language
> >> > defined precision (sort of like what Java does so that it is inefficient
> >> > on any machine that doesn't well match the language specification) or
> >> > you get non-portable answers. C was designed for efficiency over
> >> > portability, which is one reason it did succeed in its designed market.
> >>
> >> I was debating whether to make this point as well. MM is a broad-brush
> >> kind of person and I am sure there is some meaning (possibly along the
> >> lines you paint here) that is what was really meant. Anyway, for what
> >> it's worth, my example was going to be
> >>
> >> unsigned long long bit_set(void)
> >> {
> >> return 0x800008000200000020000000800A20AC;
> >> }
> >>
> >> where the author clearly knew that unsigned long long was 128 bits wide.
> >>
> >> This function can't be written portably (in the usual sense of the word)
> >> because not all implementations have an 128-bit unsigned type. The
> >> whole program would need to be re-engineered (quite possible including
> >> some of the I/O library) to use an invented fake 128-bit integer type.
> >> And even that counts as "portable", it's likely that a total re-design
> >> of affected parts would be an better option.
> >>
> >> The fact that this function is pure is, to put is mildly, secondary to
> >> the fact that it is very much not portable.
> >>
> > A function maps bits on entry to bits on exit, and if you want to be
> > 100% portable you have to specify it in terms of bits. So yes, you
> > need to fake up a 128 bit type if you need 128 bit computations. But
> > you can do that.
>
> You appeared to want your odd distinction for "structuring" the code
> with, unless I misunderstood, portability in mind. The point of these
> examples is that a few Malcolm functions might well be the portability
> headaches, and not any of the Malcolm procedures.
>
All the "Malcolm functions" can be written portably, but that doesn't
mean to say that they are written portably, or that if they are not
written portably they are somehow lesser Malcolm functions. That
doesn't even say that they should be written portably.
The signatures need to be specified portably if the code is to be
portable, of course. Which means that we have to say that "an
implemention of a function" means "a compatible mapping of bits to
bits", not a "a mapping of C variables to C variables", though the
latter is how we think in practice, until, as with 128 bit arithmetic,
it bites us and we need to drop down to talking about bits.
In practice, might our Malcolm functions be the portablity headache,
not the IO? In a sense, that you might be fairly confident that
you won't lose the IO, less confident that you won't lose 128 bit type.
But you should know when your Malcolm functions are using non-portable
operations on types. Fix that, and they will work for as long as there
is a compatible dialect of C. However the IO system may be taken away
because of some unexpected future development.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-13 11:13 -0400 |
| Message-ID | <5k%kG.2$th5.0@fx14.iad> |
| In reply to | #151298 |
On 4/12/20 7:39 AM, Malcolm McLean wrote:
> On Saturday, 11 April 2020 21:45:30 UTC+1, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 4/10/20 2:38 PM, Malcolm McLean wrote:
>>>> On Friday, 10 April 2020 15:13:20 UTC+1, 嘱 Tiib wrote:
>>>>>
>>>>> I was asking because you were seemingly claiming that when
>>>>> some used bits are originating from memory mapped input and/or
>>>>> some altered bits go into memory mapped output then it somehow
>>>>> does not matter because the code is likely platform specific.
>>>>> However purity and portability seem to be orthogonal properties
>>>>> of code and correlation seems incidental.
>>>>>
>>>> Pure functions can always be written portably.
>>>
>>> Disagree here. The ONLY way you can make such a claim is to restrict
>>> your machine definition to something that isn't efficient. Either you
>>> need to define that all math is to be done in infinite precision
>>> arithmetic (which is inefficient on most machines), has a language
>>> defined precision (sort of like what Java does so that it is inefficient
>>> on any machine that doesn't well match the language specification) or
>>> you get non-portable answers. C was designed for efficiency over
>>> portability, which is one reason it did succeed in its designed market.
>>
>> I was debating whether to make this point as well. MM is a broad-brush
>> kind of person and I am sure there is some meaning (possibly along the
>> lines you paint here) that is what was really meant. Anyway, for what
>> it's worth, my example was going to be
>>
>> unsigned long long bit_set(void)
>> {
>> return 0x800008000200000020000000800A20AC;
>> }
>>
>> where the author clearly knew that unsigned long long was 128 bits wide.
>>
>> This function can't be written portably (in the usual sense of the word)
>> because not all implementations have an 128-bit unsigned type. The
>> whole program would need to be re-engineered (quite possible including
>> some of the I/O library) to use an invented fake 128-bit integer type.
>> And even that counts as "portable", it's likely that a total re-design
>> of affected parts would be an better option.
>>
>> The fact that this function is pure is, to put is mildly, secondary to
>> the fact that it is very much not portable.
>>
> A function maps bits on entry to bits on exit, and if you want to be
> 100% portable you have to specify it in terms of bits. So yes, you
> need to fake up a 128 bit type if you need 128 bit computations. But
> you can do that.
> Instead of saying "this function must return a C unsigned long that
> holds the value 0x800008000200000020000000800A20AC, which is clearly
> impossible to achieve portably, we need to say
> "this function must map the unit set (an empty list of bits in), to
> the set of bits that represent values, choosing the member that
> represents the value 0x800008000200000020000000800A20AC".
>
> You then have to provide "the set of bits that represent values", which
> depends on the rest of the program.
>
> There's the human-meaningful function you are trying to model, then
> there's the C type. Sometimes, though rarely, the C types won't be
> up to the task of modelling the human-meaningful function, so you
> have to drop down to bits.
>
> To give another example, consider the fucntion "cosine". We could say
> the human meaningful function is "this function shall a reasonable
> approximation to the cosine of theta, as long as theta is reasonably
> close to the range +/- 2 * PI". Or we could say, "this function shall
> return the cosine of theta, adhering exactly to important body standard
> this and that".
> You can reasonably want either, but if the higher ups demand the second,
> we have a portablity headache. However that won't daunt us. We'll just
> download some floating point routines from github, and build the
> function on top of integer operations.
>
So I guess this means that C can't have functions, since C has no
totally portable way of defining inputs and outputs in terms of 'bits'.
The closest you can get with this would be arrays of unsigned chars,
which even that is technically not portable in C since you have some
machines where CHAR_BITS != 8. Also most of the standard library are not
functiona since it defines inputs and outputs in terms of things that
aren't fixed in size. (maybe some of the string functions are if you are
willing to restrict yourself to machines with CHAR_BITS = 8).
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web