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

#164800

On 05/02/2022 17:38, james...@alumni.caltech.edu wrote:
> On Saturday, February 5, 2022 at 10:17:11 AM UTC-5, Bart wrote:
> ...
>> My point is exactly that you don't know what's going on, if not because
>> it's UB, it's because it's implementation defined or for some other
>> weird reason. Take this:
>>
>> _Bool a=0;
>>
>> for (int i=0; i<10; ++i){
>> printf("%d ",a);
>> ++a;
>> }
>>
>> What will be the output? For ++a, it's:
>>
>> 0 1 1 1 1 1 ...
>>
>> But for --a it's:
>>
>> 0 1 0 1 0 1 ...
>>
>> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
>>
>> Try this:
>>
>> a = 1;
>> ++a;
>> --a;
>>
>> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
>> increments, and now the result is 1.
>>
>> _Bool has special semantics compared with int, yet the language still
>> allows you to do all things associated with int.
>>
>> What is type result type of !!? It is int, not _Bool. _Bool is a
>> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
>> values of int, or 0 and non-zero, then I know exactly where I'm at.
> 
> The rules are really quite simple: _Bool expressions get promoted to int values of either 0 or 1, depending upon whether the _Bool value is false or true. During the evaluation of all expressions, those values behave the same as any other int with a value of 0 or 1. On conversion to _Bool, values that compare equal to zero get converted to false, all other values convert to true. Everything you've observed is explained by those simple rules,

It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which 
outputs all zeros. Maybe another non-conforming one?

> except for the behavior you've described for "2 lesser compilers", which is non-conforming. You can't blame C for the behavior of compilers that fail to to conform to its rules.

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

#164802

On 2/5/22 12:57 PM, Bart wrote:
> 
> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which 
> outputs all zeros. Maybe another non-conforming one?

Could the code have been compiled as C++, it uses different rules.

If I remember right, in C++ if x is a bool, then x-- is defined to set x 
false and return the previous value of x, a test and clear instruction.

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

#164815

On 05/02/2022 19:29, Richard Damon wrote:
> On 2/5/22 12:57 PM, Bart wrote:
>>
>> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
>> outputs all zeros. Maybe another non-conforming one?
> 
> Could the code have been compiled as C++, it uses different rules.
> 
> If I remember right, in C++ if x is a bool, then x-- is defined to set x
> false and return the previous value of x, a test and clear instruction.

As far as I can tell, pre- and post-decrement of booleans have never
been allowed in C++.  Pre- and post-increment give "true", matching C.


This is from C++14 (since I happen to have it open) 5.2.6p2 :

"""
The operand of postfix -- is decremented analogously to the postfix ++
operator, except that the operand shall not be of type bool.
"""

It says the same thing about pre-decrement.  Both pre- and
post-increment were deprecated, and removed in C++17.


I think perhaps for his MSVC test, Bart used "BOOL", which is one of the
Windows API's specific types made for C90, and is a typedef for "int".

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

#164818

On 06/02/2022 14:15, David Brown wrote:
> On 05/02/2022 19:29, Richard Damon wrote:
>> On 2/5/22 12:57 PM, Bart wrote:
>>>
>>> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
>>> outputs all zeros. Maybe another non-conforming one?
>>
>> Could the code have been compiled as C++, it uses different rules.
>>
>> If I remember right, in C++ if x is a bool, then x-- is defined to set x
>> false and return the previous value of x, a test and clear instruction.
> 
> As far as I can tell, pre- and post-decrement of booleans have never
> been allowed in C++.  Pre- and post-increment give "true", matching C.
> 
> 
> This is from C++14 (since I happen to have it open) 5.2.6p2 :
> 
> """
> The operand of postfix -- is decremented analogously to the postfix ++
> operator, except that the operand shall not be of type bool.
> """
> 
> It says the same thing about pre-decrement.  Both pre- and
> post-increment were deprecated, and removed in C++17.
> 
> 
> I think perhaps for his MSVC test, Bart used "BOOL", which is one of the
> Windows API's specific types made for C90, and is a typedef for "int".

