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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-01-22 08:31 -0500 |
| Message-ID | <IGTGJ.5622$1_.3043@fx37.iad> |
| In reply to | #164537 |
On 1/22/22 7:53 AM, Mateusz Viste wrote: > 2022-01-22 at 13:05 +0100, David Brown wrote: >> You seem to imagine that compiler warnings invariably indicate a >> problem, and that disabling (or not enabling) a warning hides errors >> in your code. That is simply not true. > > You are mistaken, I'm not imagining anything. I use -Weverything > because I like that the compiler warns me about things that he finds > odd. Sometimes it's an annoyance, but then it's easy to shut it by > instructing him not to check this specific warning. Other times it helps > finding a bug that would otherwise require a human to track it down. > Recent example: I got a warning about a shadowed variable (and it was > indeed a mistake). This warning is not present in -Wall nor -Wextra. > >> Others, however, are very much a matter of style and preference, >> according to the needs of the programmer and the code. I, for >> example, /do/ enable "-Wpadded" for my own code - but I do not expect >> the majority of other users to want it. > > That is definitely *not* a matter of style or preference. There are > situations where automatic struct padding is harmful, typically when > using said struct to communicate with other implementations. Such > padding might not occur on one compiler or architecture, but occurs on > another. Warning about that in this context is very much helpful. > Majority of my code does not rely on exact struct size and alignment, > hence for these scenarios I disable this check. But again - it's not at > all about style, it's strictly about what the structs are to be used > for, and this is something the compiler cannot guess. > >> But blinding saying "enable everything" is no more helpful than >> blindly disabling everything. > > I don't think that I ever said that I "blindly enable everything". > > > Mateusz > That one may not be, but there are some that are purely stylistic, and different implementations enforce different styles. One big class is 'redundant' parentheses. Some implementations consider some operations to have 'unnatural' precedence, and will advise adding parentheses to make that explicit, while others will warn that those parentheses aren't needed and are just redundant.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-22 15:53 +0100 |
| Message-ID | <ssh5pb$1sp1$1@gioia.aioe.org> |
| In reply to | #164539 |
2022-01-22 at 08:31 -0500, Richard Damon wrote: > One big class is 'redundant' parentheses. Some implementations > consider some operations to have 'unnatural' precedence, and will > advise adding parentheses to make that explicit, while others will > warn that those parentheses aren't needed and are just redundant. Yes, I know those and they are indeed about style, or even "code religion". In the same register are the warnings about fall-through case statements in a switch (I do not disable these warnings, though, as 95% of my switches are meant NOT to fall-through, and for the rest of cases I write a proper comment next to it so clang is happy - and I find it's actually a very good practice). Anyway - yes, you are right, but David chose a very unfortunate example and I was responding specifically to that. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-22 16:46 +0100 |
| Message-ID | <ssh8t4$3mp$1@dont-email.me> |
| In reply to | #164540 |
On 22/01/2022 15:53, Mateusz Viste wrote: > 2022-01-22 at 08:31 -0500, Richard Damon wrote: >> One big class is 'redundant' parentheses. Some implementations >> consider some operations to have 'unnatural' precedence, and will >> advise adding parentheses to make that explicit, while others will >> warn that those parentheses aren't needed and are just redundant. > > Yes, I know those and they are indeed about style, or even "code > religion". In the same register are the warnings about fall-through > case statements in a switch (I do not disable these warnings, though, as > 95% of my switches are meant NOT to fall-through, and for the rest of > cases I write a proper comment next to it so clang is happy - and I > find it's actually a very good practice). > > Anyway - yes, you are right, but David chose a very unfortunate example > and I was responding specifically to that. > The choice of whether or not you want a warning on extra padding on structs is a matter of style and the type of code you are writing. Yes, sometimes it matters if there is unexpected padding in your structs. Yes, sometimes it does /not/ matter. Neither situation /requires/ the warning, and neither requires that the warning is disabled. If you need to be sure of that a struct is the size you expect and need, you can add padding manually and use _Static_assert (or a macro-based alternative for older C standards) to check the size at compile-time. Some care is always needed if the code must be portable, as type sizes and alignments may vary according to the target. If you don't care about the padding and find that the warning is being triggered, you can still add the padding manually, or ignore the warning, or disable it temporarily. (gcc and clang have pragmas for that.)
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-24 09:33 +0100 |
| Message-ID | <sslo93$61s$1@gioia.aioe.org> |
| In reply to | #164542 |
2022-01-22 at 16:46 +0100, David Brown wrote: > The choice of whether or not you want a warning on extra padding on > structs is a matter of style and the type of code you are writing. Not really what you were saying earlier, but nice try. > Yes, sometimes it matters if there is unexpected padding in your > structs. Yes, sometimes it does /not/ matter. Neither situation > /requires/ the warning, and neither requires that the warning is > disabled. In this line of thought I propose to simplify the argument to "no warnings are required at all" and let's be done with it. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-24 10:15 +0100 |
| Message-ID | <sslqnv$9v2$1@dont-email.me> |
| In reply to | #164572 |
On 24/01/2022 09:33, Mateusz Viste wrote: > 2022-01-22 at 16:46 +0100, David Brown wrote: >> The choice of whether or not you want a warning on extra padding on >> structs is a matter of style and the type of code you are writing. > > Not really what you were saying earlier, but nice try. > >> Yes, sometimes it matters if there is unexpected padding in your >> structs. Yes, sometimes it does /not/ matter. Neither situation >> /requires/ the warning, and neither requires that the warning is >> disabled. > > In this line of thought I propose to simplify the argument to > "no warnings are required at all" and let's be done with it. > I'm not sure why you have decided this is some sort of battle rather than sharing experiences and suggestions for how to get the most help from your compiler, but I guess we are done with this thread.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-22 10:03 -0800 |
| Message-ID | <86tudvodft.fsf@linuxsc.com> |
| In reply to | #164539 |
Richard Damon <Richard@Damon-Family.org> writes: [regarding various warning options and program style] > That one may not be, but there are some that are purely stylistic, > and different implementations enforce different styles. > > One big class is 'redundant' parentheses. Some implementations > consider some operations to have 'unnatural' precedence, and will > advise adding parentheses to make that explicit, while others will > warn that those parentheses aren't needed and are just redundant. Personally I would like to see a compiler option that warns in /all/ cases of redundant parentheses.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-23 12:28 +0100 |
| Message-ID | <ssje46$tpl$1@dont-email.me> |
| In reply to | #164545 |
On 22/01/2022 19:03, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > > [regarding various warning options and program style] > >> That one may not be, but there are some that are purely stylistic, >> and different implementations enforce different styles. >> >> One big class is 'redundant' parentheses. Some implementations >> consider some operations to have 'unnatural' precedence, and will >> advise adding parentheses to make that explicit, while others will >> warn that those parentheses aren't needed and are just redundant. > > Personally I would like to see a compiler option that warns > in /all/ cases of redundant parentheses. > Do you think that would be much used? I can understand how some people might find the warning interesting, but the prime purpose of warnings in compilers is to help people spot possible errors in their code - code that does not do what they think it does, or does not do what they intended it to do. There are other kinds of static checking systems that go beyond that to purely stylistic matters - checking for spelling in identifiers, maximum number of lines in a function, and whatever. This kind of check might fit better at such a level. Both gcc and clang/llvm have frameworks for extensions and checkers that would be suitable, allowing people to add new checks in a high-level language (such as Python) without having to go through the laborious process of changing the core compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-01-23 11:48 +0000 |
| Message-ID | <ssjf9l$5f4$1@dont-email.me> |
| In reply to | #164550 |
On 23/01/2022 11:28, David Brown wrote:
> On 22/01/2022 19:03, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>> [regarding various warning options and program style]
>>
>>> That one may not be, but there are some that are purely stylistic,
>>> and different implementations enforce different styles.
>>>
>>> One big class is 'redundant' parentheses. Some implementations
>>> consider some operations to have 'unnatural' precedence, and will
>>> advise adding parentheses to make that explicit, while others will
>>> warn that those parentheses aren't needed and are just redundant.
>>
>> Personally I would like to see a compiler option that warns
>> in /all/ cases of redundant parentheses.
>>
>
> Do you think that would be much used? I can understand how some people
> might find the warning interesting, but the prime purpose of warnings in
> compilers is to help people spot possible errors in their code - code
> that does not do what they think it does, or does not do what they
> intended it to do.
Tim thinks that everyone should know all the C precedence levels,
including those for ?: operators, so should they should never never to
use parentheses for clarity or avoid ambiguity.
This sounds like something that can be used to catch people out. So
detecting:
a << (b + c)
is a sign that someone is unsure about relevant precedences of << and +;
they should instead write:
a << b + c
While this ought to be perfectly clear without parentheses:
a ? b ? c : d ? e : f : g;
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-01-23 08:36 -0800 |
| Message-ID | <1bb9bdc9-5c15-4fa7-8f6c-53d59a349ed6n@googlegroups.com> |
| In reply to | #164551 |
On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote: > While this ought to be perfectly clear without parentheses: > > a ? b ? c : d ? e : f : g; It looks bad to read for me. Parentheses do not help to reason there. Writing in more usual to human logic may help: !a ? g : b ? c : d ? e : f; Also adding newlines to emphasize what is value and what condition may help: !a ? g : b ? c : d ? e : f; But parentheses would make original to look even more garbage.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-01-23 16:55 +0000 |
| Message-ID | <ssk1a9$3oh$1@dont-email.me> |
| In reply to | #164553 |
On 23/01/2022 16:36, Öö Tiib wrote:
> On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote:
>
>> While this ought to be perfectly clear without parentheses:
>>
>>
> a ? b ? c : d ? e : f : g;
>
> It looks bad to read for me. Parentheses do not help to reason there.
> Writing in more usual to human logic may help:
>
> !a ? g : b ? c : d ? e : f;
>
> Also adding newlines to emphasize what is value and what condition
> may help:
>
> !a ? g
> : b ? c
> : d ? e
> : f;
>
> But parentheses would make original to look even more garbage.
>
If pseudo-code, my example corresponds do:
if a then
if b then
c
else
if d then
e
else
f
end
end
else
g
end
(Transcribed from AST display of the C code.) That suggests the
parentheses would go here:
a ? (b ? c : (d ? e : f)) : g
You version is transformed, but presumably you had to already know what
it meant in order to do that.
A multi-line, indented layout would help, provided you were confident
that that was what it meant without the parentheses. But then you are
much better off using if-else. (Unfortunately in C if-else cannot return
a value.)
I only use such short-form constructs on one line.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-23 19:17 -0800 |
| Message-ID | <86czkhom8w.fsf@linuxsc.com> |
| In reply to | #164553 |
Tiib <ootiib@hot.ee> writes: > On Sunday, 23 January 2022 at 13:48:18 UTC+2, Bart wrote: [edited to reflect what I believe is correct attribution] >> While this ought to be perfectly clear without parentheses: >> >> a ? b ? c : d ? e : f : g; > > It looks bad to read for me. Parentheses do not help to reason > there. Writing in more usual to human logic may help: > > !a ? g : b ? c : d ? e : f; > > Also adding newlines to emphasize what is value and what condition > may help: > > !a ? g > : b ? c > : d ? e > : f; > > But parentheses would make original to look even more garbage. I don't disagree with your comments. For me though the high order bit is that this is a pointless and contrived example, and not deserving of any other reaction. Just like so many other of Bart's postings.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-21 12:11 -0500 |
| Message-ID | <ssepg1$2s3$1@dont-email.me> |
| In reply to | #164507 |
On 1/21/22 9:59 AM, Mateusz Viste wrote: ... > them from -std=gnu89 to -std=c89 to identify the gnu89 extensions that > I use. Here is the result: > > __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() Many (most? all? - I haven't bothered to check.) of those are not gcc extensions, they're part of the POSIX standard library.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 18:28 +0100 |
| Message-ID | <sseqf1$p7v$2@gioia.aioe.org> |
| In reply to | #164512 |
2022-01-21 at 12:11 -0500, James Kuyper wrote: > Many (most? all? - I haven't bothered to check.) of those are not gcc > extensions, they're part of the POSIX standard library. They are still extensions of C89 (mostly picked out from C99), hence why I use -std=gnu89 in practice instead of the more puritan -std=c89. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-21 12:59 -0500 |
| Message-ID | <ssesak$oea$1@dont-email.me> |
| In reply to | #164516 |
On 1/21/22 12:28 PM, Mateusz Viste wrote:
> 2022-01-21 at 12:11 -0500, James Kuyper wrote:
>> Many (most? all? - I haven't bothered to check.) of those are not gcc
>> extensions, they're part of the POSIX standard library.
>
> They are still extensions of C89 (mostly picked out from C99), hence
> why I use -std=gnu89 in practice instead of the more puritan -std=c89.
They are not compiler extensions, because they're not associated with
the compiler, nor are they associated with C99. A fully conforming
implementation of C running on a POSIX platform should accept the
following code even when running in strict C89 mode, without relying
upon any extensions:
#define _POSIX_C_SOURCE 2
#include <stdio.h>
int main()
{
FILE * file = popen("", "");
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-21 17:23 +0000 |
| Message-ID | <9_BGJ.170561$X2_b.72894@fx09.ams4> |
| In reply to | #164507 |
Mateusz Viste <mateusz@xyz.invalid> writes: >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. That hasn't been my experience. In fact, there are valid arguments for moving the declaration closer to the use, particularly in functions that may exit before using an initialized declaration. Either via a basic block (stand-alone or as part of a conditional or looping construct) or using C++/C99 features.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 18:35 +0100 |
| Message-ID | <sseqsk$19vr$1@gioia.aioe.org> |
| In reply to | #164514 |
2022-01-21 at 17:23 GMT, Scott Lurndal wrote: > >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. > > That hasn't been my experience. > > In fact, there are valid arguments for moving the > declaration closer to the use, particularly in functions > that may exit before using an initialized declaration. > > Either via a basic block (stand-alone or as part of a > conditional or looping construct) or using C++/C99 features. If you have such need, then it is likely that your functions are really long. Maybe there are good reasons for it, but in my experience it is more often than not the sign of a function that would better be exploded into more, smaller, more specialized functions. I often miss it myself, and I see it only when I realize that I have to scroll three screens of text to figure out what the rowcount variable is about. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-21 18:06 +0000 |
| Message-ID | <pCCGJ.338776$6kH7.305209@fx03.ams4> |
| In reply to | #164517 |
Mateusz Viste <mateusz@xyz.invalid> writes: >2022-01-21 at 17:23 GMT, Scott Lurndal wrote: >> >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. >> >> That hasn't been my experience. >> >> In fact, there are valid arguments for moving the >> declaration closer to the use, particularly in functions >> that may exit before using an initialized declaration. >> >> Either via a basic block (stand-alone or as part of a >> conditional or looping construct) or using C++/C99 features. > >If you have such need, then it is likely that your functions are really >long. What does early exit (e.g. parameter validation) have to do with overlong functions?
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 20:04 +0100 |
| Message-ID | <ssf045$19vr$2@gioia.aioe.org> |
| In reply to | #164521 |
2022-01-21 at 18:06 GMT, Scott Lurndal wrote:
> What does early exit (e.g. parameter validation) have to do
> with overlong functions?
What does parameter validation have to do with the position where
variables are declared?
Perhaps you could post a (very short) example of what you mean?
"function that may exit before using an initialized declaration" is
something that I handle as below, that's why I do not understand why
it's an argument for where what is declared. But show me your way
please so I can understand your point of view.
char *fn(int a) {
char *res = NULL;
if (a < 1) goto GAMEOVER;
res = malloc(a);
if (res == NULL) goto GAMEOVER;
return(res);
GAMEOVER:
free(res);
return(NULL);
}
Mateusz
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-21 19:14 +0000 |
| Message-ID | <CCDGJ.246968$Gbad.173877@fx12.ams4> |
| In reply to | #164523 |
Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-01-21 at 18:06 GMT, Scott Lurndal wrote:
>> What does early exit (e.g. parameter validation) have to do
>> with overlong functions?
>
>What does parameter validation have to do with the position where
>variables are declared?
>
>Perhaps you could post a (very short) example of what you mean?
>"function that may exit before using an initialized declaration" is
>something that I handle as below, that's why I do not understand why
>it's an argument for where what is declared. But show me your way
>please so I can understand your point of view.
>
>char *fn(int a) {
> char *res = NULL;
>
> if (a < 1) goto GAMEOVER;
So the initialization of res executes unnecessary instructions
to zero 8 bytes on the stack. Moving the declaration after the if statement
reduces the instruction count in that path. In certain functions, that can
make a difference in performance.
I once believed as you do, but the benefits of placing the
declaration closer to the use has many benefits and few
downsides.
And I've seen some pretty long functions that are not easily
amenable to factorization into smaller functions for structural
or performance reasons.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-21 17:02 -0800 |
| Message-ID | <86mtjopoq5.fsf@linuxsc.com> |
| In reply to | #164524 |
scott@slp53.sl.home (Scott Lurndal) writes: > [...] I've seen some pretty long functions that are not easily > amenable to factorization into smaller functions for structural > or performance reasons. Can you post an example or two of those? Ideally one of each, one where structure impedes refactoring and one where performance impedes refactoring.
[toc] | [prev] | [next] | [standalone]
Page 2 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