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

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

*rubeyes*: realloc(ptr, 0) is UB?

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

Contents

  *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 00:32 +0000
    Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-17 01:57 +0000
      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 02:32 +0000
        Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-17 03:06 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 03:08 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-17 03:34 +0000
    Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-17 11:37 +0100
      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 17:47 +0000
        Re: *rubeyes*: realloc(ptr, 0) is UB? BGB <cr88192@gmail.com> - 2024-01-17 12:39 -0600
    Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:27 +0000
      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 17:57 +0000
        Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 22:13 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 22:31 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-18 00:23 -0800
            Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-18 15:14 +0000
              Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-18 13:26 -0500
                Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 19:31 +0000
                  Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-18 15:01 -0500
                    Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 22:43 +0000
                      Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 15:14 -0800
                      Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-18 16:13 -0800
                        Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 03:06 +0000
                          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 03:47 -0800
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 10:21 +0000
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 18:54 +0000
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:01 -0800
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-23 09:35 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 09:08 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:56 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 05:51 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-24 23:37 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 07:54 -0800
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-26 21:04 +0000
                                          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:39 -0800
                        Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-19 20:29 +0000
                          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 21:35 +0000
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 03:08 -0800
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:32 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-25 09:08 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 18:49 +0000
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:35 -0800
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-25 11:45 -0800
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 13:40 -0800
                                          Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-26 09:27 +0100
                                            Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-29 13:21 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 12:20 -0800
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-28 18:17 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 01:02 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-28 20:09 -0500
                          Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-19 13:37 -0800
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 21:50 +0000
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-19 14:16 -0800
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 03:25 -0800
                              Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-21 11:55 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 09:41 -0800
                                Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 12:22 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-21 20:34 +0000
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-21 21:54 +0100
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 21:20 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-22 09:20 +0100
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-21 13:31 -0800
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 21:49 +0000
                                          Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-21 22:09 +0000
                                            Re: *rubeyes*: realloc(ptr, 0) is UB? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-21 23:49 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-22 09:24 +0100
                                          Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:09 +0000
                                            Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-23 09:28 +0100
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-21 21:37 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 17:05 -0800
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 17:09 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 21:16 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 17:14 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 17:04 -0800
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-22 02:05 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-21 18:37 -0800
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-22 11:55 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-22 12:00 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:08 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-21 20:51 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 10:22 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-22 11:27 +0000
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 19:36 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-22 20:40 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? bart <bc@freeuk.com> - 2024-01-22 22:14 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-22 14:38 -0800
                                          Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-22 14:40 -0800
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 22:45 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-22 14:54 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 23:05 +0000
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 04:04 -0800
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-22 12:36 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 08:23 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 08:27 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:34 +0000
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 04:42 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Spiros Bousbouras <spibou@gmail.com> - 2024-01-22 19:23 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:20 -0800
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 06:55 -0800
                        Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-20 19:50 -0800
                          Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-21 05:11 +0000
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 05:20 +0000
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 14:38 -0800
                          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 14:33 -0800
                            Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-21 15:04 -0800
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 08:12 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 08:06 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 18:17 +0000
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 18:43 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Richard Kettlewell <invalid@invalid.invalid> - 2024-01-22 19:11 +0000
                                      Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 02:46 +0000
                                        Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 14:54 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:08 -0800
                              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 19:28 -0800
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:33 +0000
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 07:46 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 07:44 +0000
                                Re: *rubeyes*: realloc(ptr, 0) is UB? David Brown <david.brown@hesbynett.no> - 2024-01-24 10:41 +0100
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:34 -0800
                                    Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 02:47 -0800
                                  Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-24 12:23 -0500
                        Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 05:10 -0800
              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 15:41 -0800
      Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-17 17:46 -0800
        Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-18 15:12 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-18 20:47 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 22:45 +0000
              Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-18 23:47 +0000
                Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 00:03 +0000
                Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-19 21:11 +0000
                  Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 21:31 +0000
              Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-18 23:48 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:34 -0800
          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-19 16:14 -0800
            Re: *rubeyes*: realloc(ptr, 0) is UB? scott@slp53.sl.home (Scott Lurndal) - 2024-01-20 00:26 +0000
              Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 11:53 -0800
    Re: *rubeyes*: realloc(ptr, 0) is UB? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-17 23:03 +0000
      Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 00:10 +0000
        Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-17 17:38 -0800
        Re: *rubeyes*: realloc(ptr, 0) is UB? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-18 22:20 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 22:47 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-19 16:27 +0000
              Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-19 16:39 +0000
                Re: *rubeyes*: realloc(ptr, 0) is UB? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-22 23:12 +0000
                  Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 01:16 -0500
                    Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-23 22:15 -0800
                    Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-25 13:27 -0500
          Re: *rubeyes*: realloc(ptr, 0) is UB? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-18 18:37 -0500
      Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-17 17:35 -0800
        Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-18 05:54 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 05:59 +0000
            Re: *rubeyes*: realloc(ptr, 0) is UB? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-18 06:59 +0000
          Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-18 00:18 -0800
        Re: *rubeyes*: realloc(ptr, 0) is UB? Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-18 22:21 +0000
    Re: *rubeyes*: realloc(ptr, 0) is UB? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-17 17:45 -0800

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#380288 — *rubeyes*: realloc(ptr, 0) is UB?