All tests used _Bool.

BOOL, defined as int, would have given results of 0 1 2 3 ... for ++a, 
and 0 -1 -2 -3 ... for --a.

(I don't know how to put MSVC into C mode, but I suspect it already is. 
A couple of 1000-line C programs, with .c extensions, that fail with 
g++, pass with gcc and MSVC.

Also, while MSVC compiles a C++ hello-world program when it has a .cpp 
extension, it fails dramatically if I change to a .c extension. All my 
tests were .c files.)

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

#164830

Bart <bc@freeuk.com> writes:
[...]
> (I don't know how to put MSVC into C mode, but I suspect it already
> is. A couple of 1000-line C programs, with .c extensions, that fail
> with g++, pass with gcc and MSVC.

You can confirm this by using "class" as an identifier, or, if you want
to be more explicit, something like this:

#ifdef __cplusplus
#error "Compiled as C++"
#endif

> Also, while MSVC compiles a C++ hello-world program when it has a .cpp
> extension, it fails dramatically if I change to a .c extension. All my 
> tests were .c files.)

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

#164799

On Friday, February 4, 2022 at 2:39:14 PM UTC-5, Bart wrote:
...
> union { 
> _Bool a; 
> unsigned char b; 
> } x; 
> 
> x.b=0x55; 
> printf("A= %X\n", x.a); 
> printf("B= %X\n", x.b); 
> 
> if (x.a == true) puts("A is True"); 
> if (x.a == false) puts("A is False"); 
> if (x.a != true && x.a != false) puts("A is neither True nor False"); 
> 
> different compilers show different results, including this from gcc -O0: 
> 
> A= 55 
> B= 55 
> A is True 
> A is False 
> A is neither True nor False 
> 
> MSVC shows this: 
> 
> A= 55 
> B= 55 
> A is neither True nor False 
> 
> while Clang, and gcc -O3, displays: 
> 
> A= 1 
> B= 55 
> A is True 
> 
> You can probably claim this is due to UB or whatever, but the fact 
> remains that using regular int types, the results will be consistent and 
> predictable across all compilers.


Could you name a single type other than char, unsigned char, or signed
char, that could be used to replace _Bool in that code, which would result
in your code having consistent results on all implementations?
Type punning between incompatible types almost always has, at best, 
implementation-defined results. The only reason that signed char would
work is this particular case is that the signed and unsigned versions of char
are mandated to have the same representation for positive values of signed
char, making them semi-compatible. Even that would disappear if your code had
 used a value greater than SCHAR_MAX.

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

#164801

On 05/02/2022 17:50, james...@alumni.caltech.edu wrote:
> On Friday, February 4, 2022 at 2:39:14 PM UTC-5, Bart wrote:
> ...
>> union {
>> _Bool a;
>> unsigned char b;
>> } x;
>>
>> x.b=0x55;
>> printf("A= %X\n", x.a);
>> printf("B= %X\n", x.b);
>>
>> if (x.a == true) puts("A is True");
>> if (x.a == false) puts("A is False");
>> if (x.a != true && x.a != false) puts("A is neither True nor False");
>>
>> different compilers show different results, including this from gcc -O0:
>>
>> A= 55
>> B= 55
>> A is True
>> A is False
>> A is neither True nor False
>>
>> MSVC shows this:
>>
>> A= 55
>> B= 55
>> A is neither True nor False
>>
>> while Clang, and gcc -O3, displays:
>>
>> A= 1
>> B= 55
>> A is True
>>
>> You can probably claim this is due to UB or whatever, but the fact
>> remains that using regular int types, the results will be consistent and
>> predictable across all compilers.
> 
> 
> Could you name a single type other than char, unsigned char, or signed
> char,

Why other than those types? They are the only choices if I wanted an 
8-bit boolean representation. With 'char' used in place of _Bool, then 
all compilers I tried have the same output, that of MSVC above, with 
both members having values of 0x55, and .a being neither true/1 nor 
false/0, which it isn't.

