Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70446 > unrolled thread
| Started by | woodbrian77@gmail.com |
|---|---|
| First post | 2019-12-13 21:28 -0800 |
| Last post | 2019-12-15 09:49 +0000 |
| Articles | 20 on this page of 309 — 26 participants |
Back to article view | Back to comp.lang.c++
Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-13 21:28 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-14 09:23 +0000
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-14 17:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 09:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-14 12:00 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 13:51 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:13 -0800
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 15:35 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:03 -0800
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2019-12-15 15:41 +1300
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-14 22:55 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:53 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:18 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:44 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 20:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-15 15:11 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 23:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 15:41 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-16 05:18 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:46 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:57 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:21 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:37 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 15:13 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 14:12 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 19:35 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:14 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-17 08:32 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:26 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:11 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 11:23 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:31 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:56 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:42 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-19 20:26 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 09:25 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 04:35 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 16:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 10:36 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 16:33 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 17:22 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 10:18 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-21 21:21 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 14:30 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-22 21:36 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-22 15:05 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-22 17:03 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-22 17:46 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-22 18:07 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:23 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-23 16:33 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 18:51 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 17:02 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 19:17 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-24 09:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-24 02:16 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-25 00:30 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 09:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 16:38 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 17:33 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 19:52 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:14 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-27 09:41 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:05 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-28 21:01 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 09:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 12:21 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:30 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 21:45 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:10 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 14:03 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 12:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 04:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 13:01 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 15:17 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:22 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:49 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 17:18 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:12 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 18:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:38 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 19:17 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 20:55 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:01 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 13:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 14:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 14:12 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 15:39 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 15:45 +0100
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 15:22 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 17:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:21 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:35 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:59 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 12:23 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:14 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:52 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 18:58 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:00 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:21 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:22 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:46 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 20:30 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:44 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:10 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 13:03 +0100
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2020-01-12 07:50 +1300
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-11 11:55 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 23:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:04 +0100
Re: Don't be fooled by cpp.sh Richard Damon <Richard@Damon-Family.org> - 2020-01-04 20:04 -0500
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 13:36 +0100
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-06 18:39 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:16 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 17:01 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 17:34 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:29 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-30 19:37 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 11:19 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:14 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:06 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 05:39 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:39 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:25 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 12:00 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:10 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 16:42 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:07 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 15:48 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:24 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 12:02 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 10:52 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 13:27 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 16:45 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-02 16:55 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 17:24 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-02 18:30 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 09:40 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 22:58 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:28 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:56 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:20 -0500
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-03 14:53 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 17:22 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:45 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 09:01 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 21:05 -0500
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:46 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-10 09:51 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:59 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:06 +0200
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 14:06 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:38 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:13 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-31 17:06 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:09 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:11 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:13 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-01 09:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:25 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-03 10:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:43 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-04 18:02 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-05 10:41 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 12:31 -0600
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-05 20:11 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-05 11:22 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 21:07 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-05 20:40 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-06 18:08 -0600
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-06 23:17 -0500
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:37 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:28 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:15 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:33 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 12:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:14 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-31 12:29 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:17 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:32 +0100
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-30 14:57 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:23 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 22:16 -0500
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:30 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:12 -0800
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:07 -0800
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 13:50 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2020-01-01 08:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:28 +0000
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:26 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-29 11:31 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:35 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-29 18:40 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:12 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:10 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 12:11 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 22:20 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 01:23 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 15:54 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-30 17:07 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 19:58 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 23:59 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-30 21:23 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-28 18:09 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-26 18:30 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-27 09:58 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:06 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-28 08:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 16:57 +0000
Re: Don't be fooled by cpp.sh Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-02 23:18 -0500
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-26 10:54 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 22:50 +0200
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-26 10:38 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-24 17:52 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-24 23:53 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-25 08:51 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-25 10:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-21 08:42 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:25 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:28 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 20:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-18 22:12 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:47 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:03 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:49 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 12:05 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 12:19 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-16 21:13 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:38 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-17 09:14 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-17 17:50 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:35 +0100
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-15 20:48 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:55 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:12 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 06:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 09:10 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 18:33 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 19:29 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-15 23:38 -0500
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:23 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:36 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:43 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:44 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 12:10 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:21 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 10:54 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 11:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:15 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:23 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 09:31 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:23 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-16 21:45 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:20 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-17 21:56 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 22:06 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 19:42 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 11:56 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:18 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 21:03 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 00:04 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-17 01:06 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 14:51 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:25 -0500
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 14:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:32 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:52 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:24 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:56 -0800
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-16 20:45 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 22:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 04:07 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 14:44 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:54 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 15:52 +0000
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 11:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 22:10 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 22:08 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-18 08:56 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-17 23:55 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:36 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 22:40 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:17 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:24 -0800
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 12:13 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:44 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 18:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:49 +0000
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 16:49 +0100 |
| Message-ID | <qud6ao$ure$1@dont-email.me> |
| In reply to | #70818 |
On 30/12/2019 14:22, Bonita Montero wrote:
>> Want a better example? From math.h:
>>
>> __header_always_inline int __inline_signbitf(float __x) {
>> union { float __f; unsigned int __u; } __u;
>> __u.__f = __x;
>> return (int)(__u.__u >> 31);
>> }
>>
>
> In C++ you could do: (int)((unsigned &)x >> 31)
You /could/ write that, but it has undefined behaviour.
There are a number of ways this code could be written so that it is
correct (at least on platforms with "float" and "unsigned int" both
32-bit and the same endianness), and with optimal code generation for
good compilers. My preference for a function like this would be :
#include <string.h>
int sign_bit(float x) {
unsigned int y;
memcpy(&y, &x, sizeof(x));
return y >> 31;
}
It is simple, clear, and efficient (on the compilers I use, anyway).
Of course, this is part of a standard library header - the
implementation can use any method it likes, with a total disregard to
whether it is defined in the C and/or C++ standards, or how portable it
might be.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 17:18 +0100 |
| Message-ID | <qud816$8o3$1@news.albasani.net> |
| In reply to | #70824 |
>>> Want a better example? From math.h:
>>>
>>> __header_always_inline int __inline_signbitf(float __x) {
>>> union { float __f; unsigned int __u; } __u;
>>> __u.__f = __x;
>>> return (int)(__u.__u >> 31);
>>> }
>>>
>> In C++ you could do: (int)((unsigned &)x >> 31)
> You /could/ write that, but it has undefined behaviour.
The first code has the same UB.
But that's pure theory.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 18:12 +0100 |
| Message-ID | <qudb5l$s7l$1@dont-email.me> |
| In reply to | #70826 |
On 30/12/2019 17:18, Bonita Montero wrote:
>>>> Want a better example? From math.h:
>>>>
>>>> __header_always_inline int __inline_signbitf(float __x) {
>>>> union { float __f; unsigned int __u; } __u;
>>>> __u.__f = __x;
>>>> return (int)(__u.__u >> 31);
>>>> }
>>>>
>
>>> In C++ you could do: (int)((unsigned &)x >> 31)
>
>> You /could/ write that, but it has undefined behaviour.
>
> The first code has the same UB.
Not at all.
The first code is in C, in a standard header. Type-punning via unions
is defined behaviour in C.
When you use it in C++, if it is part of the standard library then it is
part of the implementation - and can use any extension or additional
features provided by the compiler that is part of that implementation.
Many compilers - such as gcc (the likely compiler in this case) allow
type-punning in unions in C++, at least for POD types. That would make
it implementation-specific behaviour in an implementation-specific
header, which is fine.
Your code is undefined behaviour in C++, totally unrelated to
union-based type-punning, and /not/ supported by many compilers. Not
just in theory - but in practice also. Don't mess with changing types
through pointer (or, equivalently, reference) casting - it is undefined
behaviour and many compilers (including gcc, clang and msvc) /will/ make
you suffer for such language abuse.
> But that's pure theory.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 18:16 +0100 |
| Message-ID | <qudbck$ve5$1@news.albasani.net> |
| In reply to | #70830 |
> The first code is in C, in a standard header. > Type-punning via unions is defined behaviour in C. My code does the same.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 18:38 +0100 |
| Message-ID | <qudcni$58g$1@dont-email.me> |
| In reply to | #70831 |
On 30/12/2019 18:16, Bonita Montero wrote: >> The first code is in C, in a standard header. >> Type-punning via unions is defined behaviour in C. > > My code does the same. Your irritating habit of snipping too much in replies has confused you. Your code did not use "union".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-30 19:17 +0100 |
| Message-ID | <qudf0c$m8o$1@news.albasani.net> |
| In reply to | #70832 |
>>> The first code is in C, in a standard header. >>> Type-punning via unions is defined behaviour in C. >> My code does the same. > Your irritating habit of snipping too much in replies has confused you. > Your code did not use "union". Tell me the platform where my code does not do the same. There will never be any.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 20:55 +0100 |
| Message-ID | <qudkob$mpi$1@dont-email.me> |
| In reply to | #70834 |
On 30/12/2019 19:17, Bonita Montero wrote: >>>> The first code is in C, in a standard header. >>>> Type-punning via unions is defined behaviour in C. > >>> My code does the same. > >> Your irritating habit of snipping too much in replies has confused >> you. Your code did not use "union". > > Tell me the platform where my code does not do the same. > There will never be any. Sorry, wrong. When you write code that messes with the type used to access data, you fall foul of the type-based access rules of C and C++. You can only access data via an lvalue of appropriate type (a compatible type, or a char type). Anything else is not defined by the standards. And compilers use this for "type-based alias analysis" optimisations. You will find that often code such as yours will work as you expect, but occasionally it will not. Typically, simple test code will generate the results you think - but in more complex situations where code gets shuffled around, inlined, cloned, and otherwise manipulated, there will be occasions where the compiler can generate tighter code on the assumption that types like "int" and "float" never share the same address. Compilers with powerful optimisers, like gcc and clang, will be more likely to use such optimisations - but msvc does it too on occasion. Thus gcc and clang will warn you about that code, at least with a minimum of sensible options. I don't know if msvc will - I expect so, given appropriate flags. This is, obviously, independent of platform. (And again - it is /not/ the same thing as the union code. The clue is that code that uses unions for type-punning, will use the keyword "union". Your code does not.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 03:13 +0100 |
| Message-ID | <queas0$8po$1@news.albasani.net> |
| In reply to | #70836 |
>> Tell me the platform where my code does not do the same. >> There will never be any. > Sorry, wrong. > When you write code that messes with the type used to access data, you > fall foul of the type-based access rules of C and C++. You can only > access data via an lvalue of appropriate type (a compatible type, or a > char type). Anything else is not defined by the standards. There is no compiler and there won't be any compiler that behaves different here. You're not a practical programmer but a theorist.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 13:01 +0100 |
| Message-ID | <qufdaq$lde$1@dont-email.me> |
| In reply to | #70843 |
On 31/12/2019 03:13, Bonita Montero wrote:
>>> Tell me the platform where my code does not do the same.
>>> There will never be any.
>
>> Sorry, wrong.
>> When you write code that messes with the type used to access data, you
>> fall foul of the type-based access rules of C and C++. You can only
>> access data via an lvalue of appropriate type (a compatible type, or a
>> char type). Anything else is not defined by the standards.
>
> There is no compiler and there won't be any compiler that behaves
> different here.
> You're not a practical programmer but a theorist.
>
Again, you are wrong. Type-based alias optimisations are used on many
compilers, and they can give unexpected results from code that uses
inappropriate conversions like this. As I said, in simple test code you
often get the results that you'd expect if you did not know about the
effective type rules. But I have seen contrary results from MSVC, gcc
and clang - /all/ of these have type-based alias analysis optimisations
that can give you unexpected results when you don't understand (or
ignore) the rules of the language. This is not "just theory" - it is
practice. (It is not easy to get this effect on MSVC, but it does happen.)
It is so much "real world practice" that the Linux kernel is complied
with "-fno-strict-aliasing" to turn off type-based alias analysis -
because their code abuses types and accesses in a way that conflicts
with the standards.
It is incomprehensible to me how some people react with denial of
reality to things like this. It is fair enough to say "I wish C and C++
allowed casts like this" or "my code will only work on compilers like
gcc -fno-strict-aliasing because it messes with pointer types". But to
blindly say "I know this is against the rules of the language, but I'll
do it anyway because I think it should be allowed" takes a special kind
of stubborn stupidity.
If you want to write knowingly incorrect code, that's up to you. But
please do not recommend it to others.
Let's demonstrate with a simple example of type-based alias
optimisation. It's a little different from your example, because it's
simpler to demonstrate the issue without a lot of extra surrounding
code, and it can be handled simply in <https://godbolt.org>. And it
applies equally to C and C++.
int foo(int * px, float * py) {
int x = *px;
*py = 0;
return x + *px;
}
gcc -O2 -fno-strict-aliasing gives:
foo:
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rsi], 0x00000000
add eax, DWORD PTR [rdi]
ret
With that flag, the compiler adds semantics to the C (or C++) language
to allow accessing data via non-compatible pointers or references. That
means it has to re-read via px, just in case py pointed to the same address.
Without the special flag, you get:
foo:
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rsi], 0x00000000
add eax, eax
ret
It is more efficient code, based on the (valid) assumption that a
pointer to int and pointer to float can't refer to the same object.
MSVC /O2 gives:
int foo(int * __ptr64,float * __ptr64) PROC
; foo, COMDAT
mov r8d, DWORD PTR [rcx]
mov DWORD PTR [rdx], 0
mov eax, DWORD PTR [rcx]
add eax, r8d
ret 0
MSVC does not do this kind of type-based optimisation in this case, and
reads through px twice. Maybe I haven't used powerful enough
optimisation flags here.
ICC -O2 gives:
foo(int*, float*):
mov eax, DWORD PTR [rdi] #3.14
add eax, DWORD PTR [rdi] #5.17
mov DWORD PTR [rsi], 0 #4.6
ret
Bizarrely, icc re-reads via px, but does so out of order - giving code
that is less efficient than gcc but still dependent on type-based alias
analysis (and more efficient than gcc -fno-strict-aliasing).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 13:13 +0100 |
| Message-ID | <qufe15$p1q$1@news.albasani.net> |
| In reply to | #70857 |
> Again, you are wrong.
No, there isn't any compiler and there wont be ever any compiler
where what I wrote doesn't work.
.
> Type-based alias optimisations are used on many compilers, and
> they can give unexpected results from code that uses inappropriate
> conversions like this.
Not what I wrote: in this case the compiler does see the aliasing.
> Let's demonstrate with a simple example of type-based alias
> optimisation. It's a little different from your example, because it's
> simpler to demonstrate the issue without a lot of extra surrounding
> code, and it can be handled simply in <https://godbolt.org>. And it
> applies equally to C and C++.
> int foo(int * px, float * py) {
> int x = *px;
> *py = 0;
> return x + *px;
> }
That's a totally different issue.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 14:09 +0100 |
| Message-ID | <qufh9k$b9n$1@dont-email.me> |
| In reply to | #70860 |
On 31/12/2019 13:13, Bonita Montero wrote:
>> Again, you are wrong.
>
> No, there isn't any compiler and there wont be ever any compiler
> where what I wrote doesn't work.
This is not guaranteed. It won't work with the compiler/flag
combination I use, since it will be rejected as a fatal error when you
try to compile the code.
>
>> Type-based alias optimisations are used on many compilers, and
>> they can give unexpected results from code that uses inappropriate
>> conversions like this.
>
> Not what I wrote: in this case the compiler does see the aliasing.
It might - and it might not, depending on how code is re-arranged,
broken up, transferred around. And even if the compiler /does/ see the
aliasing, there is no guarantee it will honour it.
I fully agree that it is highly unlikely for a compiler to interpret the
exact code you wrote in any way other than the way you intended it. But
for serious programming, "highly unlikely" is not good enough.
Similar code, with the same fundamental error you made, could easily end
up interpreted differently.
And I totally fail to understand how you could think it's okay to break
the rules because you think "no one will notice if I break them just a
little bit".
Your code is wrong. Broken. A good compiler can see that and warn
about it.
>
>> Let's demonstrate with a simple example of type-based alias
>> optimisation. It's a little different from your example, because it's
>> simpler to demonstrate the issue without a lot of extra surrounding
>> code, and it can be handled simply in <https://godbolt.org>. And it
>> applies equally to C and C++.
>> int foo(int * px, float * py) {
>> int x = *px;
>> *py = 0;
>> return x + *px;
>> }
>
> That's a totally different issue.
>
No, it is the same issue. It is a different bit of code, because it is
easier to show the trouble it can cause, but it is the same underlying
issue - the same paragraph in the standards.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 14:12 +0100 |
| Message-ID | <qufhg9$fq4$1@news.albasani.net> |
| In reply to | #70864 |
>> No, there isn't any compiler and there wont be ever any compiler >> where what I wrote doesn't work. > This is not guaranteed. This de-facto guaranteed. > It won't work with the compiler/flag combination I use, .. This absolutely hasn't anything to do with the aliasing-options of the compiler; at least with the code I showed. > It might - and it might not, ... It will definitely, you compulsive pettifogging idiot. > I fully agree that it is highly unlikely for a compiler to interpret > the exact code you wrote in any way other than the way you intended it. Theres for sure a lot of code that is like what I showed so that no compiler-vendor can ignore this. >> That's a totally different issue. > No, it is the same issue. No, that's a different issue because of the lack of the opportunity to detect the aliasing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 15:39 +0100 |
| Message-ID | <qufmis$a3m$1@dont-email.me> |
| In reply to | #70865 |
On 31/12/2019 14:12, Bonita Montero wrote: > >>> No, there isn't any compiler and there wont be ever any compiler >>> where what I wrote doesn't work. > >> This is not guaranteed. > > This de-facto guaranteed. "de-facto" means it is /not/ guaranteed ! > >> It won't work with the compiler/flag combination I use, .. > > This absolutely hasn't anything to do with the aliasing-options > of the compiler; at least with the code I showed. The code you showed would not compile with the compiler and flags that I use. It is not a matter of it might generate unexpected code - it is a matter of failing to compile. And the flags I use here are not particularly unusual amongst people who care about code quality: gcc -O2 -Wall -Werror Guess what the fatal error message is? """ error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] """ Oh, in fact it /does/ have a something to do with the aliasing options of the compiler. The error comes because the compiler, with -O2, enables the "-fstrict-aliasing" option - it assumes you understand the C and C++ rules here, and optimises your code on that assumption. It is, of course, my choice to use the compiler in a way that minimises the risk of accidentally writing incorrect code. And if code quality is not an issue for you, then you can write whatever you want and turn off or ignore any warnings you get. But this is an example of a commonly used C++ implementation which fails to support the code you wrote. > >> It might - and it might not, ... > > It will definitely, you compulsive pettifogging idiot. > >> I fully agree that it is highly unlikely for a compiler to interpret >> the exact code you wrote in any way other than the way you intended it. > > Theres for sure a lot of code that is like what I showed so that no > compiler-vendor can ignore this. The compiler I use doesn't ignore it - with the options I use, it rejects it (this is entirely compliant with the standards - a compiler does not have to accept code with undefined behaviour). It also provides an option (-fno-strict-aliasing) to let people write code like yours if they want. I agree, compiler vendors should not ignore mistakes like this, and good compiler vendors do not ignore it. Bad compiler vendors quietly accept it, encouraging people to mistakenly think their code is fine. > >>> That's a totally different issue. > >> No, it is the same issue. > > No, that's a different issue because of the lack of the opportunity > to detect the aliasing. > Again, you are wrong. The principle - that you may not use inappropriate lvalue types for accessing data - is independent of what the compiler may know or not know. This is because the language does not specify what the compiler may or may not know. In some compilers, the compiler looks only at an expression at a time, and knows very little - in others, there is whole program optimisation allowing it to know aliasing information across units. That is why breaking these aliasing rules is undefined behaviour, and not a constraint (which would require the compiler to give a diagnostic) - compilers can, and should, issue a diagnostic if they can see unavoidable undefined behaviour, but the standards don't insist that compilers are that smart.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 15:45 +0100 |
| Message-ID | <qufmtr$29c$1@news.albasani.net> |
| In reply to | #70868 |
>>> This is not guaranteed. >> This de-facto guaranteed. > "de-facto" means it is /not/ guaranteed ! de-facto means practically, but not theoretically. >> This absolutely hasn't anything to do with the aliasing-options >> of the compiler; at least with the code I showed. > The code you showed would not compile with the compiler and flags that I > use. It will. > It is not a matter of it might generate unexpected code - it is a matter > of failing to compile. > And the flags I use here are not particularly unusual amongst people who > care about code quality: > gcc -O2 -Wall -Werror > Guess what the fatal error message is? Treating warnings as errors is not what the C++-standard mandates; that's compiler-specific. And no one uses -Wall practically because it generates a lot of nonsense-warnings and most libraries will not compile without a imense number of warnings. >> No, that's a different issue because of the lack of the opportunity >> to detect the aliasing. > Again, you are wrong. No, any compiler will detect the aliasing independent of any aliasing -specific compiler-optionns.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-12-31 15:22 +0000 |
| Message-ID | <bJJOF.202766$NM1.122075@fx38.am4> |
| In reply to | #70870 |
On 2019-12-31, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> This is not guaranteed. > >>> This de-facto guaranteed. > >> "de-facto" means it is /not/ guaranteed ! > > de-facto means practically, but not theoretically. Until someone decides otherwise. Anyway, compiling old C++ code boils done correcting mistakes like that... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 17:16 +0100 |
| Message-ID | <qufs80$kti$1@news.albasani.net> |
| In reply to | #70872 |
>> de-facto means practically, but not theoretically. > Until someone decides otherwise. Anyway, compiling old > C++ code boils done correcting mistakes like that... No one decides otherwise for that trivially to detect aliasing type. This would break a lot of code for sure.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 17:51 +0100 |
| Message-ID | <qufuaj$oup$1@dont-email.me> |
| In reply to | #70870 |
On 31/12/2019 15:45, Bonita Montero wrote: >>>> This is not guaranteed. > >>> This de-facto guaranteed. > >> "de-facto" means it is /not/ guaranteed ! > > de-facto means practically, but not theoretically. > Yes - and therefore /not/ guaranteed by the standards or any other actual /written/ information. Not that any of this applies to your code, anyway. You've written an expression that worked the way you expected in your tests. That's fine if you are writing code for one specific compiler with one specific set of flags, and you test appropriately - sometimes that is what you want in code. (This is not uncommon in my line of work - but I then claim "it works in this case, in these precise build circumstances" - not "it's de-facto", or "it's guaranteed to work".) >>> This absolutely hasn't anything to do with the aliasing-options >>> of the compiler; at least with the code I showed. > >> The code you showed would not compile with the compiler and flags that I >> use. > > It will. Why on earth would you deny that? > >> It is not a matter of it might generate unexpected code - it is a matter >> of failing to compile. >> And the flags I use here are not particularly unusual amongst people who >> care about code quality: >> gcc -O2 -Wall -Werror >> Guess what the fatal error message is? > > Treating warnings as errors is not what the C++-standard mandates; > that's compiler-specific. What part of "the compiler and flags that I use" made you think I was referring to the standards? The C++ (and C) standards make it clear that the accessing via the cast you had was undefined behaviour. A compiler is free to treat that as it wants - including halting compilation with an error, and also including generating code as though the access were allowed, and also including generating the result the programmer wanted while testing and quietly corrupting data once the program is deployed. > And no one uses -Wall practically because > it generates a lot of nonsense-warnings and most libraries will not > compile without a imense number of warnings. > Nonsense. No one uses "/Wall" (if that is the right option) on MSVC because it really means "enable all warnings supported by the compiler" and generates a great deal of noise for most code. Most gcc and clang users who see their compiler as a development tool and not just a dumb translator, use -Wall regularly - because there it means "enable a set of warnings appropriate for almost all good code". >>> No, that's a different issue because of the lack of the opportunity >>> to detect the aliasing. > >> Again, you are wrong. > > No, any compiler will detect the aliasing independent of any aliasing > -specific compiler-optionns. The aliasing abuse here is not compiler specific - it is in the standards. /Detection/ of the abuse, and how the code is otherwise treated, is compiler-specific because the standards give no instructions on how it is to be handled.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 17:59 +0100 |
| Message-ID | <qufuq5$f65$1@news.albasani.net> |
| In reply to | #70879 |
>> Treating warnings as errors is not what the C++-standard mandates; >> that's compiler-specific. > What part of "the compiler and flags that I use" made you think I was > referring to the standards? That's your personal taste and not C++. > The C++ (and C) standards make it clear that the accessing via the cast > you had was undefined behaviour. That doesn't matter if because all compilers support this trivial kind of aliasing. > A compiler is free to treat that as it wants - ... No one writes such a compiler because what I wrote is commond and the compiler-writers can't break common habits. > Nonsense. No one uses "/Wall" (if that is the right option) on MSVC > because it really means "enable all warnings supported by the compiler" > and generates a great deal of noise for most code. Most gcc and clang > users who see their compiler as a development tool and not just a dumb > translator, use -Wall regularly - because there it means "enable a set > of warnings appropriate for almost all good code". No, there are a lot of useless child-proof locks in the -Wall-warnings. > The aliasing abuse here is not compiler specific - it is in the > standards. ... The standards don't count in this specific case.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 18:21 +0100 |
| Message-ID | <qug028$3e2$1@dont-email.me> |
| In reply to | #70882 |
On 31/12/2019 17:59, Bonita Montero wrote: >>> Treating warnings as errors is not what the C++-standard mandates; >>> that's compiler-specific. > >> What part of "the compiler and flags that I use" made you think I was >> referring to the standards? > > That's your personal taste and not C++. What part of "the compiler and flags that I use" made you think it was something other than my personal choice? But it is still perfectly good for C++. The flags I use do not hinder good C++ code here - they only cause a compile-time error on the undefined behaviour in this case. > >> The C++ (and C) standards make it clear that the accessing via the >> cast you had was undefined behaviour. > > That doesn't matter if because all compilers support this trivial > kind of aliasing. Yes, it matters - it matters to people that want to write correct code, and not "I know this is crap, but it worked when I tried it" code. > >> A compiler is free to treat that as it wants - ... > > No one writes such a compiler because what I wrote is commond and > the compiler-writers can't break common habits. What you wrote is not particularly common, I think. And yes, people write compilers that take issue with it - I use such a compiler daily. (Do you think reality changes just because you deny it so often?) > >> Nonsense. No one uses "/Wall" (if that is the right option) on MSVC >> because it really means "enable all warnings supported by the >> compiler" and generates a great deal of noise for most code. Most gcc >> and clang users who see their compiler as a development tool and not >> just a dumb translator, use -Wall regularly - because there it means >> "enable a set of warnings appropriate for almost all good code". > > No, there are a lot of useless child-proof locks in the -Wall-warnings. > What compiler are you referring to here? I was taking about gcc, which has "-Wall" but no "-Wall-warnings". And yes, lots of people use it. Again, mindlessly denying reality will not convince anyone. >> The aliasing abuse here is not compiler specific - it is in the >> standards. ... > > The standards don't count in this specific case. > Right... That's because compilers implement C++ based on "Bonita says so" rules rather than the standards. I'll bear that in mind.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 18:35 +0100 |
| Message-ID | <qug0tu$8rd$1@news.albasani.net> |
| In reply to | #70889 |
>> That's your personal taste and not C++. > What part of "the compiler and flags that I use" made you think it was > something other than my personal choice? Those which make every warning an error; that's very uncommon and nerdish. >> That doesn't matter if because all compilers support this trivial >> kind of aliasing. > Yes, it matters - it matters to people that want to write correct code, > and not "I know this is crap, but it worked when I tried it" code. The code I have shown works with any compiler. > What you wrote is not particularly common, I think. You think that yout habits are the center of the world. >>> The aliasing abuse here is not compiler specific - it is in the >>> standards. ... >> The standards don't count in this specific case. > Right... > That's because compilers implement C++ based on "Bonita says so" > rules rather than the standards. I'll bear that in mind. No, what I wrot is simply common because it is very convenient over having a union.
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web