Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #89160 > unrolled thread
| Started by | Muttley@dastardlyhq.com |
|---|---|
| First post | 2023-02-20 16:45 +0000 |
| Last post | 2023-02-21 08:15 -0800 |
| Articles | 20 on this page of 206 — 22 participants |
Back to article view | Back to comp.lang.c++
Is this safe? Muttley@dastardlyhq.com - 2023-02-20 16:45 +0000
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-20 18:34 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-20 11:16 -0800
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-20 21:39 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-20 12:56 -0800
Re: Is this safe? Tony Oliver <guinness.tony@gmail.com> - 2023-02-20 16:17 -0800
Re: Is this safe? Manu Raju <MR@invalid.invalid> - 2023-02-21 01:57 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:15 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 12:31 +0200
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-21 05:36 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-21 02:19 -0800
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-21 14:16 +0100
Re: Is this safe? Ralf Goertz <me@myprovider.invalid> - 2023-02-21 14:40 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-21 05:51 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 15:58 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 14:55 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 19:02 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 17:13 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 19:58 +0200
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-02-21 12:15 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 23:41 +0200
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-03 12:57 -0800
Re: Is this safe? Tony Oliver <guinness.tony@gmail.com> - 2023-02-20 16:14 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-20 23:48 -0500
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-21 00:05 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:14 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-20 21:18 -0500
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-20 20:38 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:18 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-21 15:12 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 14:53 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-21 10:35 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-22 09:25 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-22 22:33 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:25 +0000
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 07:05 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-22 21:21 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 09:39 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:35 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 12:30 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 10:34 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 13:20 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:00 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 18:24 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:28 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 19:01 +0200
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-23 11:57 -0500
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 19:12 +0200
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-23 11:57 -0500
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 12:20 -0500
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-02-24 02:15 +0000
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-24 15:24 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 02:14 -0500
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 07:18 -0500
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:01 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 11:50 -0500
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:41 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 19:44 +0100
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 15:02 +0100
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-02-23 14:49 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 16:25 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:10 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 20:46 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 20:05 +0000
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:48 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 22:12 -0500
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 10:49 +0200
Re: Is this safe? Ralf Fassel <ralfixx@gmx.de> - 2023-02-24 11:36 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-24 15:39 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 10:29 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 17:20 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 17:09 +0000
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-24 17:32 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 11:56 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 16:04 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 15:47 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 19:13 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-25 19:00 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 08:43 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 10:31 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-25 16:40 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 18:42 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 11:58 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 16:25 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 15:45 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 19:15 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 08:44 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 10:40 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 10:24 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 18:31 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 08:38 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-28 01:33 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 10:17 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-28 02:43 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:50 +0100
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 03:19 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 08:10 -0500
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 05:42 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 09:39 -0500
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 07:12 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 11:29 -0500
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:45 +0100
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 11:31 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 20:59 +0100
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-01 14:29 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:37 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 15:56 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 18:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-01 09:37 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-01 02:29 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 19:56 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-01 12:53 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 21:13 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-02 01:48 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-03 21:44 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-03 20:16 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-04 22:55 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 07:11 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-05 20:44 +0000
Re: Is this safe? Mr Flibble <flibble2@reddwarf.jmc.corp> - 2023-03-05 21:00 +0000
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-05 13:59 -0800
Re: Is this safe? Mr Flibble <flibble2@reddwarf.jmc.corp> - 2023-03-05 23:07 +0000
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-06 00:22 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 14:26 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-06 00:51 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-06 02:17 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-05 08:13 -0800
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 09:05 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 09:47 -0700
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 14:40 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:07 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-03-01 21:37 -0500
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-01 22:30 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-01 14:27 +0100
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:48 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-02 10:29 +0100
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 19:53 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:08 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-02 01:32 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:56 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-02 04:02 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-02 15:00 +0100
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-02 07:59 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 15:38 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-02 11:16 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-02 11:08 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-03 09:53 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-04 06:47 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-02 19:35 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-28 17:40 +0100
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 12:16 -0500
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 18:39 +0100
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-24 10:03 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 19:59 +0100
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-25 06:47 +0100
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-25 10:23 +0200
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 07:16 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:31 -0800
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-23 16:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:15 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-24 12:17 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 12:24 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 15:18 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 15:55 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 18:20 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 17:05 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 19:24 +0200
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-24 09:46 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 17:30 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:12 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-23 02:47 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 15:59 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 11:55 -0500
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 08:37 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:19 -0800
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:09 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 12:21 -0500
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:55 +0000
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 13:57 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 17:28 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 21:44 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-24 08:48 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-21 10:58 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-22 09:26 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-22 22:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:29 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 08:28 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 17:16 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 22:24 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-22 21:30 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:31 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 22:00 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 22:20 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 01:34 -0500
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 10:32 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-25 00:19 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-22 08:09 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-21 22:32 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-22 08:32 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-22 09:17 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-04 23:28 -0700
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 11:08 -0700
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:22 -0700
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 16:42 -0700
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-08 05:46 -0700
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-21 08:15 -0800
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-03-05 13:59 -0800 |
| Message-ID | <tu33bh$1eo3t$1@dont-email.me> |
| In reply to | #89456 |
On 3/5/2023 1:00 PM, Mr Flibble wrote:
> On 05/03/2023 20:44, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Saturday, 4 March 2023 at 22:55:37 UTC, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Friday, 3 March 2023 at 21:45:09 UTC, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, 1 March 2023 at 21:13:59 UTC, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Wednesday, 1 March 2023 at 19:56:23 UTC, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 1 March 2023 at 09:38:08 UTC,
>>>>>>>>>>> Mut...@dastardlyhq.com wrote:
>>>>>>>>>>>> On Tue, 28 Feb 2023 18:34:10 +0100
>>>>>>>>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>>>>>>>>> On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
>>>>>>>>>>>>>> A function can follow specifications to the letter and
>>>>>>>>>>>>>> still have hidden
>>>>>>>>>>>>>> bugs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The /specification/ can have bugs or be inappropriate in
>>>>>>>>>>>>> some way. The
>>>>>>>>>>>>> /hardware/ can have bugs. But if a piece of code gives the
>>>>>>>>>>>>> specified
>>>>>>>>>>>>> output and effects for the specified inputs, then it is
>>>>>>>>>>>>> correct and
>>>>>>>>>>>>> bug-free.
>>>>>>>>>>>> Really?
>>>>>>>>>>>>
>>>>>>>>>>>> Spec: function always returns 10
>>>>>>>>>>>>
>>>>>>>>>>>> int func()
>>>>>>>>>>>> {
>>>>>>>>>>>> char *ptr = 0;
>>>>>>>>>>>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>>>>>>>>>>>> return 10;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Bug free?
>>>>>>>>>>>>
>>>>>>>>>>> A better example would be
>>>>>>>>>>>
>>>>>>>>>>> int func()
>>>>>>>>>>> {
>>>>>>>>>>> char *ptr = malloc(1);
>>>>>>>>>>> return 10;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> This function will always return 10, so it's to
>>>>>>>>>>> specification. But
>>>>>>>>>>> it's the source of a bug.
>>>>>>>>>> This is a better example (because it has defined behaviour),
>>>>>>>>>> but does
>>>>>>>>>> the function meet the specification? I would say that, speaking
>>>>>>>>>> informally, specifications are taken to be minimal. Would
>>>>>>>>>>
>>>>>>>>>> int func() { getchar(); return 10; }
>>>>>>>>>>
>>>>>>>>>> meet the specification as well?
>>>>>>>>>>
>>>>>>>>> This is where you get trapped by C's misuse of the term
>>>>>>>>> "function".
>>>>>>>>> If the term "function" were used in the proper mathematical sense,
>>>>>>>>> then the program's memory would be in one state on function
>>>>>>>>> entry and
>>>>>>>>> another on function return, and so you can't have a function
>>>>>>>>> without a
>>>>>>>>> specification.
>>>>>>>> No, that's not the issue. Of course it would help if functions were
>>>>>>>> functions, but the terminology is not the issue here. A sin
>>>>>>>> function
>>>>>>>> (in some unimpeachable language like Haskell) that did all sorts of
>>>>>>>> other computations and took an hour, or used half the available
>>>>>>>> memory,
>>>>>>>> would not meet the specification because, in my book, the
>>>>>>>> specification
>>>>>>>> should be taken to be minimal.
>>>>>>>>> But C "functions" can perform actions. Specifying correct
>>>>>>>>> actions is a whole
>>>>>>>>> different ball game to specifying functions, which are just
>>>>>>>>> mappings from
>>>>>>>>> one set to another.
>>>>>>>> So lets' call them all "procedures" for the moment and get back
>>>>>>>> to the
>>>>>>>> question at hand. Should a specification be taken to be essentially
>>>>>>>> minimal? I would say so.
>>>>>>>>
>>>>>>> If functions are functions then the bits on function entry define
>>>>>>> the
>>>>>>> state of the bits on function exit, and if they match, the
>>>>>>> function is
>>>>>>> correct.
>>>>>> I think the first "functions" refers to C function but second does
>>>>>> not
>>>>>> refer to either mathematical functions nor, say, functions in
>>>>>> Haskell so
>>>>>> I think you are talking about what I once referred to as
>>>>>> Malcolm-functions. Unfortunately I don't remember enough about
>>>>>> what you
>>>>>> mean by the term to do anything but agree with the consequent.
>>>>>>
>>>>> A Malcolm function is that subset of mathematical functions which can
>>>>> be implemented by programming languages. A mathematical function is a
>>>>> mapping from an input set to an output set such that for every member
>>>>> of the input set there is one and only member of the output set. Since
>>>>> Malcolm functions are programming entities, the input set has to
>>>>> ultimately be bits, and the output set also ultimately has to be
>>>>> bits. So bits on function entry determines bits on function
>>>>> exit. Unlike "pure functions" there are no special syntactical or data
>>>>> hiding requirement on Malcolm functions. To all intents and purposes,
>>>>> the term is identical in meaning to the term "function", used in the
>>>>> accepted sense in a computer context, not in the C sense to mean
>>>>> "subroutine".
>>>> I don't know what bits are involved. You can't mean just the bits in
>>>> the parameter and return values or
>>>> int func() { getchar(); return 10; }
>>>> would be a Malcolm function, and you can't mean all the bits in the
>>>> entire (virtual) system or the specification for such a function would
>>>> be ridiculous.
>>>>
>>> A mathematical function doesn't cease to be a mathematical function
>>> because its specification is ridiculous.
>>
>> Of course. And the same would be true of non-mathematical functions as
>> well. I'm trying to find out how your functions are specified. How is
>> the Malcolm function that "just returns 10" specified?
>>
>>> If each possible bit state on code entry maps to one and only one
>>> possible bit state on code exit, and the code doesn't do anything
>>> else, like turn LEDs on or off, then the code is a "function" or if
>>> you prefer, a "Malcolm function".
>>
>> So
>>
>> int f(int x) { extern int inc; return x + inc++; }
>>
>> is a Malcolm function, yes?
>
> Mathematical functions don't have side-effects; f has side effects so
> isn't a mathematical function.
Imvvho, it is still "mathematical", in the sense that it performs
mathematical "tasks" on the mutable state? A side effect to me means the
function did something else besides providing a return value.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble2@reddwarf.jmc.corp> |
|---|---|
| Date | 2023-03-05 23:07 +0000 |
| Message-ID | <1749a88c7e0c7d6d$34$1053351$3aa16cbb@news.newsdemon.com> |
| In reply to | #89460 |
On 05/03/2023 21:59, Chris M. Thomasson wrote:
> On 3/5/2023 1:00 PM, Mr Flibble wrote:
>> On 05/03/2023 20:44, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Saturday, 4 March 2023 at 22:55:37 UTC, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Friday, 3 March 2023 at 21:45:09 UTC, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Wednesday, 1 March 2023 at 21:13:59 UTC, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Wednesday, 1 March 2023 at 19:56:23 UTC, Ben Bacarisse wrote:
>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On Wednesday, 1 March 2023 at 09:38:08 UTC,
>>>>>>>>>>>> Mut...@dastardlyhq.com wrote:
>>>>>>>>>>>>> On Tue, 28 Feb 2023 18:34:10 +0100
>>>>>>>>>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>>>>>>>>>> On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
>>>>>>>>>>>>>>> A function can follow specifications to the letter and
>>>>>>>>>>>>>>> still have hidden
>>>>>>>>>>>>>>> bugs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The /specification/ can have bugs or be inappropriate in
>>>>>>>>>>>>>> some way. The
>>>>>>>>>>>>>> /hardware/ can have bugs. But if a piece of code gives the
>>>>>>>>>>>>>> specified
>>>>>>>>>>>>>> output and effects for the specified inputs, then it is
>>>>>>>>>>>>>> correct and
>>>>>>>>>>>>>> bug-free.
>>>>>>>>>>>>> Really?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Spec: function always returns 10
>>>>>>>>>>>>>
>>>>>>>>>>>>> int func()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> char *ptr = 0;
>>>>>>>>>>>>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>>>>>>>>>>>>> return 10;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug free?
>>>>>>>>>>>>>
>>>>>>>>>>>> A better example would be
>>>>>>>>>>>>
>>>>>>>>>>>> int func()
>>>>>>>>>>>> {
>>>>>>>>>>>> char *ptr = malloc(1);
>>>>>>>>>>>> return 10;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> This function will always return 10, so it's to
>>>>>>>>>>>> specification. But
>>>>>>>>>>>> it's the source of a bug.
>>>>>>>>>>> This is a better example (because it has defined behaviour),
>>>>>>>>>>> but does
>>>>>>>>>>> the function meet the specification? I would say that, speaking
>>>>>>>>>>> informally, specifications are taken to be minimal. Would
>>>>>>>>>>>
>>>>>>>>>>> int func() { getchar(); return 10; }
>>>>>>>>>>>
>>>>>>>>>>> meet the specification as well?
>>>>>>>>>>>
>>>>>>>>>> This is where you get trapped by C's misuse of the term
>>>>>>>>>> "function".
>>>>>>>>>> If the term "function" were used in the proper mathematical
>>>>>>>>>> sense,
>>>>>>>>>> then the program's memory would be in one state on function
>>>>>>>>>> entry and
>>>>>>>>>> another on function return, and so you can't have a function
>>>>>>>>>> without a
>>>>>>>>>> specification.
>>>>>>>>> No, that's not the issue. Of course it would help if functions
>>>>>>>>> were
>>>>>>>>> functions, but the terminology is not the issue here. A sin
>>>>>>>>> function
>>>>>>>>> (in some unimpeachable language like Haskell) that did all
>>>>>>>>> sorts of
>>>>>>>>> other computations and took an hour, or used half the available
>>>>>>>>> memory,
>>>>>>>>> would not meet the specification because, in my book, the
>>>>>>>>> specification
>>>>>>>>> should be taken to be minimal.
>>>>>>>>>> But C "functions" can perform actions. Specifying correct
>>>>>>>>>> actions is a whole
>>>>>>>>>> different ball game to specifying functions, which are just
>>>>>>>>>> mappings from
>>>>>>>>>> one set to another.
>>>>>>>>> So lets' call them all "procedures" for the moment and get back
>>>>>>>>> to the
>>>>>>>>> question at hand. Should a specification be taken to be
>>>>>>>>> essentially
>>>>>>>>> minimal? I would say so.
>>>>>>>>>
>>>>>>>> If functions are functions then the bits on function entry
>>>>>>>> define the
>>>>>>>> state of the bits on function exit, and if they match, the
>>>>>>>> function is
>>>>>>>> correct.
>>>>>>> I think the first "functions" refers to C function but second
>>>>>>> does not
>>>>>>> refer to either mathematical functions nor, say, functions in
>>>>>>> Haskell so
>>>>>>> I think you are talking about what I once referred to as
>>>>>>> Malcolm-functions. Unfortunately I don't remember enough about
>>>>>>> what you
>>>>>>> mean by the term to do anything but agree with the consequent.
>>>>>>>
>>>>>> A Malcolm function is that subset of mathematical functions which can
>>>>>> be implemented by programming languages. A mathematical function is a
>>>>>> mapping from an input set to an output set such that for every member
>>>>>> of the input set there is one and only member of the output set.
>>>>>> Since
>>>>>> Malcolm functions are programming entities, the input set has to
>>>>>> ultimately be bits, and the output set also ultimately has to be
>>>>>> bits. So bits on function entry determines bits on function
>>>>>> exit. Unlike "pure functions" there are no special syntactical or
>>>>>> data
>>>>>> hiding requirement on Malcolm functions. To all intents and purposes,
>>>>>> the term is identical in meaning to the term "function", used in the
>>>>>> accepted sense in a computer context, not in the C sense to mean
>>>>>> "subroutine".
>>>>> I don't know what bits are involved. You can't mean just the bits in
>>>>> the parameter and return values or
>>>>> int func() { getchar(); return 10; }
>>>>> would be a Malcolm function, and you can't mean all the bits in the
>>>>> entire (virtual) system or the specification for such a function would
>>>>> be ridiculous.
>>>>>
>>>> A mathematical function doesn't cease to be a mathematical function
>>>> because its specification is ridiculous.
>>>
>>> Of course. And the same would be true of non-mathematical functions as
>>> well. I'm trying to find out how your functions are specified. How is
>>> the Malcolm function that "just returns 10" specified?
>>>
>>>> If each possible bit state on code entry maps to one and only one
>>>> possible bit state on code exit, and the code doesn't do anything
>>>> else, like turn LEDs on or off, then the code is a "function" or if
>>>> you prefer, a "Malcolm function".
>>>
>>> So
>>>
>>> int f(int x) { extern int inc; return x + inc++; }
>>>
>>> is a Malcolm function, yes?
>>
>> Mathematical functions don't have side-effects; f has side effects so
>> isn't a mathematical function.
>
> Imvvho, it is still "mathematical", in the sense that it performs
> mathematical "tasks" on the mutable state? A side effect to me means the
> function did something else besides providing a return value.
And incrementing "inc" is a side effect. Even if we ignore side effects
it still isn't a mathematical function because mathematical functions
always return the same value for the same input(s).
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-03-06 00:22 +0000 |
| Message-ID | <87cz5mn2xt.fsf@bsb.me.uk> |
| In reply to | #89456 |
Mr Flibble <flibble2@reddwarf.jmc.corp> writes:
> On 05/03/2023 20:44, Ben Bacarisse wrote:
...
>> So
>> int f(int x) { extern int inc; return x + inc++; }
>> is a Malcolm function, yes?
>
> Mathematical functions don't have side-effects; f has side effects so isn't
> a mathematical function.
You presumably know about denotational semantics, yes? So what does
this remark of yours add?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-03-05 14:26 -0800 |
| Message-ID | <8b99c8ba-dfa7-4eb4-ac30-c8f6f9c869edn@googlegroups.com> |
| In reply to | #89455 |
On Sunday, 5 March 2023 at 20:44:59 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Saturday, 4 March 2023 at 22:55:37 UTC, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>
> >> > On Friday, 3 March 2023 at 21:45:09 UTC, Ben Bacarisse wrote:
> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >>
> >> >> > On Wednesday, 1 March 2023 at 21:13:59 UTC, Ben Bacarisse wrote:
> >> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >> >>
> >> >> >> > On Wednesday, 1 March 2023 at 19:56:23 UTC, Ben Bacarisse wrote:
> >> >> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> >> >> >>
> >> >> >> >> > On Wednesday, 1 March 2023 at 09:38:08 UTC, Mut...@dastardlyhq.com wrote:
> >> >> >> >> >> On Tue, 28 Feb 2023 18:34:10 +0100
> >> >> >> >> >> David Brown <david...@hesbynett.no> wrote:
> >> >> >> >> >> >On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
> >> >> >> >> >> >> A function can follow specifications to the letter and still have hidden
> >> >> >> >> >> >> bugs.
> >> >> >> >> >> >
> >> >> >> >> >> >The /specification/ can have bugs or be inappropriate in some way. The
> >> >> >> >> >> >/hardware/ can have bugs. But if a piece of code gives the specified
> >> >> >> >> >> >output and effects for the specified inputs, then it is correct and
> >> >> >> >> >> >bug-free.
> >> >> >> >> >> Really?
> >> >> >> >> >>
> >> >> >> >> >> Spec: function always returns 10
> >> >> >> >> >>
> >> >> >> >> >> int func()
> >> >> >> >> >> {
> >> >> >> >> >> char *ptr = 0;
> >> >> >> >> >> for(int i=0;i < 100000;++i) ptr[i] = 0;
> >> >> >> >> >> return 10;
> >> >> >> >> >> }
> >> >> >> >> >>
> >> >> >> >> >> Bug free?
> >> >> >> >> >>
> >> >> >> >> > A better example would be
> >> >> >> >> >
> >> >> >> >> > int func()
> >> >> >> >> > {
> >> >> >> >> > char *ptr = malloc(1);
> >> >> >> >> > return 10;
> >> >> >> >> > }
> >> >> >> >> >
> >> >> >> >> > This function will always return 10, so it's to specification. But
> >> >> >> >> > it's the source of a bug.
> >> >> >> >> This is a better example (because it has defined behaviour), but does
> >> >> >> >> the function meet the specification? I would say that, speaking
> >> >> >> >> informally, specifications are taken to be minimal. Would
> >> >> >> >>
> >> >> >> >> int func() { getchar(); return 10; }
> >> >> >> >>
> >> >> >> >> meet the specification as well?
> >> >> >> >>
> >> >> >> > This is where you get trapped by C's misuse of the term "function".
> >> >> >> > If the term "function" were used in the proper mathematical sense,
> >> >> >> > then the program's memory would be in one state on function entry and
> >> >> >> > another on function return, and so you can't have a function without a
> >> >> >> > specification.
> >> >> >> No, that's not the issue. Of course it would help if functions were
> >> >> >> functions, but the terminology is not the issue here. A sin function
> >> >> >> (in some unimpeachable language like Haskell) that did all sorts of
> >> >> >> other computations and took an hour, or used half the available memory,
> >> >> >> would not meet the specification because, in my book, the specification
> >> >> >> should be taken to be minimal.
> >> >> >> > But C "functions" can perform actions. Specifying correct actions is a whole
> >> >> >> > different ball game to specifying functions, which are just mappings from
> >> >> >> > one set to another.
> >> >> >> So lets' call them all "procedures" for the moment and get back to the
> >> >> >> question at hand. Should a specification be taken to be essentially
> >> >> >> minimal? I would say so.
> >> >> >>
> >> >> > If functions are functions then the bits on function entry define the
> >> >> > state of the bits on function exit, and if they match, the function is
> >> >> > correct.
> >> >> I think the first "functions" refers to C function but second does not
> >> >> refer to either mathematical functions nor, say, functions in Haskell so
> >> >> I think you are talking about what I once referred to as
> >> >> Malcolm-functions. Unfortunately I don't remember enough about what you
> >> >> mean by the term to do anything but agree with the consequent.
> >> >>
> >> > A Malcolm function is that subset of mathematical functions which can
> >> > be implemented by programming languages. A mathematical function is a
> >> > mapping from an input set to an output set such that for every member
> >> > of the input set there is one and only member of the output set. Since
> >> > Malcolm functions are programming entities, the input set has to
> >> > ultimately be bits, and the output set also ultimately has to be
> >> > bits. So bits on function entry determines bits on function
> >> > exit. Unlike "pure functions" there are no special syntactical or data
> >> > hiding requirement on Malcolm functions. To all intents and purposes,
> >> > the term is identical in meaning to the term "function", used in the
> >> > accepted sense in a computer context, not in the C sense to mean
> >> > "subroutine".
> >> I don't know what bits are involved. You can't mean just the bits in
> >> the parameter and return values or
> >> int func() { getchar(); return 10; }
> >> would be a Malcolm function, and you can't mean all the bits in the
> >> entire (virtual) system or the specification for such a function would
> >> be ridiculous.
> >>
> > A mathematical function doesn't cease to be a mathematical function
> > because its specification is ridiculous.
> Of course. And the same would be true of non-mathematical functions as
> well. I'm trying to find out how your functions are specified. How is
> the Malcolm function that "just returns 10" specified?
>
It's embedded in the code somewhere. So for each possible (legal) state
of the bit store on code entry there is one and one only state of the bit
store on code exit, and the code does not cause any actions over than
moving bits in the memory to be taken. So it's code that calculates a function,
or a "Malcolm function".
Of course you'd specify it as "returns 10". It's not particularly helpful to think
in terms of the whole bit store. It's only helpful if you want to draw a distinction
between code which calculates functions and code which performs actions,
and someone is a bit shaky on what a function is.
> > If each possible bit state on code entry maps to one and only one
> > possible bit state on code exit, and the code doesn't do anything
> > else, like turn LEDs on or off, then the code is a "function" or if
> > you prefer, a "Malcolm function".
> So
>
> int f(int x) { extern int inc; return x + inc++; }
>
> is a Malcolm function, yes?
>
Exactly. With this one, we do have to a bit more careful. The bits that represent
inc are incremented, whilst a value based on that number and the argument goes
into the return value. Again, we can in principle specify it by brute force, by
enumerating every possible state of the bit store on code entry and code exit.
Which tells us that it is a "function", or if you want to be pedantic about it, "code
which calculates a function".
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-03-06 00:51 +0000 |
| Message-ID | <877cvun1lj.fsf@bsb.me.uk> |
| In reply to | #89461 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Sunday, 5 March 2023 at 20:44:59 UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Saturday, 4 March 2023 at 22:55:37 UTC, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
<cut>
>> >> > A Malcolm function is that subset of mathematical functions which can
>> >> > be implemented by programming languages. A mathematical function is a
>> >> > mapping from an input set to an output set such that for every member
>> >> > of the input set there is one and only member of the output set. Since
>> >> > Malcolm functions are programming entities, the input set has to
>> >> > ultimately be bits, and the output set also ultimately has to be
>> >> > bits. So bits on function entry determines bits on function
>> >> > exit. Unlike "pure functions" there are no special syntactical or data
>> >> > hiding requirement on Malcolm functions. To all intents and purposes,
>> >> > the term is identical in meaning to the term "function", used in the
>> >> > accepted sense in a computer context, not in the C sense to mean
>> >> > "subroutine".
>> >>
>> >> I don't know what bits are involved. You can't mean just the bits in
>> >> the parameter and return values or
>> >> int func() { getchar(); return 10; }
>> >> would be a Malcolm function, and you can't mean all the bits in the
>> >> entire (virtual) system or the specification for such a function would
>> >> be ridiculous.
>> >>
>> > A mathematical function doesn't cease to be a mathematical function
>> > because its specification is ridiculous.
>>
>> Of course. And the same would be true of non-mathematical functions as
>> well. I'm trying to find out how your functions are specified. How is
>> the Malcolm function that "just returns 10" specified?
>>
> It's embedded in the code somewhere.
Eh? The specification is in the code but you can't say where?
> So for each possible (legal) state of the bit store on code entry
> there is one and one only state of the bit store on code exit, and the
> code does not cause any actions over than moving bits in the memory to
> be taken. So it's code that calculates a function,
-- of the entire system's memory --
> or a "Malcolm function".
which is why the term is needed because in CS, "function" is used to
mean all sorts things. It's not a precisely defined term without
context.
> Of course you'd specify it as "returns 10". It's not particularly
> helpful to think in terms of the whole bit store.
Which makes me wonder why you brought up this very specific definition
of "function". As I said originally, I think what we call a function is
beside the point as the specification should be take to be, loosely
speaking, minimal. The code
int f(void) {
extern unsigned long long r;
while (r != 10) r++;
return r;
}
does not meet the specification because it does too much. How you
classify it (it's a Malcolm function) is really beside the point. The
specification in terms of the bit-state on entry and exit is simply too
complex to ever use.
> It's only helpful if
> you want to draw a distinction between code which calculates functions
> and code which performs actions, and someone is a bit shaky on what a
> function is.
If you include the virtual IO state then even
putchar('a');
is an "extended Malcolm function". It's common (or it was) to model the
meaning of code by functions that operate on such a global state which
is why I did not find your reference to functions as the term is usually
used in CS to be particularly helpful.
You choose not to include all the state but only the bits that make up
the process memory. (All this assumes a simple abstract machine -- real
systems with memory-mapped IO would complicate matters.)
>> > If each possible bit state on code entry maps to one and only one
>> > possible bit state on code exit, and the code doesn't do anything
>> > else, like turn LEDs on or off, then the code is a "function" or if
>> > you prefer, a "Malcolm function".
>> So
>>
>> int f(int x) { extern int inc; return x + inc++; }
>>
>> is a Malcolm function, yes?
>>
> Exactly.
So the function that called malloc (and therefore altered some global
state as well as returning 10) was also a Malcolm function? You choose
to draw the line at altering the IO state.
> With this one, we do have to a bit more careful. The bits that
> represent inc are incremented, whilst a value based on that number and
> the argument goes into the return value. Again, we can in principle
> specify it by brute force, by enumerating every possible state of the
> bit store on code entry and code exit.
This view only allows one to say what is and what is not a Malcolm
function. It's not of any use when specifying what some code should do.
> Which tells us that it is a
> "function", or if you want to be pedantic about it, "code which
> calculates a function".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-03-06 02:17 -0800 |
| Message-ID | <84566fcb-27ae-4242-b78c-978ecdd3d4fdn@googlegroups.com> |
| In reply to | #89466 |
On Monday, 6 March 2023 at 00:52:11 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> >> Of course. And the same would be true of non-mathematical functions as
> >> well. I'm trying to find out how your functions are specified. How is
> >> the Malcolm function that "just returns 10" specified?
> >>
> > It's embedded in the code somewhere.
> Eh? The specification is in the code but you can't say where?
>
We've got this code.
int main(void)
{
int a = 1;
int b = 2;
int c = 3;
printf("a %d, b %d, c %d\n", a, b, c):
b = return10();
printf("a %d, b %d, c %d\n", a, b, c):
c = return10();
printf("a %d, b %d, c %d\n", a, b, c):
return 0;
}
The program has three integers of state. Between the calls to printf,
that state is changing, but that is all that is happening. However the two
calls make a different change to the state. They're actually two different
functions. The first one maps a = 1, b = 2, c = 3 to a =1, b = 10, c = 3.
The second one maps a = 1, b = 10, c = 3 to a = 1, b = 10 c = 10.
However you don't need to worry about this. It's just a technicality because of
the way "functions" are defined.
>
> > So for each possible (legal) state of the bit store on code entry
> > there is one and one only state of the bit store on code exit, and the
> > code does not cause any actions over than moving bits in the memory to
> > be taken. So it's code that calculates a function,
> -- of the entire system's memory --
> > or a "Malcolm function".
> which is why the term is needed because in CS, "function" is used to
> mean all sorts things. It's not a precisely defined term without
> context.
> > Of course you'd specify it as "returns 10". It's not particularly
> > helpful to think in terms of the whole bit store.
> Which makes me wonder why you brought up this very specific definition
> of "function". As I said originally, I think what we call a function is
> beside the point as the specification should be take to be, loosely
> speaking, minimal. The code
>
> int f(void) {
> extern unsigned long long r;
> while (r != 10) r++;
> return r;
> }
>
> does not meet the specification because it does too much. How you
> classify it (it's a Malcolm function) is really beside the point. The
> specification in terms of the bit-state on entry and exit is simply too
> complex to ever use.
>
A Malcolm function can be perversely written. Or it can be a naively
witten to use, for example, an exponential time algorithm which is obvious
when there's a much faster algorithm which is less obvious avialable.
However it may not do perverse IO.
The code is not a pure function. In reality, it may be a "delaying loop", in
which case it isn't really a Malcolm function (sadly), because its required
behaviour is not defined in terms of bit state on entry and bit state on exit.
>
> > It's only helpful if
> > you want to draw a distinction between code which calculates functions
> > and code which performs actions, and someone is a bit shaky on what a
> > function is.
> If you include the virtual IO state then even
>
> putchar('a');
>
> is an "extended Malcolm function". It's common (or it was) to model the
> meaning of code by functions that operate on such a global state which
> is why I did not find your reference to functions as the term is usually
> used in CS to be particularly helpful.
>
Yes, if "putchar" is is somehow writing to a memory buffer which is human-
inspectable, then "putchar" would becoame a "Maclom function". That would
be the main point in setting up such a system. The designers wouldn't use the
term "Macom function", but they want the benefits of all the code being
a Malcolm function (so no failure points, for example).
>
> You choose not to include all the state but only the bits that make up
> the process memory. (All this assumes a simple abstract machine -- real
> systems with memory-mapped IO would complicate matters.)
>
> So the function that called malloc (and therefore altered some global
> state as well as returning 10) was also a Malcolm function? You choose
> to draw the line at altering the IO state.
>
Yes. Of course you can invent a machine in which tin cans are manufactured
on the fly to meet the demands of malloc(), in which case there would be no
practical benefit to regarding memory allocation as different to IO. Reality
is that many languages don't have explicit calls to malloc() - it's just assumed
that the call will succeed and the program fails if it doesn't. But the real reason
is that Malcolm functions without malloc() would be crippled. As it is, there are
no examples of mathematical functions of bits that cannot be implememented
as Malcolm functions (there's a quote for our friend on comp.theory to attack,
and there's an obvious exception), and there are no Malcolm functions which do
anything other than calculate mathematical functions of bits. Ban malloc()
and, OK, you can sometimes finesse it through recursion, but that becomes
untrue.
> > With this one, we do have to a bit more careful. The bits that
> > represent inc are incremented, whilst a value based on that number and
> > the argument goes into the return value. Again, we can in principle
> > specify it by brute force, by enumerating every possible state of the
> > bit store on code entry and code exit.
> This view only allows one to say what is and what is not a Malcolm
> function. It's not of any use when specifying what some code should do.
>
It's very useful when specifying what some code should or should not do.
If it's a Malcolm function, it may not perform IO. This has huge benefits. Of
course that's not a sufficient specification, and going to the mathematical
defintion of function directly isn't much use, except in the case of a function
with a tiny domain. Functions need to do something human-meaningful
if they are to be good programming functions. But then you exit the realm of
what can be defined.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-05 08:13 -0800 |
| Message-ID | <864jqz9nw9.fsf@linuxsc.com> |
| In reply to | #89418 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> A Malcolm function is that subset of mathematical functions which
> can be implemented by programming languages. A mathematical
> function is a mapping from an input set to an output set such that
> for every member of the input set there is one and only member of
> the output set. Since Malcolm functions are programming entities,
> the input set has to ultimately be bits, and the output set also
> ultimately has to be bits. So bits on function entry determines
> bits on function exit. Unlike "pure functions" there are no special
> syntactical or data hiding requirement on Malcolm functions. To all
> intents and purposes, the term is identical in meaning to the term
> "function", used in the accepted sense in a computer context, not in
> the C sense to mean "subroutine".
This posting is not a response but a request for clarification.
Is this function
int
contents_of( int *p ){
return *p;
}
one you would call a Malcolm function?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-03-05 09:05 -0800 |
| Message-ID | <362c528c-f9d6-4807-b349-984890ea0f54n@googlegroups.com> |
| In reply to | #89443 |
On Sunday, 5 March 2023 at 16:14:15 UTC, Tim Rentsch wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > A Malcolm function is that subset of mathematical functions which
> > can be implemented by programming languages. A mathematical
> > function is a mapping from an input set to an output set such that
> > for every member of the input set there is one and only member of
> > the output set. Since Malcolm functions are programming entities,
> > the input set has to ultimately be bits, and the output set also
> > ultimately has to be bits. So bits on function entry determines
> > bits on function exit. Unlike "pure functions" there are no special
> > syntactical or data hiding requirement on Malcolm functions. To all
> > intents and purposes, the term is identical in meaning to the term
> > "function", used in the accepted sense in a computer context, not in
> > the C sense to mean "subroutine".
> This posting is not a response but a request for clarification.
> Is this function
>
> int
> contents_of( int *p ){
> return *p;
> }
>
> one you would call a Malcolm function?
>
Yes. On code entry, bits are pointed to by p. On code exit, the return
value contains the same bits. It's not a very useful function, but it's
clearly a function, in the mathematical sense of computing a mapping
of one bit state to another bit state, and doing nothing else.
You can argue that, on many architectures, if we pass it null, it will
put a message on the error output stream, and terminate the program.
A function can't do that. So it's not a function. But the answer is that
invalid values of p are not in its domain, and it's still a function.
I don't use the term "Malcolm function". They just functions (of bits).
The confusion is because C uses the term to mean "subroutine", and other
languages sometimes use the term syntactically, to mean code with a return
values that can be uses as the right hand side of an assignment. But
people have got the idea that the concept is my invention, whilst it isn't.
It's very well established terminology.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 09:47 -0700 |
| Message-ID | <86sfe77002.fsf@linuxsc.com> |
| In reply to | #89367 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: [what does it mean for a function to "meet its specification"?] >> This is where you get trapped by C's misuse of the term "function". >> If the term "function" were used in the proper mathematical sense, >> then the program's memory would be in one state on function entry >> and another on function return, and so you can't have a function >> without a specification. > > No, that's not the issue. Of course it would help if functions > were functions, but the terminology is not the issue here. A sin > function (in some unimpeachable language like Haskell) that did > all sorts of other computations and took an hour, or used half the > available memory, would not meet the specification because, in my > book, the specification should be taken to be minimal. > >> But C "functions" can perform actions. Specifying correct actions >> is a whole different ball game to specifying functions, which are >> just mappings from one set to another. > > So lets' call them all "procedures" for the moment and get back to > the question at hand. Should a specification be taken to be > essentially minimal? I would say so. I don't exactly agree with this view. Certainly there are some kinds of behaviors (in the general sense of the word) that are implied and meant to be understood as part of what is required for how a function behaves (again in the general sense of the word), but not so much that the specification should be taken to be "essentially minimal". Consider for example the C library function qsort(), as specified in the ISO C standard. I'm sure most people expect that qsort() mustn't do "anything more" than sort the array, e.g., it must not change the state of an input file, or change an unrelated byte of memory, etc. But there are no requirements on "invisible" behaviors such as how fast the code runs or how much memory is taken. We might be disappointed if qsort() uses an O( N**3 ) algorithm, but that disappointment is not because the specification is not met. Also compare with the C++ standard. When there are runtime requirements of O(1) or O(N) or O(N log N), etc, the C++ standard states these bounds explicitly; they are not implied or tacitly assumed. By the way, qsort() is an interesting example because of expected memory usage. I think most people would not be surprised to learn that qsort() uses (in some implementations) O(log N) stack space. But this amount of memory is not necessary. There are, IIANM, sorting algorithms that are O(N log N) in runtime and O(1) in memory usage. Does a qsort() implementation that uses a standard quicksort algorithm violate the "essentially minimal" threshold? I think most people would agree that it meets the specification given in the C standard. I guess my stance on this is that the burden falls on whoever is responsible for writing the specification. Any needed conditions must be stated explicitly, somewhere, at least informally. We should never have to rely on the reader having the same set of builtin assumptions that the author has.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-01 14:40 -0800 |
| Message-ID | <87v8jkm6x5.fsf@nosuchdomain.example.com> |
| In reply to | #89366 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> This is where you get trapped by C's misuse of the term "function".
> If the term "function" were used in the proper mathematical sense,
> then the program's memory would be in one state on function entry and
> another on function return, and so you can't have a function without a
> specification.
> But C "functions" can perform actions. Specifying correct actions is a whole
> different ball game to specifying functions, which are just mappings from
> one set to another.
No, this is where *you* get trapped by not accepting that terms can have
different meanings in different fields.
C++ functions are not mathematical functions. They're subroutines that
may or may not return values, that may or may not have side effects, and
so on. And the concept is defined clearly and unambiguously by the
standard.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-02 09:07 +0000 |
| Message-ID | <ttpovr$8s93$1@dont-email.me> |
| In reply to | #89366 |
On Wed, 1 Mar 2023 12:53:22 -0800 (PST)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>On Wednesday, 1 March 2023 at 19:56:23 UTC, Ben Bacarisse wrote:
>> This is a better example (because it has defined behaviour), but does
>> the function meet the specification? I would say that, speaking
>> informally, specifications are taken to be minimal. Would
>>
>> int func() { getchar(); return 10; }
>>
>> meet the specification as well?
>>
>This is where you get trapped by C's misuse of the term "function".
Its not a misused, its perfectly valid in the programming sense.
>If the term "function" were used in the proper mathematical sense,
Programming optionally uses maths, bit its not maths.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-03-01 21:37 -0500 |
| Message-ID | <NZTLL.743715$t5W7.129179@fx13.iad> |
| In reply to | #89348 |
On 3/1/23 5:29 AM, Malcolm McLean wrote:
> On Wednesday, 1 March 2023 at 09:38:08 UTC, Mut...@dastardlyhq.com wrote:
>> On Tue, 28 Feb 2023 18:34:10 +0100
>> David Brown <david...@hesbynett.no> wrote:
>>> On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
>>>> A function can follow specifications to the letter and still have hidden
>>>> bugs.
>>>
>>> The /specification/ can have bugs or be inappropriate in some way. The
>>> /hardware/ can have bugs. But if a piece of code gives the specified
>>> output and effects for the specified inputs, then it is correct and
>>> bug-free.
>> Really?
>>
>> Spec: function always returns 10
>>
>> int func()
>> {
>> char *ptr = 0;
>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>> return 10;
>> }
>>
>> Bug free?
>>
> A better example would be
>
> int func()
> {
> char *ptr = malloc(1);
> return 10;
> }
>
> This function will always return 10, so it's to specification. But it's the source
> of a bug.
It meets the specifications only if there is not a reasonable set of
general groud rules that apply to all specification (unless specifically
noted).
For example, a typical ground rule is that all funcitions should free
(or otherwise correct release resources) or pass off control to another
entity all items that have had there control passed to them or they have
created.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-01 22:30 -0800 |
| Message-ID | <6993f92a-9fe0-4b60-b92a-7aae121d8b10n@googlegroups.com> |
| In reply to | #89373 |
On Thursday, 2 March 2023 at 04:37:50 UTC+2, Richard Damon wrote:
> On 3/1/23 5:29 AM, Malcolm McLean wrote:
> > On Wednesday, 1 March 2023 at 09:38:08 UTC, Mut...@dastardlyhq.com wrote:
> >> On Tue, 28 Feb 2023 18:34:10 +0100
> >> David Brown <david...@hesbynett.no> wrote:
> >>> On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
> >>>> A function can follow specifications to the letter and still have hidden
> >>>> bugs.
> >>>
> >>> The /specification/ can have bugs or be inappropriate in some way. The
> >>> /hardware/ can have bugs. But if a piece of code gives the specified
> >>> output and effects for the specified inputs, then it is correct and
> >>> bug-free.
> >> Really?
> >>
> >> Spec: function always returns 10
> >>
> >> int func()
> >> {
> >> char *ptr = 0;
> >> for(int i=0;i < 100000;++i) ptr[i] = 0;
> >> return 10;
> >> }
> >>
> >> Bug free?
> >>
> > A better example would be
> >
> > int func()
> > {
> > char *ptr = malloc(1);
> > return 10;
> > }
> >
> > This function will always return 10, so it's to specification. But it's the source
> > of a bug.
>
> It meets the specifications only if there is not a reasonable set of
> general groud rules that apply to all specification (unless specifically
> noted).
>
> For example, a typical ground rule is that all funcitions should free
> (or otherwise correct release resources) or pass off control to another
> entity all items that have had there control passed to them or they have
> created.
Still it is better example as it at least does not dereference nor do pointer
arithmetic with nullptr.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-01 14:27 +0100 |
| Message-ID | <ttnjsg$3v518$1@dont-email.me> |
| In reply to | #89346 |
On 01/03/2023 10:37, Muttley@dastardlyhq.com wrote:
> On Tue, 28 Feb 2023 18:34:10 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> On 28/02/2023 16:56, Muttley@dastardlyhq.com wrote:
>>> A function can follow specifications to the letter and still have hidden
>>> bugs.
>>
>> The /specification/ can have bugs or be inappropriate in some way. The
>> /hardware/ can have bugs. But if a piece of code gives the specified
>> output and effects for the specified inputs, then it is correct and
>> bug-free.
>
> Really?
>
> Spec: function always returns 10
>
> int func()
> {
> char *ptr = 0;
> for(int i=0;i < 100000;++i) ptr[i] = 0;
> return 10;
> }
>
> Bug free?
You are accessing other data that is not part of the specification.
That has to be considered part of the input - this function would have a
precondition that 100,000 int's from address 0 onwards must be writeable.
(It is a lot easier to write clear specifications for pure functions -
no access of any non-constant global data, and no side-effect, so that
the output depends solely on the input.)
>
>>> And no one should ever steal either so I don't need a lock on my doors,
>> right?
>>>
>>
>> You lock your front door, because that forms a boundary between areas of
>> trust. You don't lock your in-house doors because you trust those
>> inside the house.
>
> The function is the house in this metaphor, the rest of the program is outside.
Then no, you don't lock your front door because you put your controlled
boundaries in a sensible place. Putting them at every function is /not/
smart.
>
>> Oh, I agree that code cannot be better than the specifications. And I
>> agree that complicated code (or complicated specifications) make things
>> much more difficult. That's why you divide things up into parts - both
>> code and specifications - and handle them individually. That's why you
>
> Perfectly working parts can still fail with bugs when put together as Ariane 5
> and Mars Climate Orbiter discovered. Format testing requires a formal system
> test too, you can't ignore it if you want to do it properly.
>
Those were failures of the specifications at a higher level - the
individual parts were fine, but the higher level systems specified the
wrong subcomponents.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-01 10:48 -0800 |
| Message-ID | <87zg8wmho4.fsf@nosuchdomain.example.com> |
| In reply to | #89355 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/03/2023 10:37, Muttley@dastardlyhq.com wrote:
>> On Tue, 28 Feb 2023 18:34:10 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 28/02/2023 16:56, Muttley@dastardlyhq.com wrote:
>>>> A function can follow specifications to the letter and still have hidden
>>>> bugs.
>>>
>>> The /specification/ can have bugs or be inappropriate in some way. The
>>> /hardware/ can have bugs. But if a piece of code gives the specified
>>> output and effects for the specified inputs, then it is correct and
>>> bug-free.
>> Really?
>> Spec: function always returns 10
>> int func()
>> {
>> char *ptr = 0;
>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>> return 10;
>> }
>> Bug free?
>
> You are accessing other data that is not part of the
> specification. That has to be considered part of the input - this
> function would have a precondition that 100,000 int's from address 0
> onwards must be writeable.
ptr contains a null pointer, which may or may not be "address 0"
(depending on just what you mean by "address 0"). The code has
undefined behavior. Conceivably it could depend on the behavior of
the target system *and* of the compiler, but it's far more likely
that it's just a bug. And as far as the C standard is concerned,
there's no guarantee that the function will return 10.
(It has additional UB if int is 16 bits.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-02 10:29 +0100 |
| Message-ID | <ttpq9k$8tki$1@dont-email.me> |
| In reply to | #89362 |
On 01/03/2023 19:48, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 01/03/2023 10:37, Muttley@dastardlyhq.com wrote:
>>> On Tue, 28 Feb 2023 18:34:10 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 28/02/2023 16:56, Muttley@dastardlyhq.com wrote:
>>>>> A function can follow specifications to the letter and still have hidden
>>>>> bugs.
>>>>
>>>> The /specification/ can have bugs or be inappropriate in some way. The
>>>> /hardware/ can have bugs. But if a piece of code gives the specified
>>>> output and effects for the specified inputs, then it is correct and
>>>> bug-free.
>>> Really?
>>> Spec: function always returns 10
>>> int func()
>>> {
>>> char *ptr = 0;
>>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>>> return 10;
>>> }
>>> Bug free?
>>
>> You are accessing other data that is not part of the
>> specification. That has to be considered part of the input - this
>> function would have a precondition that 100,000 int's from address 0
>> onwards must be writeable.
>
> ptr contains a null pointer, which may or may not be "address 0"
> (depending on just what you mean by "address 0"). The code has
> undefined behavior. Conceivably it could depend on the behavior of
> the target system *and* of the compiler, but it's far more likely
> that it's just a bug. And as far as the C standard is concerned,
> there's no guarantee that the function will return 10.
>
> (It has additional UB if int is 16 bits.)
>
Sure. But it would not meet the specifications even if "ptr" were
initiated to point to a valid array of 100,000 int's (unless that array
were private to the function - in which case it would be correct, but
inefficient).
There's been a few posts here attempting to set "ground rules" for
specifications - things that have to be followed in addition to the
explicit function-specific specification. I think perhaps a good choice
for that, especially in the context of C and C++, would be to say that
any potential influence on observable behaviour of the program has to be
specified. Observable behaviour is, fundamentally, part of the output
of a function. For those familiar with gcc and clang function
attributes, you could say that functions must be "pure" by default - any
deviation from this, potentially affecting observable behaviour, needs
to be in the specifications.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-03-01 19:53 +0000 |
| Message-ID | <87fsaos0xr.fsf@bsb.me.uk> |
| In reply to | #89346 |
Muttley@dastardlyhq.com writes:
> On Tue, 28 Feb 2023 18:34:10 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>On 28/02/2023 16:56, Muttley@dastardlyhq.com wrote:
>>> A function can follow specifications to the letter and still have hidden
>>> bugs.
>>
>>The /specification/ can have bugs or be inappropriate in some way. The
>>/hardware/ can have bugs. But if a piece of code gives the specified
>>output and effects for the specified inputs, then it is correct and
>>bug-free.
>
> Really?
>
> Spec: function always returns 10
>
> int func()
> {
> char *ptr = 0;
> for(int i=0;i < 100000;++i) ptr[i] = 0;
> return 10;
> }
>
> Bug free?
No, the code does not meet it's specification. In fact, the code has
no defined behaviour at all.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-02 09:08 +0000 |
| Message-ID | <ttpp30$8sgv$1@dont-email.me> |
| In reply to | #89363 |
On Wed, 01 Mar 2023 19:53:36 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Muttley@dastardlyhq.com writes:
>
>> On Tue, 28 Feb 2023 18:34:10 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>>On 28/02/2023 16:56, Muttley@dastardlyhq.com wrote:
>>>> A function can follow specifications to the letter and still have hidden
>>>> bugs.
>>>
>>>The /specification/ can have bugs or be inappropriate in some way. The
>>>/hardware/ can have bugs. But if a piece of code gives the specified
>>>output and effects for the specified inputs, then it is correct and
>>>bug-free.
>>
>> Really?
>>
>> Spec: function always returns 10
>>
>> int func()
>> {
>> char *ptr = 0;
>> for(int i=0;i < 100000;++i) ptr[i] = 0;
>> return 10;
>> }
>>
>> Bug free?
>
>No, the code does not meet it's specification. In fact, the code has
>no defined behaviour at all.
The specifaction is it returns 10. It does that. You're assuming it will
always crash which isn't necessarily the case depending on what machine its
running on.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-03-02 01:32 -0800 |
| Message-ID | <82462aca-a72e-493e-9c51-a916ae487584n@googlegroups.com> |
| In reply to | #89376 |
On Thursday, 2 March 2023 at 09:09:02 UTC, Mut...@dastardlyhq.com wrote:
> On Wed, 01 Mar 2023 19:53:36 +0000
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >Mut...@dastardlyhq.com writes:
> >
> >> On Tue, 28 Feb 2023 18:34:10 +0100
> >> David Brown <david...@hesbynett.no> wrote:
> >>>On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
> >>>> A function can follow specifications to the letter and still have hidden
> >>>> bugs.
> >>>
> >>>The /specification/ can have bugs or be inappropriate in some way. The
> >>>/hardware/ can have bugs. But if a piece of code gives the specified
> >>>output and effects for the specified inputs, then it is correct and
> >>>bug-free.
> >>
> >> Really?
> >>
> >> Spec: function always returns 10
> >>
> >> int func()
> >> {
> >> char *ptr = 0;
> >> for(int i=0;i < 100000;++i) ptr[i] = 0;
> >> return 10;
> >> }
> >>
> >> Bug free?
> >
> >No, the code does not meet it's specification. In fact, the code has
> >no defined behaviour at all.
> The specifaction is it returns 10. It does that. You're assuming it will
> always crash which isn't necessarily the case depending on what machine its
> running on.
>
Not necessarily. It might crash or might not. Or it might even overwrite the
area of memory used to hold return values, and return a value other than 10.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-02 09:56 +0000 |
| Message-ID | <ttprsh$94sa$1@dont-email.me> |
| In reply to | #89378 |
On Thu, 2 Mar 2023 01:32:07 -0800 (PST)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>On Thursday, 2 March 2023 at 09:09:02 UTC, Mut...@dastardlyhq.com wrote:
>> On Wed, 01 Mar 2023 19:53:36 +0000
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> >Mut...@dastardlyhq.com writes:
>> >
>> >> On Tue, 28 Feb 2023 18:34:10 +0100
>> >> David Brown <david...@hesbynett.no> wrote:
>> >>>On 28/02/2023 16:56, Mut...@dastardlyhq.com wrote:
>> >>>> A function can follow specifications to the letter and still have
>hidden
>> >>>> bugs.
>> >>>
>> >>>The /specification/ can have bugs or be inappropriate in some way. The
>> >>>/hardware/ can have bugs. But if a piece of code gives the specified
>> >>>output and effects for the specified inputs, then it is correct and
>> >>>bug-free.
>> >>
>> >> Really?
>> >>
>> >> Spec: function always returns 10
>> >>
>> >> int func()
>> >> {
>> >> char *ptr = 0;
>> >> for(int i=0;i < 100000;++i) ptr[i] = 0;
>> >> return 10;
>> >> }
>> >>
>> >> Bug free?
>> >
>> >No, the code does not meet it's specification. In fact, the code has
>> >no defined behaviour at all.
>> The specifaction is it returns 10. It does that. You're assuming it will
>> always crash which isn't necessarily the case depending on what machine its
>> running on.
>>
>Not necessarily. It might crash or might not. Or it might even overwrite the
>area of memory used to hold return values, and return a value other than 10.
The return value will be a literal in the program text area and if it
changed that it would probably be changing the program code itself.
Regardless - the function returns 10 as per the spec. The spec doesn't mention
that it also shouldn't crash.
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web