gcc had the most bizarre behaviour where .a was simultaneously both true 
and not true, and both false and not false!

Using a wider type for .a than .b would give more unpredictable results, 
but for reasons that are obvious across all compilers: the top bits of 
.a will be garbage.

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

#164779

On 2/4/22 03:44, Mateusz Viste wrote:
> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>> standard 7.3.14), type always generate only one of two possible
>> values, which is what you need for true boolean semantics. That if
>> very definitely not the case for int_fast8_t.
> 
> int_fast8_t (just like any other integer type) can be either zero or
> non-zero. Why does the exact value of "not zero" matter to you? I mean,
> what kind of practical problems can be solved with _Bool?

I'm far more interested in there being only one representation of
"true", than I am in how it's represented. If you misuse an ordinary
integer type as a substitute for a true boolean type, then equality and
inequality comparisons for that type aren't guaranteed to behave
properly - and that can be a problem. A simple comparison b1==b2, should
return a result of "true" if, and only if, both b1 and b2 are true, but
that would not be guaranteed if you misuse an ordinary integer type as
if it were a boolean type, because it might be the case that b1==3 and
b2==5.

Less importantly, in almost all cases _Bool values get implicitly
promoted to 'int'. You can take advantage of the fact that the resulting
conversion is guaranteed to produce a value of 1 if the value is true,
to write arithmetic expressions involving boolean values that could
break if you're misusing an ordinary integer type as if it were boolean.
5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
wouldn't be guaranteed with an ordinary integer type.

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

#164781

On Friday, 4 February 2022 at 16:07:12 UTC, james...@alumni.caltech.edu wrote:
> On 2/4/22 03:44, Mateusz Viste wrote: 
> > 2022-02-03 at 22:17 -0500, James Kuyper wrote: 
> >> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++ 
> >> standard 7.3.14), type always generate only one of two possible 
> >> values, which is what you need for true boolean semantics. That if 
> >> very definitely not the case for int_fast8_t. 
> > 
> > int_fast8_t (just like any other integer type) can be either zero or 
> > non-zero. Why does the exact value of "not zero" matter to you? I mean, 
> > what kind of practical problems can be solved with _Bool?
> I'm far more interested in there being only one representation of 
> "true", than I am in how it's represented. 
>
In C, true also means "exists". This is very idiomatic:
void whizzystringfunction(char *str)
{
    if (str)
    {
// we've been passed a string, do our whizzy things with it
    }
}

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

#164785

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2/4/22 03:44, Mateusz Viste wrote:
>> 2022-02-03 at 22:17 -0500, James Kuyper wrote:
>>> Conversions to C's _Bool (C standard 6.3.1.2), or C++'s bool (C++
>>> standard 7.3.14), type always generate only one of two possible
>>> values, which is what you need for true boolean semantics. That if
>>> very definitely not the case for int_fast8_t.
>> 
>> int_fast8_t (just like any other integer type) can be either zero or
>> non-zero. Why does the exact value of "not zero" matter to you? I mean,
>> what kind of practical problems can be solved with _Bool?
>
> I'm far more interested in there being only one representation of
> "true", than I am in how it's represented. If you misuse an ordinary
> integer type as a substitute for a true boolean type, then equality and
> inequality comparisons for that type aren't guaranteed to behave
> properly - and that can be a problem. A simple comparison b1==b2, should
> return a result of "true" if, and only if, both b1 and b2 are true, but
> that would not be guaranteed if you misuse an ordinary integer type as
> if it were a boolean type, because it might be the case that b1==3 and
> b2==5.

Quibble: b1==b2 is true iff b1 and b2 are both true *or* they're both
false.

[...]

> Less importantly, in almost all cases _Bool values get implicitly
> promoted to 'int'. You can take advantage of the fact that the resulting
> conversion is guaranteed to produce a value of 1 if the value is true,
> to write arithmetic expressions involving boolean values that could
> break if you're misusing an ordinary integer type as if it were boolean.
> 5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
> wouldn't be guaranteed with an ordinary integer type.

