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 | 19 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-05 09:19 -0500 |
| Message-ID | <qps0ef$1jd$1@dont-email.me> |
| In reply to | #69561 |
On 11/5/19 2:36 AM, Öö Tiib wrote: > On Tuesday, 5 November 2019 09:24:17 UTC+2, Christian Gollwitzer wrote: >> Am 05.11.19 um 06:56 schrieb Bonita Montero: >> >>> return (numeric_limits<int>::max() + 1) == numeric_limits<int>::min(); >> >> Couldn't this in theory format your hard drive (although in practice it >> never will)? Or more realistically, always return a false negative from >> a zealous optimizer? The function is_modulo() is supposed to return true if the signed overflow is defined by the implementation to result in wrap-around as an extension to C++ (21.3.4.1p62). The behavior is defined by neither the standard nor the implementation, only if is_modulo() is false. If undefined behavior causes hasTwosComplementAndWrapAround() to return false, that means that it does NOT Wrap around, so the function is returning precisely the result that it's supposed to return. The important problem is the possibility of a false positive result: hasTwosComplementAndWrapAround() returning true when signed overflow does NOT wrap around, which is entirely possible, given that the alternative to wrapping around is undefined behavior. > > Yes, when numeric_limits<int>::is_modulo is false then the > numeric_limits<int>::max() + 1 is undefined behavior. Note, in particular, that if numeric_limits<T>::is_modulo() is false, then signed overflow might, for instance, always give a result of numeric_limits<T>::min(). That would cause Bonita's implementation for hasTwosComplementAndWrapAround() to return true, despite the fact that overflow does NOT wrap around.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 08:32 +0100 |
| Message-ID | <r08tpr$e3b$1@news.albasani.net> |
| In reply to | #69548 |
I recently had the problem that I wanted to have a constant which is size_t wide and where the highest bit is set. I simply solved it that way (I assume ptrdiff_t as wide as size_t, but this should be common today on all platforms): std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); A guarantee from the standard that signed values are 2's-complement woud be nice for that.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-01-22 09:23 +0100 |
| Message-ID | <r090qk$dv2$1@dont-email.me> |
| In reply to | #71498 |
On 22.01.2020 08:32, Bonita Montero wrote: > I recently had the problem that I wanted to have a constant which is > size_t wide and where the highest bit is set. I simply solved it that > way (I assume ptrdiff_t as wide as size_t, but this should be common > today on all platforms): > std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); > A guarantee from the standard that signed values are 2's-complement > woud be nice for that. C++20 will give you that guarantee. But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 guarantees. Every time I discover a vastly simpler way of doing something, so that I prove myself stupid, I feel more optimistic since evidently my mind is still working. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 14:20 +0100 |
| Message-ID | <r09i68$t8f$1@news.albasani.net> |
| In reply to | #71499 |
> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 > guarantees. I think it would be better to write (size_t)(ptrdiff_t)-1 because the conversion of signed ints to size_t is UB when the int is nega- tive. I.e. the compiler could first make the value unsigned and then extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit -machine. With the above cast to ptrdiff_t you have at least the guarantee that the value is widened with its sign.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2020-01-22 13:37 +0000 |
| Message-ID | <20200122133741.f1f6c0810d031525560d009a@cvine--nospam--.freeserve.co.uk> |
| In reply to | #71512 |
On Wed, 22 Jan 2020 14:20:08 +0100 Bonita Montero <Bonita.Montero@gmail.com> wrote: > > But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 > > guarantees. > > I think it would be better to write (size_t)(ptrdiff_t)-1 because > the conversion of signed ints to size_t is UB when the int is nega- > tive. I.e. the compiler could first make the value unsigned and then > extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit > -machine. With the above cast to ptrdiff_t you have at least the > guarantee that the value is widened with its sign. size_t(-1) has defined behaviour in C++, if that is your point. The representation depends on the size and signedness of the destination, not the source: "A prvalue of an integer type can be converted to a prvalue of another integer type ... . If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2 n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). — end note ]" size_t(-1) will always give you all bits set, whatever the signed representation of -1 (bits will be altered if necessary).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-27 01:17 -0800 |
| Message-ID | <868slti7gm.fsf@linuxsc.com> |
| In reply to | #71499 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > On 22.01.2020 08:32, Bonita Montero wrote: > >> I recently had the problem that I wanted to have a constant which is >> size_t wide and where the highest bit is set. I simply solved it that >> way (I assume ptrdiff_t as wide as size_t, but this should be common >> today on all platforms): >> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >> A guarantee from the standard that signed values are 2's-complement >> woud be nice for that. > > C++20 will give you that guarantee. > > But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 > guarantees. Or just size_t(-1)/2+1.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-01-27 12:35 +0100 |
| Message-ID | <r0mhtd$j13$1@dont-email.me> |
| In reply to | #71616 |
On 27.01.2020 10:17, Tim Rentsch wrote: > "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > >> On 22.01.2020 08:32, Bonita Montero wrote: >> >>> I recently had the problem that I wanted to have a constant which is >>> size_t wide and where the highest bit is set. I simply solved it that >>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>> today on all platforms): >>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >>> A guarantee from the standard that signed values are 2's-complement >>> woud be nice for that. >> >> C++20 will give you that guarantee. >> >> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >> guarantees. > > Or just size_t(-1)/2+1. Or ~(size_t(-1)/2). There. :-) Thanks, - Alf
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-15 05:56 -0800 |
| Message-ID | <86a75kgdjh.fsf@linuxsc.com> |
| In reply to | #71622 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > On 27.01.2020 10:17, Tim Rentsch wrote: > >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >> >>> On 22.01.2020 08:32, Bonita Montero wrote: >>> >>>> I recently had the problem that I wanted to have a constant which is >>>> size_t wide and where the highest bit is set. I simply solved it that >>>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>>> today on all platforms): >>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >>>> A guarantee from the standard that signed values are 2's-complement >>>> woud be nice for that. >>> >>> C++20 will give you that guarantee. >>> >>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >>> guarantees. >> >> Or just size_t(-1)/2+1. > > Or ~(size_t(-1)/2). In practice that is highly likely to work, but strictly speaking it is not guaranteed (at least not in C; I believe that holds also in C++ but I am less well-versed in the C++ standard than the C standard). The reason is size_t is not required to be at least as wide as int, so the ~ could produce a negative value.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-02-16 09:17 +0100 |
| Message-ID | <r2atqe$8je$1@dont-email.me> |
| In reply to | #71855 |
On 15.02.2020 14:56, Tim Rentsch wrote: > "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: > >> On 27.01.2020 10:17, Tim Rentsch wrote: >> >>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>> >>>> On 22.01.2020 08:32, Bonita Montero wrote: >>>> >>>>> I recently had the problem that I wanted to have a constant which is >>>>> size_t wide and where the highest bit is set. I simply solved it that >>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>>>> today on all platforms): >>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >>>>> A guarantee from the standard that signed values are 2's-complement >>>>> woud be nice for that. >>>> >>>> C++20 will give you that guarantee. >>>> >>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >>>> guarantees. >>> >>> Or just size_t(-1)/2+1. >> >> Or ~(size_t(-1)/2). > > In practice that is highly likely to work, but strictly speaking > it is not guaranteed (at least not in C; I believe that holds > also in C++ but I am less well-versed in the C++ standard than > the C standard). The reason is size_t is not required to be at > least as wide as int, so the ~ could produce a negative value. Interesting point. Does any C or C++ implemention with sizeof(size_t) < sizeof(int) exist, or has any such implementation existed? Fix: `~(size_t(-1)/2u)`. But the question is, since code is about communicating to humans, does this communicate the right thing? - Alf
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-02-21 19:35 -0500 |
| Message-ID | <IH_3G.207897$MX1.202990@fx43.iad> |
| In reply to | #71868 |
On 2/16/20 3:17 AM, Alf P. Steinbach wrote: > On 15.02.2020 14:56, Tim Rentsch wrote: >> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >> >>> On 27.01.2020 10:17, Tim Rentsch wrote: >>> >>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>>> >>>>> On 22.01.2020 08:32, Bonita Montero wrote: >>>>> >>>>>> I recently had the problem that I wanted to have a constant which is >>>>>> size_t wide and where the highest bit is set. I simply solved it >>>>>> that >>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>>>>> today on all platforms): >>>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >>>>>> A guarantee from the standard that signed values are 2's-complement >>>>>> woud be nice for that. >>>>> >>>>> C++20 will give you that guarantee. >>>>> >>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >>>>> guarantees. >>>> >>>> Or just size_t(-1)/2+1. >>> >>> Or ~(size_t(-1)/2). >> >> In practice that is highly likely to work, but strictly speaking >> it is not guaranteed (at least not in C; I believe that holds >> also in C++ but I am less well-versed in the C++ standard than >> the C standard). The reason is size_t is not required to be at >> least as wide as int, so the ~ could produce a negative value. > > Interesting point. > > Does any C or C++ implemention with sizeof(size_t) < sizeof(int) exist, > or has any such implementation existed? > > Fix: `~(size_t(-1)/2u)`. But the question is, since code is about > communicating to humans, does this communicate the right thing? > > - Alf You still have the issue that if size_t is smaller than int (and unsigned) the ~ operator will set more bits then the upper bit of size_t maybe size_t(~(size_t(-1)/2u))) but the +1 version I think is cleaner.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2020-02-22 07:01 +0100 |
| Message-ID | <r2qg42$a1l$1@dont-email.me> |
| In reply to | #71938 |
On 22.02.2020 01:35, Richard Damon wrote: > On 2/16/20 3:17 AM, Alf P. Steinbach wrote: >> On 15.02.2020 14:56, Tim Rentsch wrote: >>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>> >>>> On 27.01.2020 10:17, Tim Rentsch wrote: >>>> >>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: >>>>> >>>>>> On 22.01.2020 08:32, Bonita Montero wrote: >>>>>> >>>>>>> I recently had the problem that I wanted to have a constant which is >>>>>>> size_t wide and where the highest bit is set. I simply solved it >>>>>>> that >>>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>>>>>> today on all platforms): >>>>>>> std::size_t const SIZE_T_MSB = >>>>>>> std::numeric_limits<ptrdiff_t>::min(); >>>>>>> A guarantee from the standard that signed values are 2's-complement >>>>>>> woud be nice for that. >>>>>> >>>>>> C++20 will give you that guarantee. >>>>>> >>>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >>>>>> guarantees. >>>>> >>>>> Or just size_t(-1)/2+1. >>>> >>>> Or ~(size_t(-1)/2). >>> >>> In practice that is highly likely to work, but strictly speaking >>> it is not guaranteed (at least not in C; I believe that holds >>> also in C++ but I am less well-versed in the C++ standard than >>> the C standard). The reason is size_t is not required to be at >>> least as wide as int, so the ~ could produce a negative value. >> >> Interesting point. >> >> Does any C or C++ implemention with sizeof(size_t) < sizeof(int) >> exist, or has any such implementation existed? >> >> Fix: `~(size_t(-1)/2u)`. But the question is, since code is about >> communicating to humans, does this communicate the right thing? >> >> - Alf > > You still have the issue that if size_t is smaller than int (and > unsigned) the ~ operator will set more bits then the upper bit of size_t Not in the given context, as initializer for a `size_t` constant. > maybe > > size_t(~(size_t(-1)/2u))) > but the +1 version I think is cleaner. Not needed. :) - Alf
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-24 08:22 -0800 |
| Message-ID | <86ftf0arax.fsf@linuxsc.com> |
| In reply to | #71868 |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> On 15.02.2020 14:56, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>
>>> On 27.01.2020 10:17, Tim Rentsch wrote:
>>>
>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>
>>>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>>>
>>>>>> I recently had the problem that I wanted to have a constant which is
>>>>>> size_t wide and where the highest bit is set. I simply solved it that
>>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>>>> today on all platforms):
>>>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>>>>> A guarantee from the standard that signed values are 2's-complement
>>>>>> woud be nice for that.
>>>>>
>>>>> C++20 will give you that guarantee.
>>>>>
>>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>>>> guarantees.
>>>>
>>>> Or just size_t(-1)/2+1.
>>>
>>> Or ~(size_t(-1)/2).
>>
>> In practice that is highly likely to work, but strictly speaking
>> it is not guaranteed (at least not in C; I believe that holds
>> also in C++ but I am less well-versed in the C++ standard than
>> the C standard). The reason is size_t is not required to be at
>> least as wide as int, so the ~ could produce a negative value.
>
> Interesting point.
>
> Does any C or C++ implemention with sizeof(size_t) < sizeof(int)
> exist, or has any such implementation existed?
I doubt it. Certainly I don't know of any.
> Fix: `~(size_t(-1)/2u)`. But the question is, since code is about
> communicating to humans, does this communicate the right thing?
I prefer the form I gave, because it's easer to see that the
value it produces is correct, and because it is less brittle, in
the sense that it doesn't depend on surrounding context to
produce the correct value. Come to think of it though I would
change it slightly, to get a form that works in both C and C++:
(size_t)-1 /2 +1
Normally in cases like this I would look for an alternative that
does not use a cast. Here though I think a cast is necessary:
other possible ways of robustly getting the right value all are
worse in one way or another AFAICS. Of course, if <stdint.h>
has been #include'd, we could use
SIZE_MAX/2 + 1
which uses neither a cast nor the converting of -1. So that's
probably better, in most circumstances, than the other forms
mentioned.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2020-02-24 03:12 +0000 |
| Message-ID | <r2veum$8oa$1@reader2.panix.com> |
| In reply to | #71499 |
In article <r090qk$dv2$1@dont-email.me>, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: >On 22.01.2020 08:32, Bonita Montero wrote: >> I recently had the problem that I wanted to have a constant which is >> size_t wide and where the highest bit is set. I simply solved it that >> way (I assume ptrdiff_t as wide as size_t, but this should be common >> today on all platforms): >> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >> A guarantee from the standard that signed values are 2's-complement >> woud be nice for that. > >C++20 will give you that guarantee. > >But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >guarantees. Hmm, can't one simply compute: ~(size_t)0 ^ (~(size_t)0 >> 1) ?
[toc] | [prev] | [next] | [standalone]
| From | cdalten@gmail.com |
|---|---|
| Date | 2020-02-24 05:53 -0800 |
| Message-ID | <23c15c46-b7bf-44d1-a73f-f9a3db81a977@googlegroups.com> |
| In reply to | #71988 |
On Sunday, February 23, 2020 at 7:12:31 PM UTC-8, Dan Cross wrote: > In article <r090qk$dv2$1@dont-email.me>, > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: > >On 22.01.2020 08:32, Bonita Montero wrote: > >> I recently had the problem that I wanted to have a constant which is > >> size_t wide and where the highest bit is set. I simply solved it that > >> way (I assume ptrdiff_t as wide as size_t, but this should be common > >> today on all platforms): > >> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); > >> A guarantee from the standard that signed values are 2's-complement > >> woud be nice for that. > > > >C++20 will give you that guarantee. > > > >But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 > >guarantees. > > Hmm, can't one simply compute: > > ~(size_t)0 ^ (~(size_t)0 >> 1) > > ? Bad Dan. No cookie.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-25 07:56 -0800 |
| Message-ID | <86y2sqace9.fsf@linuxsc.com> |
| In reply to | #71988 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <r090qk$dv2$1@dont-email.me>, > Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: > >> On 22.01.2020 08:32, Bonita Montero wrote: >> >>> I recently had the problem that I wanted to have a constant which is >>> size_t wide and where the highest bit is set. I simply solved it that >>> way (I assume ptrdiff_t as wide as size_t, but this should be common >>> today on all platforms): >>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min(); >>> A guarantee from the standard that signed values are 2's-complement >>> woud be nice for that. >> >> C++20 will give you that guarantee. >> >> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 >> guarantees. > > Hmm, can't one simply compute: > > ~(size_t)0 ^ (~(size_t)0 >> 1) > > ? Why not just this? (size_t)-1 /2 +1
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2020-02-25 22:00 +0000 |
| Message-ID | <r345ek$pdi$1@reader2.panix.com> |
| In reply to | #72021 |
In article <86y2sqace9.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Why not just this? (size_t)-1 /2 +1 Because I didn't think of it before you posted it, Tim. :-) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-25 16:14 -0800 |
| Message-ID | <86tv3e9pc4.fsf@linuxsc.com> |
| In reply to | #72022 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86y2sqace9.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Why not just this? (size_t)-1 /2 +1 > > Because I didn't think of it before you posted > it, Tim. :-) Thank you for that Dan. It's good to see you back in the newsgroups again.
[toc] | [prev] | [next] | [standalone]
| From | cdalten@gmail.com |
|---|---|
| Date | 2020-02-25 18:18 -0800 |
| Message-ID | <bf72f845-d34f-4396-82d8-1abd62239efc@googlegroups.com> |
| In reply to | #72023 |
Since Dan Cross has me blocked because I called him out for the wife beater that he is, let me try to fill you in on my Cross has been MIA. Background. Dan is a Math guy who used to serve in the USMC. At the time he was dating some Russian woman. They broke up because he got tired of her being the "man" in the relationship. Now let's fast forward. He found some chick from the Gaza Strip that was desperate enough to date him. They've stuck together because she let's him be the man in the relationship. They even have a kid! He also likes the fact that he can beat his gf. Whereas with the Russian woman, well, everytime that he got pissed off, she basically beat his ass. This despite that fact that he was in the USMC! These days he spends a lot of time on arbornet.org and grex.org. He goes under the name of cross on both of these sites. He prefers to hang out there because both systems are dominated by fat, middle aged, balding white men. He talks to the menz on these sites all the time just in case his current girlfriend finds a real man. Why? So he could date one of these guys!!! Dan Cross isn't getting any younger. It's now getting to the point where he will settle down with anything on two legs. This could be male, female, or shemale.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2020-02-26 02:22 +0000 |
| Message-ID | <r34kpt$9o6$1@reader2.panix.com> |
| In reply to | #72023 |
In article <86tv3e9pc4.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Because I didn't think of it before you posted >> it, Tim. :-) > >Thank you for that Dan. It's good to see you back >in the newsgroups again. Thanks, Tim! It's nice to be reading. - Dan C.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c++
csiph-web