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 203 — 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? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-21 08:15 -0800
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 10:34 +0000 |
| Message-ID | <tt7ff6$1rj3p$1@dont-email.me> |
| In reply to | #89221 |
On Thu, 23 Feb 2023 12:30:39 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: >23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas: >> On Thu, 23 Feb 2023 09:39:04 +0200 >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas: >>> >>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety >>>> means will the program crash or have hidden bugs, not whether a string gets > >>>> translated into uppercase properly or not which would be immediately >obvious. >>> >>> >>> >>> Because you asked: I have seen isdigit() crashing hard on negative >> >> Thats clearly a library bug. All bets are off when they exist. > >What makes you think so? The C standard clearly says in 7.4 (Character >handling <ctype.h>): > >"In all cases the argument is an int, the value of which shall be >representable as an unsigned char or shall equal the value of the macro >EOF. If the argument has any other value, the behavior is undefined." > >Undefined behavior may or may not involve a program crash. I would still consider a crash to be a bug. Undefined would just be returning rubbish. I can't even figure out HOW it would crash since all its doing is return (c >= '0' && c <= '9') unless there's some obscure way of doing that test even faster.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-02-23 13:20 +0200 |
| Message-ID | <tt7i6i$1rpb5$1@dont-email.me> |
| In reply to | #89222 |
23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas:
> On Thu, 23 Feb 2023 12:30:39 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> 23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas:
>>> On Thu, 23 Feb 2023 09:39:04 +0200
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas:
>>>>
>>>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety
>>>>> means will the program crash or have hidden bugs, not whether a string gets
>>
>>>>> translated into uppercase properly or not which would be immediately
>> obvious.
>>>>
>>>>
>>>>
>>>> Because you asked: I have seen isdigit() crashing hard on negative
>>>
>>> Thats clearly a library bug. All bets are off when they exist.
>>
>> What makes you think so? The C standard clearly says in 7.4 (Character
>> handling <ctype.h>):
>>
>> "In all cases the argument is an int, the value of which shall be
>> representable as an unsigned char or shall equal the value of the macro
>> EOF. If the argument has any other value, the behavior is undefined."
>>
>> Undefined behavior may or may not involve a program crash.
>
> I would still consider a crash to be a bug.
Sure, but the bug would be in your code.
> Undefined would just be returning
> rubbish. I can't even figure out HOW it would crash since all its doing is
>
> return (c >= '0' && c <= '9')
Nope, because it's not known at the compile time which characters should
be considered digits. It might do something like
if (c==(EOF)) {
return (EOF);
} else {
lock_current_locale();
int result = get_current_locale()->isdigit_map[c];
unlock_current_locale();
return result;
}
where isdigit_map is a 256-element array provided by the locale.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 16:00 +0000 |
| Message-ID | <tt82j1$1tivo$1@dont-email.me> |
| In reply to | #89224 |
On Thu, 23 Feb 2023 13:20:50 +0200 Paavo Helde <eesnimi@osa.pri.ee> wrote: >23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: >> On Thu, 23 Feb 2023 12:30:39 +0200 >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>> 23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas: >>>> On Thu, 23 Feb 2023 09:39:04 +0200 >>>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas: >>>>> >>>>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? >Safety >>>>>> means will the program crash or have hidden bugs, not whether a string >gets >>> >>>>>> translated into uppercase properly or not which would be immediately >>> obvious. >>>>> >>>>> >>>>> >>>>> Because you asked: I have seen isdigit() crashing hard on negative >>>> >>>> Thats clearly a library bug. All bets are off when they exist. >>> >>> What makes you think so? The C standard clearly says in 7.4 (Character >>> handling <ctype.h>): >>> >>> "In all cases the argument is an int, the value of which shall be >>> representable as an unsigned char or shall equal the value of the macro >>> EOF. If the argument has any other value, the behavior is undefined." >>> >>> Undefined behavior may or may not involve a program crash. >> >> I would still consider a crash to be a bug. > >Sure, but the bug would be in your code. Wrong. >> Undefined would just be returning >> rubbish. I can't even figure out HOW it would crash since all its doing is >> >> return (c >= '0' && c <= '9') > >Nope, because it's not known at the compile time which characters should >be considered digits. It might do something like Wow, talk about clutching at straws. Unlike letters the characters for digits don't change unless you're talking about something like ancient egyptian.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-02-23 18:24 +0200 |
| Message-ID | <tt83vh$1tk8v$1@dont-email.me> |
| In reply to | #89233 |
23.02.2023 18:00 Muttley@dastardlyhq.com kirjutas:
>
> Unlike letters the characters for digits don't change unless you're talking
> about something like ancient egyptian.
You are funny!
I was bored, so I coded a counter-example:
#include <locale.h>
#include <ctype.h>
#include <string>
#include <iostream>
int main() {
if (!setlocale(LC_ALL, "French_Canada.1252")) {
std::cerr << "Failed to set locale\n";
return EXIT_FAILURE;
}
std::string s = "a² + b² = c²";
bool result = isdigit(static_cast<unsigned char>(s[1]));
std::cout << "'" << s[1] << "' is " <<
(result? "a digit": "not a digit") << "\n";
}
Output:
'²' is a digit
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 16:28 +0000 |
| Message-ID | <tt846s$1to1l$1@dont-email.me> |
| In reply to | #89239 |
On Thu, 23 Feb 2023 18:24:17 +0200
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>23.02.2023 18:00 Muttley@dastardlyhq.com kirjutas:
>
>>
>> Unlike letters the characters for digits don't change unless you're talking
>> about something like ancient egyptian.
>
>You are funny!
>
>I was bored, so I coded a counter-example:
>
>#include <locale.h>
>#include <ctype.h>
>#include <string>
>#include <iostream>
>
>int main() {
> if (!setlocale(LC_ALL, "French_Canada.1252")) {
> std::cerr << "Failed to set locale\n";
> return EXIT_FAILURE;
> }
> std::string s = "a² + b² = c²";
> bool result = isdigit(static_cast<unsigned char>(s[1]));
> std::cout << "'" << s[1] << "' is " <<
> (result? "a digit": "not a digit") << "\n";
>}
>
>Output:
>
>'²' is a digit
No it isn't. I guess thats part of the undefined output then.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-02-23 19:01 +0200 |
| Message-ID | <tt865j$1tsqr$1@dont-email.me> |
| In reply to | #89240 |
23.02.2023 18:28 Muttley@dastardlyhq.com kirjutas:
> On Thu, 23 Feb 2023 18:24:17 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> 23.02.2023 18:00 Muttley@dastardlyhq.com kirjutas:
>>
>>>
>>> Unlike letters the characters for digits don't change unless you're talking
>>> about something like ancient egyptian.
>>
>> You are funny!
>>
>> I was bored, so I coded a counter-example:
>>
>> #include <locale.h>
>> #include <ctype.h>
>> #include <string>
>> #include <iostream>
>>
>> int main() {
>> if (!setlocale(LC_ALL, "French_Canada.1252")) {
>> std::cerr << "Failed to set locale\n";
>> return EXIT_FAILURE;
>> }
>> std::string s = "a² + b² = c²";
>> bool result = isdigit(static_cast<unsigned char>(s[1]));
>> std::cout << "'" << s[1] << "' is " <<
>> (result? "a digit": "not a digit") << "\n";
>> }
>>
>> Output:
>>
>> '²' is a digit
>
> No it isn't. I guess thats part of the undefined output then.
Unfortunately it is classified as a digit, and there is no UB here. This
example also shows why the functions like isdigit() are next to useless,
in addition of being slow.
I cannot even imagine a use case which would benefit from superscripts
classified as digits, especially if this happens only in some locales,
but not in others.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-23 11:57 -0500 |
| Message-ID | <tt85u0$1tj6h$3@dont-email.me> |
| In reply to | #89239 |
On 2/23/23 11:24, Paavo Helde wrote:
> 23.02.2023 18:00 Muttley@dastardlyhq.com kirjutas:
>
>> Unlike letters the characters for digits don't change unless you're
>> talking
>> about something like ancient egyptian.
>
> You are funny!
>
> I was bored, so I coded a counter-example:
>
> #include <locale.h>
> #include <ctype.h>
> #include <string>
> #include <iostream>
>
> int main() {
> if (!setlocale(LC_ALL, "French_Canada.1252")) {
> std::cerr << "Failed to set locale\n";
> return EXIT_FAILURE;
> }
> std::string s = "a² + b² = c²";
> bool result = isdigit(static_cast<unsigned char>(s[1]));
> std::cout << "'" << s[1] << "' is " <<
> (result? "a digit": "not a digit") << "\n";
> }
>
> Output:
>
> '²' is a digit
That's non-conforming.
"The isdigit function tests for any decimal-digit character (as defined
in 5.2.1)." (7.4.1.5).
"...
the 10 decimal digits
0 1 2 3 4 5 6 7 8 9" (5.2.1p3)
"digits" is italicized, an ISO convention indicating that this
constitutes the official definition of that term. '2' is on that list,
'²' is not, and that definition allows for only 10 digits.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-02-23 19:12 +0200 |
| Message-ID | <tt86p9$1tsqr$2@dont-email.me> |
| In reply to | #89246 |
23.02.2023 18:57 James Kuyper kirjutas: > On 2/23/23 11:24, Paavo Helde wrote: >> '²' is a digit > > That's non-conforming. > "The isdigit function tests for any decimal-digit character (as defined > in 5.2.1)." (7.4.1.5). > > > "... > the 10 decimal digits > 0 1 2 3 4 5 6 7 8 9" (5.2.1p3) > > "digits" is italicized, an ISO convention indicating that this > constitutes the official definition of that term. '2' is on that list, > '²' is not, and that definition allows for only 10 digits. > I stand corrected. Now I also found a footnote: "The only functions in 7.4 whose behavior is not affected by the current locale are isdigit and isxdigit". It's a pity Microsoft has not got the memo and isdigit() is thus still unusable.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-23 11:57 -0500 |
| Message-ID | <tt85t5$1tj6h$2@dont-email.me> |
| In reply to | #89224 |
On 2/23/23 06:20, Paavo Helde wrote: > 23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: ... >> Undefined would just be returning >> rubbish. I can't even figure out HOW it would crash since all its >> doing is >> >> return (c >= '0' && c <= '9') > > Nope, because it's not known at the compile time which characters > should be considered digits. It might do something like No, isdigit() and isxdigit() are special cases. They are not locale-dependent. Regardless of locale, which characters qualify is defined by cross-referencing section 5.2.1.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-02-23 12:20 -0500 |
| Message-ID | <pfNJL.1596317$GNG9.694989@fx18.iad> |
| In reply to | #89245 |
On 2/23/23 11:57 AM, James Kuyper wrote: > On 2/23/23 06:20, Paavo Helde wrote: >> 23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: > ... >>> Undefined would just be returning >>> rubbish. I can't even figure out HOW it would crash since all its >>> doing is >>> >>> return (c >= '0' && c <= '9') >> >> Nope, because it's not known at the compile time which characters >> should be considered digits. It might do something like > > No, isdigit() and isxdigit() are special cases. They are not > locale-dependent. Regardless of locale, which characters qualify is > defined by cross-referencing section 5.2.1. > > Which still allows for "extended characters" to be added. It just says that such an addition needs to hold for ALL locales. (Just makes it less likely)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-02-24 02:15 +0000 |
| Message-ID | <874jrbu7ul.fsf@bsb.me.uk> |
| In reply to | #89252 |
Richard Damon <Richard@Damon-Family.org> writes: > On 2/23/23 11:57 AM, James Kuyper wrote: >> On 2/23/23 06:20, Paavo Helde wrote: >>> 23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: >> ... >>>> Undefined would just be returning >>>> rubbish. I can't even figure out HOW it would crash since all its >>>> doing is >>>> >>>> return (c >= '0' && c <= '9') >>> >>> Nope, because it's not known at the compile time which characters >>> should be considered digits. It might do something like >> No, isdigit() and isxdigit() are special cases. They are not >> locale-dependent. Regardless of locale, which characters qualify is >> defined by cross-referencing section 5.2.1. >> > > Which still allows for "extended characters" to be added. It just says that > such an addition needs to hold for ALL locales. But 7.2 (<ctype.h>) p2 says: 2. The behavior of these functions is affected by the current locale. Those functions that have locale-specific aspects only when not in the "C" locale are noted below. and such aspects are documented for isupper (and others) but /not/ for isdigit. That a distinction is pointless unless isdigit is supposed to be an exception. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-02-24 15:24 -0800 |
| Message-ID | <86ttzaabpp.fsf@linuxsc.com> |
| In reply to | #89266 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 2/23/23 11:57 AM, James Kuyper wrote: >> >>> On 2/23/23 06:20, Paavo Helde wrote: >>> >>>> 23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: >>> >>> ... >>> >>>>> Undefined would just be returning >>>>> rubbish. I can't even figure out HOW it would crash since all its >>>>> doing is >>>>> >>>>> return (c >= '0' && c <= '9') >>>> >>>> Nope, because it's not known at the compile time which characters >>>> should be considered digits. It might do something like >>> >>> No, isdigit() and isxdigit() are special cases. They are not >>> locale-dependent. Regardless of locale, which characters qualify is >>> defined by cross-referencing section 5.2.1. >> >> Which still allows for "extended characters" to be added. It just >> says that such an addition needs to hold for ALL locales. > > But 7.2 (<ctype.h>) p2 says: > > 2. The behavior of these functions is affected by the current > locale. Those functions that have locale-specific aspects only when > not in the "C" locale are noted below. > > and such aspects are documented for isupper (and others) but /not/ for > isdigit. That a distinction is pointless unless isdigit is supposed to > be an exception. I think you may be misreading what is being said here (meaning in section 7.4 paragraph 2). The behavior of all <ctype.h> functions is (potentially) affected by the current locale. The functions that are noted are _only_ those functions whose locale-specific aspects occur in locales other than the "C" locale (but must not occur in the "C" locale). A function that does not have a note might still have locale-specific aspects, and in fact may have locale-specific aspects even for the "C" locale. For example, in section 7.4.1.4, there is no mention of the "C" locale, but the function iscntrl() tests for a locale-specific set of characters; thus iscntrl() may yield nonzero for control characters besides those mentioned in section 5.2.1 paragraph 3, even when called while the "C" locale is in effect. None of the above changes what isdigit() is allowed to do, which is specified as exactly the ten characters listed as decimal digits in section 5.2.1 paragraph 3.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-24 02:14 -0500 |
| Message-ID | <tt9o3v$24rgn$2@dont-email.me> |
| In reply to | #89252 |
On 2/23/23 12:20, Richard Damon wrote: > On 2/23/23 11:57 AM, James Kuyper wrote: >> On 2/23/23 06:20, Paavo Helde wrote: >>> 23.02.2023 12:34 Muttley@dastardlyhq.com kirjutas: >> ... >>>> Undefined would just be returning >>>> rubbish. I can't even figure out HOW it would crash since all its >>>> doing is >>>> >>>> return (c >= '0' && c <= '9') >>> >>> Nope, because it's not known at the compile time which characters >>> should be considered digits. It might do something like >> >> No, isdigit() and isxdigit() are special cases. They are not >> locale-dependent. Regardless of locale, which characters qualify is >> defined by cross-referencing section 5.2.1. Note: I forgot that I was posting this to comp.lang.c++. That's a citation from the C standard. It's the correct citation to make, because the C++ standard defines the behavior of isdigit() and isxdigit() solely by cross-referencing the C standard. However, I should have pointed out the fact that I was referring to the C standard. > Which still allows for "extended characters" to be added. It just says > that such an addition needs to hold for ALL locales. I'm not sure what you mean by "adding" extended characters. The definition of "digit" I referenced from 5.2.1 defines the term by listing exactly 10 characters, and identifying 10 as the number of things that qualify as digits. They are all members of the basic character set. Note that all of the following functions are described explicitly as returning true for a locale-specific set of characters: isalpha(), isblank(), islower(), ispunct(), isspace(), isupper() isalnum() is defined in terms of isalpha(), and is therefore locale-specific, but only insofar as isalpha() is locale-specific. iscntrl(), isgraph(), and isprint() are not directly described as locale-specific, but they cross-reference the definitions of control character and printing character in 7.4p3, which explicitly describe those as locale-specific sets. isdigit() and isxdigit() are the only ones to not be described, either indirectly or directly, as returning true for a locale-specific of characters. The other functions establish that such needs to be explicitly stated in order for it to be true. Finally, footnote 241, while not normative, clarifies that "The only functions in 7.4 whose behavior is not affected by the current locale are isdigit and isxdigit."
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-02-23 07:18 -0500 |
| Message-ID | <1QIJL.1263205$9sn9.1222858@fx17.iad> |
| In reply to | #89222 |
On 2/23/23 5:34 AM, Muttley@dastardlyhq.com wrote:
> On Thu, 23 Feb 2023 12:30:39 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> 23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas:
>>> On Thu, 23 Feb 2023 09:39:04 +0200
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas:
>>>>
>>>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety
>>>>> means will the program crash or have hidden bugs, not whether a string gets
>>
>>>>> translated into uppercase properly or not which would be immediately
>> obvious.
>>>>
>>>>
>>>>
>>>> Because you asked: I have seen isdigit() crashing hard on negative
>>>
>>> Thats clearly a library bug. All bets are off when they exist.
>>
>> What makes you think so? The C standard clearly says in 7.4 (Character
>> handling <ctype.h>):
>>
>> "In all cases the argument is an int, the value of which shall be
>> representable as an unsigned char or shall equal the value of the macro
>> EOF. If the argument has any other value, the behavior is undefined."
>>
>> Undefined behavior may or may not involve a program crash.
>
> I would still consider a crash to be a bug. Undefined would just be returning
> rubbish. I can't even figure out HOW it would crash since all its doing is
>
> return (c >= '0' && c <= '9')
>
> unless there's some obscure way of doing that test even faster.
>
The issue is that to support locales, things like isdigit might be
implemented as
int isdigit(int c) {
return _prop_table[c+1] & DIGIT_PROPERTY;
}
where _prop_table gets set to a table based on the current locale, which
might define additional characters that are digits.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 16:01 +0000 |
| Message-ID | <tt82jt$1tj23$1@dont-email.me> |
| In reply to | #89225 |
On Thu, 23 Feb 2023 07:18:05 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
>On 2/23/23 5:34 AM, Muttley@dastardlyhq.com wrote:
>> rubbish. I can't even figure out HOW it would crash since all its doing is
>>
>> return (c >= '0' && c <= '9')
>>
>> unless there's some obscure way of doing that test even faster.
>>
>
>The issue is that to support locales, things like isdigit might be
>implemented as
>
>int isdigit(int c) {
> return _prop_table[c+1] & DIGIT_PROPERTY;
>}
>
>where _prop_table gets set to a table based on the current locale, which
>might define additional characters that are digits.
Numbers don't have a locale FFS.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-02-23 11:50 -0500 |
| Message-ID | <3PMJL.102014$eRZ7.3601@fx06.iad> |
| In reply to | #89234 |
On 2/23/23 11:01 AM, Muttley@dastardlyhq.com wrote:
> On Thu, 23 Feb 2023 07:18:05 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>> On 2/23/23 5:34 AM, Muttley@dastardlyhq.com wrote:
>>> rubbish. I can't even figure out HOW it would crash since all its doing is
>>>
>>> return (c >= '0' && c <= '9')
>>>
>>> unless there's some obscure way of doing that test even faster.
>>>
>>
>> The issue is that to support locales, things like isdigit might be
>> implemented as
>>
>> int isdigit(int c) {
>> return _prop_table[c+1] & DIGIT_PROPERTY;
>> }
>>
>> where _prop_table gets set to a table based on the current locale, which
>> might define additional characters that are digits.
>
> Numbers don't have a locale FFS.
>
Nope, isdigit refers to 5.2.1 which states:
Each set is further divided into a basic character set, whose contents
are given by this subclause, and a set of zero or more locale-specific
members (which are not members of the basic character set) called
extended characters.
Thus EACH category later defined (including digits) may have
locale-specific members added.
A Nummber of languages do add there own characters for the digits,
besides the basic arabic numerals included in the standard character set.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-23 14:41 -0800 |
| Message-ID | <871qmgovh3.fsf@nosuchdomain.example.com> |
| In reply to | #89243 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 2/23/23 11:01 AM, Muttley@dastardlyhq.com wrote:
>> On Thu, 23 Feb 2023 07:18:05 -0500
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>> On 2/23/23 5:34 AM, Muttley@dastardlyhq.com wrote:
>>>> rubbish. I can't even figure out HOW it would crash since all its doing is
>>>>
>>>> return (c >= '0' && c <= '9')
>>>>
>>>> unless there's some obscure way of doing that test even faster.
>>>>
>>>
>>> The issue is that to support locales, things like isdigit might be
>>> implemented as
>>>
>>> int isdigit(int c) {
>>> return _prop_table[c+1] & DIGIT_PROPERTY;
>>> }
>>>
>>> where _prop_table gets set to a table based on the current locale, which
>>> might define additional characters that are digits.
>> Numbers don't have a locale FFS.
>>
>
> Nope, isdigit refers to 5.2.1 which states:
>
> Each set is further divided into a basic character set, whose contents
> are given by this subclause, and a set of zero or more locale-specific
> members (which are not members of the basic character set) called
> extended characters.
>
> Thus EACH category later defined (including digits) may have
> locale-specific members added.
>
> A Nummber of languages do add there own characters for the digits,
> besides the basic arabic numerals included in the standard character
> set.
5.2.1 (I'm using the n1570 C standard draft) does not say that
characters outside the basic character set can be digits. In
enumerating the characters that are included in the basic source and
execution character sets, it says:
the 10 decimal *digits*
0 1 2 3 4 5 6 7 8 9
The word "digits" is in italics, so this is the definition of the word.
If I'm reading it correctly, a character like '²' (superscript two)
might be in the extended character set, but it cannot be a "digit" in
the meaning used in the standard.
Similarly:
A *letter* is an uppercase letter or a lowercase letter as defined
above; in this International Standard the term does not include
other characters that are letters in other alphabets.
where the "above" includes a list of the 26 uppercase and 26 lowercase
Latin letters.
The isupper and islower functions can return a true result either for a
*letter* or for other locale-specific characters. isdigit() is not
locale-specific; it tests only for "any decimal-digit character (as
defined in 5.2.1)".
--
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-02-23 19:44 +0100 |
| Message-ID | <tt8c65$1uj2f$1@dont-email.me> |
| In reply to | #89234 |
On 23/02/2023 17:01, Muttley@dastardlyhq.com wrote:
> On Thu, 23 Feb 2023 07:18:05 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>> On 2/23/23 5:34 AM, Muttley@dastardlyhq.com wrote:
>>> rubbish. I can't even figure out HOW it would crash since all its doing is
>>>
>>> return (c >= '0' && c <= '9')
>>>
>>> unless there's some obscure way of doing that test even faster.
>>>
>>
>> The issue is that to support locales, things like isdigit might be
>> implemented as
>>
>> int isdigit(int c) {
>> return _prop_table[c+1] & DIGIT_PROPERTY;
>> }
>>
>> where _prop_table gets set to a table based on the current locale, which
>> might define additional characters that are digits.
>
> Numbers don't have a locale FFS.
>
That doesn't matter - it could still be implemented using such tables.
It's just that the "DIGIT_PROPERTY" bit would be the same for all locale
_prop_table tables, while bits such as for "ALPHA_PROPERTY" and
"ISUPPER_PROPERTY" might vary between locales.
On modern processors, the comparison to '0' and '9' is probably the most
efficient implementation - and . On older ones, table lookup could be
more efficient. But a table-based implementation is certainly common:
<https://elixir.bootlin.com/glibc/latest/source/ctype/ctype.h>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-02-23 15:02 +0100 |
| Message-ID | <tt7rmh$1soci$1@dont-email.me> |
| In reply to | #89222 |
On 23/02/2023 11:34, Muttley@dastardlyhq.com wrote: > On Thu, 23 Feb 2023 12:30:39 +0200 > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> 23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas: >>> On Thu, 23 Feb 2023 09:39:04 +0200 >>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas: >>>> >>>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety >>>>> means will the program crash or have hidden bugs, not whether a string gets >> >>>>> translated into uppercase properly or not which would be immediately >> obvious. >>>> >>>> >>>> >>>> Because you asked: I have seen isdigit() crashing hard on negative >>> >>> Thats clearly a library bug. All bets are off when they exist. >> >> What makes you think so? The C standard clearly says in 7.4 (Character >> handling <ctype.h>): >> >> "In all cases the argument is an int, the value of which shall be >> representable as an unsigned char or shall equal the value of the macro >> EOF. If the argument has any other value, the behavior is undefined." >> >> Undefined behavior may or may not involve a program crash. > > I would still consider a crash to be a bug. Undefined would just be returning > rubbish. Undefined behaviour means there is no define behaviour - crashing is entirely plausible. It doesn't matter what /you/ think about it. The C standard is quite clear about this - if you pass a valid argument to isdigit(), as specified in the standard, you'll get a valid result. If you pass something invalid, all bets are off and whatever happens is /your/ problem. This is so fundamental to the whole concept of programming that I am regularly surprised by people who call themselves programmers, yet fail to comprehend it. A function has a specified input domain, and a specified result or behaviour for inputs in that domain. Move outside that input domain, and you are in the realm of nonsense. You don't expect particular behaviour from 1/0 - maybe you'll get a random value, maybe you'll get a crash. Why you think calling isdigit() with an invalid input should have some guarantees is beyond me. "Garbage in, garbage out" applies to behaviour, not just values, and has been understood since Babbage designed the first programmable mechanical computer. So yes, there is a bug - it's in /your/ code if you pass an invalid value to the function. > I can't even figure out HOW it would crash since all its doing is > > return (c >= '0' && c <= '9') > > unless there's some obscure way of doing that test even faster. > There are other ways that can be faster (depending on details of processor, cache uses, and other aspects). The traditional implementation of the <ctype.h> classification functions involves lookup tables, and it is quite reasonable for a negative value to lead to things going horribly wrong.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-02-23 14:49 +0000 |
| Message-ID | <87k008tp1t.fsf@bsb.me.uk> |
| In reply to | #89226 |
David Brown <david.brown@hesbynett.no> writes: > On 23/02/2023 11:34, Muttley@dastardlyhq.com wrote: >> On Thu, 23 Feb 2023 12:30:39 +0200 >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>> 23.02.2023 11:35 Muttley@dastardlyhq.com kirjutas: >>>> On Thu, 23 Feb 2023 09:39:04 +0200 >>>> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>>>> 22.02.2023 11:25 Muttley@dastardlyhq.com kirjutas: >>>>> >>>>>> Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety >>>>>> means will the program crash or have hidden bugs, not whether a string gets >>> >>>>>> translated into uppercase properly or not which would be immediately >>> obvious. >>>>> >>>>> >>>>> >>>>> Because you asked: I have seen isdigit() crashing hard on negative >>>> >>>> Thats clearly a library bug. All bets are off when they exist. >>> >>> What makes you think so? The C standard clearly says in 7.4 (Character >>> handling <ctype.h>): >>> >>> "In all cases the argument is an int, the value of which shall be >>> representable as an unsigned char or shall equal the value of the macro >>> EOF. If the argument has any other value, the behavior is undefined." >>> >>> Undefined behavior may or may not involve a program crash. >> I would still consider a crash to be a bug. Undefined would just be >> returning >> rubbish. > > Undefined behaviour means there is no define behaviour - crashing is > entirely plausible. It doesn't matter what /you/ think about it. The C > standard is quite clear about this - if you pass a valid argument to > isdigit(), as specified in the standard, you'll get a valid result. If > you pass something invalid, all bets are off and whatever happens is /your/ > problem. > > This is so fundamental to the whole concept of programming that I am > regularly surprised by people who call themselves programmers, yet fail > to comprehend it. A function has a specified input domain, and a specified > result or behaviour for inputs in that domain. Move outside that input > domain, and you are in the realm of nonsense. This is formally true, but I think we can also legitimately ask to what extent a function's domain (and the corresponding returned values) are reasonable and helpful. > You don't expect particular > behaviour from 1/0 - maybe you'll get a random value, maybe you'll get a > crash. Why you think calling isdigit() with an invalid input should have > some guarantees is beyond me. "Garbage in, garbage out" applies to > behaviour, not just values, and has been understood since Babbage designed > the first programmable mechanical computer. Those of us with a background in languages like C are not going to be confused, but I bet almost everyone who comes to C from a more modern language will be astonished by what you have to do to get isdigit to work safely. To have a character testing function that does not work for all the values of the language's char type is, well, bonkers. In Haskell, a program won't even compile unless isDigit is called with an argument of type Char, and the result is defined to be exactly one of True or False for all values of that type. And that brings up another trap for the unwary: C's isdigit returns something that is only vaguely Boolean. For example, you can't test if char c1, c2; are both digits or neither are digits with isdigit(c1) == isdigit(c2) because the value indicating "yes" is not guaranteed to be anything other than "not zero". Instead you'd write !isdigit((unsigned char)c1) == !isdigit((unsigned char)c2) I think an occasional nod to how we have got used to such nonsense is merited! -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web