A perhaps more plausible example of that:

    int widget_count = 0;
    widget_count += has_foo_widget;
    widget_count += has_bar_widget;
    ...

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

#164787

On 2/4/22 14:12, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
>> I'm far more interested in there being only one representation of
>> "true", than I am in how it's represented. If you misuse an ordinary
>> integer type as a substitute for a true boolean type, then equality and
>> inequality comparisons for that type aren't guaranteed to behave
>> properly - and that can be a problem. A simple comparison b1==b2, should
>> return a result of "true" if, and only if, both b1 and b2 are true, but
>> that would not be guaranteed if you misuse an ordinary integer type as
>> if it were a boolean type, because it might be the case that b1==3 and
>> b2==5.
>
> Quibble: b1==b2 is true iff b1 and b2 are both true *or* they're both
> false.

Correct. There's only one false value, either way, so I was thinking
mainly about the true values, and as a result worded my statement
incorrectly.


>> Less importantly, in almost all cases _Bool values get implicitly
>> promoted to 'int'. You can take advantage of the fact that the resulting
>> conversion is guaranteed to produce a value of 1 if the value is true,
>> to write arithmetic expressions involving boolean values that could
>> break if you're misusing an ordinary integer type as if it were boolean.
>> 5*b1 + 3*b2 should have a value of either 0, 3, 5, or 8, but that
>> wouldn't be guaranteed with an ordinary integer type.
>
> A perhaps more plausible example of that:
>
> int widget_count = 0;
> widget_count += has_foo_widget;
> widget_count += has_bar_widget;

Agreed - that is a more plausible thing to do.

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

#164780

Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-02-03 at 22:28 +0000, Vir Campestris wrote:
>> I use bool all the time; why would you use anything else? It's a type 
>> that holds 2 values, and the compiler can pick what to use for your 
>> processor. It might be a bit mask, or a 64 bit word. It might even
>> vary with your optimisation settings.
>
>Can you tell what advantage it has over using, say, int_fast8_t?

half as many characters to type, and more precisely identifies function.

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

#164835

On 03/02/2022 22:48, Mateusz Viste wrote:
> 2022-02-03 at 22:28 +0000, Vir Campestris wrote:
>> I use bool all the time; why would you use anything else? It's a type
>> that holds 2 values, and the compiler can pick what to use for your
>> processor. It might be a bit mask, or a 64 bit word. It might even
>> vary with your optimisation settings.
> 
> Can you tell what advantage it has over using, say, int_fast8_t?
> 

It depends on your machine.

I've worked on machines where to read a byte from memory involves 
reading a word, shifting it, then anding with 255.

Writing one back means shifting the byte in a register, reading a word 
from memory, ANDing out the old value, ORing the new one, then writing 
back the word.

I've also worked on ones, albeit not with C, where a character isn't 8 
bits but only 6.

bool lets the compiler pick a type where the architecture can store 2 
values easily.

int_fast8_t is only convenient on machines that have hardware byte 
support. OK, that's most of them, but by no means all.

Andy

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

#164839

2022-02-06 at 22:08 +0000, Vir Campestris wrote:
> bool lets the compiler pick a type where the architecture can store 2 
> values easily.
> 
> int_fast8_t is only convenient on machines that have hardware byte 
> support. OK, that's most of them, but by no means all.

int_fast8_t is convenient on machines that have hardware support for
anything that is at least 8 bits large. I imagine that on a machine
like the one you describe (no bytes, words only) int_fast8_t would be a
word.

Mateusz

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

#164840

2022-02-07 at 09:11 +0100, Mateusz Viste wrote:
> 2022-02-06 at 22:08 +0000, Vir Campestris wrote:
> > bool lets the compiler pick a type where the architecture can store
> > 2 values easily.
> > 
> > int_fast8_t is only convenient on machines that have hardware byte 
> > support. OK, that's most of them, but by no means all.  
> 
> int_fast8_t is convenient on machines that have hardware support for
> anything that is at least 8 bits large.
                           ^^