I'm looking at the C99 and N3096 (April 2023) definitions of realloc
side by side.

N3096 says 

"Otherwise, if ptr does not match a pointer earlier returned by a memory
management function, or if the space has been deallocated by a call to
the free or realloc function, or if the size is zero, the behavior is
undefined."

Yikes! In C99 there is nothing about the size being zero:

"Otherwise, if ptr does not match a pointer earlier returned by the
calloc, malloc, or realloc function, or if the space has been
deallocated by a call to the free or realloc function, the behavior is
undefined."

Nothing about "or if the size is zero".

Yikes; when did this criminal stupidity get perpetrated?

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[toc] | [next] | [standalone]

#380295

On Wed, 17 Jan 2024 00:32:10 -0000 (UTC), Kaz Kylheku wrote:

> Nothing about "or if the size is zero".

From <https://manpages.debian.org/3/realloc.en.html>:

    If size is equal to zero, and ptr is not NULL, then the call is
    equivalent to free(ptr) (but see "Nonportable behavior" for
    portability issues).

And from the referenced section:

    The behavior of these functions when the requested size is zero is
    glibc specific; other implementations may return NULL without setting
    errno, and portable POSIX programs should tolerate such behavior.

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

#380297

On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 00:32:10 -0000 (UTC), Kaz Kylheku wrote:
>
>> Nothing about "or if the size is zero".
>
> From <https://manpages.debian.org/3/realloc.en.html>:
>
>     If size is equal to zero, and ptr is not NULL, then the call is
>     equivalent to free(ptr) (but see "Nonportable behavior" for
>     portability issues).

That is just garbage documentation though. No case in realloc
is equivalent to just free(ptr) and nothing else.

> And from the referenced section:
>
>     The behavior of these functions when the requested size is zero is
>     glibc specific; other implementations may return NULL without setting
>     errno, and portable POSIX programs should tolerate such behavior.

None of those choices is simply "undefined behavior". This is just the
old concept that implementations may have malloc(0) returning null, or
else allocate a unique pointer that can be liberated via free.

Previously, realloc(ptr, 0) behaved like free(ptr) followed by
returning the result of malloc(0).

What we see in N3096 is that this resize to zero is undefined behavior,
while malloc(0) remains well-defined.

Thus applications which previously relied on that case of realloc
now have to do this:

  void *classic_realloc(void *ptr, size_t size)
  {
    // Handle zero size case as was required in C99,
    // thereby avoiding undefined behavior.

    if (size == 0) {
      free(ptr);
      return malloc(0);
    }

    // Pass other cases to realloc.
    return realloc(ptr, size);
  }

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380301

On Wed, 17 Jan 2024 02:32:41 -0000 (UTC), Kaz Kylheku wrote:

> That is just garbage documentation though.

You’re talking about what the C spec says, I’m talking about POSIX.

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

