Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164141 > unrolled thread
| Started by | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| First post | 2021-12-31 11:02 +0100 |
| Last post | 2022-01-04 14:21 -0800 |
| Articles | 20 on this page of 180 — 23 participants |
Back to article view | Back to comp.lang.c
How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 11:02 +0100
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-31 12:33 +0000
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-31 12:33 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 14:24 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 15:00 +0100
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-31 11:38 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 20:49 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-31 18:37 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-01 17:48 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 05:51 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 15:59 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-21 16:19 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 16:51 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-21 12:08 -0500
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-21 18:14 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 18:25 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-21 20:53 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 22:22 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-22 13:05 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-22 13:53 +0100
Re: How to avoid an overflow during multiplication? Richard Damon <Richard@Damon-Family.org> - 2022-01-22 08:31 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-22 15:53 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-22 16:46 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-24 09:33 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-24 10:15 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-22 10:03 -0800
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-23 12:28 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-01-23 11:48 +0000
Re: How to avoid an overflow during multiplication? Öö Tiib <ootiib@hot.ee> - 2022-01-23 08:36 -0800
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-01-23 16:55 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-23 19:17 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-21 12:11 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 18:28 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-21 12:59 -0500
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-21 17:23 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 18:35 +0100
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-21 18:06 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-21 20:04 +0100
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-21 19:14 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 17:02 -0800
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-22 16:59 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-24 08:01 -0800
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 16:24 +0000
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 17:38 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-24 11:28 -0800
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 22:44 +0000
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-24 15:34 -0800
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 14:50 +0000
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-25 18:30 +0000
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 18:50 +0000
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-25 14:42 -0800
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 23:05 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-29 04:54 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-24 21:50 -0500
Re: How to avoid an overflow during multiplication? Manfred <invalid@invalid.add> - 2022-01-25 19:24 +0100
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 18:35 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-29 10:05 -0800
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-01-21 20:46 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 17:32 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-22 09:57 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-22 09:44 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-22 15:26 -0500
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-22 14:44 -0800
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 23:37 -0800
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-22 12:04 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-24 09:59 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-03 10:24 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-03 21:34 +0100
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-02-03 13:33 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-03 22:57 +0100
Re: How to avoid an overflow during multiplication? Vir Campestris <vir.campestris@invalid.invalid> - 2022-02-03 22:28 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-03 23:48 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-03 22:17 -0500
Re: How to avoid an overflow during multiplication? Öö Tiib <ootiib@hot.ee> - 2022-02-04 00:36 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-04 10:49 +0100
Re: How to avoid an overflow during multiplication? Öö Tiib <ootiib@hot.ee> - 2022-02-04 09:03 -0800
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 00:52 -0800
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-07 10:03 +0000
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 11:22 +0000
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-07 14:58 +0000
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 09:06 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-04 09:44 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-04 11:06 +0100
Re: How to avoid an overflow during multiplication? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-02-04 05:53 -0800
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-04 15:27 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-04 15:53 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-05 14:11 +0100
Re: How to avoid an overflow during multiplication? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-02-05 09:15 -0800
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-04 19:38 +0000
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-05 14:23 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-05 15:16 +0000
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-05 17:27 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-05 16:41 +0000
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-06 12:01 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-06 13:24 +0000
Re: How to avoid an overflow during multiplication? Manfred <invalid@add.invalid> - 2022-02-05 23:18 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-06 00:11 -0500
Re: How to avoid an overflow during multiplication? Manfred <noname@add.invalid> - 2022-02-06 18:43 +0100
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-06 15:03 +0100
Re: How to avoid an overflow during multiplication? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-05 09:38 -0800
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-05 17:57 +0000
Re: How to avoid an overflow during multiplication? Richard Damon <Richard@Damon-Family.org> - 2022-02-05 13:29 -0500
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-06 15:15 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-06 14:34 +0000
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-02-06 12:56 -0800
Re: How to avoid an overflow during multiplication? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-05 09:50 -0800
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-02-05 18:09 +0000
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-04 11:06 -0500
Re: How to avoid an overflow during multiplication? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-02-04 09:02 -0800
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-02-04 11:12 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-04 19:36 -0500
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2022-02-04 16:38 +0000
Re: How to avoid an overflow during multiplication? Vir Campestris <vir.campestris@invalid.invalid> - 2022-02-06 22:08 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-07 09:11 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-07 09:13 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-07 09:14 +0100
Re: How to avoid an overflow during multiplication? Vir Campestris <vir.campestris@invalid.invalid> - 2022-02-07 21:42 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-07 23:43 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-03 22:35 -0500
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 21:14 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-02-05 11:40 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-05 13:46 -0500
Re: How to avoid an overflow during multiplication? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-05 23:30 +0000
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-06 00:17 -0500
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-02-06 15:21 +0100
Re: How to avoid an overflow during multiplication? dave_thompson_2@comcast.net - 2022-05-14 12:34 -0400
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-15 07:19 -0700
Re: How to avoid an overflow during multiplication? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-14 12:04 -0700
Re: How to avoid an overflow during multiplication? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-14 12:15 -0700
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-15 07:25 -0700
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-31 15:41 -0800
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2021-12-31 16:17 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 16:22 +0100
Re: How to avoid an overflow during multiplication? Guillaume <message@bottle.org> - 2021-12-31 19:35 +0100
Re: How to avoid an overflow during multiplication? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-31 13:53 +0100
Re: How to avoid an overflow during multiplication? Öö Tiib <ootiib@hot.ee> - 2021-12-31 05:10 -0800
Re: How to avoid an overflow during multiplication? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-31 14:25 +0100
Re: How to avoid an overflow during multiplication? scott@slp53.sl.home (Scott Lurndal) - 2021-12-31 16:16 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 17:32 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 14:31 +0100
Re: How to avoid an overflow during multiplication? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-31 14:37 +0100
Re: How to avoid an overflow during multiplication? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-31 15:21 -0800
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-01 13:50 +0100
Re: How to avoid an overflow during multiplication? Michael S <already5chosen@yahoo.com> - 2022-01-01 10:31 -0800
Re: How to avoid an overflow during multiplication? Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-01 20:03 +0100
Re: How to avoid an overflow during multiplication? Bart <bc@freeuk.com> - 2022-01-01 19:18 +0000
Re: How to avoid an overflow during multiplication? David Brown <david.brown@hesbynett.no> - 2022-01-02 13:38 +0100
Re: How to avoid an overflow during multiplication? Michael S <already5chosen@yahoo.com> - 2021-12-31 05:37 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 14:55 +0100
Re: How to avoid an overflow during multiplication? Michael S <already5chosen@yahoo.com> - 2021-12-31 06:12 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 16:11 +0100
Re: How to avoid an overflow during multiplication? Manfred <noname@add.invalid> - 2021-12-31 20:54 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 21:19 +0100
Re: How to avoid an overflow during multiplication? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-31 15:19 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 16:24 +0100
Re: How to avoid an overflow during multiplication? Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-31 15:13 +0000
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 17:00 +0100
Re: How to avoid an overflow during multiplication? Richard Damon <Richard@Damon-Family.org> - 2021-12-31 12:16 -0500
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-31 10:28 -0800
Re: How to avoid an overflow during multiplication? pa@see.signature.invalid (Pierre Asselin) - 2021-12-31 20:18 +0000
Re: How to avoid an overflow during multiplication? Manfred <noname@add.invalid> - 2021-12-31 21:27 +0100
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 21:39 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-20 19:41 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-31 21:31 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-31 17:39 -0800
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-02 09:08 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-31 19:08 -0500
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-31 19:45 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-01 18:24 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-01 19:31 -0500
Re: How to avoid an overflow during multiplication? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-01-01 16:53 -0800
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-04 00:32 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-04 09:43 +0100
Re: How to avoid an overflow during multiplication? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-04 07:20 -0800
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-04 18:19 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-04 10:50 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-04 17:37 +0100
Re: How to avoid an overflow during multiplication? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-04 15:01 -0500
Re: How to avoid an overflow during multiplication? Mateusz Viste <mateusz@xyz.invalid> - 2022-01-04 21:45 +0100
Re: How to avoid an overflow during multiplication? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-01-04 14:21 -0800
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-07 09:06 -0800 |
| Message-ID | <86pmnyip2o.fsf@linuxsc.com> |
| In reply to | #164848 |
Bart <bc@freeuk.com> writes: > On 07/02/2022 08:52, Tim Rentsch wrote: > >> Using _Bool works here too: >> >> _Bool p_valid = p; >> >> The conversion to _Bool converts null pointers to 0, and non-null >> pointers to 1. > > This leads to: > > _Bool b; > > b = &b; > > which looks unintuitive. Usually the LHS would be of type T, then the > RHS would have the incompatible type T* It is querelis gratia querimonia as usual, I see. (With apologies to my high school Latin teacher. I never was good at Latin.)
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-04 09:44 +0100 |
| Message-ID | <stip0g$1aii$1@gioia.aioe.org> |
| In reply to | #164766 |
2022-02-03 at 22:17 -0500, James Kuyper wrote: > Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++ > standard 7.3.14), type always generate only one of two possible > values, which is what you need for true boolean semantics. That if > very definitely not the case for int_fast8_t. int_fast8_t (just like any other integer type) can be either zero or non-zero. Why does the exact value of "not zero" matter to you? I mean, what kind of practical problems can be solved with _Bool? Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-04 11:06 +0100 |
| Message-ID | <stitqj$23u$1@dont-email.me> |
| In reply to | #164772 |
On 04/02/2022 09:44, Mateusz Viste wrote: > 2022-02-03 at 22:17 -0500, James Kuyper wrote: >> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++ >> standard 7.3.14), type always generate only one of two possible >> values, which is what you need for true boolean semantics. That if >> very definitely not the case for int_fast8_t. > > int_fast8_t (just like any other integer type) can be either zero or > non-zero. Why does the exact value of "not zero" matter to you? I mean, > what kind of practical problems can be solved with _Bool? > There are, I think, two main differences here. First is the logical one. A "bool" is a type that can be either "true" or "false". This is clearer, simpler, and more closely models the programmer's intent than storing a 0 or a 1 in a small integer type. If I read : bool isThingValid(const thing * p) I know the result will be either "true" or "false". If I read: int_fast8_t isThingValid(const thing * p) I am left wondering if the thing might be partially valid, with a scale. I wonder /why/ the programmer wanted an arithmetic integer type aimed at high-speed small integer ranges. Will the function always return 0 or 1? Does it consider non-zero as "true" ? Is it going to give a negative value if there is an error? Did the programmer really want to use an enumerated type but is converting to int_fast8_t to save space somehow? Prior to C99, it was extremely common in C programming to define your own Boolean type. Mostly this was done by something like: typedef int bool; #define true 1 #define false 0 But sometimes signed or unsigned char was used, sometimes an enumerated type, sometimes slightly different names or capitalisations were used. A few would give different values for "true" and "false" (I've never really understood why). Some would define "true" as "(0 == 0)" or similar, in the mistaken belief that the result might vary by compiler. It is hugely simpler, clearer and more portable to stick to the one standard type. Secondly, there are technical differences. The conversion of an integer "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that "b" is either 0 or 1 - and the compiler can use that knowledge for optimisation (as can the programmer). This can mean some operations (such as conversion from an integer) may be less efficient, but other operations (such as logical operations) are more efficient. Overall, it is usually a win. Of course you can write your C code without ever needing the type _Bool. But you can write /better/ code, in a clearer, easier and more efficient manner if you use it when appropriate. (In C++, "bool" and its distinction from other integer types is hugely more important.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-02-04 05:53 -0800 |
| Message-ID | <46fd23b2-d691-4742-b387-f66d071463a7n@googlegroups.com> |
| In reply to | #164774 |
On Friday, 4 February 2022 at 10:06:42 UTC, David Brown wrote: > On 04/02/2022 09:44, Mateusz Viste wrote: > > 2022-02-03 at 22:17 -0500, James Kuyper wrote: > >> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++ > >> standard 7.3.14), type always generate only one of two possible > >> values, which is what you need for true boolean semantics. That if > >> very definitely not the case for int_fast8_t. > > > > int_fast8_t (just like any other integer type) can be either zero or > > non-zero. Why does the exact value of "not zero" matter to you? I mean, > > what kind of practical problems can be solved with _Bool? > > > There are, I think, two main differences here. > > First is the logical one. A "bool" is a type that can be either "true" > or "false". This is clearer, simpler, and more closely models the > programmer's intent than storing a 0 or a 1 in a small integer type. If > I read : > > bool isThingValid(const thing * p) > > I know the result will be either "true" or "false". > > > If I read: > > int_fast8_t isThingValid(const thing * p) > > I am left wondering if the thing might be partially valid, with a scale. > I wonder /why/ the programmer wanted an arithmetic integer type > Yes. If a function returns values that are logically either true/false, then the best way to document this is to return a boolean. However if it takes values which are either true.false, then you have this problem void SetSpinEdit(SpinEdit *control, double value, bool clamp, bool roundtoprecison, bool propagatemessage); All looks reasonable. A SpinEdit is obviously some GUI widget that displays a real value. The second parameter is the value it is set to. "clamp" must mean that the control has "maximum" and "minimum" values and we want to honour those in case our value is out of range. "roundtoprecision" probably means that the control show, for example, two places after the decimal point, and if we pass 1.234 we expect "1.23" to be displayed and the internal value to be as close to 1.23 as floating point will allow. "propagatemessage" probaby means that the control has a callback associated with it when the user enters a value, and we want that callback to be called. However when you see this. double height = fabs(maximumvalue(x, N)); // Maintainer's comment. Bug in this test here ? if (height != GetSpinEdit(height_spn)) SetSpnEdit(height_spn, height, true, false, false); It's far less obvious what is going on.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-04 15:27 +0100 |
| Message-ID | <stjd4t$722$1@dont-email.me> |
| In reply to | #164775 |
On 04/02/2022 14:53, Malcolm McLean wrote: > On Friday, 4 February 2022 at 10:06:42 UTC, David Brown wrote: >> On 04/02/2022 09:44, Mateusz Viste wrote: >>> 2022-02-03 at 22:17 -0500, James Kuyper wrote: >>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++ >>>> standard 7.3.14), type always generate only one of two possible >>>> values, which is what you need for true boolean semantics. That if >>>> very definitely not the case for int_fast8_t. >>> >>> int_fast8_t (just like any other integer type) can be either zero or >>> non-zero. Why does the exact value of "not zero" matter to you? I mean, >>> what kind of practical problems can be solved with _Bool? >>> >> There are, I think, two main differences here. >> >> First is the logical one. A "bool" is a type that can be either "true" >> or "false". This is clearer, simpler, and more closely models the >> programmer's intent than storing a 0 or a 1 in a small integer type. If >> I read : >> >> bool isThingValid(const thing * p) >> >> I know the result will be either "true" or "false". >> >> >> If I read: >> >> int_fast8_t isThingValid(const thing * p) >> >> I am left wondering if the thing might be partially valid, with a scale. >> I wonder /why/ the programmer wanted an arithmetic integer type >> > Yes. If a function returns values that are logically either true/false, then the > best way to document this is to return a boolean. > > However if it takes values which are either true.false, then you have this > problem > > void SetSpinEdit(SpinEdit *control, double value, bool clamp, bool roundtoprecison, bool propagatemessage); > > All looks reasonable. A SpinEdit is obviously some GUI widget that displays a real value. The second parameter > is the value it is set to. "clamp" must mean that the control has "maximum" and "minimum" values and > we want to honour those in case our value is out of range. "roundtoprecision" probably means that > the control show, for example, two places after the decimal point, and if we pass 1.234 we expect "1.23" > to be displayed and the internal value to be as close to 1.23 as floating point will allow. "propagatemessage" > probaby means that the control has a callback associated with it when the user enters a value, and we want > that callback to be called. > > However when you see this. > > double height = fabs(maximumvalue(x, N)); > // Maintainer's comment. Bug in this test here ? > if (height != GetSpinEdit(height_spn)) > SetSpnEdit(height_spn, height, true, false, false); > > It's far less obvious what is going on. > That is a completely separate issue, and nothing to do with the question, which was "what advantages are there to using _Bool over an plain integer type?". Yes, it's hard to see what SetSpnEdit(height_spn, height, true, false, false); is doing. But you don't make anything better by writing SetSpnEdit(height_spn, height, 1, 0, 0); We could discuss ways to handle such paramaters in a clearer or less error-prone way, but that would be a completely different discussion and there is little in the improvements of C99 over C90 that affect it.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-04 15:53 +0100 |
| Message-ID | <stjele$1hsd$1@gioia.aioe.org> |
| In reply to | #164776 |
2022-02-04 at 15:27 +0100, David Brown wrote: > That is a completely separate issue, and nothing to do with the > question, which was "what advantages are there to using _Bool over an > plain integer type?". I think that in a vicious way, it is not separate. > Yes, it's hard to see what > SetSpnEdit(height_spn, height, true, false, false); > > is doing. But you don't make anything better by writing > SetSpnEdit(height_spn, height, 1, 0, 0); If I would be a user of _Bool, I'd be very tempted to use the first form (and end up with a hardly readable line). Since I do not use _Bool, I prefer doing this: #define FLAG_SETSPN_CLAMP 0x01 #define FLAG_SETSPN_ROUNDTOPREC 0x02 #define FLAG_SETSPN_PROPAGMSG 0x04 SetSpnEdit(height_spn, height, FLAG_SETSPN_CLAMP); You will say that the same can be done with having _Bool available (and not using it, in this specific case), and you will be obviously right. I guess it's a vicious side effect of the human mind - "if I have a hammer, then everything looks like nails". :-) Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-05 14:11 +0100 |
| Message-ID | <stlt2u$q62$1@dont-email.me> |
| In reply to | #164777 |
On 04/02/2022 15:53, Mateusz Viste wrote: > 2022-02-04 at 15:27 +0100, David Brown wrote: >> That is a completely separate issue, and nothing to do with the >> question, which was "what advantages are there to using _Bool over an >> plain integer type?". > > I think that in a vicious way, it is not separate. > >> Yes, it's hard to see what >> SetSpnEdit(height_spn, height, true, false, false); >> >> is doing. But you don't make anything better by writing >> SetSpnEdit(height_spn, height, 1, 0, 0); > > If I would be a user of _Bool, I'd be very tempted to use the first form > (and end up with a hardly readable line). I think you need to work on your temptation issues. When a language supports a feature, you are not /required/ to use it just because it is there. There are perhaps a dozen different ways to make the call to SetSpnEdit clearer and safer - none of them are in any way broken by the existence of "_Bool". > I guess it's a vicious side effect of the human mind - "if I have a > hammer, then everything looks like nails". :-) > You seem to be limiting yourself severely as a programmer. How you code is of course up to you, but please do not assume all programmers are going to see things that way. And your analogy is all wrong. You are claiming that because you only have a hammer (int), you are better equipped to invent a spanner when you need it than people who also have access to a screwdriver (_Bool). There is an argument to be made that the power of a programming language comes from what it stops you from doing just as much as from what it allows you to do, and that more features and possibilities allows for more misuse as well as more good usage. I really don't think C99 comes anywhere close to having too many features as a language. Historically, many of the new features of C99 were taken from gcc (and other compilers) extensions to C90 (such as "inline", C++ comments, and mixing statements and declarations), or as standardisations of existing common practices (such as size-specific integer types and boolean types). To a fair extent, C99 was a standardisation of the language people were already using for C programming.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-02-05 09:15 -0800 |
| Message-ID | <f2c562fa-cf23-4cb3-90b1-d18b2711d561n@googlegroups.com> |
| In reply to | #164792 |
On Saturday, 5 February 2022 at 13:12:32 UTC, David Brown wrote: > On 04/02/2022 15:53, Mateusz Viste wrote: > > 2022-02-04 at 15:27 +0100, David Brown wrote: > >> That is a completely separate issue, and nothing to do with the > >> question, which was "what advantages are there to using _Bool over an > >> plain integer type?". > > > > I think that in a vicious way, it is not separate. > > > >> Yes, it's hard to see what > >> SetSpnEdit(height_spn, height, true, false, false); > >> > >> is doing. But you don't make anything better by writing > >> SetSpnEdit(height_spn, height, 1, 0, 0); > > > > If I would be a user of _Bool, I'd be very tempted to use the first form > > (and end up with a hardly readable line). > I think you need to work on your temptation issues. When a language > supports a feature, you are not /required/ to use it just because it is > there. There are perhaps a dozen different ways to make the call to > SetSpnEdit clearer and safer - none of them are in any way broken by the > existence of "_Bool". > > I guess it's a vicious side effect of the human mind - "if I have a > > hammer, then everything looks like nails". :-) > > > You seem to be limiting yourself severely as a programmer. How you code > is of course up to you, but please do not assume all programmers are > going to see things that way. > > And your analogy is all wrong. You are claiming that because you only > have a hammer (int), you are better equipped to invent a spanner when > you need it than people who also have access to a screwdriver (_Bool). > > > There is an argument to be made that the power of a programming language > comes from what it stops you from doing just as much as from what it > allows you to do, and that more features and possibilities allows for > more misuse as well as more good usage. > Yes. In C you can't refer to anything outside the source file, unless you import it via a header or declare it "extern" in that source file. That's a good restriction that keeps code modular. You can't use non-Latin identifiers, which is another good rule, because most educated people can read Latin script, but most programmers can't read most of the other alphabets in existence. You could enforce a rule that a function cannot take more than one boolean parameter. That would prevent a castastophe such as SetSpnEdit. But language standards committees are reluctant to pass stylistic rules like that. Goto is considered harmful. So some languages disallowed it. However it's often had to be put back in, because automatic code generators which are banned from using goto are harder to write. That's an example of how improving a language by removing abiliites can be double-edged.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-04 19:38 +0000 |
| Message-ID | <stjvbo$dmc$1@dont-email.me> |
| In reply to | #164774 |
On 04/02/2022 10:06, David Brown wrote:
> On 04/02/2022 09:44, Mateusz Viste wrote:
>> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>>> standard 7.3.14), type always generate only one of two possible
>>> values, which is what you need for true boolean semantics. That if
>>> very definitely not the case for int_fast8_t.
>>
>> int_fast8_t (just like any other integer type) can be either zero or
>> non-zero. Why does the exact value of "not zero" matter to you? I mean,
>> what kind of practical problems can be solved with _Bool?
>>
>
> There are, I think, two main differences here.
>
> First is the logical one. A "bool" is a type that can be either "true"
> or "false". This is clearer, simpler, and more closely models the
> programmer's intent than storing a 0 or a 1 in a small integer type. If
> I read :
>
> bool isThingValid(const thing * p)
>
> I know the result will be either "true" or "false".
>
>
> If I read:
>
> int_fast8_t isThingValid(const thing * p)
>
> I am left wondering if the thing might be partially valid, with a scale.
> I wonder /why/ the programmer wanted an arithmetic integer type aimed
> at high-speed small integer ranges. Will the function always return 0
> or 1? Does it consider non-zero as "true" ? Is it going to give a
> negative value if there is an error? Did the programmer really want to
> use an enumerated type but is converting to int_fast8_t to save space
> somehow?
>
> Prior to C99, it was extremely common in C programming to define your
> own Boolean type. Mostly this was done by something like:
>
> typedef int bool;
> #define true 1
> #define false 0
>
> But sometimes signed or unsigned char was used, sometimes an enumerated
> type, sometimes slightly different names or capitalisations were used.
> A few would give different values for "true" and "false" (I've never
> really understood why). Some would define "true" as "(0 == 0)" or
> similar, in the mistaken belief that the result might vary by compiler.
>
> It is hugely simpler, clearer and more portable to stick to the one
> standard type.
>
>
> Secondly, there are technical differences. The conversion of an integer
> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
> "b" is either 0 or 1 - and the compiler can use that knowledge for
> optimisation (as can the programmer). This can mean some operations
> (such as conversion from an integer) may be less efficient, but other
> operations (such as logical operations) are more efficient. Overall, it
> is usually a win.
You're never really quite sure what's happening with _Bool.
There's little control over its size. And in A program like this:
union {
_Bool a;
unsigned char b;
} x;
x.b=0x55;
printf("A= %X\n", x.a);
printf("B= %X\n", x.b);
if (x.a == true) puts("A is True");
if (x.a == false) puts("A is False");
if (x.a != true && x.a != false) puts("A is neither True nor False");
different compilers show different results, including this from gcc -O0:
A= 55
B= 55
A is True
A is False
A is neither True nor False
MSVC shows this:
A= 55
B= 55
A is neither True nor False
while Clang, and gcc -O3, displays:
A= 1
B= 55
A is True
You can probably claim this is due to UB or whatever, but the fact
remains that using regular int types, the results will be consistent and
predictable across all compilers. It /is/ possible for the byte value
that usually represents a bool type to be set something that is neither
true (1) or false (0).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-05 14:23 +0100 |
| Message-ID | <stltoc$u8l$1@dont-email.me> |
| In reply to | #164786 |
On 04/02/2022 20:38, Bart wrote:
> On 04/02/2022 10:06, David Brown wrote:
>> Secondly, there are technical differences. The conversion of an integer
>> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>> optimisation (as can the programmer). This can mean some operations
>> (such as conversion from an integer) may be less efficient, but other
>> operations (such as logical operations) are more efficient. Overall, it
>> is usually a win.
>
> You're never really quite sure what's happening with _Bool.
>
> There's little control over its size. And in A program like this:
>
> union {
> _Bool a;
> unsigned char b;
> } x;
>
> x.b=0x55;
> printf("A= %X\n", x.a);
> printf("B= %X\n", x.b);
>
<snip>
> You can probably claim this is due to UB or whatever, but the fact
> remains that using regular int types, the results will be consistent and
> predictable across all compilers. It /is/ possible for the byte value
> that usually represents a bool type to be set something that is neither
> true (1) or false (0).
>
It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
you care.) It is also common sense. A _Bool contains either 0 or 1 -
any other value is invalid and can't be achieved without extraordinary
effort designed purely to make bad code.
Yes, you know /exactly/ what is happening with _Bool - write sane code,
and you get the results you expect. Write code with clear and
intentional errors with the sole intention of getting inconsistent
results, and you get exactly what you expect.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-05 15:16 +0000 |
| Message-ID | <stm4co$8r8$1@dont-email.me> |
| In reply to | #164793 |
On 05/02/2022 13:23, David Brown wrote:
> On 04/02/2022 20:38, Bart wrote:
>> On 04/02/2022 10:06, David Brown wrote:
>
>>> Secondly, there are technical differences. The conversion of an integer
>>> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>> optimisation (as can the programmer). This can mean some operations
>>> (such as conversion from an integer) may be less efficient, but other
>>> operations (such as logical operations) are more efficient. Overall, it
>>> is usually a win.
>>
>> You're never really quite sure what's happening with _Bool.
>>
>> There's little control over its size. And in A program like this:
>>
>> union {
>> _Bool a;
>> unsigned char b;
>> } x;
>>
>> x.b=0x55;
>> printf("A= %X\n", x.a);
>> printf("B= %X\n", x.b);
>>
>
> <snip>
>
>> You can probably claim this is due to UB or whatever, but the fact
>> remains that using regular int types, the results will be consistent and
>> predictable across all compilers. It /is/ possible for the byte value
>> that usually represents a bool type to be set something that is neither
>> true (1) or false (0).
>>
>
> It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
> you care.) It is also common sense. A _Bool contains either 0 or 1 -
> any other value is invalid and can't be achieved without extraordinary
> effort designed purely to make bad code.
>
> Yes, you know /exactly/ what is happening with _Bool - write sane code,
> and you get the results you expect. Write code with clear and
> intentional errors with the sole intention of getting inconsistent
> results, and you get exactly what you expect.
My point is exactly that you don't know what's going on, if not because
it's UB, it's because it's implementation defined or for some other
weird reason. Take this:
_Bool a=0;
for (int i=0; i<10; ++i){
printf("%d ",a);
++a;
}
What will be the output? For ++a, it's:
0 1 1 1 1 1 ...
But for --a it's:
0 1 0 1 0 1 ...
(With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
Try this:
a = 1;
++a;
--a;
Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
increments, and now the result is 1.
_Bool has special semantics compared with int, yet the language still
allows you to do all things associated with int.
What is type result type of !!? It is int, not _Bool. _Bool is a
half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
values of int, or 0 and non-zero, then I know exactly where I'm at.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-05 17:27 +0100 |
| Message-ID | <stm8i0$422$1@dont-email.me> |
| In reply to | #164794 |
On 05/02/2022 16:16, Bart wrote:
> On 05/02/2022 13:23, David Brown wrote:
>> On 04/02/2022 20:38, Bart wrote:
>>> On 04/02/2022 10:06, David Brown wrote:
>>
>>>> Secondly, there are technical differences. The conversion of an
>>>> integer
>>>> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>> optimisation (as can the programmer). This can mean some operations
>>>> (such as conversion from an integer) may be less efficient, but other
>>>> operations (such as logical operations) are more efficient.
>>>> Overall, it
>>>> is usually a win.
>>>
>>> You're never really quite sure what's happening with _Bool.
>>>
>>> There's little control over its size. And in A program like this:
>>>
>>> union {
>>> _Bool a;
>>> unsigned char b;
>>> } x;
>>>
>>> x.b=0x55;
>>> printf("A= %X\n", x.a);
>>> printf("B= %X\n", x.b);
>>>
>>
>> <snip>
>>
>>> You can probably claim this is due to UB or whatever, but the fact
>>> remains that using regular int types, the results will be consistent and
>>> predictable across all compilers. It /is/ possible for the byte value
>>> that usually represents a bool type to be set something that is neither
>>> true (1) or false (0).
>>>
>>
>> It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
>> you care.) It is also common sense. A _Bool contains either 0 or 1 -
>> any other value is invalid and can't be achieved without extraordinary
>> effort designed purely to make bad code.
>>
>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>> and you get the results you expect. Write code with clear and
>> intentional errors with the sole intention of getting inconsistent
>> results, and you get exactly what you expect.
>
> My point is exactly that you don't know what's going on, if not because
> it's UB, it's because it's implementation defined or for some other
> weird reason. Take this:
>
> _Bool a=0;
>
> for (int i=0; i<10; ++i){
> printf("%d ",a);
> ++a;
> }
>
> What will be the output? For ++a, it's:
>
> 0 1 1 1 1 1 ...
++a means (a += 1), which in turn means (a = a + 1). The boolean is
converted to an int (either 0 or 1), and 1 is added giving either 1 or
2. Conversion back to _Bool is on the basis of comparison to 0 - since
neither 1 nor 2 compares equal to 0, the result of "++a" will always
leave "a" as "true".
>
> But for --a it's:
>
> 0 1 0 1 0 1 ...
Similar reasoning - if "a" is currently "true", then after "--a" it is
left as "false". If "a" is currently "false", then "a = a - 1" will
give "a = -1", and thus set "a" to "true" (1).
It's not hard, not UB, not unexpected. (It is also almost certainly not
found in real code, which is why compilers like gcc with "-Wall" will
warn you that it's probably a mistake in your code. And in C++, it is
not allowed at all.)
>
> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
MSVC is primarily a C++ compiler, not a C compiler. I don't have access
to it other than via <https://godbolt.org>, and there it is only C++.
But almost certainly, you have made an error - it seems far more likely
than supposing MS failed to correctly implement _Bool in C.
For the "lesser compilers", you are clearly using an "int", not a "_Bool".
>
> Try this:
>
> a = 1;
> ++a;
> --a;
>
> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
> increments, and now the result is 1.
"_Bool" is not "int". Why would you think it acts like it?
>
> _Bool has special semantics compared with int, yet the language still
> allows you to do all things associated with int.
>
> What is type result type of !!? It is int, not _Bool. _Bool is a
> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
> values of int, or 0 and non-zero, then I know exactly where I'm at.
The logical and relational operators in C evaluate to "int", values 0 or
1, preceding the introduction of _Bool to the language.
The fact that you personally get confused about _Bool and don't
understand what it is and how it is defined, does not mean that it is
unclear, confusing, imprecise, or that anyone else fails to comprehend it.
However, now you know the rules that apply even when doing something as
deliberately unrealistic and pointless as incrementing or decrementing a
boolean variable. So you can no longer claim that you don't understand
it, or are not sure what is going on, and can now happily make use of
this extremely useful type.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-05 16:41 +0000 |
| Message-ID | <stm9ci$9k6$1@dont-email.me> |
| In reply to | #164795 |
On 05/02/2022 16:27, David Brown wrote: > On 05/02/2022 16:16, Bart wrote: > The fact that you personally get confused about _Bool and don't > understand what it is and how it is defined, does not mean that it is > unclear, confusing, imprecise, or that anyone else fails to comprehend it. > > However, now you know the rules that apply even when doing something as > deliberately unrealistic and pointless as incrementing or decrementing a > boolean variable. So you can no longer claim that you don't understand > it, or are not sure what is going on, and can now happily make use of > this extremely useful type. OK, so I see _Bool used in APIs which I might want to call via an FFI. Which more universal type is most likely to correspond to it? What are the actual values I can expect to see across all bits? What assumptions can I make? I'd quite like to know those answers when coding in C too!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-06 12:01 +0100 |
| Message-ID | <sto9pe$lbp$1@dont-email.me> |
| In reply to | #164796 |
On 05/02/2022 17:41, Bart wrote: > On 05/02/2022 16:27, David Brown wrote: >> On 05/02/2022 16:16, Bart wrote: > >> The fact that you personally get confused about _Bool and don't >> understand what it is and how it is defined, does not mean that it is >> unclear, confusing, imprecise, or that anyone else fails to comprehend >> it. >> >> However, now you know the rules that apply even when doing something as >> deliberately unrealistic and pointless as incrementing or decrementing a >> boolean variable. So you can no longer claim that you don't understand >> it, or are not sure what is going on, and can now happily make use of >> this extremely useful type. > > OK, so I see _Bool used in APIs which I might want to call via an FFI. > > Which more universal type is most likely to correspond to it? What are > the actual values I can expect to see across all bits? What assumptions > can I make? > > I'd quite like to know those answers when coding in C too! When calling an API that takes a _Bool parameter, you follow whatever the ABI for the platform says. I would expect that in most cases (I don't know of any exceptions, but I haven't looked - and I'd be glad to hear of them), a _Bool takes the same space and ABI conventions as an unsigned char. So you can simply pass an unsigned char with value 0 or 1. But you do have to make sure it is either 0 or 1, nothing else. When writing an FFI handler, /you/ are responsible for finding, reading and understanding the appropriate ABI documents. C "_Bool" and C++ "bool" will be included there.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-06 13:24 +0000 |
| Message-ID | <stoi66$huv$1@dont-email.me> |
| In reply to | #164812 |
On 06/02/2022 11:01, David Brown wrote: > On 05/02/2022 17:41, Bart wrote: >> On 05/02/2022 16:27, David Brown wrote: >>> On 05/02/2022 16:16, Bart wrote: >> >>> The fact that you personally get confused about _Bool and don't >>> understand what it is and how it is defined, does not mean that it is >>> unclear, confusing, imprecise, or that anyone else fails to comprehend >>> it. >>> >>> However, now you know the rules that apply even when doing something as >>> deliberately unrealistic and pointless as incrementing or decrementing a >>> boolean variable. So you can no longer claim that you don't understand >>> it, or are not sure what is going on, and can now happily make use of >>> this extremely useful type. >> >> OK, so I see _Bool used in APIs which I might want to call via an FFI. >> >> Which more universal type is most likely to correspond to it? What are >> the actual values I can expect to see across all bits? What assumptions >> can I make? >> >> I'd quite like to know those answers when coding in C too! > > When calling an API that takes a _Bool parameter, you follow whatever > the ABI for the platform says. I would expect that in most cases (I > don't know of any exceptions, but I haven't looked - and I'd be glad to > hear of them), a _Bool takes the same space and ABI conventions as an > unsigned char. So you can simply pass an unsigned char with value 0 or > 1. But you do have to make sure it is either 0 or 1, nothing else. > > When writing an FFI handler, /you/ are responsible for finding, reading > and understanding the appropriate ABI documents. C "_Bool" and C++ > "bool" will be included there. The Win64 ABI mentions little about the actual types of primitives, which is as it should be. It's mainly about sizes, and whether they are floats or not. It should be language-neutral. The System V x64 ABI starts with a long list of C types, which sounds off - why make a special case for C, and not for any of innumerable other languages? But this is Unix, where everyone knows that Unix and C are very chummy. In any case, the API is not the ABI. At the point at which I need to choose a corresponding type to _Bool in the API, and have to be aware of representation and semantics, I will not know the target, and therefore the ABI. For example, the SYSV ABI for x64 tells me that 'long' is a 64-bit type, but that's not correct for Windows nor 32-bit Linux. So the answer seems to be to just make assumptions. BTW within Windows APIs, 'BOOL' is defined on top of 'int'.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <invalid@add.invalid> |
|---|---|
| Date | 2022-02-05 23:18 +0100 |
| Message-ID | <stmt35$o14$1@gioia.aioe.org> |
| In reply to | #164795 |
On 2/5/22 5:27 PM, David Brown wrote:
> On 05/02/2022 16:16, Bart wrote:
>> On 05/02/2022 13:23, David Brown wrote:
>>> On 04/02/2022 20:38, Bart wrote:
>>>> On 04/02/2022 10:06, David Brown wrote:
>>>
>>>>> Secondly, there are technical differences. The conversion of an
>>>>> integer
>>>>> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed that
>>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>>> optimisation (as can the programmer). This can mean some operations
>>>>> (such as conversion from an integer) may be less efficient, but other
>>>>> operations (such as logical operations) are more efficient.
>>>>> Overall, it
>>>>> is usually a win.
>>>>
>>>> You're never really quite sure what's happening with _Bool.
>>>>
>>>> There's little control over its size. And in A program like this:
>>>>
>>>> union {
>>>> _Bool a;
>>>> unsigned char b;
>>>> } x;
>>>>
>>>> x.b=0x55;
>>>> printf("A= %X\n", x.a);
>>>> printf("B= %X\n", x.b);
>>>>
>>>
>>> <snip>
>>>
>>>> You can probably claim this is due to UB or whatever, but the fact
>>>> remains that using regular int types, the results will be consistent and
>>>> predictable across all compilers. It /is/ possible for the byte value
>>>> that usually represents a bool type to be set something that is neither
>>>> true (1) or false (0).
>>>>
>>>
>>> It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
>>> you care.) It is also common sense. A _Bool contains either 0 or 1 -
>>> any other value is invalid and can't be achieved without extraordinary
>>> effort designed purely to make bad code.
>>>
>>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>>> and you get the results you expect. Write code with clear and
>>> intentional errors with the sole intention of getting inconsistent
>>> results, and you get exactly what you expect.
>>
>> My point is exactly that you don't know what's going on, if not because
>> it's UB, it's because it's implementation defined or for some other
>> weird reason. Take this:
>>
>> _Bool a=0;
>>
>> for (int i=0; i<10; ++i){
>> printf("%d ",a);
>> ++a;
>> }
>>
>> What will be the output? For ++a, it's:
>>
>> 0 1 1 1 1 1 ...
>
> ++a means (a += 1), which in turn means (a = a + 1). The boolean is
> converted to an int (either 0 or 1), and 1 is added giving either 1 or
> 2. Conversion back to _Bool is on the basis of comparison to 0 - since
> neither 1 nor 2 compares equal to 0, the result of "++a" will always
> leave "a" as "true".
>
>>
>> But for --a it's:
>>
>> 0 1 0 1 0 1 ...
>
> Similar reasoning - if "a" is currently "true", then after "--a" it is
> left as "false". If "a" is currently "false", then "a = a - 1" will
> give "a = -1", and thus set "a" to "true" (1).
>
> It's not hard, not UB, not unexpected. (It is also almost certainly not
> found in real code, which is why compilers like gcc with "-Wall" will
> warn you that it's probably a mistake in your code. And in C++, it is
> not allowed at all.)
>
[snip anything about MSVC]
Your explanation is correct, but I still think that Bart has a point.
This example shows that, as it has been designed, _Bool is not
completely a self-consistent type.
There is no reason why a boolean type should behave as shown with ++ and --.
The fact that this is the result of an implicit round trip to and from
'int' shows that _Bool is to some extent still intermingled with 'int',
despite the intention of making a true boolean type to get rid of the
traditional use of 'int' for this purpose.
I know that this is still an extreme example, and I wouldn't write code
like this:
Obviously, if a is a _Bool, "a++" should be replaced with "a = true",
and "a--" should be replaced with "a = !a"
However, the fact that writing "a++" and "a--" is allowed gives Bart a
point, IMO.
>
> The logical and relational operators in C evaluate to "int", values 0 or
> 1, preceding the introduction of _Bool to the language.
>
> The fact that you personally get confused about _Bool and don't
> understand what it is and how it is defined, does not mean that it is
> unclear, confusing, imprecise, or that anyone else fails to comprehend it.
>
> However, now you know the rules that apply even when doing something as
> deliberately unrealistic and pointless as incrementing or decrementing a
> boolean variable. So you can no longer claim that you don't understand
> it, or are not sure what is going on, and can now happily make use of
> this extremely useful type.
>
One might argue that the fact that the rules explain the result do not
make the rules right.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-06 00:11 -0500 |
| Message-ID | <stnl9u$aut$1@dont-email.me> |
| In reply to | #164805 |
On 2/5/22 17:18, Manfred wrote: > On 2/5/22 5:27 PM, David Brown wrote: ... > There is no reason why a boolean type should behave as shown with ++ and --. > > The fact that this is the result of an implicit round trip to and from > 'int' shows that _Bool is to some extent still intermingled with 'int', > despite the intention of making a true boolean type to get rid of the > traditional use of 'int' for this purpose. Well, what would you expect when applying arithmetic operators to boolean values? If I weren't familiar with the C standard's specifications for such things, I wouldn't have any expectations at all - you shouldn't use such operators on boolean values. ... >> However, now you know the rules that apply even when doing something as >> deliberately unrealistic and pointless as incrementing or decrementing a >> boolean variable. So you can no longer claim that you don't understand >> it, or are not sure what is going on, and can now happily make use of >> this extremely useful type. >> > > One might argue that the fact that the rules explain the result do not > make the rules right. The committee is the ultimate authority with respect to the C standard - there's no other authority against which their decisions can be compared for correctness. You can say it's poorly designed, internally inconsistent, inconsistent with existing architectures or other computer languages, etc.; but to say it's wrong implies a standard of correctness it can be compared with, and there is none. In C, the ++ operator does what the C standard says it should do - you can decide whether or not what it does is useful for you, but there's no basis for saying that what the standard says about it is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-02-06 18:43 +0100 |
| Message-ID | <stp1bl$mq9$1@gioia.aioe.org> |
| In reply to | #164810 |
On 2/6/2022 6:11 AM, James Kuyper wrote: > On 2/5/22 17:18, Manfred wrote: >> On 2/5/22 5:27 PM, David Brown wrote: > ... >> There is no reason why a boolean type should behave as shown with ++ and --. >> >> The fact that this is the result of an implicit round trip to and from >> 'int' shows that _Bool is to some extent still intermingled with 'int', >> despite the intention of making a true boolean type to get rid of the >> traditional use of 'int' for this purpose. > > Well, what would you expect when applying arithmetic operators to > boolean values? If I weren't familiar with the C standard's > specifications for such things, I wouldn't have any expectations at all > - you shouldn't use such operators on boolean values. Exactly, and I add that from the same perspective it would be better if arithmetic operators on boolean types weren't allowed by the language. Allowing them might open some niche corner use case, but at the same time it exposes the language to a critique about consistency like Bart's, which, as I said, has in fact some grounds. > > ... >>> However, now you know the rules that apply even when doing something as >>> deliberately unrealistic and pointless as incrementing or decrementing a >>> boolean variable. So you can no longer claim that you don't understand >>> it, or are not sure what is going on, and can now happily make use of >>> this extremely useful type. >>> >> >> One might argue that the fact that the rules explain the result do not >> make the rules right. > > The committee is the ultimate authority with respect to the C standard - > there's no other authority against which their decisions can be compared > for correctness. You can say it's poorly designed, internally > inconsistent, inconsistent with existing architectures or other computer > languages, etc.; but to say it's wrong implies a standard of correctness > it can be compared with, and there is none. In C, the ++ operator does > what the C standard says it should do - you can decide whether or not > what it does is useful for you, but there's no basis for saying that > what the standard says about it is wrong. While I was writing that last sentence I've been wondering about the word "right" because of the meaning you reply at. I meant "right" as "well done", "smart", "well designed" etc. I think it was clear because the sentence is about "rules": rules are, by definition, mandatory, hence your meaning for "correctness" is implicit in the definition of "rule". Therefore, arguing about whether a rule is right or wrong is about the rule being well designed, thought of, chosen or not. In a sense, it's like with law in civil life: you have to abide to all laws, and it is right to do so - but at the same time one is allowed to say if some law, in their opinion, is not right, just or fair. The former part is about cohabitation in a civil society, the latter is about (the right for) critical thought. Lots of "right"'s here... (I like the English language, even if I am not a native English speaker, however I think one of its weaknesses is the more limited vocabulary compared to other languages)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-02-06 15:03 +0100 |
| Message-ID | <stokem$i37$1@dont-email.me> |
| In reply to | #164805 |
On 05/02/2022 23:18, Manfred wrote:
> On 2/5/22 5:27 PM, David Brown wrote:
>> On 05/02/2022 16:16, Bart wrote:
>>> On 05/02/2022 13:23, David Brown wrote:
>>>> On 04/02/2022 20:38, Bart wrote:
>>>>> On 04/02/2022 10:06, David Brown wrote:
>>>>
>>>>>> Secondly, there are technical differences. The conversion of an
>>>>>> integer
>>>>>> "x" to a _Bool "b" is effectively "b = !!x;". You are guaranteed
>>>>>> that
>>>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>>>> optimisation (as can the programmer). This can mean some operations
>>>>>> (such as conversion from an integer) may be less efficient, but other
>>>>>> operations (such as logical operations) are more efficient.
>>>>>> Overall, it
>>>>>> is usually a win.
>>>>>
>>>>> You're never really quite sure what's happening with _Bool.
>>>>>
>>>>> There's little control over its size. And in A program like this:
>>>>>
>>>>> union {
>>>>> _Bool a;
>>>>> unsigned char b;
>>>>> } x;
>>>>>
>>>>> x.b=0x55;
>>>>> printf("A= %X\n", x.a);
>>>>> printf("B= %X\n", x.b);
>>>>>
>>>>
>>>> <snip>
>>>>
>>>>> You can probably claim this is due to UB or whatever, but the fact
>>>>> remains that using regular int types, the results will be
>>>>> consistent and
>>>>> predictable across all compilers. It /is/ possible for the byte value
>>>>> that usually represents a bool type to be set something that is
>>>>> neither
>>>>> true (1) or false (0).
>>>>>
>>>>
>>>> It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
>>>> you care.) It is also common sense. A _Bool contains either 0 or 1 -
>>>> any other value is invalid and can't be achieved without extraordinary
>>>> effort designed purely to make bad code.
>>>>
>>>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>>>> and you get the results you expect. Write code with clear and
>>>> intentional errors with the sole intention of getting inconsistent
>>>> results, and you get exactly what you expect.
>>>
>>> My point is exactly that you don't know what's going on, if not because
>>> it's UB, it's because it's implementation defined or for some other
>>> weird reason. Take this:
>>>
>>> _Bool a=0;
>>>
>>> for (int i=0; i<10; ++i){
>>> printf("%d ",a);
>>> ++a;
>>> }
>>>
>>> What will be the output? For ++a, it's:
>>>
>>> 0 1 1 1 1 1 ...
>>
>> ++a means (a += 1), which in turn means (a = a + 1). The boolean is
>> converted to an int (either 0 or 1), and 1 is added giving either 1 or
>> 2. Conversion back to _Bool is on the basis of comparison to 0 - since
>> neither 1 nor 2 compares equal to 0, the result of "++a" will always
>> leave "a" as "true".
>>
>>>
>>> But for --a it's:
>>>
>>> 0 1 0 1 0 1 ...
>>
>> Similar reasoning - if "a" is currently "true", then after "--a" it is
>> left as "false". If "a" is currently "false", then "a = a - 1" will
>> give "a = -1", and thus set "a" to "true" (1).
>>
>> It's not hard, not UB, not unexpected. (It is also almost certainly not
>> found in real code, which is why compilers like gcc with "-Wall" will
>> warn you that it's probably a mistake in your code. And in C++, it is
>> not allowed at all.)
>>
>
> [snip anything about MSVC]
>
> Your explanation is correct, but I still think that Bart has a point.
> This example shows that, as it has been designed, _Bool is not
> completely a self-consistent type.
I don't agree. What is inconsistent about it?
>
> There is no reason why a boolean type should behave as shown with ++ and
> --.
Yes, there is - it is the only sensible and consistent possibility for
C. _Bool is an unsigned integer type - any integer types whose values
are a subset of those of "int" get promoted to "int" before arithmetic
operations. You might not think that's the best way to design a
programming language (and you would certainly not be alone in that), but
it is the way C works.
C philosophy has always been to change as little of the existing
language as possible when adding new features - the behaviour of _Bool
in C was made to keep the definitions of operators unchanged.
When C++ was designed, they could take more freedoms - "bool" was there
from the start, and there was less need for compatibility with C
standards. Relational operators in C++ evaluate to a "bool", rather
than an "int", which is more sensible - but C could not make that change
without affecting the existing language and code.
As far as I know (and I haven't checked all the details), "--a" and
"a--" has never been allowed for booleans in C++, while "++a" and "a++"
were removed in C++17.
>
> The fact that this is the result of an implicit round trip to and from
> 'int' shows that _Bool is to some extent still intermingled with 'int',
> despite the intention of making a true boolean type to get rid of the
> traditional use of 'int' for this purpose.
Welcome to C :-)
It is no different from "char" or "short int" in this respect.
"_Bool" is not a strong boolean type, in the manner of - say - Pascal or
Ada. It is not as independent as in C++. It was made such that the
majority of code that used an "int" (or a char of some sort, or an
enumeration) to hold a boolean value could be changed to use _Bool and
still work the same - without causing other disruption to code. And in
additional to standardising a boolean type, it added the useful property
of always being 0 or 1.
>
> I know that this is still an extreme example, and I wouldn't write code
> like this:
>
> Obviously, if a is a _Bool, "a++" should be replaced with "a = true",
> and "a--" should be replaced with "a = !a"
>
> However, the fact that writing "a++" and "a--" is allowed gives Bart a
> point, IMO.
>
Bart's "point" was that _Bool is difficult to understand, unpredictable,
and varies between toolchains. He is wrong in almost all of that. (The
one thing that is correct is that the size of _Bool is
implementation-dependent - it is not necessarily 1.)
If you want to make the point that C's _Bool is not quite the ideal way
to have booleans in a programming language, then I'd agree - C++'s
version is better in several ways. But it is the best that could be
done in an addition to the C language, and the result is an extremely
useful type that C programmers use regularly.
>>
>> The logical and relational operators in C evaluate to "int", values 0 or
>> 1, preceding the introduction of _Bool to the language.
>>
>> The fact that you personally get confused about _Bool and don't
>> understand what it is and how it is defined, does not mean that it is
>> unclear, confusing, imprecise, or that anyone else fails to comprehend
>> it.
>>
>> However, now you know the rules that apply even when doing something as
>> deliberately unrealistic and pointless as incrementing or decrementing a
>> boolean variable. So you can no longer claim that you don't understand
>> it, or are not sure what is going on, and can now happily make use of
>> this extremely useful type.
>>
>
> One might argue that the fact that the rules explain the result do not
> make the rules right.
You could argue that the rules are not the best choice if designing a
programming language from scratch, and including a boolean type at the
beginning. There's a lot about the rules of C that people disagree with
(though they will disagree about what they disagree with). However, C
is the language defined by the standards - it works well for a lot of
purposes. _Bool fits that perfectly.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-05 09:38 -0800 |
| Message-ID | <3b6f2718-aff3-4d04-b44b-fb65ebcdef32n@googlegroups.com> |
| In reply to | #164794 |
On Saturday, February 5, 2022 at 10:17:11 AM UTC-5, Bart wrote:
...
> My point is exactly that you don't know what's going on, if not because
> it's UB, it's because it's implementation defined or for some other
> weird reason. Take this:
>
> _Bool a=0;
>
> for (int i=0; i<10; ++i){
> printf("%d ",a);
> ++a;
> }
>
> What will be the output? For ++a, it's:
>
> 0 1 1 1 1 1 ...
>
> But for --a it's:
>
> 0 1 0 1 0 1 ...
>
> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
>
> Try this:
>
> a = 1;
> ++a;
> --a;
>
> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
> increments, and now the result is 1.
>
> _Bool has special semantics compared with int, yet the language still
> allows you to do all things associated with int.
>
> What is type result type of !!? It is int, not _Bool. _Bool is a
> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
> values of int, or 0 and non-zero, then I know exactly where I'm at.
The rules are really quite simple: _Bool expressions get promoted to int values of either 0 or 1, depending upon whether the _Bool value is false or true. During the evaluation of all expressions, those values behave the same as any other int with a value of 0 or 1. On conversion to _Bool, values that compare equal to zero get converted to false, all other values convert to true. Everything you've observed is explained by those simple rules, except for the behavior you've described for "2 lesser compilers", which is non-conforming. You can't blame C for the behavior of compilers that fail to to conform to its rules.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web