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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-12-31 11:02 +0100 |
| Subject | How to avoid an overflow during multiplication? |
| Message-ID | <sqmkg9$157v$1@gioia.aioe.org> |
I have this little function:
/* converts an amount of ticks into human time (micro-seconds)
* timeunits: number of ticks to convert into actual time
* tempo : the time length (in microseconds) of grouplen ticks
*/
uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo)
{
return ticks * tempo / grouplen;
}
In practical situations the end result of this computation is
guaranteed to always fit inside an uint32_t, but the above formula
overflows easily in the (ticks * tempo) part.
The easy & stupid way to avoid this overflow would be this:
return ticks * (tempo / grouplen);
...but it's obviously not a good solution, since it may loose a lot of
resolution. The hacky compromise that I currently use is this:
return ticks * (((tempo << 3) / grouplen) >> 3);
It works fine in my practical tests, so I might just as well be done
with it, but I wonder if there is a cleaner approach to such seemingly
simple problem?
I should also add that this part of the program is performance
critical, so I cannot afford branching or any other expensive
computations. It's also worth noting that "grouplen" is guaranteed to
be a positive number that never changes across the calls of the
function (which, in truth, is not even a function, but it was easier to
format it as such for this exercise).
Mateusz
[toc] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-12-31 12:33 +0000 |
| Message-ID | <875yr554z4.fsf@bsb.me.uk> |
| In reply to | #164141 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Mateusz Viste <mateusz@xyz.invalid> writes: >>uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo) > ... >>In practical situations the end result of this computation is >>guaranteed to always fit inside an uint32_t, but the above formula >>overflows easily in the (ticks * tempo) part. > > See the section > > Multiplication > > on the Web page > > INT32-C. Ensure that operations on signed integers do not result in > overflow What web page? I found a document (by searching for these words) but that was all about detecting signed integer overflow. The OP does not want to detect the overflow (technically, the wrapping since the types are unsigned), but to get the right result even though the intermediate calculation wraps. Detecting the wrapping might be a first step, but the OP has a rough and ready solution already, so anything that complicated is not going to be suitable. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-12-31 12:33 +0000 |
| Message-ID | <8735m954yz.fsf@bsb.me.uk> |
| In reply to | #164141 |
Mateusz Viste <mateusz@xyz.invalid> writes:
> I have this little function:
>
> /* converts an amount of ticks into human time (micro-seconds)
> * timeunits: number of ticks to convert into actual time
> * tempo : the time length (in microseconds) of grouplen ticks
> */
> uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo)
> {
> return ticks * tempo / grouplen;
> }
>
> In practical situations the end result of this computation is
> guaranteed to always fit inside an uint32_t, but the above formula
> overflows easily in the (ticks * tempo) part.
There's a technical detail here which is that in C unsigned arithmetic
can't overflow. Arithmetic overflow is reserved for serious undefined
situation. Unsigned arithmetic just "wraps round" in a defined manner.
But there's nothing unclear about your question: the result is always <=
UINT32_MAX, but ticks * tempo isn't. You want to know how to calculate
the result correctly in all cases.
Interesting question. The obvious way is to use a wider type for the
multiplication (uint_least64_t) but that's probably not what you want.
> The easy & stupid way to avoid this overflow would be this:
>
> return ticks * (tempo / grouplen);
>
> ...but it's obviously not a good solution, since it may loose a lot of
> resolution. The hacky compromise that I currently use is this:
>
> return ticks * (((tempo << 3) / grouplen) >> 3);
I don't think this helps. I think that (when tempo << 3 does not wrap)
you get the same result as the original. Maybe I'm missing something.
> It works fine in my practical tests, so I might just as well be done
> with it, but I wonder if there is a cleaner approach to such seemingly
> simple problem?
I feel there should be a way, but I can't think of one right now.
> I should also add that this part of the program is performance
> critical, so I cannot afford branching or any other expensive
> computations. It's also worth noting that "grouplen" is guaranteed to
> be a positive number that never changes across the calls of the
> function (which, in truth, is not even a function, but it was easier to
> format it as such for this exercise).
Since grouplen does not change, can you find, at the start, gl1 and gl2,
ideally close to the square root of grouplen, so that you can use
(ticks / gl1) * (tempo / gl2)
instead? Obviously you may not be able to find such numbers, but there
may be constraints on grouplen that make this work.
> Mateusz
>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-12-31 14:24 +0100 |
| Message-ID | <sqn0aq$1e8b$1@gioia.aioe.org> |
| In reply to | #164144 |
2021-12-31 at 12:33 +0000, Ben Bacarisse wrote:
> There's a technical detail here which is that in C unsigned arithmetic
> can't overflow. Arithmetic overflow is reserved for serious undefined
> situation. Unsigned arithmetic just "wraps round" in a defined
> manner.
Can you provide the source please? I know that what you describe is the
standard behavior of all C compilers (that I know), but I could not
find the definition of multiplicative wrapping in the ISO 9899:1990
(yes, this is ANSI C). All I did find is this:
G.2 Undefined behavior
The behavior in the following circumstances is undefined:
(...)
-- An arithmetic operation is invalid (such as division or modulus by
0) or produces a result that cannot be represented in the space
provided (such as overflow or underflow)
> Interesting question. The obvious way is to use a wider type for the
> multiplication (uint_least64_t) but that's probably not what you want.
I should have mentioned that this runs on a 16-bit CPU. Doing 32-bit
multiplications is hard enough already, emulating 64-long types would
have a disastrous effect on performances. I also do not have access to
an FPU.
> > return ticks * (((tempo << 3) / grouplen) >> 3);
>
> I don't think this helps. I think that (when tempo << 3 does not
> wrap) you get the same result as the original. Maybe I'm missing
> something.
I'm sorry, you are correct of course. I copied the code wrong when
typing the message and misplaced one set of parenthesis. Here's the
actual hack I use:
return (ticks * (((tempo << 3) / grouplen))) >> 3;
> I feel there should be a way, but I can't think of one right now.
So we're on the same page.
On top of what I have already described, here is a short test program I
used to exhibit the problem and test for solutions:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
int main(int argc, char **argv) {
if (argc != 4) {
printf("usage: %s ticks tempo grouplen\n", argv[0]);
} else {
uint32_t r1, r2, r3, r4;
uint32_t ticks = atoi(argv[1]);
uint32_t tempo = atoi(argv[2]);
uint32_t grouplen = atoi(argv[3]);
r1 = ticks * tempo / grouplen;
r2 = ticks * (tempo / grouplen);
r3 = (ticks * (((tempo << 3) / grouplen))) >> 3;
r4 = (uint64_t)ticks * (uint64_t)tempo / grouplen;
printf("r1 = %u\nr2 = %u\nr3 = %u\nr4 = %u\n", r1, r2, r3, r4);
}
return 0;
}
And here how it runs with a set of real-life values that initially
borked my program:
./mul 9120 1090909 15370
r1 = 88429 <-- oops very bad
r2 = 638400 <-- more or less fine, but not very precise
r3 = 646380 <-- still not perfect, but acceptable precision
r4 = 647305 <-- perfect but slow
> Since grouplen does not change, can you find, at the start, gl1 and
> gl2, ideally close to the square root of grouplen, so that you can use
>
> (ticks / gl1) * (tempo / gl2)
I'm not sure I understand the goal here... Won't I still loose lots of
precision due to integer div rounding?
Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-12-31 15:00 +0100 |
| Message-ID | <sqn2dj$14ld$2@gioia.aioe.org> |
| In reply to | #164147 |
2021-12-31 at 13:41 GMT, Stefan Ram wrote: > |A computation involving unsigned operands can never overflow, > |because a result that cannot be represented by the resulting > |unsigned integer type is reduced modulo the number that is > |one greater than the largest value that can be represented by > |the resulting type. > n2310, 6.2.5p9 Had missed that one, thanks! (In my ANSI C copy it is at 6.1.2.5, p23) Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-12-31 11:38 -0800 |
| Message-ID | <877dbk36qu.fsf@nosuchdomain.example.com> |
| In reply to | #164154 |
Mateusz Viste <mateusz@xyz.invalid> writes:
> 2021-12-31 at 13:41 GMT, Stefan Ram wrote:
>> |A computation involving unsigned operands can never overflow,
>> |because a result that cannot be represented by the resulting
>> |unsigned integer type is reduced modulo the number that is
>> |one greater than the largest value that can be represented by
>> |the resulting type.
>> n2310, 6.2.5p9
>
> Had missed that one, thanks!
>
> (In my ANSI C copy it is at 6.1.2.5, p23)
You mean ISO C. (C standards have been published by ISO, not ANSI,
since 1990.) Which edition are you using?
It's section 6.2.5 in C99 and later. If you're seeing that paragraph in
section 6.1.2.5, you're probably using the C90 standard (which doesn't
have paragraph numbers, BTW). I suggest grabbing a more recent draft.
N1570 is nearly equivalent to the C11 standard. (There are drafts that
are close to the C17 standard, but most of them are password protected.)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
--
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 | 2021-12-31 20:49 +0100 |
| Message-ID | <sqnmsm$1ff8$1@gioia.aioe.org> |
| In reply to | #164170 |
2021-12-31 at 11:38 -0800, Keith Thompson wrote: > > (In my ANSI C copy it is at 6.1.2.5, p23) > > You mean ISO C. (C standards have been published by ISO, not ANSI, > since 1990.) No, I do mean ANSI, although it was a conjoint work with ISO. > Which edition are you using? The cover says: "American National Standard for Programming Languages - C ANSI/ISO 9899-1990 (revision and redesignation of ANSI X3.159-1989) Approved August 3, 1992" > I suggest grabbing a more recent draft. N1570 is nearly equivalent to > the C11 standard. (There are drafts that are close to the C17 > standard, but most of them are password protected.) Meh. I'm *really* not interested in those post-1990 atrocities. At all. Will stay with ANSI C, it worked very well for me so far. Sorry. :-) Mateusz
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-12-31 18:37 -0500 |
| Message-ID | <sqo47m$n9p$1@dont-email.me> |
| In reply to | #164171 |
On 12/31/21 2:49 PM, Mateusz Viste wrote: > 2021-12-31 at 11:38 -0800, Keith Thompson wrote: >>> (In my ANSI C copy it is at 6.1.2.5, p23) >> >> You mean ISO C. (C standards have been published by ISO, not ANSI, >> since 1990.) > > No, I do mean ANSI, although it was a conjoint work with ISO. > >> Which edition are you using? > > The cover says: > > "American National Standard for Programming Languages - C > ANSI/ISO 9899-1990 > (revision and redesignation of ANSI X3.159-1989) > Approved August 3, 1992" Calling it ANSI C is not very useful, because that designation is ambiguous. Every version of the C standard has been adopted as a standard by both ANSI and ISO, so referring to ANSI C doesn't make it clear whether you're referring to C90, C99, C2011, or C2017. That would be fine if you were referring to any or all four of those versions collectively - but you do seem to be referring only to C90. uint32_t and uint16_t, both of which are used in your code, were added to the language in C99. So apparently you don't consider C99 a complete atrocity.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-01 17:48 +0100 |
| Message-ID | <sqq0lb$1g77$1@gioia.aioe.org> |
| In reply to | #164180 |
2021-12-31 at 18:37 -0500, James Kuyper wrote: > Calling it ANSI C is not very useful, because that designation is > ambiguous. I was only stating about "my copy of ANSI C". Didn't mean to specify any more than that, really. > uint32_t and uint16_t, both of which are used in your code, were added > to the language in C99. So apparently you don't consider C99 a > complete atrocity. My answer was obviously slightly provocative. In truth, I am no puritan and I do pick sometime things out of C89, like uint32_t, snprintf() and the like. I also appreciate __uint128_t very much, even though it is not part of any standard. For practical purposes I find the gnu89 dialect to suit me pretty well. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-21 05:51 -0800 |
| Message-ID | <86v8ydp57h.fsf@linuxsc.com> |
| In reply to | #164198 |
Mateusz Viste <mateusz@xyz.invalid> writes: > 2021-12-31 at 18:37 -0500, James Kuyper wrote: > >> Calling it ANSI C is not very useful, because that designation is >> ambiguous. > > I was only stating about "my copy of ANSI C". Didn't mean to specify > any more than that, really. > >> uint32_t and uint16_t, both of which are used in your code, were added >> to the language in C99. So apparently you don't consider C99 a >> complete atrocity. > > My answer was obviously slightly provocative. In truth, I am no puritan > and I do pick sometime things out of C89, like uint32_t, snprintf() and > the like. I also appreciate __uint128_t very much, even though it is not > part of any standard. For practical purposes I find the gnu89 dialect > to suit me pretty well. 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. Also, I'm curious to know what extensions, if any, from the gnu additions you make use of.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 15:59 +0100 |
| Message-ID | <ssehod$hfk$1@gioia.aioe.org> |
| In reply to | #164505 |
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. That's only one simple example, but I hope it conveys the larger idea. > Also, I'm curious to know what extensions, if any, from the gnu > additions you make use of. That's an interesting question that I was unable to answer from the top of my head. It has been so long that I code in gnu89 that I wasn't able to tell what exactly is non-vanilla-C89 in the set of C features I use. To answer your question I took a couple of my projects and switched 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() Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-21 16:19 +0100 |
| Message-ID | <sseiun$cf0$1@dont-email.me> |
| In reply to | #164507 |
On 21/01/2022 15:59, Mateusz Viste wrote: > 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. The scope of a variable begins just after the completion of its declarator. /All/ variables in all varieties of C must be declared at the top of their scope, since that's where their scope starts. In C90, local variables can only be declared at the start of a block, before any statements - but they don't have to be at the top of the function. > Fine, but *I* don't like it, as I find > that it encourages sloppy programming. That is contrary to what many others find. Personal preferences are, of course, personal. > 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. > > That's only one simple example, but I hope it conveys the larger idea. > >> Also, I'm curious to know what extensions, if any, from the gnu >> additions you make use of. > > That's an interesting question that I was unable to answer from the top > of my head. It has been so long that I code in gnu89 that I wasn't able > to tell what exactly is non-vanilla-C89 in the set of C features I use. > To answer your question I took a couple of my projects and switched > 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) There is nothing in C90 that prevents the existence and use of a header of that name containing such typedefs. > 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() > None of these are, AFAIK, compiler extensions. They are library functions (and types). The type "__int128" is a gcc extension. (And if you have __uint128_t, presumably it is a typedef of "unsigned __int128".) You might find you are using other gcc extensions without thinking about it, as a number of features of C99 started off as gcc extensions to C90.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 16:51 +0100 |
| Message-ID | <ssekpf$1flc$1@gioia.aioe.org> |
| In reply to | #164508 |
2022-01-21 at 16:19 +0100, David Brown wrote: > The scope of a variable begins just after the completion of its > declarator. /All/ variables in all varieties of C must be declared at > the top of their scope, since that's where their scope starts. > > In C90, local variables can only be declared at the start of a block, > before any statements - but they don't have to be at the top of the > function. My wording was not precise, sorry. When I wrote "scope" I meant "block" indeed. > > __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) > > There is nothing in C90 that prevents the existence and use of a > header of that name containing such typedefs. But then you could say the same about many other things, like the DT_DIR definition or even functions like snprintf(). Yet gcc hides then when called with -std=c89. > None of these are, AFAIK, compiler extensions. They are library > functions (and types). > > The type "__int128" is a gcc extension. (And if you have __uint128_t, > presumably it is a typedef of "unsigned __int128".) Does not look like a typedef, a recursive grep for "uint128" in /usr/include/ does not yield any result. Not that it matters much, of course. > You might find you are using other gcc extensions without thinking > about it Entirely possible, yes, since I am not checking every line of my code against the ANSI/ISO 9899-1990 reference book. :) Mateusz
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-21 12:08 -0500 |
| Message-ID | <ssepah$1gm$1@dont-email.me> |
| In reply to | #164509 |
On 1/21/22 10:51 AM, Mateusz Viste wrote: > 2022-01-21 at 16:19 +0100, David Brown wrote: ... >>> __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) >> >> There is nothing in C90 that prevents the existence and use of a >> header of that name containing such typedefs. > > But then you could say the same about many other things, like the DT_DIR > definition or even functions like snprintf(). Yet gcc hides then when > called with -std=c89. In C89, stdint.h was not a standard header. However, if its implemented as an actual header file (it doesn't have to be), and if that file can be found in the compiler's normal search path (which it needn't be, in C89 mode), it should still be opened and could be processed as if it were a user-written header file. There's no reason for it to contain any features which would prevent it from being parsed as C89 code. The only potential problem is that one or more of the typedefs might be for [unsigned] long long or an extended integer type that the compiler doesn't support in C89 mode. This is actually disproportionately likely to work, because many sources provided C89-compatible versions of stdint.h, for use while waiting for the rest of C99 to be implemented by their preferred compiler. snprintf(), on the other hand, is a C standard library function declared in <stdio.h>, which was introduced in C99, and had a name that was NOT reserved to the implementation in C89. Therefore, strictly conforming C89 code could declare and define an identifier with that same name and external linkage. Therefore, an implementation fully conforming to C89 must not do anything to prevent such code from behaving as required by the C89 standard. In particular, it must NOT declare that identifier in <stdio.h>, and it must not link to a version of the C standard library that contains such a function (unless the linker supports weak identifiers, with your program's own snprintf() being used instead of the library version).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-21 18:14 +0100 |
| Message-ID | <ssepll$4a4$1@dont-email.me> |
| In reply to | #164509 |
On 21/01/2022 16:51, Mateusz Viste wrote: > 2022-01-21 at 16:19 +0100, David Brown wrote: >> The scope of a variable begins just after the completion of its >> declarator. /All/ variables in all varieties of C must be declared at >> the top of their scope, since that's where their scope starts. >> >> In C90, local variables can only be declared at the start of a block, >> before any statements - but they don't have to be at the top of the >> function. > > My wording was not precise, sorry. When I wrote "scope" I meant "block" > indeed. > >>> __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) >> >> There is nothing in C90 that prevents the existence and use of a >> header of that name containing such typedefs. > > But then you could say the same about many other things, like the DT_DIR > definition or even functions like snprintf(). Yet gcc hides then when > called with -std=c89. You could indeed say that about other things. Some C libraries will include functions that are not specified in the standards, others limit themselves more. Some enable functions only if particular C standards are chosen. To be conforming, a standard header should not define symbols that are not in the relevant standard version, and not in the reserved namespaces. For example, you should in a C90 program be able to #include <stdio.h> without clashing with your own declaration for snprintf. Not all implementations (compiler and library combinations, together with flags or other settings) are as conforming as they might be - in particular, gcc (and common Linux C libraries) is not conforming by default and enables a fair number of extensions. And the "-std=gnu89" will enable more of these than "-std=c89". Identifiers that begin with two underscores, such as "__uint128_t", are freely available for an implementation to define regardless of standards. > >> None of these are, AFAIK, compiler extensions. They are library >> functions (and types). >> >> The type "__int128" is a gcc extension. (And if you have __uint128_t, >> presumably it is a typedef of "unsigned __int128".) > A quick check shows that gcc (at least, the version I looked at and on x86-64 target) also defines __int128_t and __uint128_t out of the box. The reference manual only mentions __int128. But gcc pre-defines a whole range of types starting with two underscores that are not documented in the user manual, because they are not intended for normal code - more commonly they provide the bases for typedefs of things like size_t, uintptr_t, and many other types. > Does not look like a typedef, a recursive grep for "uint128" in > /usr/include/ does not yield any result. Not that it matters much, of > course. Indeed. > >> You might find you are using other gcc extensions without thinking >> about it > > Entirely possible, yes, since I am not checking every line of my code > against the ANSI/ISO 9899-1990 reference book. :) > You can use "-std=c90 -Wpedantic" to give warnings on most non-standard code. (If you are interested, of course.)
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 18:25 +0100 |
| Message-ID | <sseq9h$p7v$1@gioia.aioe.org> |
| In reply to | #164513 |
2022-01-21 at 18:14 +0100, David Brown wrote: > > Entirely possible, yes, since I am not checking every line of my > > code against the ANSI/ISO 9899-1990 reference book. :) > > You can use "-std=c90 -Wpedantic" to give warnings on most > non-standard code. (If you are interested, of course.) I know, and I use, but it's still quite tolerant. Even -Wall hides a fair number of warnings. It's why lately I don't use gcc at all and prefer relying on clang with its very cool -Weverything. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-21 20:53 +0100 |
| Message-ID | <ssf2v1$baq$1@dont-email.me> |
| In reply to | #164515 |
On 21/01/2022 18:25, Mateusz Viste wrote: > 2022-01-21 at 18:14 +0100, David Brown wrote: >>> Entirely possible, yes, since I am not checking every line of my >>> code against the ANSI/ISO 9899-1990 reference book. :) >> >> You can use "-std=c90 -Wpedantic" to give warnings on most >> non-standard code. (If you are interested, of course.) > > I know, and I use, but it's still quite tolerant. Even -Wall hides a > fair number of warnings. It's why lately I don't use gcc at all and > prefer relying on clang with its very cool -Weverything. > "-Wall" does not "hide" any warnings - it enables warnings. The name is a bit of a misnomer - if you think of it as "enable warnings that all reasonable code will pass without complaint", you have a better view than if you think it enables all warnings. Remember, gcc is used as a system compiler on many OS's, and has to strike a balance between complaint-free compilation of existing (perhaps decades old) code that has been used successfully with old compiler versions, and giving helpful feedback to developers to aid them write correct code. "-Wextra" enables many more warnings - with most developers disagreeing about some of the warnings, but not agreeing on which ones they disagree about. So expect some fine-tuning to suit your particular preferences and needs. (For my own use, I start with "-Wall -Wextra" and have a number of other options that I enable or disable.) "-Wpedantic" is more specific - it attempts to be strict about warning on anything that the C standards say should have a diagnostic, as well as the use of any gcc extensions (if you have picked a non-extended standard). You might also like "-Wc90-c99-compat", which will warn about using anything from C99 that was not in C90. (No warning system is ever 100% free from false positives or false negatives.) clang's "-Weverything", as I understand it, was never intended to be useful with real code. It is primarily for testing purposes.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-21 22:22 +0100 |
| Message-ID | <ssf87g$19vr$3@gioia.aioe.org> |
| In reply to | #164525 |
2022-01-21 at 20:53 +0100, David Brown wrote: > "-Wall" does not "hide" any warnings - it enables warnings. Yes, but not "all" of them. Some (many!) are still hidden. And I understand the reasons, I just do not agree with them. > clang's "-Weverything", as I understand it, was never intended to be > useful with real code. It is primarily for testing purposes. Perhaps, nonetheless *I* use it extensively in "real" code and I'm very happy with it. Of course I do have to disable a few annoying warnings sometimes (like the one about struct padding), but I prefer enabling all and hand-pick what to ignore, rather than enabling a vague set of defaults and then wonder what possibly I am missing. The advantage of -Weverything is that when I upgrade clang, I get all the newly added cool warnings immediately, without the need to study clang's changelog in the matter. If I don't like the new additions - no problem, I can easily disable them. > You might also like "-Wc90-c99-compat", which will warn about using > anything from C99 that was not in C90. Sounds nice, sadly clang does not know it. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-01-22 13:05 +0100 |
| Message-ID | <ssgrth$d2d$1@dont-email.me> |
| In reply to | #164527 |
On 21/01/2022 22:22, Mateusz Viste wrote: > 2022-01-21 at 20:53 +0100, David Brown wrote: >> "-Wall" does not "hide" any warnings - it enables warnings. > > Yes, but not "all" of them. Some (many!) are still hidden. And I > understand the reasons, I just do not agree with them. > >> clang's "-Weverything", as I understand it, was never intended to be >> useful with real code. It is primarily for testing purposes. > > Perhaps, nonetheless *I* use it extensively in "real" code and I'm very > happy with it. Of course I do have to disable a few annoying warnings > sometimes (like the one about struct padding), but I prefer enabling all > and hand-pick what to ignore, rather than enabling a vague set of > defaults and then wonder what possibly I am missing. > > The advantage of -Weverything is that when I upgrade clang, I get all > the newly added cool warnings immediately, without the need to study > clang's changelog in the matter. If I don't like the new additions - no > problem, I can easily disable them. 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. Some warnings cover things that are very probably a mistake. And some handle things that were allowed in older C standards but are no longer acceptable according to current standards - but the compiler by default accepts them for convenience of using old code. 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. I am a big fan of warning flags and static error checking in general. But blinding saying "enable everything" is no more helpful than blindly disabling everything. Either you have to write convoluted and strange code to avoid tripping any warnings, or your compiler output will be swamped with warning messages that don't indicate a real problem. The situation gets even worse if you use more powerful third-party linters without understanding them and picking the features and warnings that make sense for your usage. > >> You might also like "-Wc90-c99-compat", which will warn about using >> anything from C99 that was not in C90. > > Sounds nice, sadly clang does not know it. > clang and gcc each have their pros and cons.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-22 13:53 +0100 |
| Message-ID | <ssguog$e4s$1@gioia.aioe.org> |
| In reply to | #164535 |
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
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web