#380302

On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 02:32:41 -0000 (UTC), Kaz Kylheku wrote:
>
>> That is just garbage documentation though.
>
> You’re talking about what the C spec says, I’m talking about POSIX.

Oh, I'm sorry, am I in the wrong newsgroup?

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380304

On Wed, 17 Jan 2024 03:08:22 -0000 (UTC), Kaz Kylheku wrote:

> Oh, I'm sorry, am I in the wrong newsgroup?

No need to apologize, just leave quietly.

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

#380319

On 17/01/2024 01:32, Kaz Kylheku wrote:
> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
> side by side.
> 
> N3096 says
> 
> "Otherwise, if ptr does not match a pointer earlier returned by a memory
> management function, or if the space has been deallocated by a call to
> the free or realloc function, or if the size is zero, the behavior is
> undefined."
> 
> Yikes! In C99 there is nothing about the size being zero:
> 
> "Otherwise, if ptr does not match a pointer earlier returned by the
> calloc, malloc, or realloc function, or if the space has been
> deallocated by a call to the free or realloc function, the behavior is
> undefined."
> 
> Nothing about "or if the size is zero".
> 
> Yikes; when did this criminal stupidity get perpetrated?
> 


Nothing stops a particular library implementation from giving this all a 
defined behaviour.  It was already "implementation defined" - if you 
want to be able to use malloc or realloc with size 0, then you need to 
know exactly how your library says it will behave or your code will risk 
serious problems.

While I don't know why this change was made, and I agree it sounds a 
strange change to make, I cannot see how any code would be affected by 
it.  Either your code is non-portable and relies on specific behaviour 
(documented by your particular library, or additional standards such as 
POSIX), or it has portability issues that could lead to failures if it 
is used with a library that doesn't match your guessed behaviour - the C 
standards making this UB does not change anything.

All this means, in my eyes, is that developers are being encouraged to 
take responsibility for size zero allocations in their own code - make 
an active choice about how they will deal with it (if it can occur in 
their code).  After all, there is no single appropriate choice of 
behaviour for malloc or realloc of zero size - the best way to handle it 
will depend on the user program.

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

#380348

On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
> On 17/01/2024 01:32, Kaz Kylheku wrote:
>> Yikes; when did this criminal stupidity get perpetrated?
>> 
>
> Nothing stops a particular library implementation from giving this all a 
> defined behaviour.

Nothings stops getchar() from being locally defined as an extension;
let's make it undefined behavior!

An entire language can be defined by an implementation, with no
standard.

People use plenty of these and tech marches on.

> It was already "implementation defined" - if you 
> want to be able to use malloc or realloc with size 0, then you need to 
> know exactly how your library says it will behave or your code will risk 
> serious problems.

No, not serious. Very minor problems in a rare combination of
circumstances.

It's possible that realloc(ptr, 0) will return null, and this null
indicates that the reallocation failed due to OOM, meaning that ptr is
still valid.

This situation is indistinguishable from ptr having been freed,
and the null just being the result of a working zero size allocation.

(Implementations can easily resolve the ambiguity internally and
guarantee that realloc(ptr, 0) will free the object, and not
leak ptr.)

> While I don't know why this change was made, and I agree it sounds a 
> strange change to make, I cannot see how any code would be affected by 
> it.  Either your code is non-portable and relies on specific behaviour 
> (documented by your particular library, or additional standards such as 
> POSIX), or it has portability issues that could lead to failures if it 
> is used with a library that doesn't match your guessed behaviour - the C 
> standards making this UB does not change anything.

It isn't nonportable. Dynamic array management code can resize an object
down to zero (as an alternative to freeing it). There is no problem with
this (other than the possible ambiguity under OOM conditions). In the
abstract semantics, the old object is freed, and you get a new one as if
from malloc(0).

Code can easily be written not to care whether malloc(0) returns null
or non-null.

> All this means, in my eyes, is that developers are being encouraged to 
> take responsibility for size zero allocations in their own code - make 

