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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-22 16:59 +0000 |
| Message-ID | <RJWGJ.370432$tX27.294028@fx04.ams4> |
| In reply to | #164528 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >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. Probably not without violating various non-disclosure or employment agreements. In most cases, they were in bare-metal performance critical code (operating systems, hypervisors) in C and C++. One in particular is the code to handle page table walks in an ARM64 processor simulator. Another was handling the fork() system call in a unix-derived MPP operating system. Both in C++. See, for example, the pseudocode for AArch64.S1Translate in ARM's DDI0487G_b on page J1-8110. The C++ version of that is templated to handle both S1 and S2 table walks.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-24 08:01 -0800 |
| Message-ID | <86v8y9m8ba.fsf@linuxsc.com> |
| In reply to | #164543 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> 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. > > Probably not without violating various non-disclosure or employment > agreements. Surely you can find some example that wouldn't go against your existing agreements. Probably even one of the covered examples would be okay if stripped of comments and had all the identifers changed to randomly chosen names (and for good measure take out all extra horizontal white space). The code doesn't have to compile, just show the "shape" of the function; it's unlikely that would be giving away any kind of trade secrets. And it doesn't have to be one of the very longest functions; in fact between 50 and 100 lines is probably easier than some super long monster. (Having said that, I wouldn't mind a much longer function if that's the best you can find.) > One in particular is the code to handle page table walks in > an ARM64 processor simulator. Another was handling the fork() > system call in a unix-derived MPP operating system. Both in C++. This is comp.lang.c. My question is about C code, not C++ code. C++ is a completely different animal.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-24 16:24 +0000 |
| Message-ID | <HoAHJ.12386$1_.5423@fx37.iad> |
| In reply to | #164583 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> 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. >> >> Probably not without violating various non-disclosure or employment >> agreements. > >Surely you can find some example that wouldn't go against your >existing agreements. Probably even one of the covered examples >would be okay if stripped of comments and had all the identifers >changed to randomly chosen names (and for good measure take out >all extra horizontal white space). The code doesn't have to >compile, just show the "shape" of the function; it's unlikely >that would be giving away any kind of trade secrets. And it >doesn't have to be one of the very longest functions; in fact >between 50 and 100 lines is probably easier than some super long >monster. (Having said that, I wouldn't mind a much longer >function if that's the best you can find.) I do tend to honor copyrights, which precludes much of this. > >> One in particular is the code to handle page table walks in >> an ARM64 processor simulator. Another was handling the fork() >> system call in a unix-derived MPP operating system. Both in C++. > >This is comp.lang.c. My question is about C code, not C++ code. >C++ is a completely different animal. No, it's just C with added capabilities. And if I ever get some free time where I have nothing else to do, and your request bubbles up to the top of the future-to-do list, I'll spend the time to find an example and clear it for public display.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-24 17:38 +0000 |
| Message-ID | <tuBHJ.15393$jb4.14798@fx24.iad> |
| In reply to | #164584 |
scott@slp53.sl.home (Scott Lurndal) writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>Surely you can find some example that wouldn't go against your
>>existing agreements.
Ok, a long C function:
/**
* Scaled down version of printf(3).
*
* Two additional formats:
*
* The format %b is supported to decode error registers.
* Its usage is:
*
* <tt>
* printf("reg=%b\n", regval, "\<base\>\<arg\>*");
* </tt>
*
* where \<base\> is the output base expressed as a control character, e.g.
* \\10 gives octal; \\20 gives hex. Each arg is a sequence of characters,
* the first of which gives the bit number to be inspected (origin 1), and
* the next characters (up to a control character, i.e. a character <= 32),
* give the name of the register. Thus:
*
* <tt><pre>
* printf("reg=%b\n", 3, "\10\2BITTWO\1BITONE\n");
* </pre></tt>
*
* would produce output:
*
* <tt>
* reg=3<BITTWO,BITONE>
* </tt>
*
* XXX: %D -- Hexdump, takes pointer and separator string:
* ("%6D", ptr, ":") -> XX:XX:XX:XX:XX:XX
* ("%*D", len, ptr, " " -> XX XX XX XX ...
*
* @param fmt pointer to printf format string
* @param ap pointer to argument list
* @param buf pointer to buffer to receive formatted, zero terminated results
* @param limit number of chars buf can hold, INCLUDING zero termination
* @return the number of chars put into buf, does NOT include zero terminator
*/
size_t
format(const char *fmt, va_list ap, char *buf, size_t limit)
{
/* Reserve one byte for '\0', in buffer overflow case. */
#define PCHAR(c) {int cc=(c); if (retval < (limit - 1)) {*d++ = cc; retval++;} }
char nbuf[MAXNBUF];
char *d = buf;
const char *p, *percent, *q;
uint8 *up;
int ch, n;
uint64 num;
int base, lflag, qflag, tmp, width, ladjust, sharpflag, neg, sign, dot;
int cflag, hflag, jflag, tflag, zflag;
int dwidth;
char padc;
size_t retval = 0;
num = 0;
if (fmt == NULL)
fmt = "(fmt null)\n";
for (;;) {
padc = ' ';
width = 0;
while ((ch = (uint8)*fmt++) != '%') {
if (ch == '\0') {
*d++ = '\0';
retval++;
return (retval);
}
PCHAR(ch);
}
percent = fmt - 1;
qflag = 0; lflag = 0; ladjust = 0; sharpflag = 0; neg = 0;
sign = 0; dot = 0; dwidth = 0;
cflag = 0; hflag = 0; jflag = 0; tflag = 0; zflag = 0;
reswitch: switch (ch = (uint8)*fmt++) {
case '.':
dot = 1;
goto reswitch;
case '#':
sharpflag = 1;
goto reswitch;
case '+':
sign = 1;
goto reswitch;
case '-':
ladjust = 1;
goto reswitch;
case '%':
PCHAR(ch);
break;
case '*':
if (!dot) {
width = va_arg(ap, int);
if (width < 0) {
ladjust = !ladjust;
width = -width;
}
} else {
dwidth = va_arg(ap, int);
}
goto reswitch;
case '0':
if (!dot) {
padc = '0';
goto reswitch;
}
case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
for (n = 0;; ++fmt) {
n = n * 10 + ch - '0';
ch = *fmt;
if (ch < '0' || ch > '9')
break;
}
if (dot)
dwidth = n;
else
width = n;
goto reswitch;
case 'b':
num = (uint32)va_arg(ap, int);
p = va_arg(ap, char *);
for (q = ksprintn(nbuf, num, *p++, NULL); *q;)
PCHAR(*q--);
if (num == 0)
break;
for (tmp = 0; *p;) {
n = *p++;
if (num & (1 << (n - 1))) {
PCHAR(tmp ? ',' : '<');
for (; (n = *p) > ' '; ++p)
PCHAR(n);
tmp = 1;
} else
for (; *p > ' '; ++p)
continue;
}
if (tmp)
PCHAR('>');
break;
case 'c':
PCHAR(va_arg(ap, int));
break;
case 'D':
up = va_arg(ap, uint8 *);
p = va_arg(ap, char *);
if (!width)
width = 16;
while(width--) {
PCHAR(hex2ascii(*up >> 4));
PCHAR(hex2ascii(*up & 0x0f));
up++;
if (width)
for (q=p;*q;q++)
PCHAR(*q);
}
break;
case 'd':
case 'i':
base = 10;
sign = 1;
goto handle_sign;
case 'h':
if (hflag) {
hflag = 0;
cflag = 1;
} else
hflag = 1;
goto reswitch;
case 'j':
jflag = 1;
goto reswitch;
case 'l':
if (lflag) {
lflag = 0;
qflag = 1;
} else
lflag = 1;
goto reswitch;
case 'n':
if (jflag)
*(va_arg(ap, int64 *)) = retval;
else if (qflag)
*(va_arg(ap, int64 *)) = retval;
else if (lflag)
*(va_arg(ap, long *)) = retval;
else if (zflag)
*(va_arg(ap, size_t *)) = retval;
else if (hflag)
*(va_arg(ap, short *)) = retval;
else if (cflag)
*(va_arg(ap, char *)) = retval;
else
*(va_arg(ap, int *)) = retval;
break;
case 'o':
base = 8;
goto handle_nosign;
case 'p':
base = 16;
sharpflag = (width == 0);
sign = 0;
num = (uintptr_t)va_arg(ap, void *);
goto number;
case 'q':
qflag = 1;
goto reswitch;
case 's':
p = va_arg(ap, char *);
if (p == NULL)
p = "(null)";
if (!dot)
n = strlen (p);
else
for (n = 0; n < dwidth && p[n]; n++)
continue;
width -= n;
if (!ladjust && width > 0)
while (width--)
PCHAR(padc);
while (n--)
PCHAR(*p++);
if (ladjust && width > 0)
while (width--)
PCHAR(padc);
break;
case 't':
tflag = 1;
goto reswitch;
case 'u':
base = 10;
goto handle_nosign;
case 'x':
case 'X':
if (dot) {
padc = '0';
}
base = 16;
goto handle_nosign;
case 'y':
base = 16;
sign = 1;
goto handle_sign;
case 'z':
zflag = 1;
goto reswitch;
handle_nosign:
sign = 0;
if (jflag)
num = va_arg(ap, uint64);
else if (qflag)
num = va_arg(ap, uint64);
else if (tflag)
num = va_arg(ap, int64);
else if (lflag)
num = va_arg(ap, uint64);
else if (zflag)
num = va_arg(ap, size_t);
else if (hflag)
num = (uint16)va_arg(ap, int);
else if (cflag)
num = (uint8)va_arg(ap, int);
else
num = va_arg(ap, uint32);
goto number;
handle_sign:
if (jflag)
num = va_arg(ap, int64);
else if (qflag)
num = va_arg(ap, int64);
else if (tflag)
num = va_arg(ap, int64);
else if (lflag)
num = va_arg(ap, long);
else if (zflag)
num = va_arg(ap, size_t);
else if (hflag)
num = (short)va_arg(ap, int);
else if (cflag)
num = (char)va_arg(ap, int);
else
num = va_arg(ap, int);
number:
if (sign && (int64)num < 0) {
neg = 1;
num = -(int64)num;
}
p = ksprintn(nbuf, num, base, &tmp);
if (sharpflag && num != 0) {
if (base == 8)
tmp++;
else if (base == 16)
tmp += 2;
}
if (neg)
tmp++;
if (!ladjust && width && (width -= tmp) > 0)
while (width--)
PCHAR(padc);
if (neg)
PCHAR('-');
if (sharpflag && num != 0) {
if (base == 8) {
PCHAR('0');
} else if (base == 16) {
PCHAR('0');
PCHAR('x');
}
}
while (*p)
PCHAR(*p--);
if (ladjust && width && (width -= tmp) > 0)
while (width--)
PCHAR(padc);
break;
default:
while (percent < fmt)
PCHAR(*percent++);
break;
}
}
#undef PCHAR
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-24 11:28 -0800 |
| Message-ID | <86r18xlyqk.fsf@linuxsc.com> |
| In reply to | #164586 |
scott@slp53.sl.home (Scott Lurndal) writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>> Surely you can find some example that wouldn't go against your >>> existing agreements. > > Ok, a long C function: [...] Good, thank you for tracking down what looks like a good example. Before I look any further, are there any particular aspects you would say are important to pay attention to or that contribute to difficulty in refactoring?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-24 22:44 +0000 |
| Message-ID | <_YFHJ.874$dV.864@fx44.iad> |
| In reply to | #164591 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>> Surely you can find some example that wouldn't go against your
>>>> existing agreements.
>>
>> Ok, a long C function: [...]
>
>Good, thank you for tracking down what looks like a good
>example.
>
>Before I look any further, are there any particular aspects
>you would say are important to pay attention to or that
>contribute to difficulty in refactoring?
Not really, other than that I believe this was derived
from BSD at one point.
Here's the helpers:
#define NBBY 8 /* number of bits in a byte */
/* Max number conversion buffer length: a uint64 in base 2, plus zero byte. */
#define MAXNBUF (sizeof(int64) * NBBY + 1)
char const hex2ascii_data[] = "0123456789abcdefghijklmnopqrstuvwxyz";
#define hex2ascii(hex) (hex2ascii_data[hex])
/**
* Put a NUL-terminated ASCII number (base <= 36) in a buffer in reverse
* order; return an optional length and a pointer to the last character
* written in the buffer (i.e., the first character of the string).
* The buffer pointed to by `nbuf' must have length >= MAXNBUF.
*
* @param nbuf buffer to hold the converted number.
* @param num The value to be converted.
* @param base The radix to be used in converting.
* @param lenp A pointer to where return the pointer to the last character
* written in the buffer. Specify NULL to not have this
* pointer returned.
* @returns A pointer to the start of the output buffer.
*/
static char *
ksprintn(char *nbuf, uint64 num, int base, int *lenp)
{
char *p;
p = nbuf;
*p = '\0';
do {
*++p = hex2ascii(num % base);
} while (num /= base);
if (lenp)
*lenp = p - nbuf;
return (p);
}
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-24 15:34 -0800 |
| Message-ID | <87r18wn1wd.fsf@nosuchdomain.example.com> |
| In reply to | #164597 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>> Surely you can find some example that wouldn't go against your
>>>>> existing agreements.
>>>
>>> Ok, a long C function: [...]
>>
>>Good, thank you for tracking down what looks like a good
>>example.
>>
>>Before I look any further, are there any particular aspects
>>you would say are important to pay attention to or that
>>contribute to difficulty in refactoring?
>
> Not really, other than that I believe this was derived
> from BSD at one point.
>
> Here's the helpers:
>
> #define NBBY 8 /* number of bits in a byte */
Why not just use CHAR_BIT?
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-25 14:50 +0000 |
| Message-ID | <L6UHJ.15869$mS1.11374@fx10.iad> |
| In reply to | #164600 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>> Surely you can find some example that wouldn't go against your
>>>>>> existing agreements.
>>>>
>>>> Ok, a long C function: [...]
>>>
>>>Good, thank you for tracking down what looks like a good
>>>example.
>>>
>>>Before I look any further, are there any particular aspects
>>>you would say are important to pay attention to or that
>>>contribute to difficulty in refactoring?
>>
>> Not really, other than that I believe this was derived
>> from BSD at one point.
^^^
>>
>> Here's the helpers:
>>
>> #define NBBY 8 /* number of bits in a byte */
>
>Why not just use CHAR_BIT?
Was CHAR_BIT available in 1983?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-01-25 18:30 +0000 |
| Message-ID | <87lez31xcs.fsf@bsb.me.uk> |
| In reply to | #164615 |
scott@slp53.sl.home (Scott Lurndal) writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>> >>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>>> >>>>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>>>> >>>>>>> Surely you can find some example that wouldn't go against your >>>>>>> existing agreements. >>>>> >>>>> Ok, a long C function: [...] >>>> >>>>Good, thank you for tracking down what looks like a good >>>>example. >>>> >>>>Before I look any further, are there any particular aspects >>>>you would say are important to pay attention to or that >>>>contribute to difficulty in refactoring? >>> >>> Not really, other than that I believe this was derived >>> from BSD at one point. > ^^^ >>> >>> Here's the helpers: >>> >>> #define NBBY 8 /* number of bits in a byte */ >> >>Why not just use CHAR_BIT? > > Was CHAR_BIT available in 1983? The code does not appear to date from 1983. You have 64-bit integers, size_t, void, function prototypes, uintptr_t and doubtless other things I've missed. In 1983 you could not even rely on what header to include for strlen, malloc, varargs and so on, so for the original 1983-era code you would not have been able to rely on anything in a header(!), but clearly the code has been updated to use many post 1983 features. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-25 18:50 +0000 |
| Message-ID | <jEXHJ.10$h91.3@fx48.iad> |
| In reply to | #164622 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>>> >>>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>>> >>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>>>> >>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>>>>> >>>>>>>> Surely you can find some example that wouldn't go against your >>>>>>>> existing agreements. >>>>>> >>>>>> Ok, a long C function: [...] >>>>> >>>>>Good, thank you for tracking down what looks like a good >>>>>example. >>>>> >>>>>Before I look any further, are there any particular aspects >>>>>you would say are important to pay attention to or that >>>>>contribute to difficulty in refactoring? >>>> >>>> Not really, other than that I believe this was derived >>>> from BSD at one point. >> ^^^ >>>> >>>> Here's the helpers: >>>> >>>> #define NBBY 8 /* number of bits in a byte */ >>> >>>Why not just use CHAR_BIT? >> >> Was CHAR_BIT available in 1983? > >The code does not appear to date from 1983. You have 64-bit integers, >size_t, void, function prototypes, uintptr_t and doubtless other things >I've missed. In 1983 you could not even rely on what header to include >for strlen, malloc, varargs and so on, so for the original 1983-era code >you would not have been able to rely on anything in a header(!), but >clearly the code has been updated to use many post 1983 features. > The original for that came from BSD, probably 4.2ish. It was updated to handle 64-bits when we ported it to the hypervisor 17 years ago.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-01-25 14:42 -0800 |
| Message-ID | <875yq7mo8q.fsf@nosuchdomain.example.com> |
| In reply to | #164615 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>
>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>>
>>>>>>> Surely you can find some example that wouldn't go against your
>>>>>>> existing agreements.
>>>>>
>>>>> Ok, a long C function: [...]
>>>>
>>>>Good, thank you for tracking down what looks like a good
>>>>example.
>>>>
>>>>Before I look any further, are there any particular aspects
>>>>you would say are important to pay attention to or that
>>>>contribute to difficulty in refactoring?
>>>
>>> Not really, other than that I believe this was derived
>>> from BSD at one point.
> ^^^
>>>
>>> Here's the helpers:
>>>
>>> #define NBBY 8 /* number of bits in a byte */
>>
>>Why not just use CHAR_BIT?
>
> Was CHAR_BIT available in 1983?
Oh, *that* BSD, not one of its later derivatives! (I first used C under
BSD 4.1 myself.)
As others have mentioned, the code was updated to use newer features.
Replacing NBBY with CHAR_BIT would have made sense, but it's not a huge
deal.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-25 23:05 +0000 |
| Message-ID | <Mm%HJ.1037$V31.65@fx47.iad> |
| In reply to | #164630 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>>> >>>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>>> >>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>>>>> >>>>>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>>>>> >>>>>>>> Surely you can find some example that wouldn't go against your >>>>>>>> existing agreements. >>>>>> >>>>>> Ok, a long C function: [...] >>>>> >>>>>Good, thank you for tracking down what looks like a good >>>>>example. >>>>> >>>>>Before I look any further, are there any particular aspects >>>>>you would say are important to pay attention to or that >>>>>contribute to difficulty in refactoring? >>>> >>>> Not really, other than that I believe this was derived >>>> from BSD at one point. >> ^^^ >>>> >>>> Here's the helpers: >>>> >>>> #define NBBY 8 /* number of bits in a byte */ >>> >>>Why not just use CHAR_BIT? >> >> Was CHAR_BIT available in 1983? > >Oh, *that* BSD, not one of its later derivatives! (I first used C under >BSD 4.1 myself.) > >As others have mentioned, the code was updated to use newer features. >Replacing NBBY with CHAR_BIT would have made sense, but it's not a huge >deal. Looks like they eliminated it in recent freebsd: https://svnweb.freebsd.org/base/head/sys/kern/subr_prf.c?view=markup starts at line 590.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-29 04:54 -0800 |
| Message-ID | <86ee4qn1m2.fsf@linuxsc.com> |
| In reply to | #164597 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> >>>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>>> >>>>> Surely you can find some example that wouldn't go against your >>>>> existing agreements. >>> >>> Ok, a long C function: [...] >> >> Good, thank you for tracking down what looks like a good >> example. >> >> Before I look any further, are there any particular aspects >> you would say are important to pay attention to or that >> contribute to difficulty in refactoring? > > Not really, other than that I believe this was derived > from BSD at one point. > > Here's the helpers: [...] I got these, thank you. Additional comments in a followup to your posting elsethread.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-01-24 21:50 -0500 |
| Message-ID | <713da016-3175-4d0b-79b6-698d675c2e04@alumni.caltech.edu> |
| In reply to | #164584 |
On 1/24/22 11:24, Scott Lurndal wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: ... >> This is comp.lang.c. My question is about C code, not C++ code. >> C++ is a completely different animal. That's false, but so is the following: > No, it's just C with added capabilities. The C++ standard devotes 8 pages (C.5) to describing differences between the way C and C++ handle a variety of issues, and another pair of pages (C.6) that describe how the version of the C standard library that is supported as part of the C++ standard library differs from the one described by the C standard. That's not a lot out of a standard that runs 1826 pages, but it not entirely negligible, either. Note that those lists do not include the features that C++ has that C doesn't - they're about differences in the way that features shared between the two languages work.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <invalid@invalid.add> |
|---|---|
| Date | 2022-01-25 19:24 +0100 |
| Message-ID | <sspf9d$1877$1@gioia.aioe.org> |
| In reply to | #164602 |
On 1/25/2022 3:50 AM, James Kuyper wrote: > On 1/24/22 11:24, Scott Lurndal wrote: >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > ... >>> This is comp.lang.c. My question is about C code, not C++ code. >>> C++ is a completely different animal. > > That's false, but so is the following: > >> No, it's just C with added capabilities. > > The C++ standard devotes 8 pages (C.5) to describing differences between > the way C and C++ handle a variety of issues, and another pair of pages > (C.6) that describe how the version of the C standard library that is > supported as part of the C++ standard library differs from the one > described by the C standard. That's not a lot out of a standard that > runs 1826 pages, but it not entirely negligible, either. > > Note that those lists do not include the features that C++ has that C > doesn't - they're about differences in the way that features shared > between the two languages work. > All true; it may also be worth recalling that this subthread is about justification of long functions, and that C++ was brought up in this comment: > ... In most cases, they were in bare-metal performance > critical code (operating systems, hypervisors) in C and C++. > > One in particular is the code to handle page table walks in > an ARM64 processor simulator. Another was handling the fork() > system call in a unix-derived MPP operating system. Both in C++. Now, it is one of the goals of C++ compared to C to be able to write more efficient and thus more compact code. I don't think C++ has failed in this respect - the criticism of those who favor C against C++ may be about complexity of the language, or lack of expressiveness in terms of clarity, but not being more verbose than C. In particular, with reference to the example posted elsethread, replacing long 'switch' blocks with more structured constructs is one typical refactoring when porting to C++.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-01-25 18:35 +0000 |
| Message-ID | <zpXHJ.7$h91.1@fx48.iad> |
| In reply to | #164621 |
Manfred <invalid@invalid.add> writes: >On 1/25/2022 3:50 AM, James Kuyper wrote: >> On 1/24/22 11:24, Scott Lurndal wrote: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> ... >>>> This is comp.lang.c. My question is about C code, not C++ code. >>>> C++ is a completely different animal. >> >> That's false, but so is the following: >> >>> No, it's just C with added capabilities. >> >> The C++ standard devotes 8 pages (C.5) to describing differences between >> the way C and C++ handle a variety of issues, and another pair of pages >> (C.6) that describe how the version of the C standard library that is >> supported as part of the C++ standard library differs from the one >> described by the C standard. That's not a lot out of a standard that >> runs 1826 pages, but it not entirely negligible, either. >> >> Note that those lists do not include the features that C++ has that C >> doesn't - they're about differences in the way that features shared >> between the two languages work. >> > >All true; it may also be worth recalling that this subthread is about >justification of long functions, and that C++ was brought up in this >comment: > >> ... In most cases, they were in bare-metal performance >> critical code (operating systems, hypervisors) in C and C++. >> >> One in particular is the code to handle page table walks in >> an ARM64 processor simulator. Another was handling the fork() >> system call in a unix-derived MPP operating system. Both in C++. > >Now, it is one of the goals of C++ compared to C to be able to write >more efficient and thus more compact code. I don't think C++ has failed >in this respect - the criticism of those who favor C against C++ may be >about complexity of the language, or lack of expressiveness in terms of >clarity, but not being more verbose than C. > >In particular, with reference to the example posted elsethread, >replacing long 'switch' blocks with more structured constructs is one >typical refactoring when porting to C++. Can you do that form of refactoring (specifically for a text formatting function such as the implementation of printf posted earlier) without sacrificing performance? C++ basically sucks today if you use the output streams for formatting instead of snprintf style format specifiers, not to mention making maintenance (and L10N/I18N more complicated). (note that the formatting example was used in a bare-metal high-performance hypervisor on small supercomputer written in C++. No libraries, no STL, no exceptions, no RTTI, just C with classes - because every cycle wasted in the hypervisor is not available to user code).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-29 10:05 -0800 |
| Message-ID | <86a6femn7g.fsf@linuxsc.com> |
| In reply to | #164623 |
scott@slp53.sl.home (Scott Lurndal) writes: > Manfred <invalid@invalid.add> writes: > >> On 1/25/2022 3:50 AM, James Kuyper wrote: >> >>> On 1/24/22 11:24, Scott Lurndal wrote: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>> ... >>> >>>>> This is comp.lang.c. My question is about C code, not C++ code. >>>>> C++ is a completely different animal. >>> >>> That's false, but so is the following: >>> >>>> No, it's just C with added capabilities. >>> >>> The C++ standard devotes 8 pages (C.5) to describing differences between >>> the way C and C++ handle a variety of issues, and another pair of pages >>> (C.6) that describe how the version of the C standard library that is >>> supported as part of the C++ standard library differs from the one >>> described by the C standard. That's not a lot out of a standard that >>> runs 1826 pages, but it not entirely negligible, either. >>> >>> Note that those lists do not include the features that C++ has that C >>> doesn't - they're about differences in the way that features shared >>> between the two languages work. >> >> All true; it may also be worth recalling that this subthread is about >> justification of long functions, and that C++ was brought up in this >> comment: >> >>> ... In most cases, they were in bare-metal performance >>> critical code (operating systems, hypervisors) in C and C++. >>> >>> One in particular is the code to handle page table walks in >>> an ARM64 processor simulator. Another was handling the fork() >>> system call in a unix-derived MPP operating system. Both in C++. >> >> Now, it is one of the goals of C++ compared to C to be able to write >> more efficient and thus more compact code. I don't think C++ has failed >> in this respect - the criticism of those who favor C against C++ may be >> about complexity of the language, or lack of expressiveness in terms of >> clarity, but not being more verbose than C. >> >> In particular, with reference to the example posted elsethread, >> replacing long 'switch' blocks with more structured constructs is one >> typical refactoring when porting to C++. > > Can you do that form of refactoring (specifically for a text > formatting function such as the implementation of printf posted > earlier) without sacrificing performance? [further C++ remarks > omitted] Writing in plain C, it isn't difficult to restructure the posted printf-like code into multiple small or reasonably sized functions (no more than 40ish lines, say). The effort needed isn't trivial but it isn't really challenging either. I'm intrigued by the phrase "without sacrificing performance". I see no reason to suppose the performance of a restructured version should be worse than that of the original. (Of course this means on average; most likely some cases would be better and others would be worse, but overall not significantly different.) So I'm wondering why someone would think the performance of the original is going to be better than refactored/restructured alternatives. Looking at subr_prf.c (from the link posted elsethread) offers a clue. The structure of that code is very nearly identical to the code posted here. Looking at the copyright dates, it looks like the subr_prf code was written between about 30 and 35 years ago. At that time there were two significant differences relative to today: processor behavior was less advanced, and compiler technology was less sophisticated. Both of these trends make it more likely that some performance advantage, if there was any, of that earlier code would not accrue for more modern machines when using more modern tools. There are at least two other factors that weigh on the question. One is workload: it is quite possible that alternative A would give better performance than alternative B for one set of inputs, and vice versa for a different set of inputs, and so which alternative is better depends on what distribution of inputs is expected. Another is operating context: these days performance is highly multi-dimensional, being affected by all sorts of things beyond just what sequence of instructions is executed. Here again we might very well see a situation where alternative A is better in one operating environment whereas alternative B is better in a different operating environment. For both of these factors it would be very unusual to see one alternative give better results over all points in the space of plausible scenarios. So it may be the case that the posted code would do better than some proposed restructing, for its expected workload and intended operating environment, etc. Without more specifics, however, the proposition remains unconvincing.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-01-21 20:46 +0000 |
| Message-ID | <875yqc3jge.fsf@bsb.me.uk> |
| 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;
> res = malloc(a);
> if (res == NULL) goto GAMEOVER;
>
> return(res);
>
> GAMEOVER:
> free(res);
> return(NULL);
> }
As is so often the case with made-up examples, this raises more
questions than it answers. fn seems to me to be this:
char *fn(int a) {
if (a > 0)
return malloc(a);
return 0;
}
or, as I'd write it,
char *fn(int a) { return a > 0 ? malloc(a) : 0; }
Maybe there was some implied use of res before returning, so the
variable would be needed:
char *fn(int a) {
if (a > 0) {
char *res = malloc(a);
if (res) {
/* make use of res here before returning */
return res;
}
}
return 0;
}
but again, no need to initialise res anywhere but at the start of a
block.
Avoiding C99 mixed declarations and statements will, sometimes, require
an object to be initialised where it would not otherwise need to be, but
this code is not an example of that.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-01-21 17:32 -0800 |
| Message-ID | <867daspnbt.fsf@linuxsc.com> |
| In reply to | #164507 |
Mateusz Viste <mateusz@xyz.invalid> writes: I'm responding in several parts to help keep the various aspects separate. > 2022-01-21 at 05:51 -0800, Tim Rentsch wrote: > >> 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. [.. list to be addressed in subsequent followup ..] That was interesting, thank you. Can I ask you to repeat the experiment with -std=c89 -pedantic-errors (and no other warnings or errors enabled) to see if that yields any additional items? Also if it isn't too much bother, with -std=c99 -pedantic-errors. I am most curious to see if anything else turns up (in either of the tests).
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2022-01-22 09:57 +0100 |
| Message-ID | <ssggu0$9p4$1@gioia.aioe.org> |
| In reply to | #164531 |
2022-01-21 at 17:32 -0800, Tim Rentsch wrote: > That was interesting, thank you. Can I ask you to repeat the > experiment with -std=c89 -pedantic-errors In fact that was the case already, albeit I use -pedantic in lieu of -pedantic-errors to avoid stopping early if possible. > Also if it isn't too much bother, with -std=c99 -pedantic-errors. I didn't see any new errors. There was a lot less errors/warnings overall, which is not surprising since c99 brings some of the extensions present in gnu89. The fact that there was less warnings made me spot two that I hadn't noticed earlier (although they are present in both -c89 and -c99): DT_LNK initgroups() So to answer your question: no, -c99 did not result in any new errors compared to -c89. I wonder, though - why did you think it could? Isn't c99 a superset of c89? The only possible reason I see is that when compiling in -c89, make could abort earlier since it will stop at the first module file in error, hence some of the C files won't even be looked at. Is that what you thought about? Mateusz
[toc] | [prev] | [next] | [standalone]
Page 3 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