Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #164141 > unrolled thread

How to avoid an overflow during multiplication?

Back to article view | Back to comp.lang.c

Contents

  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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9  Next page →

#164790

2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
> I see this as two or three related questions, which I will try to
> answer in turn.

Thanks for the time you took to answer this in such a well-structured
and concise way. Much appreciated.

> First there are several constructs that C89/C90 permits but are
> disallowed in C99:
>   * calls to functions not previously declared are implicitly
>     declared (with nothing known about the parameter types, and
>     as returning type 'int')

That's a problem only in theory, because in practice compilers warn
about it anyway. At least these that I use do (gcc and clang, with -Wall
-pedantic). Such program:

  int main(void) { return(poo(1)); }
  int poo(kupa) { return(kupa); }

Triggers a warning with both gcc and clang, in both std=c89 and std=c99
(in all cases I use the -Wall flag, as I always do with all my code):

poo.c:1:25: warning: implicit declaration of function ‘poo’

Hence, while I agree with you on the theoretical annoyance of implicit
function declaration, it does not appear to be a practical concern.

>   * declarations (especially functions) are allowed not to give
>     a type specifier, in which case the type defaults to 'int'

Same story as above. gcc and clang both emit this, in both c89 and c99
modes with -pedantic:

for unspecified function type:
poo.c:2:1: warning: return type defaults to ‘int’

for unspecified parameter type:
poo.c:2:9: warning: parameter 'kupa' was not declared, defaulting to
type 'int'

>   * 'return' statements need not give an expression in a
>     function that returns a non-void type, and conversely

I have to admit I didn't know about that. But again, compilers
warn about this in both c89 and c99 modes:

clang (warns even without any extra warning flags):
poo.c:2:18: warning: non-void function does not return a value

gcc (requires -Wall):
poo.c:2:1: warning: control reaches end of non-void function

The function I tested was simply this:
int poo(kupa) {  }

> Number 10: 'enum' definitions allow a trailing comma.  Only a
> convenience feature, but a useful one

I think it is nice only because it limits the amount of changed lines
when adding a new value at the end of the list, so an svn diff is one
line shorter. But then I always wonder: did the programmer forgot about
some terminating entry, or did he leave this useless comma there on
purpose?

> Number 9: array parameters may have 'static' and 'const' etc.
> Normally I use array notation (eg, 'int x[]') for parameters
> that are treated as arrays rather than as pointers to single
> objects.  This feature allows length and qualifier information to
> be added to the pointer parameter while still retaining array
> notation in the parameter declaration.

I am not sure I understand this one (and I also never use array
notation in function parameters). Are you referring to such construct?

  void pupa(const char s[]) {
    printf("%c", s[0]);
  }

Apparently this passes without warnings in both c89 and c99 modes of
clang and gcc. But I probably misunderstood you.

> Number 8: 'va_copy' macro.  I found 'va_copy' indispensable
> while implementing an extension to printf().

I never needed this, but this certainly depends on the kind of programs
one writes. Anyway, va_copy() is part of gnu89.

> Number 7: 'long long' type (and library functions).  It's nice to
> have an integer type that is guaranteed to be at least 64 bits,
> which C89/C90 doesn't have.

I agree, and I routinely use int64_t types in c89 mode (requires
including stdint.h).

> Number 6: snprintf and friends.  Needed for safe formatting.

Agreed, I use them very often. They are part of gnu89.

> Number 5: restricted pointers.  Especially when a function has
> parameters that are pointers to characters, 'restrict' can help a
> lot with quality of generated code (because of aliasing concerns).

I find it's an optimization feature that is a burden to the programmer,
and that can lead to new bugs due to opening extra UB possibilities.
But I'd be curious to see benchmarks that demonstrate the practical
performance gain that may be achieved. Perhaps it's worth it in some
limited, performance-critical parts of code.

> Number 4: variadic macros.