(should have been "16" obviously) :)

Mateusz

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

#164841

2022-02-07 at 09:13 +0100, Mateusz Viste wrote:
> 2022-02-07 at 09:11 +0100, Mateusz Viste wrote:
> > 2022-02-06 at 22:08 +0000, Vir Campestris wrote:  
> > > bool lets the compiler pick a type where the architecture can
> > > store 2 values easily.
> > > 
> > > int_fast8_t is only convenient on machines that have hardware
> > > byte support. OK, that's most of them, but by no means all.    
> > 
> > int_fast8_t is convenient on machines that have hardware support for
> > anything that is at least 8 bits large.  
>                            ^^
> (should have been "16" obviously) :)

(no it shouldn't, I will stop posting before the morning coffee now)

Mateusz

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

#164858

On 07/02/2022 08:11, Mateusz Viste wrote:
> 2022-02-06 at 22:08 +0000, Vir Campestris wrote:
>> bool lets the compiler pick a type where the architecture can store 2
>> values easily.
>>
>> int_fast8_t is only convenient on machines that have hardware byte
>> support. OK, that's most of them, but by no means all.
> 
> int_fast8_t is convenient on machines that have hardware support for
> anything that is at least 8 bits large. I imagine that on a machine
> like the one you describe (no bytes, words only) int_fast8_t would be a
> word.
> 
.. which means using 64 bits for each boolean. If you cared about space 
you'd probably use a bitmask.

bool tells the compiler what you are going to put in it.

The compiler optimisation settings tell the compiler whether you care 
about speed or size.

As I said originally it's entirely valid for the compiler to put a bunch 
of bools into a bitmask (as long as you never ask for their address!) 
but it can't do that if you've insisted that it store at least 8 bits.

Andy

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

#164859

2022-02-07 at 21:42 +0000, Vir Campestris wrote:
> > int_fast8_t is convenient on machines that have hardware support for
> > anything that is at least 8 bits large. I imagine that on a machine
> > like the one you describe (no bytes, words only) int_fast8_t would
> > be a word.
> >   
> .. which means using 64 bits for each boolean. If you cared about
> space you'd probably use a bitmask.

If I cared about space, then I'd probably use a simple char, because a
bitmask might actually end up taking more space than using a single
byte. If we really are that much space-constrained, then it is
important to also account for all the extra shifting, ANDing and ORing
operations that the program will have to contain for handling the
bitmask each time a flag is accessed.

> bool tells the compiler what you are going to put in it.
> 
> The compiler optimisation settings tell the compiler whether you care 
> about speed or size.

That's delegation. And it's fine, but whatever the compiler chooses to
do is not guaranteed to be what I want... esp. in the extreme context
you suggest (ie. a program so space-constrained that one needs to count
every bit of memory).

> As I said originally it's entirely valid for the compiler to put a
> bunch of bools into a bitmask (as long as you never ask for their
> address!) but it can't do that if you've insisted that it store at
> least 8 bits.

Bitmasks are cool, but not for the reason you mentioned - at least not
from my point of view. I like bitmasks because I find them to be an
elegant and convenient way of passing many flags to a function with a
single argument and still having nice, self-explanatory names (while
not cluttering the function call with all the flags I am not passing).
Having the compiler store bools inside a bitmask is a debatable
feature... We do not get the advantage of function call clarity that a
bitmask provides, but do have its drawbacks (slower to access and more
code required).

Mateusz

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

#164767

On 2/3/22 15:34, Mateusz Viste wrote:
...
> let me ask: what C99 feature do you use, that you wouldn't want to
> loose?

Many of the new features that I especially like are related to floating
point operations, which is of special interest to me because I've
specialized in scientific computer programming. I've marked those with
asterisks below. But the rest would be of interest to me pretty much
regardless of what kind of programming I was doing. Paragraph 5 of the
forward to C99 summarizes the changes from C90. These are the ones I
particularly like:


— more precise aliasing rules via effective type
— restricted pointers
— variable length arrays
— flexible array members
— static and type qualifiers in parameter array declarators
— complex (and imaginary) support in <complex.h>*
— remove implicit int
— reliable integer division
— hexadecimal floating-point constants and %a and %A printf/scanf
conversion specifiers*
— compound literals
— designated initializers
— // comments
— extended integer types and library functions in <inttypes.h> and
<stdint.h>
— remove implicit function declaration
— mixed declarations and code
— new block scopes for selection and iteration statements
— additional math library functions in <math.h> *
— treatment of error conditions by math library functions
(math_errhandling )*
— floating-point environment access in <fenv.h>*
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support*
— the snprintf family of functions in <stdio.h>
— standard pragmas*
— _ _func_ _ predefined identifier
— additional strftime conversion specifiers
— relaxed constraints on aggregate and union initialization
— return without expression not permitted in function that returns a
value (and vice versa)

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

#164788

Mateusz Viste <mateusz@xyz.invalid> writes:

> 2022-02-03 at 10:24 -0800, Tim Rentsch wrote:

[...]

>> If you don't give C99 an earnest try of non-trivial duration,
>> you'll never know.
>
> [...] I do use C99 from time to time on some oddball projects, but
> for my daily stuff I simply don't feel it brings anything on top of
> what I have already with gnu89.  But maybe I missed some key things,
> so let me ask:  what C99 feature do you use, that you wouldn't want
> to loose?

I see this as two or three related questions, which I will try to
answer in turn.  The third of these relates to the question of
using option -std=gnuXX versus option -std=cXX, and is addressed
in the last section.

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')

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

  * '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.
But they are all dangerous, especially implicit declaration of
functions, and it is good that C99 requires them to be flagged.


Second, there are lots of C99 additions (my list has at least 20)
that I find useful.  These span a range of utility but in each
case either they offer something that is at best very inconvenient
to do in C89/C90 or that is only a minor convenience but one I
have gotten used to and would not want to give up.  Here is a
selected subset, in rough order of increasing significance:

Number 10: 'enum' definitions allow a trailing comma.  Only a
convenience feature, but a useful one, and it makes the language
more regular by aligning with the analogous rule for array
initializers.

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.

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

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.

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

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

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

Variadic macros make writing a 'cases()' macro possible (and of
course there are other applications as well).  I /write/ variadic
macros not very often, but I often see situations where /applying/
a variadic macro can make the code cleaner and neater.

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.

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.

Number 1: compound literals and designated initializers.  I put
these two features together because they are often used together
and because there is some synergy between them.  Individually, a
compound literal is often a safer alternative to casting, and
designated initializers provide an easy way of initializing a
sparse array (provided "sparse" means most of the elements are
zero).  There are of course other applications but the last
sentence gives a couple of common examples.

I find myself using most of the features in the above list (not
all certainly, but more than half) in almost every C program I
work on.


Third area: on the matter of -std=gnuXX versus -std=cXX.

Many years ago I didn't pay much attention to differences between
gnu C and ISO standard C.  Little by little I became aware of the
distinction and what some implications are of using one versus
using the other.

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 have seen
this result a lot more often than I would like.

A second key difference is that what "gnu C" means can (and
unfortunately sometimes does) change over time.  Standard C
doesn't have that property (assuming of course we are sticking to
one version of the ISO C standard, such as C99).

I understand that some programs need access to functionality that
simply is not available if compiling as strictly standard C.  In
such cases the use of non-standard options cannot be avoided, but
it can be localized.  If and when problems come up, they will be
easier to deal with by virtue of being confined to a relatively
small and well-defined part of the program.

In times past I had a more laissez faire attitude toward allowing
non-standard compiler options.  What changed my mind was being
bitten when something would work in one place or time and then
not work in another place or time.  Using strictly standard C is
reliable and dependable, and that is worth a lot.  Sometimes it
is necessary to make a (local) pragmatic exception to that rule,
and that's fine, but it's better for program structure and
reliability that such cases be exceptions rather than the usual
choice.

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

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