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 4 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-01-22 09:44 -0800 |
| Message-ID | <86y237oecd.fsf@linuxsc.com> |
| In reply to | #164533 |
Mateusz Viste <mateusz@xyz.invalid> writes: > 2022-01-21 at 17:32 -0800, Tim Rentsch wrote: > >> That was interesting, thank you. Can I ask you to repeat the >> experiment with -std=c89 -pedantic-errors > > In fact that was the case already, albeit I use -pedantic in lieu of > -pedantic-errors to avoid stopping early if possible. > >> Also if it isn't too much bother, with -std=c99 -pedantic-errors. > > I didn't see any new errors. There was a lot less errors/warnings > overall, which is not surprising since c99 brings some of the > extensions present in gnu89. The fact that there was less warnings made > me spot two that I hadn't noticed earlier (although they are present > in both -c89 and -c99): > > DT_LNK > initgroups() Both of these are amenable to the posix.h scheme I mentioned in my earlier posting. Also, after a bit more investigation, I discovered select() is not the problem I thought it was; an interface for select() can be provided in the same way as the other functions, including FD_CLR etc (although for clients these will be function calls rather than macros). > So to answer your question: no, -c99 did not result in any new errors > compared to -c89. I wonder, though - why did you think it could? Isn't > c99 a superset of c89? [...] My question was mostly about whether -pedantic would add anything. However, there are constructs that are legal in C89/C90 but in C99 are constraint violations. There aren't many of these, and mostly I expect they would not come up, but I thought it worth asking the question. > The only possible reason I see is that when > compiling in -c89, make could abort earlier since it will stop at the > first module file in error, hence some of the C files won't even be > looked at. Is that what you thought about? No, I was unconsciously assuming that you would manage your build process well enough so that there wouldn't be any problems along these lines.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-22 15:26 -0500 |
| Message-ID | <sshpag$qsh$1@dont-email.me> |
| In reply to | #164533 |
On 1/22/22 03:57, Mateusz Viste wrote: ... > So to answer your question: no, -c99 did not result in any new errors > compared to -c89. I wonder, though - why did you think it could? Isn't > c99 a superset of c89? No. It come close, but there were several changes that could negatively affect strictly conforming C89 code: * Removal of implicit int. * In C89, it was implementation-defined whether integer division rounded toward 0 or toward negative infinity; in C90, it's required to round toward 0. * // comments can change the interpretation of certain unlikely combinations, that were previously used as a way of detecting whether you were translating the code as C or as C++: * New rules for the types of integer constants and the integer promotions can change the results of certain expressions. * return without expression not permitted in function that returns a value (and vice versa)' * 'restrict' used to be an unreserved name, and as such could be used in user code. Now it's a keyword.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-22 14:44 -0800 |
| Message-ID | <86lez7o0et.fsf@linuxsc.com> |
| In reply to | #164548 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 1/22/22 03:57, Mateusz Viste wrote: > ... > >> So to answer your question: no, -c99 did not result in any new errors >> compared to -c89. I wonder, though - why did you think it could? Isn't >> c99 a superset of c89? > > No. It come close, but there were several changes that could negatively > affect strictly conforming C89 code: > > * Removal of implicit int. > * In C89, it was implementation-defined whether integer division rounded > toward 0 or toward negative infinity; in C90, it's required to round > toward 0. > * // comments can change the interpretation of certain unlikely > combinations, that were previously used as a way of detecting whether > you were translating the code as C or as C++: > * New rules for the types of integer constants and the integer > promotions can change the results of certain expressions. > * return without expression not permitted in function that returns a > value (and vice versa)' > * 'restrict' used to be an unreserved name, and as such could be used in > user code. Now it's a keyword. Good list. In addition, C89/C90 allows implicit function declaration, but C99 does not. Also, in C99 'inline' is a keyword, but was not in C89/C90.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-21 23:37 -0800 |
| Message-ID | <8635lgp6fw.fsf@linuxsc.com> |
| In reply to | #164507 |
Mateusz Viste <mateusz@xyz.invalid> writes: (Again I am responding in several parts to help keep the various aspects separate.) > 2022-01-21 at 05:51 -0800, Tim Rentsch wrote: > >> Also, I'm curious to know what extensions, if any, from the gnu >> additions you make use of. > > [...] Here is [what was found]: > > __uint128_t (also uint64_t / uint32_t / uint8_t but it seems gcc > tolerates those even in c89 mode, as long as stdint.h is included) > struct timeval > struct timespec > DT_DIR / DT_REG > PATH_MAX > > clock_gettime() / CLOCK_MONOTONIC > select() / fd_set / FD_SET() / FD_ZERO() / FD_ISSET() > strcasecmp() > getaddrinfo() / freeaddrinfo() / struct addrinfo / gai_strerror() > inet_aton() > mrand48() > snprintf() / vsnprintf() > strdup() > realpath() > chroot() > fileno() > popen() / pclose() > setenv() / unsetenv() > vsyslog() I think almost all of these can be made available, and fairly easily, without having to resort to -std=gnuXX or general use of any #defines of _XOPEN_SOURCE or similar symbols. My usual practice is to put POSIX-related interfaces in a separate file (eg, posix.h and posix.c), with only posix.c turning on any needed extra functionality by using #define _XOPEN_SOURCE or whatever. Most of the interfaces listed above can be made available directly through a posix.h header and used in standard-conforming C code. I had no trouble making such a header for things like strdup, chroot, setenv, and almost all the rest. The macros for numeric constants cannot be supplied directly but it isn't difficult to work around that aspect in various ways. The various struct types can be used but only in pointer form rather than directly. It's easy to work around that, if perhaps somewhat tedious, by providing an abstract interface for those types in posix.h (and posix.c implementing it). The one problem child is select() and friends. My suggestion there is to make a slightly higher level interface and used that rather than using select() directly. The motivation for doing all this is to get a program that is almost exclusively purely standard conforming. The big problem with using magic #defines or -std=gnuXX is like the proverbial saying about a box of chocolates: you never know what you're going to get. Worse, it can and sometimes does change between different compiler releases. Localizing all that stuff to a single .c file reduces the surface area of exposure and also makes it easy to identify what non-standard interfaces are being used and where.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-22 12:04 -0800 |
| Message-ID | <86pmojo7th.fsf@linuxsc.com> |
| In reply to | #164507 |
Mateusz Viste <mateusz@xyz.invalid> writes: (Again I am responding in several parts to help keep the various aspects separate. This posting is the last of three.) > 2022-01-21 at 05:51 -0800, Tim Rentsch wrote: > >> Can you say what you think the downside is of using C99? If >> there are parts of C99 you don't like you can always just not >> use them. > > You are of course right, but that's not really the point. Let me > provide one example. In C99, it is legal to declare a variable that > is not at the top of the scope. Fine, but *I* don't like it, as I > find that it encourages sloppy programming. If I'm allowed to use > something and it appears to be easier on the short term, I will most > probably abuse it. Yes, I am a feeble human. C89 is a way to keep > my laziness in check: all variables have to be at the top of the > scope so I can see them upfront. If it starts to be messy, then it > is because my scope needs to be refactored. I share your distaste for mixing declarations and code, including the part about sometimes being tempted to use it. Despite that, I find C99 a non-trivial improvement over C89/C90. There are a few constructs (not many, just a few) that are legal in C89/C90 (mainly for historical reasons) but require warnings in C99, and that's good. Beyond that, C99 has compound literals, designated initializers, more liberal rules for initializing structs and arrays, // comments, long long integer types, and a variety of other useful additions. Yes I know you can get some of these under -std=gnu89, but then you get all sorts of other stuff that is unknown and purely under the whim of GNU or clang or whoever. I've been bitten in the past by letting in these extra and unknown options, and it caused some difficulties. These days my C code is strictly limited to standard-conforming code unless there is a specific deliberate exception, and those are always restricted to as narrow a scope as feasible. For me the benefit of not allowing any non-standard functionality in the code definitely outweighs the inconvenience of being tempted to use intra-code declarations. To be explicit the above is not meant as an argument to convince you. I am however interested in whatever reactions you might have. > That's only one simple example, but I hope it conveys the larger > idea. I have looked through the list of changes between C90 and C99 and don't see anything else that looks objectionable. Can I ask you to provide a more comprehensive list? I really am at a loss to know what sorts of things you wouldn't like and also would be tempted to use.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-24 09:59 +0100 |
| Message-ID | <sslpp3$61s$2@gioia.aioe.org> |
| In reply to | #164547 |
2022-01-22 at 12:04 -0800, Tim Rentsch wrote: > To be explicit the above is not meant as an argument to convince > you. I am however interested in whatever reactions you might > have. My reaction is simply that in real world, there's no one ring to rule them all. Each of us has to choose the tools that suit him best, based on many things: the exact need at hand, personal preferences, and personal limitations to name only the few that come to mind immediately. > I have looked through the list of changes between C90 and C99 and > don't see anything else that looks objectionable. Can I ask you > to provide a more comprehensive list? I really am at a loss to > know what sorts of things you wouldn't like and also would be > tempted to use. It's not only about temptation, it also about using tools that are as simple as possible. I like games with simple rules - one reason why I prefer Go over chess. Some say it's because I lack brain power, and they may be right. Now, C99 isn't *that* much of a complication that I couldn't grasp it, but then where do I draw the line? C89 (or its gnu dialect) works for me and allows me to do the jobs I need to do without pain, so why bother. Now, about features that I don't like in C99: - VLAs (temptation argument again, that may lead to stack exhaustion) - bool (don't see what added value this brings) - complex & imaginary numbers (I admit those may be useful in some niche usage, but *I* never had such need) I also agree that C99 brings its share of improvements, which are part of the set of features I had listed earlier. But so does the gnu89 dialect, with the extra layer of POSIX that I often rely on. Hence in my very personal usage I consider gnu89 to be a pretty optimal tool. And I do not expect other people to agree, because of the reasons stated earlier. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-03 10:24 -0800 |
| Message-ID | <86sfszlsfd.fsf@linuxsc.com> |
| In reply to | #164573 |
Mateusz Viste <mateusz@xyz.invalid> writes: > 2022-01-22 at 12:04 -0800, Tim Rentsch wrote: > >> To be explicit the above is not meant as an argument to convince >> you. I am however interested in whatever reactions you might >> have. > > My reaction is simply that in real world, there's no one ring to rule > them all. Each of us has to choose the tools that suit him best, based > on many things: the exact need at hand, personal preferences, and > personal limitations to name only the few that come to mind immediately. I am trying to understand the reasons for those preferences. >> I have looked through the list of changes between C90 and C99 and >> don't see anything else that looks objectionable. Can I ask you >> to provide a more comprehensive list? I really am at a loss to >> know what sorts of things you wouldn't like and also would be >> tempted to use. > > It's not only about temptation, it also about using tools that are as > simple as possible. I like games with simple rules - one reason why I > prefer Go over chess. Some say it's because I lack brain power, and > they may be right. [...] > > Now, about features that I don't like in C99: > - VLAs (temptation argument again, that may lead to stack exhaustion) > - bool (don't see what added value this brings) > - complex & imaginary numbers (I admit those may be useful in some > niche usage, but *I* never had such need) With all due respect, these sound more like rationalizations than reasons. Have you made any effort to discover changes and new features in C99 that you would like? It's important to look at both sides, advantages as well as disadvantages. > [...] Now, C99 isn't *that* much of a complication that I > couldn't grasp it, but then where do I draw the line? C89 (or its gnu > dialect) works for me and allows me to do the jobs I need to do without > pain, so why bother. If you don't give C99 an earnest try of non-trivial duration, you'll never know.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-03 21:34 +0100 |
| Message-ID | <sthe7t$1cph$1@gioia.aioe.org> |
| In reply to | #164758 |
2022-02-03 at 10:24 -0800, Tim Rentsch wrote: > > Now, about features that I don't like in C99: > > - VLAs (temptation argument again, that may lead to stack > > exhaustion) > > - bool (don't see what added value this brings) > > - complex & imaginary numbers (I admit those may be useful in some > > niche usage, but *I* never had such need) > > With all due respect, these sound more like rationalizations than > reasons. These are my reasons, I'm sorry to disappoint. > If you don't give C99 an earnest try of non-trivial duration, > you'll never know. It's not like I reject C99 completely - I do use it in a few projects, mainly for bad reasons (to name two: extensive use of VLAs, looked nice and fun when I started using it, and by the time I realized that's a trap it was too late - the cost of redoing things the proper way is too high now so I'm living with it now ; second is 3rd-party code that insists on using [0]-sized arrays and mixes variable declaration with code). Anyway - I do use C99 from time to time on some oddball projects, but for my daily stuff I simply don't feel it brings anything on top of what I have already with gnu89. But maybe I missed some key things, so let me ask: what C99 feature do you use, that you wouldn't want to loose? Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-02-03 13:33 -0800 |
| Message-ID | <877dabljnf.fsf@nosuchdomain.example.com> |
| In reply to | #164759 |
Mateusz Viste <mateusz@xyz.invalid> writes:
[...]
> It's not like I reject C99 completely - I do use it in a few projects,
> mainly for bad reasons (to name two: extensive use of VLAs, looked nice
> and fun when I started using it, and by the time I realized that's a
> trap it was too late - the cost of redoing things the proper way is too
> high now so I'm living with it now ; second is 3rd-party code that
> insists on using [0]-sized arrays and mixes variable declaration with
> code).
C99 doesn't support zero-sized arrays. Attempting to define a
zero-sized ordinary array is a constraint violation. Creating a
zero-sized VLA has undefined behavior.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-03 22:57 +0100 |
| Message-ID | <sthj43$124e$1@gioia.aioe.org> |
| In reply to | #164760 |
2022-02-03 at 13:33 -0800, Keith Thompson wrote: > C99 doesn't support zero-sized arrays. You are right indeed, 0-sized arrays are a GNU extension. Seems I misremembered this one. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-02-03 22:28 +0000 |
| Message-ID | <sthkum$5nu$2@dont-email.me> |
| In reply to | #164759 |
On 03/02/2022 20:34, Mateusz Viste wrote: > what C99 feature do you use, that you wouldn't want to > loose? I mostly use C++. I use bool all the time; why would you use anything else? It's a type that holds 2 values, and the compiler can pick what to use for your processor. It might be a bit mask, or a 64 bit word. It might even vary with your optimisation settings. Andy
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-03 23:48 +0100 |
| Message-ID | <sthm4i$d2b$1@gioia.aioe.org> |
| In reply to | #164763 |
2022-02-03 at 22:28 +0000, Vir Campestris wrote: > I use bool all the time; why would you use anything else? It's a type > that holds 2 values, and the compiler can pick what to use for your > processor. It might be a bit mask, or a 64 bit word. It might even > vary with your optimisation settings. Can you tell what advantage it has over using, say, int_fast8_t? Mateusz
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-03 22:17 -0500 |
| Message-ID | <sti5s0$dtj$1@dont-email.me> |
| In reply to | #164764 |
On 2/3/22 17:48, Mateusz Viste wrote: > 2022-02-03 at 22:28 +0000, Vir Campestris wrote: >> I use bool all the time; why would you use anything else? It's a type >> that holds 2 values, and the compiler can pick what to use for your >> processor. It might be a bit mask, or a 64 bit word. It might even >> vary with your optimisation settings. > > Can you tell what advantage it has over using, say, int_fast8_t? 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.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-02-04 00:36 -0800 |
| Message-ID | <6f966456-55d7-40f4-9815-25096cd2c709n@googlegroups.com> |
| In reply to | #164766 |
On Friday, 4 February 2022 at 05:17:33 UTC+2, james...@alumni.caltech.edu wrote: > On 2/3/22 17:48, Mateusz Viste wrote: > > 2022-02-03 at 22:28 +0000, Vir Campestris wrote: > >> I use bool all the time; why would you use anything else? It's a type > >> that holds 2 values, and the compiler can pick what to use for your > >> processor. It might be a bit mask, or a 64 bit word. It might even > >> vary with your optimisation settings. > > > > Can you tell what advantage it has over using, say, int_fast8_t? > 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. That bool has only two values was already said above. It feels tautological that more constrained type brings less opportunities of misuse and so less cases to check or to unit test. I do not know why it is not perceived as an advantage by some people or why they get offended like if they were accused or suspected of misuse by providing such benefit.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-02-04 10:49 +0100 |
| Message-ID | <stisri$195u$1@gioia.aioe.org> |
| In reply to | #164771 |
2022-02-04 at 00:36 -0800, Öö Tiib wrote:
> That bool has only two values was already said above. It feels
> tautological that more constrained type brings less opportunities of
> misuse and so less cases to check or to unit test. I do not know
> why it is not perceived as an advantage by some people or why
> they get offended like if they were accused or suspected of misuse
> by providing such benefit.
You are right of course. Having an emulated "1-bit" type is, in theory,
providing a nice way to handle values that are expected to be binary in
nature.
What I am wondering about is the practical use of it - ie. in what kind
of situation such _Bool type could save the day. I am certainly biased,
since I always used normal integer to keep flags, so I am genuinely
interested to see how other people do.
My usual need for "booleans" is storing flags. I do this then:
int flag_zorgl;
const char *s = read_string_from_space();
flag_zorgl = is_zorgl_present(s);
(...)
if (flag_zorgl) process_str_with_a_zorgl(s);
(...)
if (!flag_zorgl) no_zorgl_data_processing(s);
The above could very well use a _Bool. But would it be significantly
faster? Shorter? Safer? What I am looking for is a tangible example of
_Bool's added value in a practical situation.
It's worth noting that in the above code is_zorgl_present() could be
replaced by count_zorgls(), which would provide more information to the
program, without affecting the "boolean-like" operations. This is, of
course, an advantage only if the program requires such extra
information.
One scenario I can think of where _Bool would work better, is if
someone does this kind of things:
/* do something that require zorgl or other but not both */
if (flag_zorgl ^ flag_other) process(s);
This is an example I came up with only in a effort of trying to find a
rationalization for _Bool, it's not something I recall ever needing. If
I'd had needed it, I'd have to put some safeguards around values in
flags, or write a much longer form:
if (((flag_zorgl) && (!flag_other)) || ((!flag_zorgl) && (flag_other)))
{
process(s);
}
...or alternatively I could use an enum of two values to simulate a
bool. Either way it would be more hassle than _Bool. But again - it is
not something I recall ever needing. Are there other examples that
would be less hypothetical?
Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-02-04 09:03 -0800 |
| Message-ID | <00f67fc8-5b55-4fb8-9efb-427ad3abbd5dn@googlegroups.com> |
| In reply to | #164773 |
On Friday, 4 February 2022 at 11:50:11 UTC+2, Mateusz Viste wrote:
> 2022-02-04 at 00:36 -0800, Öö Tiib wrote:
> > That bool has only two values was already said above. It feels
> > tautological that more constrained type brings less opportunities of
> > misuse and so less cases to check or to unit test. I do not know
> > why it is not perceived as an advantage by some people or why
> > they get offended like if they were accused or suspected of misuse
> > by providing such benefit.
>
> You are right of course. Having an emulated "1-bit" type is, in theory,
> providing a nice way to handle values that are expected to be binary in
> nature.
>
> What I am wondering about is the practical use of it - ie. in what kind
> of situation such _Bool type could save the day. I am certainly biased,
> since I always used normal integer to keep flags, so I am genuinely
> interested to see how other people do.
It is typically used to store, to return and to pass separate truth
values. I suspect you know that:
device->allows_cellular_connection = true; // store
if (is_authenticated(user)) { /*... */ } // return
set_visibility(separator, false); // pass
> My usual need for "booleans" is storing flags. I do this then:
>
> int flag_zorgl;
> const char *s = read_string_from_space();
>
> flag_zorgl = is_zorgl_present(s);
> (...)
> if (flag_zorgl) process_str_with_a_zorgl(s);
> (...)
> if (!flag_zorgl) no_zorgl_data_processing(s);
Yes that was what I meant. We can easily use int or char or enum type
for that flag_zorgl but then we just have doubt if it is worth to put a
debug check here or there or if it is worth to write unit tests for cases
when it has some other value than 0 or 1.
assert(flag_zorgl == 0 || flag_zorgl == 1);
>
> The above could very well use a _Bool. But would it be significantly
> faster? Shorter? Safer? What I am looking for is a tangible example of
> _Bool's added value in a practical situation.
>
> It's worth noting that in the above code is_zorgl_present() could be
> replaced by count_zorgls(), which would provide more information to the
> program, without affecting the "boolean-like" operations. This is, of
> course, an advantage only if the program requires such extra
> information.
My review would require rename ... flag_zorgl containing count of those
would be confusing. Also instead of if(count_zorgls(s)) I would
prefer if (count_zorgls(s)>0) or if (count_zorgls(s)!=0) as those
are more logical to read and each of us has huge displays
and can type 2-3 characters in blink of eye.
> One scenario I can think of where _Bool would work better, is if
> someone does this kind of things:
>
> /* do something that require zorgl or other but not both */
> if (flag_zorgl ^ flag_other) process(s);
>
> This is an example I came up with only in a effort of trying to find a
> rationalization for _Bool, it's not something I recall ever needing. If
> I'd had needed it, I'd have to put some safeguards around values in
> flags, or write a much longer form:
>
> if (((flag_zorgl) && (!flag_other)) || ((!flag_zorgl) && (flag_other)))
> {
> process(s);
> }
Huh? C does have logical and && and logical or || but logical
xor ^^ seems missing. Why? Because != can be used as logical xor.
But with ints where 42 means also true it looks bit weird:
if ( !flag_zorgl != !!flag_other ) process(s);
>
> ...or alternatively I could use an enum of two values to simulate a
> bool. Either way it would be more hassle than _Bool. But again - it is
> not something I recall ever needing. Are there other examples that
> would be less hypothetical?
No. For me the clear reasons are already sufficient:
1) the type conveys to reader of code that it has only two values
2) no one raises questions about need of checking if it is really so
3) compilers and programmers can find opportunities to optimise
thanks to that fact.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-07 00:52 -0800 |
| Message-ID | <867da7jbxc.fsf@linuxsc.com> |
| In reply to | #164773 |
Mateusz Viste <mateusz@xyz.invalid> writes:
> 2022-02-04 at 00:36 -0800, Tiib wrote:
>
>> That bool has only two values was already said above. It feels
>> tautological that more constrained type brings less opportunities
>> of misuse and so less cases to check or to unit test. I do not
>> know why it is not perceived as an advantage by some people or why
>> they get offended like if they were accused or suspected of misuse
>> by providing such benefit.
>
> You are right of course. Having an emulated "1-bit" type is, in
> theory, providing a nice way to handle values that are expected to
> be binary in nature.
>
> What I am wondering about is the practical use of it - ie. in
> what kind of situation such _Bool type could save the day. I am
> certainly biased, since I always used normal integer to keep
> flags, so I am genuinely interested to see how other people do.
> [...]
Consider the following code excerpt
enum {
FLAG_X = 1,
FLAG_Y = 2,
FLAG_Z = 4,
... etc ...
};
...
unsigned flags;
...
if( flags & FLAG_Y ) .. something ...
The purpose of _Bool is to hold the value of an expression in
just the same way that the expression would give in a logical
context such as if(), while(), do ... while(), or the middle
expression of for(). If for some reason we want to reuse or
hold on to the value of the expression inside an if() test,
using _Bool provides a good way to do that:
_Bool flag_y = flags & FLAG_Y;
I am something of an "old school" C programmer. If 'p' is a
pointer variable, I don't mind writing (and in fact often
prefer writing)
if( p ) ...
rather than the more verbose
if( p != NULL ) ...
Using _Bool works here too:
_Bool p_valid = p;
The conversion to _Bool converts null pointers to 0, and non-null
pointers to 1.
One reason we might want to save logical values in a variable is
to be able to combine logical expressions conveniently, without
needing to write out the '!= 0' that is implicit in logical
contexts. Also, because each _Bool is guaranteed to hold either
0 or 1 and nothing else, they can be combined using &, ^, and |
(if that is wanted) rather than && and || (and who knows what for
exclusive or). Of course I'm a big fan of && and ||, and tend to
use them more often than the bitwise & and |, but occasionally &,
^, and | do a better job of conveying how I think about the
conditions involved.
Another situation where I have found _Bool useful is inside
structs that hold lots of logical values. Rather use ordinary
members, logical values can be held in _Bool bitfields:
struct whatever {
_Bool property_a : 1;
_Bool property_b : 1;
_Bool property_c : 1;
/* etc */
};
Bitfields of type _Bool have the same "logical value" behavior
that regular _Bool variables have, namely converting any scalar
quantity to _Bool gives 1 if the converted quantity compares
not equal to 0, and 0 otherwise.
IME _Bool works well for most variables that are meant to hold a
logical value. Moreover if _Bool is not used then there is the
awkward question of what type to use instead. I wouldn't go so
far as to say that _Bool should be used for all such variables
and without exception, but in most cases it does seem to provide
a better fit than the other integer types.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-07 10:03 +0000 |
| Message-ID | <stqqol$qho$1@dont-email.me> |
| In reply to | #164845 |
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*
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-02-07 11:22 +0000 |
| Message-ID | <87y22mq5u6.fsf@bsb.me.uk> |
| 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* That's an unwarranted intuition: void *p; p = &p; -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-02-07 14:58 +0000 |
| Message-ID | <strc1t$n7q$1@dont-email.me> |
| In reply to | #164849 |
On 07/02/2022 11:22, Ben Bacarisse wrote: > 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* > > That's an unwarranted intuition: > > void *p; > p = &p; OK, there's that, although at least both sides are pointers to something. A void target on either side makes both targets compatible. I first came across this behaviour of _Bool in code that I think was passing the address of a struct to a function expecting a _Bool argument. It was rather puzzling (apart from the fact that the address of a struct instance would always be true). An explicit conversion (for example using !! on the argument, where the 0/1 result is a more reasonable value to pass to a _Bool parameter) would have made things clearer.
[toc] | [prev] | [next] | [standalone]
Page 4 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