In over 20 years of C I think that I used a variadic macro maybe two
times. :) And IIRC this was the reason I switched to C99 for these
projects, at least temporarily (because each time the macro was some
dirty hack that wasn't meant to stay in production code).

> Number 3: variably modified types.  Variable length arrays are
> sometimes problematic because of the danger of stack overflow.
> But variably modified types, which are akin to VLAs but not the
> same, provide similar benefits without the associated risk of
> blowing the stack.

I know VLAs because I have been bitten by them in the past, but the
Variably Modified Types *without* the concept of VLAs is a new one to
me. Would you mind providing a short example where such VMT-without-VLA
is used meaningfully?

> Number 2: non-constant block-level initializers for structs and
> arrays.  In C89/C90 initializers for structs and array must have
> constant values for each element, including variables that are
> function locals.  In C99 this limitation is removed, avoiding the
> need to do element-by-element assignment for what is logically
> just an initialization.

Saves a memcpy() call (on paper, not in implementation)... ok, why not.

> Number 1: compound literals and designated initializers.

The idea here, as I understand it, is to pass structs or unions to
functions without having to declare them first. As such:

  #include <stdio.h>

  struct t { int x, y; };

  static void poo(struct t p) {
    printf("x = %d , y = %d\n", p.x, p.y);
  }

  int main(void) {
    poo((struct t){0, 1});
    return(0);
  }

I wondered for a while what practical use I could have of it, and the
only place I was able to find quickly is for calling select() without
declaring a timeout struct first. But that would work only if I do not
need to read the struct back (and often I do, and yes I know it's a
despicable linuxism). You put it as #1 reason for C99, though, so I
imagine there must be some other hugely interesting uses that I don't
see right away. I will keep that in mind in my future code, looking for
occasions where it could be a win.

> One key difference is that when using standard C you know what
> you're getting.  To say that another way, standard C can be
> counted on to be the same across different platforms.  Conversely
> it is frustrating to take a program that compiles under gnu C
> on one platform but doesn't on a different platform.

I understand your point, really, but I consider this to be rather a
matter of aesthetics. Whether you have an ISO C program with
platform-dependent functions in a separate file or a gnu89 program, the
end result won't differ that much... In both cases you will have to
spend some time to port the thing if target platform changes.


To sum up - from the list you kindly provided there are some things that
are simply diagnostics, and these are available in compilers also in
C89. Other things are nice additions to C89 and that they are also
available in gnu89 (if one accepts using gnu89). One or two features
that are of disputable interest (because they depend on individual
needs probably), and then one or two that are potentially interesting. I
don't see any revolution that would change my coding life, but
nonetheless I will keep an eye on those one or two potentially
interesting things in the context of my daily work.


Mateusz

[toc] | [prev] | [next] | [standalone]

#164803

On 2/5/22 05:40, Mateusz Viste wrote:
> 2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
...
>> Number 9: array parameters may have 'static' and 'const' etc.
>> Normally I use array notation (eg, 'int x[]') for parameters
>> that are treated as arrays rather than as pointers to single
>> objects.  This feature allows length and qualifier information to
>> be added to the pointer parameter while still retaining array
>> notation in the parameter declaration.
> 
> I am not sure I understand this one (and I also never use array
> notation in function parameters). Are you referring to such construct?
> 
>   void pupa(const char s[]) {
>     printf("%c", s[0]);
>   }
> 
> Apparently this passes without warnings in both c89 and c99 modes of
> clang and gcc. But I probably misunderstood you.

He's referring to two separate features that were introduced in C99. In
all versions of standard C, all three of the following declarations have
exactly the same meaning:

void func(int []);
void func(int [25536]);
void func(int *);

This only applies to the leading dimension of pointers that are declared
as if they were arrays.

And the same is true of the corresponding K&R style definitions:
void func(a)
	int a[];
{
}

void func(a)
	int a[25536];
{
}

void func(a)
	int *a;
{
}

You can debate the desirability of this feature, but it goes all the way
back to K&R C, and there's lots of code written using each of the three
different ways a pointer parameter can be declared.

In C99, the committee added the feature that you could put one or more
qualifiers (const, volatile, or restrict) into the first dimension of a
pointer parameter declared as if it was an array, and the effect would
be the same as if the qualifier was used in the appropriate location in
an ordinary pointer declaration:

int qualified(int array[const]);

means exactly the same thing as

int qualified(const int *array);

In C2011, _Atomic was added to the list of qualifiers.

The other feature is that you can declare a function parameter as follows:

double limited(float [static 36]);

"If the keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression." (7.5.3p7).

Violating this "shall" has undefined behavior (4p2), which doesn't sound
like much of an advantage. However, that also allows implementations to
warn you with a diagnostic, if they can determine that your code might
violate that requirement. If they can determine that it will
unconditionally violate that requirement, they can even reject the
program at compile time. It's that non-mandatory diagnostic that I
consider valuable. It cannot, unfortunately, be made mandatory, because
in many cases it's difficult, and often even impossible, to determine at
compile time whether a piece of code will violate that requirement. But
when it can be determined, I consider that a very valuable warning. YMMV.

[toc] | [prev] | [next] | [standalone]

#164806

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 2/5/22 05:40, Mateusz Viste wrote:
>> 2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
> ...
>>> Number 9: array parameters may have 'static' and 'const' etc.
>>> Normally I use array notation (eg, 'int x[]') for parameters
>>> that are treated as arrays rather than as pointers to single
>>> objects.  This feature allows length and qualifier information to
>>> be added to the pointer parameter while still retaining array
>>> notation in the parameter declaration.
>> 
>> I am not sure I understand this one (and I also never use array
>> notation in function parameters). Are you referring to such construct?
>> 
>>   void pupa(const char s[]) {
>>     printf("%c", s[0]);
>>   }
>> 
>> Apparently this passes without warnings in both c89 and c99 modes of
>> clang and gcc. But I probably misunderstood you.
>
> He's referring to two separate features that were introduced in C99.
<cut>
> In C99, the committee added the feature that you could put one or more
> qualifiers (const, volatile, or restrict) into the first dimension of a
> pointer parameter declared as if it was an array, and the effect would
> be the same as if the qualifier was used in the appropriate location in
> an ordinary pointer declaration:
>
> int qualified(int array[const]);
>
> means exactly the same thing as
>
> int qualified(const int *array);

I don't think so.  It means the same as

  int qualified(int *const array);

6.7.6.3 p7:

  A declaration of a parameter as "array of type" shall be adjusted to
  "qualified pointer to type", where the type qualifiers (if any) are
  those specified within the [ and ] of the array type derivation.

It is the implied pointer that is qualified.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#164811

On 2/5/22 18:30, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
>> In C99, the committee added the feature that you could put one or more
>> qualifiers (const, volatile, or restrict) into the first dimension of a
>> pointer parameter declared as if it was an array, and the effect would
>> be the same as if the qualifier was used in the appropriate location in
>> an ordinary pointer declaration:
>>
>> int qualified(int array[const]);
>>
>> means exactly the same thing as
>>
>> int qualified(const int *array);
>
> I don't think so. It means the same as
>
> int qualified(int *const array);
>
> 6.7.6.3 p7:
>
> A declaration of a parameter as "array of type" shall be adjusted to
> "qualified pointer to type", where the type qualifiers (if any) are
> those specified within the [ and ] of the array type derivation.
>
> It is the implied pointer that is qualified.

You're right, of course. I remembered it backwards, and didn't check. I
should have realized my mistake, because the feature wouldn't be needed
if it worked the way I specified - qualifiers before the '*' can be
specified just as easily when declaring a pointer parameter as if it
were an array, as when declaring it explicitly as a pointer.

[toc] | [prev] | [next] | [standalone]

#164816

On 05/02/2022 19:46, James Kuyper wrote:

> The other feature is that you can declare a function parameter as follows:
> 
> double limited(float [static 36]);
> 
> "If the keyword static also appears within the [ and ] of the array type
> derivation, then for each call to the function, the value of the
> corresponding actual argument shall provide access to the first element
> of an array with at least as many elements as specified by the size
> expression." (7.5.3p7).
> 
> Violating this "shall" has undefined behavior (4p2), which doesn't sound
> like much of an advantage. However, that also allows implementations to
> warn you with a diagnostic, if they can determine that your code might
> violate that requirement. If they can determine that it will
> unconditionally violate that requirement, they can even reject the
> program at compile time. It's that non-mandatory diagnostic that I
> consider valuable. It cannot, unfortunately, be made mandatory, because
> in many cases it's difficult, and often even impossible, to determine at
> compile time whether a piece of code will violate that requirement. But
> when it can be determined, I consider that a very valuable warning. YMMV.
> 

This would also mean that :

	double limited(float [static 1]);

is equivalent to :

	double limited(float *);

except that you may not pass a null pointer to a call in the first case.
 Again, this gives the compiler a chance to do some more helpful
diagnostics (as well as documenting requirement in the code).

[toc] | [prev] | [next] | [standalone]

#166160

(Sorry for delay, I just found this somehow went in a file folder
instead of outbox)

On Fri, 04 Feb 2022 21:14:59 -0800, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote:

> Mateusz Viste <mateusz@xyz.invalid> writes:
> > so let me ask:  what C99 feature do you use, that you wouldn't want
> > to loose?
...
> First there are several constructs that C89/C90 permits but are
> disallowed in C99:
...
>   * 'return' statements need not give an expression in a
>     function that returns a non-void type, and conversely
> 
> I understand why K&R C (and later C89/C90) allowed these things.
...
Not conversely. return expr in void function was a constraint
violation in C89/90. (And impossible in K&R which had no void.)

[toc] | [prev] | [next] | [standalone]

#166166

dave_thompson_2@comcast.net writes:

> (Sorry for delay, I just found this somehow went in a file folder
> instead of outbox)
>
> On Fri, 04 Feb 2022 21:14:59 -0800, Tim Rentsch
> <tr.17687@z991.linuxsc.com> wrote:
>
>> Mateusz Viste <mateusz@xyz.invalid> writes:
>>
>>> so let me ask:  what C99 feature do you use, that you wouldn't want
>>> to loose?
>
> ...
>
>> First there are several constructs that C89/C90 permits but are
>> disallowed in C99:
>
> ...
>
>>   * 'return' statements need not give an expression in a
>>     function that returns a non-void type, and conversely
>>
>> I understand why K&R C (and later C89/C90) allowed these things.
>
> ...
> Not conversely.  return expr in void function was a constraint
> violation in C89/90.  (And impossible in K&R which had no void.)

Thank you for the follow-up (and no worries about the delay).

To the best of my knowledge all of the following are true
statements.

K&R C did not have a void type (although some pre-standard C
compilers may have had support for void).

In both the ANSI C standard (C89) and the first ISO C standard
(C90), a return statement with an expression is a constraint
violation if it appears in a function whose return type is void
(although some pre-standard C compilers may not have observed
this rule).

K&R C, C89, and C90 all allow things like this:

    int
    f(){
        ...
        return;
    }

    g(){
        ...
        return  0;
    }

In the ISO C99 standard, paragraph 5 in the Foreword says (in
part) the following:

    This second edition cancels and replaces the first edition,
    ISO/IEC 9899:1990, as amended and corrected by ISO/IEC
    9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and ISO/IEC
    9899/COR2:1996.  Major changes from the previous edition
    include:

        [...]

        -- return without expression not permitted in function
           that returns a value (and vice versa)

I hope these observations clarify my earlier comment.

[toc] | [prev] | [next] | [standalone]

#166161

On 2/4/2022 9:14 PM, Tim Rentsch wrote:
> 
> First there are several constructs that C89/C90 permits but are
> disallowed in C99:
> 
>    * calls to functions not previously declared are implicitly
>      declared (with nothing known about the parameter types, and
>      as returning type 'int')

True.

>    * declarations (especially functions) are allowed not to give
>      a type specifier, in which case the type defaults to 'int'


With one remark: in C89/90 a declaration has to specify at least one 
declaration-specifier, which is a storage-class-specifier, 
type-specifier or a type-qualifier. Declarations that have none are 
illegal in C89/90

   /* File scope */
   foo();        /* this is not a valid declaration */
   const bar();  /* this is a valid declaration, implicit `int` */
   static baz(); /* this is a valid declaration, implicit `int` */

The only exception from this rule is function *definitions*, which are 
governed by a separate branch of grammar

   qux() {} /* this is a valid definition, implicit `int` */

>    * 'return' statements need not give an expression in a
>      function that returns a non-void type, and conversely

True, but not the "conversely" part. Supplying an expression to a 
`return` statement in a `void` function is a constraint violation.

> 
> Number 4: variadic macros.  Compare this fragment
> 
>      case 1: case 2: case 3: case 4:
>      case 5: case 6: case 7: case 8: case 9:
> 
> with this fragment
> 
>      cases(1,2,3,4,5,6,7,8,9):

Well, the latter is a constraint violation in all versions of standard 
C. Comma operator is not allowed in constant expressions. It is C++ that 
lifted that restriction, but in C it still stands.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#166162

On 5/14/2022 12:04 PM, Andrey Tarasevich wrote:
>> Number 4: variadic macros.  Compare this fragment
>>
>>      case 1: case 2: case 3: case 4:
>>      case 5: case 6: case 7: case 8: case 9:
>>
>> with this fragment
>>
>>      cases(1,2,3,4,5,6,7,8,9):
> 
> Well, the latter is a constraint violation in all versions of standard 
> C. Comma operator is not allowed in constant expressions. It is C++ that 
> lifted that restriction, but in C it still stands.


Oh... My mistake. Apparently I misunderstood what was being said. You 
mean that `cases` is a macro that unfolds into a bunch of separate 
`case` labels. Got it. No problems then.

I missed the fact that it is spelled as `cases`. I misread it as

   case (1,2,3,4,5,6,7,8,9):

which would be legal in modern C++, but not in C.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#166167

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 2/4/2022 9:14 PM, Tim Rentsch wrote:
>
>> First there are several constructs that C89/C90 permits but are
>> disallowed in C99:
>>
>>    * calls to functions not previously declared are implicitly
>>      declared (with nothing known about the parameter types, and
>>      as returning type 'int')
>
> True.
>
>>    * declarations (especially functions) are allowed not to give
>>      a type specifier, in which case the type defaults to 'int'
>
> With one remark:  in C89/90 a declaration has to specify at least
> one declaration-specifier, [...]

Yes, the statement is only about type specifiers, not other
declaration specifiers.

>>    * 'return' statements need not give an expression in a
>>      function that returns a non-void type, and conversely
>
> True, but not the "conversely" part.  Supplying an expression to a
> return` statement in a `void` function is a constraint violation.

A post from Dave Thompson gave this same observation, and I have
just now responded to his posting.

[toc] | [prev] | [next] | [standalone]

#164181

Mateusz Viste <mateusz@xyz.invalid> writes:
> 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"

The 1990 ISO C standard is nearly equivalent to the 1989 ANSI C
standard.  A major difference is that the sections were renumbered.  In
the 1989 edition, the core language was in section 3.  In the 1990 ISO
standard, it's section 6.

>> 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. :-)

Strictly speaking, the term "ANSI C" is ambiguous.  People often use it
to refer to the language defined by the 1989 ANSI C standard, but in
fact ANSI has officially adopted each new ISO C standard edition and
considers the previous editions to be obsolete.  I suggest referring to
"C90" rather than "ANSI C".

-- 
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]

#164158

On 31/12/2021 14:24, Mateusz Viste wrote:

> 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;
> 
Hacks like that are common and, IMHO, entirely reasonable on limited
power small systems.  I've used them regularly.

The risk, however, is that you make mistakes about when things can
overflow - particularly if something changes.  It can all work fine for
a while until someone changes a scaling constant or range limits
somewhere else in the program, and you've got a silent bug.

Often you can reduce that risk by having the value "3" here calculated
automatically from the ranges, or at least defined in the same place as
any other relevant constants along with suitable comments.  If you can,
it is a good idea to use static assertions to get compile-time failures
if something is going to go wrong:

_Static_assert(MAX_TICKS * ((tempo << 3) / grouplen)) < 0x100000000,
	"Check that multiplication does not overflow");


"_Static_assert" was introduced in C11, but you can use macro-based
equivalents prior to that.  I can post a useable definition if you need one.

[toc] | [prev] | [next] | [standalone]

#164160

2021-12-31 at 16:17 +0100, David Brown wrote:
> > return (ticks * (((tempo << 3) / grouplen))) >> 3;
> >   
> Hacks like that are common and, IMHO, entirely reasonable on limited
> power small systems.  I've used them regularly.

Ah, so I didn't invent anything... again.
Good, so it's not as stupid as I initially thought then.

> Often you can reduce that risk by having the value "3" here calculated
> automatically from the ranges, or at least defined in the same place
> as any other relevant constants along with suitable comments.  If you
> can, it is a good idea to use static assertions to get compile-time
> failures if something is going to go wrong

Good idea. Thanks!

Mateusz

[toc] | [prev] | [next] | [standalone]

#164168

Le 31/12/2021 à 14:41, Stefan Ram a écrit :
> Mateusz Viste <mateusz@xyz.invalid> wrote:
>> 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
> 
> |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.

Yep. Which, by the way, is a pretty funny way of defining "never 
overflowing".

Yes, in C it's very straightforward. Arithmetic operations on unsigned 
are always modulo 2^N, with N the number of bits of the resulting type.

So indeed, they can't overflow. The result is just effectively truncated 
if it *would* overflow.

Now make sure you understand the implications of doing your operations 
modulo 2^N.

[toc] | [prev] | [next] | [standalone]

#164145

Am 31.12.2021 um 11:02 schrieb Mateusz Viste:

> uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo)
> {
>    return ticks * tempo / grouplen;
      return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen);

On x86 f.e. the compiler will still use a 32 * 32 multiplication
because it sees that the casted value's upper halves are zero.
And after / grouplen you can safely cast the result to uint32_t.

[toc] | [prev] | [next] | [standalone]

#164146

On Friday, 31 December 2021 at 14:53:24 UTC+2, Bonita Montero wrote:
> Am 31.12.2021 um 11:02 schrieb Mateusz Viste: 
> 
> > uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo) 
> > { 
> > return ticks * tempo / grouplen;
> return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen); 
> 
> On x86 f.e. the compiler will still use a 32 * 32 multiplication 
> because it sees that the casted value's upper halves are zero. 

I suspect that minority of programmers work on code that should
run on x86 right now. OP did not indicate that they are among such. 

> And after / grouplen you can safely cast the result to uint32_t.

[toc] | [prev] | [next] | [standalone]

#164148

Am 31.12.2021 um 14:10 schrieb Öö Tiib:
> On Friday, 31 December 2021 at 14:53:24 UTC+2, Bonita Montero wrote:
>> Am 31.12.2021 um 11:02 schrieb Mateusz Viste:
>>
>>> uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo)
>>> {
>>> return ticks * tempo / grouplen;
>> return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen);
>>
>> On x86 f.e. the compiler will still use a 32 * 32 multiplication
>> because it sees that the casted value's upper halves are zero.
> 
> I suspect that minority of programmers work on code that should
> run on x86 right now. OP did not indicate that they are among such.

There are a lot of CPUs that have Vx * Vx = V2x multiplications.
ARM also.

[toc] | [prev] | [next] | [standalone]

#164163

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>On Friday, 31 December 2021 at 14:53:24 UTC+2, Bonita Montero wrote:
>> Am 31.12.2021 um 11:02 schrieb Mateusz Viste: 
>> 
>> > uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t tempo) 
>> > { 
>> > return ticks * tempo / grouplen;
>> return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen); 
>> 
>> On x86 f.e. the compiler will still use a 32 * 32 multiplication 
>> because it sees that the casted value's upper halves are zero. 
>
>I suspect that minority of programmers work on code that should
>run on x86 right now. OP did not indicate that they are among such. 

Indeed, and the OP subsequently clarified that it is a 16-bit
microcontroller.

[toc] | [prev] | [next] | [standalone]

#164164

2021-12-31 at 16:16 GMT, Scott Lurndal wrote:
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
> >On Friday, 31 December 2021 at 14:53:24 UTC+2, Bonita Montero wrote:
> > 
> >> Am 31.12.2021 um 11:02 schrieb Mateusz Viste: 
> >>   
> >> > uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t
> >> > tempo) { 
> >> > return ticks * tempo / grouplen;  
> >> return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen); 
> >> 
> >> On x86 f.e. the compiler will still use a 32 * 32 multiplication 
> >> because it sees that the casted value's upper halves are zero.   
> >
> >I suspect that minority of programmers work on code that should
> >run on x86 right now. OP did not indicate that they are among such.
> > 
> 
> Indeed, and the OP subsequently clarified that it is a 16-bit
> microcontroller.

Did not.
I said "16-bit Intel 80C86". You can't be more "x86" than that. :)

Mateusz

[toc] | [prev] | [next] | [standalone]

#164149

2021-12-31 at 13:53 +0100, Bonita Montero wrote:
> Am 31.12.2021 um 11:02 schrieb Mateusz Viste:
> 
> > uint32_t ticks2time(uint32_t ticks, uint32_t grouplen, uint16_t
> > tempo) {
> >    return ticks * tempo / grouplen;  
>       return (uint32_t)((uint64_t)ticks * (uint64_t)tempo / grouplen);
> 
> On x86 f.e. the compiler will still use a 32 * 32 multiplication
> because it sees that the casted value's upper halves are zero.
> And after / grouplen you can safely cast the result to uint32_t.

I should have mentioned what CPU I run this on, my bad. It is an Intel
80C86. 7 MHz, no FPU. Using 64 bits in any way is not really an option.

The machine is this one specifically: https://youtu.be/8ssDGBTssUI?t=97

Mateusz

[toc] | [prev] | [next] | [standalone]

Page 7 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