Working code that relies on zero size allocations already (even if
that isn't the best alternative in that code) won't fix itself to become
defined again.

> an active choice about how they will deal with it (if it can occur in 
> their code).  After all, there is no single appropriate choice of 
> behaviour for malloc or realloc of zero size - the best way to handle it 
> will depend on the user program.

A malloc of zero size is still defined; only realloc to zero size is
no longer defined. If you pretend that the remark about size zero isn't
there in the description of realloc, the rest of the description of
realloc still says that the old object will be freed, and the new one
will come as if from a malloc request for that size.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380357

On 1/17/2024 11:47 AM, Kaz Kylheku wrote:
> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>> On 17/01/2024 01:32, Kaz Kylheku wrote:
>>> Yikes; when did this criminal stupidity get perpetrated?
>>>
>>
>> Nothing stops a particular library implementation from giving this all a
>> defined behaviour.
> 
> Nothings stops getchar() from being locally defined as an extension;
> let's make it undefined behavior!
> 
> An entire language can be defined by an implementation, with no
> standard.
> 
> People use plenty of these and tech marches on.
> 

And then Clang goes and decides to make any use of these functions cause 
the whole control-flow path to be pruned from existence or something...
Since, after all, it is UB...

( Partly satire, but wouldn't exactly be surprised... )


>> It was already "implementation defined" - if you
>> want to be able to use malloc or realloc with size 0, then you need to
>> know exactly how your library says it will behave or your code will risk
>> serious problems.
> 
> No, not serious. Very minor problems in a rare combination of
> circumstances.
> 
> It's possible that realloc(ptr, 0) will return null, and this null
> indicates that the reallocation failed due to OOM, meaning that ptr is
> still valid.
> 
> This situation is indistinguishable from ptr having been freed,
> and the null just being the result of a working zero size allocation.
> 
> (Implementations can easily resolve the ambiguity internally and
> guarantee that realloc(ptr, 0) will free the object, and not
> leak ptr.)
> 

Yeah, find something sensible to do and do it.
Knowing modern compilers, declaring anything as UB throws a big wrench 
into things.


>> While I don't know why this change was made, and I agree it sounds a
>> strange change to make, I cannot see how any code would be affected by
>> it.  Either your code is non-portable and relies on specific behaviour
>> (documented by your particular library, or additional standards such as
>> POSIX), or it has portability issues that could lead to failures if it
>> is used with a library that doesn't match your guessed behaviour - the C
>> standards making this UB does not change anything.
> 
> It isn't nonportable. Dynamic array management code can resize an object
> down to zero (as an alternative to freeing it). There is no problem with
> this (other than the possible ambiguity under OOM conditions). In the
> abstract semantics, the old object is freed, and you get a new one as if
> from malloc(0).
> 
> Code can easily be written not to care whether malloc(0) returns null
> or non-null.
> 

Yes.


>> All this means, in my eyes, is that developers are being encouraged to
>> take responsibility for size zero allocations in their own code - make
> 
> Working code that relies on zero size allocations already (even if
> that isn't the best alternative in that code) won't fix itself to become
> defined again.
> 
>> an active choice about how they will deal with it (if it can occur in
>> their code).  After all, there is no single appropriate choice of
>> behaviour for malloc or realloc of zero size - the best way to handle it
>> will depend on the user program.
> 
> A malloc of zero size is still defined; only realloc to zero size is
> no longer defined. If you pretend that the remark about size zero isn't
> there in the description of realloc, the rest of the description of
> realloc still says that the old object will be freed, and the new one
> will come as if from a malloc request for that size.
> 

Agreed.

My personal preference is that behaviors be kept "sensible" when possible.



At least in my own compiler, I generally try for sensible behaviors.
   But, within the limit that the compiler may also be buggy...

Finding and fixing bugs is a priority, but as I see it, things like 
optimization concerns (or esoteric edge cases) should not be 
justification for deviating from otherwise sensible behavior (and 
instead limited to cases that would not otherwise be visible to the 
program in question).

Granted, I would also prefer it if compilers were not allowed to make 
optimizations which may change the visible behavior of a program (at 
least within "sane" limits) but, alas... ( Say, we put the burden of 
proof on the compiler that an optimization does not change the visible 
output or behavior of the program. ).

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

#380344

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>I'm looking at the C99 and N3096 (April 2023) definitions of realloc
>side by side.
>
>N3096 says 
>
>"Otherwise, if ptr does not match a pointer earlier returned by a memory
>management function, or if the space has been deallocated by a call to
>the free or realloc function, or if the size is zero, the behavior is
>undefined."
>
>Yikes! In C99 there is nothing about the size being zero:
>
>"Otherwise, if ptr does not match a pointer earlier returned by the
>calloc, malloc, or realloc function, or if the space has been
>deallocated by a call to the free or realloc function, the behavior is
>undefined."
>
>Nothing about "or if the size is zero".
>
>Yikes; when did this criminal stupidity get perpetrated?

I'm not sure what stupidity you are referring to, but IIRC, there was
some recent standardization activity relating to realloc
when size == 0 because there were differences in the behavior
between different implementations.   Making the behavior
undefined was the only rational choice.

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

#380350

On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>Yikes; when did this criminal stupidity get perpetrated?
>
> I'm not sure what stupidity you are referring to, but IIRC, there was
> some recent standardization activity relating to realloc
> when size == 0 because there were differences in the behavior
> between different implementations.   Making the behavior
> undefined was the only rational choice.

No, the rational choice is letting those implementations be
nonconforming, until they fix their shit.

You cannot claw back decades-old defined behaviors in a major
language standard because some players are getting it wrong
in some way.

I now have to do things like this in all the code I work on:

  void *sane_realloc(void *ptr, size_t size)
  {
    if (size == 0) {
      free(ptr);
      return malloc(0); // don't care if that didn't work
    }
    return realloc(ptr, size);
  }
 
or, if I don't suspect realloc-to-zero is being used:

  void *sane_realloc(void *ptr, size_t size)
  {
    assert (size != 0);
    return realloc(ptr, size);
  }

and this is code that will never even run on those rogue implementations
whose botchery lead to the poor decision of the language being damaged.

Any implementation of realloc whatsoever could just do this internally:

  void *realloc(void *ptr, size_t size)
  {
    if (size == 0) {
      __free(ptr);
      return __malloc(0);
    }
    // call our internal __realloc implementation that
    // we suspect doesn't handle zero.
    return __realloc(ptr, size);
  }

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380376

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>Yikes; when did this criminal stupidity get perpetrated?
>>
>> I'm not sure what stupidity you are referring to, but IIRC, there was
>> some recent standardization activity relating to realloc
>> when size == 0 because there were differences in the behavior
>> between different implementations.   Making the behavior
>> undefined was the only rational choice.
>
>No, the rational choice is letting those implementations be
>nonconforming, until they fix their shit.
>
>You cannot claw back decades-old defined behaviors in a major

Nobody is clawing anything back.  No compiler is going to
change its behavior because undefined behavior is now
called undefined behavior.

Everything that's been done for decades will still work just
fine.

Realloc with a length zero  - never - made any sense anyway.


>language standard because some players are getting it wrong
>in some way.
>
>I now have to do things like this in all the code I work on:
>
>  void *sane_realloc(void *ptr, size_t size)
>  {
>    if (size == 0) {
>      free(ptr);
>      return malloc(0); // don't care if that didn't work
>    }
>    return realloc(ptr, size);
>  }

You can also just never call sane_realloc with a size of zero.

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

#380379

On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>Yikes; when did this criminal stupidity get perpetrated?
>>>
>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>> some recent standardization activity relating to realloc
>>> when size == 0 because there were differences in the behavior
>>> between different implementations.   Making the behavior
>>> undefined was the only rational choice.
>>
>>No, the rational choice is letting those implementations be
>>nonconforming, until they fix their shit.
>>
>>You cannot claw back decades-old defined behaviors in a major
>
> Nobody is clawing anything back.  No compiler is going to
> change its behavior because undefined behavior is now
> called undefined behavior.

What? The behavior was defined in the absence of the new piece of text
saying that the behavior of realloc is arbitrarily undefined when size
is zero.

> Everything that's been done for decades will still work just
> fine.

Even if nothing changes in the library implementation of realloc, a
highly optimizing compiler can now treat everything after a realloc(ptr,
0) as unreachable code:

  void f(void *p)
  {
     realloc(p, 0);
  }

This function can be compiled the same as:

  void f(void *p)
  {
     __builtin_unreachable();
  }

This is not something that the library people can keep fully working by
simply not messing with realloc.

> Realloc with a length zero  - never - made any sense anyway.

Yes it does; in a dynamic vector type, you can tell the thing to resize
to zero size. If that API is implemented with realloc, it now has
undefined behavior according to n3096.

>>language standard because some players are getting it wrong
>>in some way.
>>
>>I now have to do things like this in all the code I work on:
>>
>>  void *sane_realloc(void *ptr, size_t size)
>>  {
>>    if (size == 0) {
>>      free(ptr);
>>      return malloc(0); // don't care if that didn't work
>>    }
>>    return realloc(ptr, size);
>>  }
>
> You can also just never call sane_realloc with a size of zero.

That could be more work. You have to identify what does that,
if anything, and fix it.

If your project already has a wrapper for realloc, it's easy
to fix it there.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380402

scott@slp53.sl.home (Scott Lurndal) writes:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>
>>>> Yikes; when did this criminal stupidity get perpetrated?
>>>
>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>> some recent standardization activity relating to realloc
>>> when size == 0 because there were differences in the behavior
>>> between different implementations.   Making the behavior
>>> undefined was the only rational choice.
>>
>> No, the rational choice is letting those implementations be
>> nonconforming, until they fix their shit.
>>
>> You cannot claw back decades-old defined behaviors in a major
>
> Nobody is clawing anything back.  [...]

This statement seems directly contradicted by the proposed
modification to the C standard, which changes previously
defined behavior to undefined behavior.

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

#380412

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>
>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>
>>>>> Yikes; when did this criminal stupidity get perpetrated?
>>>>
>>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>>> some recent standardization activity relating to realloc
>>>> when size == 0 because there were differences in the behavior
>>>> between different implementations.   Making the behavior
>>>> undefined was the only rational choice.
>>>
>>> No, the rational choice is letting those implementations be
>>> nonconforming, until they fix their shit.
>>>
>>> You cannot claw back decades-old defined behaviors in a major
>>
>> Nobody is clawing anything back.  [...]
>
>This statement seems directly contradicted by the proposed
>modification to the C standard, which changes previously
>defined behavior to undefined behavior.

Clawing back implies that existing programs that rely
on either behavior will stop working.

That's not the case in the real world.

From the application portability point of view, there is little
difference between implementation defined and undefined behavior.

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

#380418

On 1/18/24 10:14, Scott Lurndal wrote:
...
> From the application portability point of view, there is little
> difference between implementation defined and undefined behavior.

There's a big difference when there's only a limited range of permitted
behaviors, as in this case. It's entirely feasible to write code that
copes with both possibilities, which won't be able to deal with the
infinite variety of behaviors allowed when the behavior is undefined.
The behavior of non __STDC__ pragmas is implementation-defined, but it's
almost the same as  undefined behavior. There's some implicit
restrictions: since pragmas are recognized as such in translation phase
4, they cannot affect behavior that occurs during translation phases
1-3. Most other kinds of implementation-defined behavior are
substantially more restricted than that.
It's been said that real-world implementations won't take advantage of
this undefined behavior - but I think that's optimistic thinking.

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

#380422

On 2024-01-18, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 1/18/24 10:14, Scott Lurndal wrote:
> ...
>> From the application portability point of view, there is little
>> difference between implementation defined and undefined behavior.
>
> There's a big difference when there's only a limited range of permitted
> behaviors, as in this case. It's entirely feasible to write code that
> copes with both possibilities, which won't be able to deal with the
> infinite variety of behaviors allowed when the behavior is undefined.

Perhaps what Scott means that it doesn't matter because all the
implementations you're targetting will play nice and continue to define
the behavior as before, so you will be relying on a documented
extension.

You only have to deal with the infinite variety of behaviors when you're
not relying on a documented extension, but on disassembly of code and
extensive testing. For this specific feature, that doesn't even begin to
be economic; what you do is write a realloc wrapper which provides the
old behavior(s) and doesn't step on the UB.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380426

On 1/18/24 14:31, Kaz Kylheku wrote:
...
> Perhaps what Scott means that it doesn't matter because all the
> implementations you're targetting will play nice and continue to define
> the behavior as before, ...

I already addressed that point - confidence that implementations will
play nice is unjustified.

> ... so you will be relying on a documented
> extension.

You need to make sure what behavior is actually documented in that case
by each implementation. I remember one famous bug that was due to an
implementation documenting that, when a particular option was chosen,
code which could only be reached if certain kinds of undefined behavior
occurred would be removed. This is a valid optimization, because there's
no requirements that any particular thing occur when the behavior is
undefined - in particular, there's no requirement that the otherwise
unreachable code be executed. It can be a useful optimization, because
it removes dead code, reducing the size of the executable.
Someone wrote such code, with incorrect expectations about what would
happen when the behavior was undefined, when in fact it wouldn't be
executed at all. They compiled it with that option turned on (it wasn't
even on by default, but only when explicitly requested), and got upset
when the relevant code was in fact removed.
It's OK to rely upon the requirements imposed by an implementation when
the C standard doesn't impose any - but when you do so, you need to make
sure you actually know what those requirements are.

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

#380439

On 2024-01-18, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> It's OK to rely upon the requirements imposed by an implementation when
> the C standard doesn't impose any - but when you do so, you need to make
> sure you actually know what those requirements are.

Exactly, and in this specific case, it's not worth the effort compared
to writing a realloc wrapper that avoids the undefined behavior, while
itself providing a C99 conforming one.

I'm not going to use realloc(ptr, 0) and check everyone's documentation.

And then what if I don't find it defined? The what? Back to the
wrapper I could have just written in the first place.

We could have system-specific #ifdefs to make the wrapper a trivial
inline job that just calls realloc versus something meaty.

I hate testing for specific systems; it's a better process to check
for *features*, like 

  #if HAVE_BRAINDAMAGED_REALLOC
  ...
  #else

I like to have these features auto-detected. This cannot be
auto-detected; the build configuration machinery would have to fall back
on checking for specifi compilers/versions and libraries/versions.

In the end I will just have a CPU-cycle-wasting wrapper for all
platforms.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

#380442

On 1/18/2024 2:43 PM, Kaz Kylheku wrote:
> On 2024-01-18, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> It's OK to rely upon the requirements imposed by an implementation when
>> the C standard doesn't impose any - but when you do so, you need to make
>> sure you actually know what those requirements are.
> 
> Exactly, and in this specific case, it's not worth the effort compared
> to writing a realloc wrapper that avoids the undefined behavior, while
> itself providing a C99 conforming one.
> 
> I'm not going to use realloc(ptr, 0) and check everyone's documentation.
> 
> And then what if I don't find it defined? The what? Back to the
> wrapper I could have just written in the first place.
> 
> We could have system-specific #ifdefs to make the wrapper a trivial
> inline job that just calls realloc versus something meaty.
> 
> I hate testing for specific systems; it's a better process to check
> for *features*, like
> 
>    #if HAVE_BRAINDAMAGED_REALLOC
>    ...
>    #else

Made me literally laugh out loud! Thanks! :^)


> 
> I like to have these features auto-detected. This cannot be
> auto-detected; the build configuration machinery would have to fall back
> on checking for specifi compilers/versions and libraries/versions.
> 
> In the end I will just have a CPU-cycle-wasting wrapper for all
> platforms.
> 
> 

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

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web