Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69548 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-04 20:48 +0100 |
| Last post | 2020-02-26 02:22 +0000 |
| Articles | 20 on this page of 219 — 25 participants |
Back to article view | Back to comp.lang.c++
two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 20:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 21:19 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 14:39 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:31 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 11:23 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 15:43 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 16:58 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-05 21:45 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 13:33 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 13:51 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 14:37 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 15:38 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 15:53 +0100
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 10:06 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-06 17:00 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 17:47 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 17:54 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-06 20:00 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:13 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:44 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:36 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 22:54 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-07 00:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 17:54 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 18:15 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:33 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 10:55 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:15 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 20:53 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:25 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 23:05 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-07 10:23 +0200
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 22:20 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:12 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:24 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 07:14 -0700
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 11:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-10 16:31 +0200
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 19:02 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 12:08 +0200
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-11 13:59 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 17:09 +0200
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2019-11-18 07:40 -0500
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:27 -0800
Re: two's complement idea cdalten@gmail.com - 2020-01-24 05:39 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 17:53 +0200
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:31 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 21:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 07:08 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 09:30 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 09:57 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 09:02 -0800
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-05 17:15 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 10:19 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-05 19:31 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 11:55 -0800
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-05 22:48 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 15:49 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:13 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:00 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 05:26 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 21:50 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 02:01 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-08 14:03 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 12:08 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 13:17 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-10 14:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 17:08 +0100
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:34 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-11 07:48 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 21:31 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-04 23:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:32 +0100
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-04 19:55 -0700
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-05 05:52 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-05 18:17 +1300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 05:55 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 06:33 -0700
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 07:46 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 06:46 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:03 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 06:56 +0100
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2019-11-05 08:24 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 08:35 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 23:36 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 09:19 -0500
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:32 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-22 09:23 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 14:20 +0100
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 13:37 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:17 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-27 12:35 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:56 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-16 09:17 +0100
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2020-02-21 19:35 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-22 07:01 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 08:22 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-24 03:12 +0000
Re: two's complement idea cdalten@gmail.com - 2020-02-24 05:53 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 07:56 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-25 22:00 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 16:14 -0800
Re: two's complement idea cdalten@gmail.com - 2020-02-25 18:18 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-26 02:22 +0000
Page 1 of 11 [1] 2 3 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-04 20:48 +0100 |
| Subject | two's complement idea |
| Message-ID | <qppva0$cbj$1@news.albasani.net> |
What would realls speak against that numieric_limits<type> would include a flag whether a type has a two's complement and maybe another flag that says that a type has a two's complement wrap-around?
[toc] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-04 21:19 +0100 |
| Message-ID | <qpq152$88v$1@news.albasani.net> |
| In reply to | #69548 |
> What would realls speak against that numieric_limits<type> would include > a flag whether a type has a two's complement and maybe another flag that > says that a type has a two's complement wrap-around? And a further flag that says that signed shifts have the usual behaviour as on most platforms?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-04 14:39 -0800 |
| Message-ID | <fb41f203-289c-40f5-b667-3866bcf4d351@googlegroups.com> |
| In reply to | #69549 |
On Monday, 4 November 2019 22:19:56 UTC+2, Bonita Montero wrote: > > What would realls speak against that numieric_limits<type> would include > > a flag whether a type has a two's complement and maybe another flag that You yourself started a thread discussing proposal paper p0907r0 at end of July "In the end, rason will come" that would make it redundant. > > says that a type has a two's complement wrap-around? The numeric_limits<type>::is_modulo is already there. Unfortunately no compiler sets it to signed types (even with -fwrapv flag). > And a further flag that says that signed shifts have the usual behaviour > as on most platforms? Language lawyers at isocpp.org seem quite uncertain what they want: <https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/MZzCyAL1qRo/p493_UdUAgAJ>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-05 10:31 +0100 |
| Message-ID | <qprfhd$2r5$1@dont-email.me> |
| In reply to | #69553 |
On 04/11/2019 23:39, Öö Tiib wrote: > On Monday, 4 November 2019 22:19:56 UTC+2, Bonita Montero wrote: >>> What would realls speak against that numieric_limits<type> would include >>> a flag whether a type has a two's complement and maybe another flag that > > You yourself started a thread discussing proposal paper p0907r0 > at end of July "In the end, rason will come" that would make it redundant. > >>> says that a type has a two's complement wrap-around? > > The numeric_limits<type>::is_modulo is already there. Unfortunately > no compiler sets it to signed types (even with -fwrapv flag). > >> And a further flag that says that signed shifts have the usual behaviour >> as on most platforms? > > Language lawyers at isocpp.org seem quite uncertain what they want: > <https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/MZzCyAL1qRo/p493_UdUAgAJ> > I think there are a few points that can be taken from the discussions on this topic in various places. 1. Two's complement representation, with no padding bits, should be standardised. There simply is no need for anything else in the C++ world - there are no implementations of C++ with any other representation, and no likelihood of them being used in the future. Picking the one fixed representation simplifies a few things in the standard. 2. Some people get very worked up about signed integer overflow behaviour. There are also several widely believed, but incorrect, myths about it - such as ideas that it used to be defined behaviour, or that it always wraps on x86 systems, or that defining wrapping behaviour is always a good idea, or that the undefined nature of signed integer overflow is just a hangover from when different representations were allowed. None of these is true. 3. Some code is written assuming that signed integers wrap on overflow, and the code is incorrect if that is not the case for the implementation used. 4. Some code would be easier to write in a correct and efficient way if signed integer overflow wrapped. 5. Some code is more efficient if signed integer overflow is undefined behaviour (assuming a suitable optimising compiler). 6. Some errors are significantly easier to detect (statically, or using run-time tools like sanitizers) when signed integer overflow is undefined behaviour. 7. Sometimes it would also be useful with undefined behaviour for unsigned integer overflow, for efficiency reasons or for detecting errors in the code. To my mind, this all says C++ should support both models - indeed, it should support several. I would propose a set of template classes, such as: std::overflow_wrap<T> std::overflow_undef<T> std::overflow_saturate<T> std::overflow_throw<T> These could be used with any integer types, signed and unsigned. The standard unsigned types are equivalent to the overflow_wrap types. The standard signed types are overflow_undef. Implementations would be free to implement overflow_undef (and therefore plain signed integer types) in any way they want, with the expectation that it is efficient. But compilers should document clearly if they consider plain ints to be overflow_undef. And if they say they are overflow_wrap, then they must be entirely consistent about it. (If you look in MSVC's documentation, you'll get the impression that it wraps on overflow - except when it optimises on the assumption that overflow doesn't occur.) I'd also be in favour of having a standardised pragma to change the behaviour of plain int types, as an aid to dealing with existing code. When people can't agree, and when every option has its advantages and disadvantages, the only rational solution is to give people an explicit choice.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-05 11:23 +0100 |
| Message-ID | <qpriio$gsq$1@news.albasani.net> |
| In reply to | #69562 |
> 3. Some code is written assuming that signed integers wrap on overflow,
> and the code is incorrect if that is not the case for the implementation
> used.
On which architectures today?
> 5. Some code is more efficient if signed integer overflow is undefined
> behaviour (assuming a suitable optimising compiler).
Which optimization?
Optimizing the following away:
int i;
...
if( i + 1 < i )
...
doesn't make sense.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-05 15:43 +0100 |
| Message-ID | <qps1q0$a0a$1@dont-email.me> |
| In reply to | #69564 |
On 05/11/2019 11:23, Bonita Montero wrote:
>> 3. Some code is written assuming that signed integers wrap on overflow,
>> and the code is incorrect if that is not the case for the implementation
>> used.
>
> On which architectures today?
All architectures. Some (few) compilers specifically document that they
have wrapping behaviour on overflow - most don't, even if they /usually/
wrap.
Most hardware these days has wrapping on signed integer overflow, unless
you specifically choose instructions with different behaviour (like
trapping on overflow or saturation). So you often get it as a
side-effect of the compiler generating efficient code. But that does
not mean the language supports it, or the compiler supports it.
Remember, "undefined behaviour" includes "sometimes giving wrapped results".
Consider this code:
int foo(int x) {
return (x * 20) / 5;
}
What is foo(214748367) (assuming 32-bit ints) ?
With x = 214748367, x * 20 is 4294967340, equal to 0x10000002c. So with
wrapping signed arithmetic, x * 20 is 44. Dividing by 5 gives 8
(rounding down).
On the other hand, it's easy to think that "foo" can be reduced to "x *
4". As long as there are no overflows in calculating "x * 20", that is
always true. So an optimising compiler that knows signed integer
overflow never happens, will generate "x * 4" code for foo - it's just
an "lea" or a "shl" instruction in x86, and much more efficient than
doing a multiply by 20 and then a divide by 5.
Applying this, foo(214748367) is 858993468.
These are two completely different answers. One is with wrapping
overflow semantics, the other is with an efficient implementation but
relies on optimising from the assumption that undefined behaviour,
signed integer overflow, never occurs.
Let's look in practice.
Paste this into godbolt.org, and look at it for different compilers
(with optimisations enabled).
const int testval = 214748367;
int foo(int x) {
return (x * 20) / 5;
}
int foo1(void) {
return foo(testval);
}
MSVC generates "shl eax, 2" for "foo" - efficient code, for undefined
behaviour in signed integer overflow. "foo1" is "mov eax, 8" - when
doing compile-time calculation for the value, it uses wrapping semantics
and gives a different value from the result of using the compiled function.
There is nothing wrong with that, of course - it is perfectly good C and
C++ behaviour. But it would be unexpected for people who think signed
integers wrap.
gcc gives an "lea" instruction for "foo", which is effectively the same
as MSVC. For "foo1", it returns 858993468, which is the same value as
it gives running the instructions of foo, but does not match wrapping
behaviour.
gcc also has the option "-fwrapv" to give full wrapping semantics.
"foo" is then handled by a full multiply by 20 followed by a divide by
5, and "foo1" returns 8.
Again, this is all fine. If you want wrapping signed semantics, you can
ask for it and get it. If not, you get efficient code.
>
>> 5. Some code is more efficient if signed integer overflow is undefined
>> behaviour (assuming a suitable optimising compiler).
>
> Which optimization?
> Optimizing the following away:
>
> int i;
> ...
> if( i + 1 < i )
> ...
>
> doesn't make sense.
Sure it makes sense. It's basic maths - if you add 1 to a number, with
normal arithmetic, you can't make it smaller. If you specifically have
a different arithmetic system, such as a modulo system, then it's a
different matter. But C and C++ don't have that for signed integers
(though any compiler is free to give you those semantics if it wants).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-05 16:58 +0100 |
| Message-ID | <qps668$s0h$1@news.albasani.net> |
| In reply to | #69568 |
>> Optimizing the following away: >> >> int i; >> ... >> if( i + 1 < i ) >> ... >> >> doesn't make sense. > Sure it makes sense. It's basic maths - if you add 1 to a number, with > normal arithmetic, you can't make it smaller. With the same reasoning you could say that unsigneds might never wrap; but in fact they're specified to wrap. And That's not how computers work. If someone does this he does the above intentionally there's only _one_ reason for it: he wants to check for wrap-around. So this is an optimization which no one asked for.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-11-05 21:45 +0200 |
| Message-ID | <qpsjg8$srn$1@dont-email.me> |
| In reply to | #69570 |
On 5.11.2019 17:58, Bonita Montero wrote: > > With the same reasoning you could say that unsigneds might never > wrap; but in fact they're specified to wrap. In retrospect, this (wrapping unsigneds) looks like a major design mistake. IMO, wrapping integers (signed or unsigned) are an example of "optimization which nobody asked for", and they are there basically only because the hardware happened to support such operations.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-11-06 13:33 +0100 |
| Message-ID | <qpuej0$16e1$1@gioia.aioe.org> |
| In reply to | #69575 |
On 11/5/2019 8:45 PM, Paavo Helde wrote:
> On 5.11.2019 17:58, Bonita Montero wrote:
>>
>> With the same reasoning you could say that unsigneds might never
>> wrap; but in fact they're specified to wrap.
>
> In retrospect, this (wrapping unsigneds) looks like a major design mistake.
No, it isn't.
>
> IMO, wrapping integers (signed or unsigned) are an example of
> "optimization which nobody asked for", and they are there basically only
> because the hardware happened to support such operations.
>
Look at the following code and see for yourself how efficient it is to
check for integer overflow if unsigned integers do wrap.
Achieving the same would be much more verbose (and less efficient) if
unsigned overflow were not defined behavior.
(taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
char* make_pathname (const char *dir, const char *fname, const char *ext)
{
size_t dirlen = strlen (dir);
size_t filelen = strlen (fname);
size_t extlen = strlen (ext);
size_t pathlen = dirlen;
// detect and handle integer wrapping
if ( (pathlen += filelen) < filelen
|| (pathlen += extlen) < extlen
|| (pathlen += 3) < 3)
return 0;
char *p, *path = malloc (pathlen);
if (!path)
return 0;
p = memcpy (path, dir, dirlen);
p [dirlen] = '/';
p = memcpy (p + dirlen + 1, fname, filelen);
p [filelen] = '.';
memcpy (p + filelen + 1, ext, extlen + 1);
return path;
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 13:51 +0100 |
| Message-ID | <qpufk8$60u$1@news.albasani.net> |
| In reply to | #69589 |
> char* make_pathname (const char *dir, const char *fname, const char *ext)
> {
> size_t dirlen = strlen (dir);
> size_t filelen = strlen (fname);
> size_t extlen = strlen (ext);
> size_t pathlen = dirlen;
> // detect and handle integer wrapping
> if ( (pathlen += filelen) < filelen
> || (pathlen += extlen) < extlen
> || (pathlen += 3) < 3)
> return 0;
Sorry, but when are paths longer than size_t?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 14:37 +0100 |
| Message-ID | <qpuia9$u6s$1@dont-email.me> |
| In reply to | #69589 |
On 06/11/2019 13:33, Manfred wrote:
> On 11/5/2019 8:45 PM, Paavo Helde wrote:
>> On 5.11.2019 17:58, Bonita Montero wrote:
>>>
>>> With the same reasoning you could say that unsigneds might never
>>> wrap; but in fact they're specified to wrap.
>>
>> In retrospect, this (wrapping unsigneds) looks like a major design
>> mistake.
>
> No, it isn't.
>
>>
>> IMO, wrapping integers (signed or unsigned) are an example of
>> "optimization which nobody asked for", and they are there basically
>> only because the hardware happened to support such operations.
>>
>
> Look at the following code and see for yourself how efficient it is to
> check for integer overflow if unsigned integers do wrap.
> Achieving the same would be much more verbose (and less efficient) if
> unsigned overflow were not defined behavior.
>
> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>
> char* make_pathname (const char *dir, const char *fname, const char *ext)
> {
> size_t dirlen = strlen (dir);
> size_t filelen = strlen (fname);
> size_t extlen = strlen (ext);
>
> size_t pathlen = dirlen;
>
> // detect and handle integer wrapping
> if ( (pathlen += filelen) < filelen
> || (pathlen += extlen) < extlen
> || (pathlen += 3) < 3)
> return 0;
That is just silly, in all sorts of ways.
First, decide if the function is an "internal" function where you can
trust the parameters, and have undefined behaviour if assumptions don't
hold, or an "external" function where you have to check the validity of
the parameters.
If it is internal, you know the lengths of the passed strings will not
sum to more than 4G - or you don't care if someone does something
ridiculous. (And on most modern systems, size_t is 64-bit - overflowing
here would require 16 EB ram for storing the strings.)
If it is external, the checking is too little - if you have char*
pointers from an unknown source, you should be wary about running
strlen() on them because you don't know if it will actually end with a 0
in a reasonable limit.
You only need to check for overflow if it is possible for the
calculations to overflow. If the operands are too small to cause an
overflow, there will not be an overflow.
And until you are talking about large integers for cryptography or that
sort of thing, adding up realistic numbers will not overflow a 64-bit type.
So /if/ you have an old 32-bit size_t system, and /if/ you have
maliciously crafted parameters that point to huge strings (and you'll
have to make them point within the same string - you don't get over 4 GB
user memory address space with 32-bit size_t), then you can do your
adding up using 64-bit types and you get zero risk of overflow.
uint_least64_t dirlen = strlen (dir);
uint_least64_t filelen = strlen (fname);
uint_least64_t extlen = strlen (ext);
uint_least64_t pathlen = dirlen + filelen + extlen;
if (big_size_t > MAX_SANE_PATHLENGTH) return 0;
There are times when unsigned wrapping overflow is useful. This is not
one of them.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-11-06 15:38 +0100 |
| Message-ID | <qpult3$a44$1@gioia.aioe.org> |
| In reply to | #69593 |
On 11/6/2019 2:37 PM, David Brown wrote:
> On 06/11/2019 13:33, Manfred wrote:
>> On 11/5/2019 8:45 PM, Paavo Helde wrote:
>>> On 5.11.2019 17:58, Bonita Montero wrote:
>>>>
>>>> With the same reasoning you could say that unsigneds might never
>>>> wrap; but in fact they're specified to wrap.
>>>
>>> In retrospect, this (wrapping unsigneds) looks like a major design
>>> mistake.
>>
>> No, it isn't.
>>
>>>
>>> IMO, wrapping integers (signed or unsigned) are an example of
>>> "optimization which nobody asked for", and they are there basically
>>> only because the hardware happened to support such operations.
>>>
>>
>> Look at the following code and see for yourself how efficient it is to
>> check for integer overflow if unsigned integers do wrap.
>> Achieving the same would be much more verbose (and less efficient) if
>> unsigned overflow were not defined behavior.
>>
>> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>>
>> char* make_pathname (const char *dir, const char *fname, const char *ext)
>> {
>> size_t dirlen = strlen (dir);
>> size_t filelen = strlen (fname);
>> size_t extlen = strlen (ext);
>>
>> size_t pathlen = dirlen;
>>
>> // detect and handle integer wrapping
>> if ( (pathlen += filelen) < filelen
>> || (pathlen += extlen) < extlen
>> || (pathlen += 3) < 3)
>> return 0;
>
> That is just silly, in all sorts of ways.
You realize that this comes from the glibc maintainers, don't you?
You can say they wrote silly code for this example (I don't), but I
doubt there are many more knowledgeable people about this kind of matter
than them.
Moreover, I took this as an example of detection of integer overflow.
The fact that it happens to be about pathname strings is irrelevant to
this discussion.
>
> First, decide if the function is an "internal" function where you can
> trust the parameters, and have undefined behaviour if assumptions don't
> hold, or an "external" function where you have to check the validity of
> the parameters.
This example was written about code safety, so yes, I believe it is
pretty clear the assumption is that strings come from an external source.
Obviously this applies to string /contents/; the pointer themselves can
only be internal to the program (can't they?), so no need to check for
null pointer.
On the other hand, contents of the string is checked by ensuring that
the result of strlen and their combination is valid. This is ensured
/exactly/ by making use of unsigned wrapping behavior.
>
> If it is internal, you know the lengths of the passed strings will not
> sum to more than 4G - or you don't care if someone does something
> ridiculous. (And on most modern systems, size_t is 64-bit - overflowing
> here would require 16 EB ram for storing the strings.)
>
> If it is external, the checking is too little - if you have char*
> pointers from an unknown source, you should be wary about running
> strlen() on them because you don't know if it will actually end with a 0
> in a reasonable limit.
This code handles C strings, so there is no way to check for their
length other than running strlen.
The fact that you seem to miss is that it is exactly thanks to the check
that you call "silly" that it is ensured that they "actually end with a
0 in a reasonable limit".
We could argue about what happens with /read/ access to a
non-0-terminated string, but I would simply assume that the strings are
0 terminated, since the function is going to be called by some other
part of the program that can take care that there is a 0 at the end of
the buffer. What is not guaranteed is that the strings actually contain
pathnames, and don't contain very long malicious text instead (e.g. they
could come from stdin).
That risk is avoided by the code you call silly.
So, no there is not too little checking.
>
>
> You only need to check for overflow if it is possible for the
> calculations to overflow. If the operands are too small to cause an
> overflow, there will not be an overflow.
>
> And until you are talking about large integers for cryptography or that
> sort of thing, adding up realistic numbers will not overflow a 64-bit type.
In fact cryptography is another example where unsigned wrap is useful,
but it would be much more complex (and off topic) to draw an example of
this (not that I claim to be an expert in this area)
And no, just assuming that "adding up realistic numbers will not
overflow a 64-bit type" is not what safe code is about.
>
> So /if/ you have an old 32-bit size_t system, and /if/ you have
> maliciously crafted parameters that point to huge strings (and you'll
> have to make them point within the same string - you don't get over 4 GB
> user memory address space with 32-bit size_t), then you can do your
> adding up using 64-bit types and you get zero risk of overflow.
>
>
> uint_least64_t dirlen = strlen (dir);
> uint_least64_t filelen = strlen (fname);
> uint_least64_t extlen = strlen (ext);
>
> uint_least64_t pathlen = dirlen + filelen + extlen;
>
> if (big_size_t > MAX_SANE_PATHLENGTH) return 0;
You realize that this code is less efficient than the original one,
don't you?
And what would be the correct value for MAX_SANE_PATHLENGTH? Are you
aware of the trouble that has been caused by Windows MAX_PATH?
The example I posted achieves the same level of safety, using less
resources, and allowing for the maximum string length that the system
can /safely/ handle (don't miss the check after malloc). What more do
you want?
>
>
> There are times when unsigned wrapping overflow is useful. This is not
> one of them.
>
I suggest you read the code again (and its source - it is instructive)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 15:53 +0100 |
| Message-ID | <qpumps$gre$1@news.albasani.net> |
| In reply to | #69594 |
>>> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>>>
>>> char* make_pathname (const char *dir, const char *fname, const char
>>> *ext)
>>> {
>>> size_t dirlen = strlen (dir);
>>> size_t filelen = strlen (fname);
>>> size_t extlen = strlen (ext);
>>>
>>> size_t pathlen = dirlen;
>>>
>>> // detect and handle integer wrapping
>>> if ( (pathlen += filelen) < filelen
>>> || (pathlen += extlen) < extlen
>>> || (pathlen += 3) < 3)
>>> return 0;
>> That is just silly, in all sorts of ways.
> You realize that this comes from the glibc maintainers, don't you?
> You can say they wrote silly code for this example (I don't), but I
> doubt there are many more knowledgeable people about this kind of
> matter than them.
Yes, this is useless code.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-06 10:06 -0500 |
| Message-ID | <qpuni4$u0s$1@dont-email.me> |
| In reply to | #69594 |
On 11/6/19 9:38 AM, Manfred wrote: ... > And no, just assuming that "adding up realistic numbers will not > overflow a 64-bit type" is not what safe code is about. Assuming it: no. Verifying it: yes. If you validate your inputs, you can often place upper and lower limits on the value of an expression calculated from those inputs. If those limits fall within the range that is guaranteed to be representable in the expression's type, it is perfectly legitimate to not bothering to include an overflow check.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2019-11-06 17:00 +0100 |
| Message-ID | <qpuqn0$hae$1@dont-email.me> |
| In reply to | #69594 |
On 06.11.2019 15:38, Manfred wrote:
> On 11/6/2019 2:37 PM, David Brown wrote:
>> On 06/11/2019 13:33, Manfred wrote:
>>> [snip]
>>> Look at the following code and see for yourself how efficient it is to
>>> check for integer overflow if unsigned integers do wrap.
>>> Achieving the same would be much more verbose (and less efficient) if
>>> unsigned overflow were not defined behavior.
>>>
>>> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>>>
>>> char* make_pathname (const char *dir, const char *fname, const char
>>> *ext)
>>> {
>>> size_t dirlen = strlen (dir);
>>> size_t filelen = strlen (fname);
>>> size_t extlen = strlen (ext);
>>>
>>> size_t pathlen = dirlen;
>>>
>>> // detect and handle integer wrapping
>>> if ( (pathlen += filelen) < filelen
>>> || (pathlen += extlen) < extlen
>>> || (pathlen += 3) < 3)
>>> return 0;
>>
>> That is just silly, in all sorts of ways.
>
> You realize that this comes from the glibc maintainers, don't you?
> You can say they wrote silly code for this example (I don't), but I
> doubt there are many more knowledgeable people about this kind of matter
> than them.
David has a point that with 32-bit `size_t` there's no way to have
separate strings whose lengths sum to >= 4G.
So some of the arguments have to point within the same superlong string
in order for the checking to end up at `return 0;`.
Whether it's silly to try to give well-defined behavior also for such an
unlikely case: maybe silly when one just codes up something for limited
use and with limited time, but probably not silly when one's crafting
widely used library code.
I.e. the context, what it's made for, "glibc", is important.
However I think the appeal to authority, "glibc /maintainers/", is a
fallacious argument.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-11-06 17:47 +0100 |
| Message-ID | <qputft$1efv$1@gioia.aioe.org> |
| In reply to | #69598 |
On 11/6/2019 5:00 PM, Alf P. Steinbach wrote:
> On 06.11.2019 15:38, Manfred wrote:
>> On 11/6/2019 2:37 PM, David Brown wrote:
>>> On 06/11/2019 13:33, Manfred wrote:
>>>> [snip]
>>>> Look at the following code and see for yourself how efficient it is to
>>>> check for integer overflow if unsigned integers do wrap.
>>>> Achieving the same would be much more verbose (and less efficient) if
>>>> unsigned overflow were not defined behavior.
>>>>
>>>> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>>>>
>>>> char* make_pathname (const char *dir, const char *fname, const char
>>>> *ext)
>>>> {
>>>> size_t dirlen = strlen (dir);
>>>> size_t filelen = strlen (fname);
>>>> size_t extlen = strlen (ext);
>>>>
>>>> size_t pathlen = dirlen;
>>>>
>>>> // detect and handle integer wrapping
>>>> if ( (pathlen += filelen) < filelen
>>>> || (pathlen += extlen) < extlen
>>>> || (pathlen += 3) < 3)
>>>> return 0;
>>>
>>> That is just silly, in all sorts of ways.
>>
>> You realize that this comes from the glibc maintainers, don't you?
>> You can say they wrote silly code for this example (I don't), but I
>> doubt there are many more knowledgeable people about this kind of
>> matter than them.
>
> David has a point that with 32-bit `size_t` there's no way to have
> separate strings whose lengths sum to >= 4G.
I should check the details (if I had the time and will to do it) but
even if this is true for the physical memory address space, if I
remember correctly the 386 has way larger virtual memory addressing
space: it does have segmenting capability, even if most OSs never used it.
I don't remember if it is possible for the 386 to address more than 4G
within a single process, though. Theoretically it is nonetheless
possible, using segments, to have a 32-bit architecture wherein the
lengths sum up to more than 4G.
More practically, the example was about code safety, and so the
possibility of malicious usage has to be assumed, hence the need for the
check (at least for the +3 part).
>
> So some of the arguments have to point within the same superlong string
> in order for the checking to end up at `return 0; >
> Whether it's silly to try to give well-defined behavior also for such an
> unlikely case: maybe silly when one just codes up something for limited
> use and with limited time, but probably not silly when one's crafting
> widely used library code.
>
> I.e. the context, what it's made for, "glibc", is important.
>
> However I think the appeal to authority, "glibc /maintainers/", is a
> fallacious argument.
It would be if it was only an appeal to authority.
After giving context (and yes, pointing out that this example was not
just rubbish taken from some dump in the internet), in the followup my
argument has gone into the subject of the matter.
>
>
> - Alf
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 17:54 +0100 |
| Message-ID | <qputsq$u6e$1@news.albasani.net> |
| In reply to | #69599 |
> I should check the details (if I had the time and will to do it) > but even if this is true for the physical memory address space, if > I remember correctly the 386 has way larger virtual memory addressing > space: it does have segmenting capability, even if most OSs never used. > it. And there is an operating-system using the glibc in a segmented environment? > space: it does have segmenting capability, even if most OSs never used > it. I don't remember if it is possible for the 386 to address more than > 4G within a single process, though. Theoretically it is nonetheless > possible, using segments, to have a 32-bit architecture wherein the > lengths sum up to more than 4G. I think it would be rather stupid to continue the segmented behaviour of the 286 protected mode with the 386 protected mode, although it is hypothetically possible. Also because the 32-bit-machnise almost never had more memory than 4GB.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2019-11-06 20:00 +0100 |
| Message-ID | <h2gjhiFkuphU1@mid.individual.net> |
| In reply to | #69600 |
On 2019-11-06 at 17:54, Bonita Montero wrote:
>> I should check the details (if I had the time and will to do it)
>> but even if this is true for the physical memory address space, if
>> I remember correctly the 386 has way larger virtual memory addressing
>> space: it does have segmenting capability, even if most OSs never used.
>> it.
>
> And there is an operating-system using the glibc in a segmented
> environment?
>
>> space: it does have segmenting capability, even if most OSs never used
>> it. I don't remember if it is possible for the 386 to address more than
>> 4G within a single process, though. Theoretically it is nonetheless
>> possible, using segments, to have a 32-bit architecture wherein the
>> lengths sum up to more than 4G.
>
> I think it would be rather stupid to continue the segmented behaviour
> of the 286 protected mode with the 386 protected mode, although it is
> hypothetically possible. Also because the 32-bit-machnise almost never
> had more memory than 4GB.
The original problem wasn't only about memory.
The designers of Windows NT *did* briefly consider adding support for
more than one 4GB segment in a program.
However, to load a new segment you first have to swap the old 4GB
segment out to disk. And they couldn't see PC hard disks ever becoming
that large. :-)
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-06 20:13 +0100 |
| Message-ID | <qpv607$8rg$1@news.albasani.net> |
| In reply to | #69604 |
> The designers of Windows NT *did* briefly consider adding support for > more than one 4GB segment in a program. The actually have it today for a small in which the thread-information-block resides: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block > However, to load a new segment you first have to swap the old 4GB > segment out to disk. That's not necessarily true.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-06 20:44 +0100 |
| Message-ID | <qpv7qj$282$1@dont-email.me> |
| In reply to | #69599 |
On 06/11/2019 17:47, Manfred wrote:
> On 11/6/2019 5:00 PM, Alf P. Steinbach wrote:
>> On 06.11.2019 15:38, Manfred wrote:
>>> On 11/6/2019 2:37 PM, David Brown wrote:
>>>> On 06/11/2019 13:33, Manfred wrote:
>>>>> [snip]
>>>>> Look at the following code and see for yourself how efficient it is to
>>>>> check for integer overflow if unsigned integers do wrap.
>>>>> Achieving the same would be much more verbose (and less efficient) if
>>>>> unsigned overflow were not defined behavior.
>>>>>
>>>>> (taken from http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm)
>>>>>
>>>>> char* make_pathname (const char *dir, const char *fname, const char
>>>>> *ext)
>>>>> {
>>>>> size_t dirlen = strlen (dir);
>>>>> size_t filelen = strlen (fname);
>>>>> size_t extlen = strlen (ext);
>>>>>
>>>>> size_t pathlen = dirlen;
>>>>>
>>>>> // detect and handle integer wrapping
>>>>> if ( (pathlen += filelen) < filelen
>>>>> || (pathlen += extlen) < extlen
>>>>> || (pathlen += 3) < 3)
>>>>> return 0;
>>>>
>>>> That is just silly, in all sorts of ways.
>>>
>>> You realize that this comes from the glibc maintainers, don't you?
>>> You can say they wrote silly code for this example (I don't), but I
>>> doubt there are many more knowledgeable people about this kind of
>>> matter than them.
>>
>> David has a point that with 32-bit `size_t` there's no way to have
>> separate strings whose lengths sum to >= 4G.
>
> I should check the details (if I had the time and will to do it) but
> even if this is true for the physical memory address space, if I
> remember correctly the 386 has way larger virtual memory addressing
> space: it does have segmenting capability, even if most OSs never used it.
The 32-bit x86 could have a larger virtual memory space than 4 GB, and
processors with the PAE could have more physical memory too (I think 64
GB, but I am not sure). However, individual processes on *nix or
Windows could only access 4 GB (split either 2G/2G or 1G/3G between
kernel space and user space). The pointers here would all be within the
same 4 GB limit.
> I don't remember if it is possible for the 386 to address more than 4G
> within a single process, though. Theoretically it is nonetheless
> possible, using segments, to have a 32-bit architecture wherein the
> lengths sum up to more than 4G.
>
> More practically, the example was about code safety, and so the
> possibility of malicious usage has to be assumed, hence the need for the
> check (at least for the +3 part).
>
Checking parameters for sanity is vital for externally-facing functions.
This one fails to check for null pointers, fails to check for sane
sizes of the strings (strlen is not a good idea on unknown strings, if
you consider excessive run time to be a problem), and fails to check for
any kind of appropriate size on the data. It checks that the curtains
are closed while leaving the front door open.
>>
>> So some of the arguments have to point within the same superlong
>> string in order for the checking to end up at `return 0; >
>> Whether it's silly to try to give well-defined behavior also for such
>> an unlikely case: maybe silly when one just codes up something for
>> limited use and with limited time, but probably not silly when one's
>> crafting widely used library code.
>>
>> I.e. the context, what it's made for, "glibc", is important.
>>
>> However I think the appeal to authority, "glibc /maintainers/", is a
>> fallacious argument.
>
> It would be if it was only an appeal to authority.
> After giving context (and yes, pointing out that this example was not
> just rubbish taken from some dump in the internet), in the followup my
> argument has gone into the subject of the matter.
>
>>
>>
>> - Alf
>
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web