Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #380288 > unrolled thread
| Started by | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| First post | 2024-01-17 00:32 +0000 |
| Last post | 2024-01-17 17:45 -0800 |
| Articles | 20 on this page of 154 — 16 participants |
Back to article view | Back to comp.lang.c
*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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-21 05:20 +0000 |
| Message-ID | <20240120211754.732@kylheku.com> |
| In reply to | #380558 |
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > On Sat, 20 Jan 2024 19:50:31 -0800, Keith Thompson wrote: > >> If realloc(ptr, 0) returns a null pointer there's no way to tell whether >> allocation failed (and ptr has not been freed) ... > > Actually, that doesn’t seem like a reasonable interpretation, because it > leads to memory leaks. That's not an "interpretation"; that's just a fact. A null return from realloc has two documented meanings; situations exist in which it cannot be distinguished which one, in any portable way. -- 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]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-21 14:38 -0800 |
| Message-ID | <868r4igvn7.fsf@linuxsc.com> |
| In reply to | #380560 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: > On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > >> On Sat, 20 Jan 2024 19:50:31 -0800, Keith Thompson wrote: >> >>> If realloc(ptr, 0) returns a null pointer there's no way to tell whether >>> allocation failed (and ptr has not been freed) ... >> >> Actually, that doesn?t seem like a reasonable interpretation, because it >> leads to memory leaks. > > That's not an "interpretation"; that's just a fact. > > A null return from realloc has two documented meanings; situations exist > in which it cannot be distinguished which one, in any portable way. I don't agree that they can't be distinguished in _any_ portable way. I suppose a case could be made that they can't be distinguished in any _convenient_ portable way. But that's not the same as _any_ portable way.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-21 14:33 -0800 |
| Message-ID | <86cytugvve.fsf@linuxsc.com> |
| In reply to | #380556 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Kaz Kylheku <433-929-6894@kylheku.com> writes: >> >>> 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. >> >> [...] >> >> I think I would have *liked* to see C23 drop the special permission >> to return a null pointer for a requested size of zero. C11 says (and >> this applies to malloc, realloc, and all other allocation functions): >> >> If the space cannot be allocated, a null pointer is returned. If >> the size of the space requested is zero, the behavior is >> implementation-defined: either a null pointer is returned, or >> the behavior is as if the size were some nonzero value, except >> that the returned pointer shall not be used to access an object. >> >> This could have been changed to: >> >> If the space cannot be allocated, a null pointer is returned. If >> the size of the space requested is zero, the behavior is as >> if the size were some nonzero value, except that the returned >> pointer shall not be used to access an object. >> >> Any existing implementations that always return a null pointer >> for malloc(0) would have to be updated. That shouldn't be a >> great burden. >> >> Note that malloc(0) or realloc(ptr, 0) can still fail and return >> a null pointer if no space can be allocated, so all allocations >> should still be checked. But with this proposed change, code >> could rely on realloc(ptr, 0) returning a non-null pointer *unless* >> available memory is critically low -- pretty much the same as in C11, >> except that a null pointer would be an indication that something >> is seriously wrong. >> >> (I remember seeing a discussion about making the behavior of >> realloc(ptr, 0) undefined. I'm making inquiries, and I'll follow >> up if I learn anything relevant.) > > I got a response from JeanHeyd Meneide. > > If realloc(ptr, 0) returns a null pointer there's no way to tell whether > allocation failed (and ptr has not been freed), or the implementation > returns a null pointer for zero-sized allocations (and ptr has been > freed). Some implementations set errno, but C doesn't require it. It's trivial to fix that problem: simply require implementations to define a preprocessor symbol about how the implementation works. Problem solved. (There are other instances of implementation-defined behavior that would benefit from analogous changes along these lines.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-21 15:04 -0800 |
| Message-ID | <87edeab85u.fsf@nosuchdomain.example.com> |
| In reply to | #380591 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>> 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.
>>>
>>> [...]
>>>
>>> I think I would have *liked* to see C23 drop the special permission
>>> to return a null pointer for a requested size of zero. C11 says (and
>>> this applies to malloc, realloc, and all other allocation functions):
>>>
>>> If the space cannot be allocated, a null pointer is returned. If
>>> the size of the space requested is zero, the behavior is
>>> implementation-defined: either a null pointer is returned, or
>>> the behavior is as if the size were some nonzero value, except
>>> that the returned pointer shall not be used to access an object.
>>>
>>> This could have been changed to:
>>>
>>> If the space cannot be allocated, a null pointer is returned. If
>>> the size of the space requested is zero, the behavior is as
>>> if the size were some nonzero value, except that the returned
>>> pointer shall not be used to access an object.
>>>
>>> Any existing implementations that always return a null pointer
>>> for malloc(0) would have to be updated. That shouldn't be a
>>> great burden.
>>>
>>> Note that malloc(0) or realloc(ptr, 0) can still fail and return
>>> a null pointer if no space can be allocated, so all allocations
>>> should still be checked. But with this proposed change, code
>>> could rely on realloc(ptr, 0) returning a non-null pointer *unless*
>>> available memory is critically low -- pretty much the same as in C11,
>>> except that a null pointer would be an indication that something
>>> is seriously wrong.
>>>
>>> (I remember seeing a discussion about making the behavior of
>>> realloc(ptr, 0) undefined. I'm making inquiries, and I'll follow
>>> up if I learn anything relevant.)
>>
>> I got a response from JeanHeyd Meneide.
>>
>> If realloc(ptr, 0) returns a null pointer there's no way to tell whether
>> allocation failed (and ptr has not been freed), or the implementation
>> returns a null pointer for zero-sized allocations (and ptr has been
>> freed). Some implementations set errno, but C doesn't require it.
>
> It's trivial to fix that problem: simply require implementations
> to define a preprocessor symbol about how the implementation
> works. Problem solved.
>
> (There are other instances of implementation-defined behavior
> that would benefit from analogous changes along these lines.)
I tend to agree that such a preprocessor symbol would be an improvement.
I still think, as I wrote above, that removing the permission to return
a null pointer on a successful zero-sized allocation would be a greater
improvement.
A preprocessor symbol makes it easier for programmers to work around the
potential difference between implementations. The change I advocate
would make it completely unnecessary.
Except, of course, that most code would still have to allow for pre-C26
behavior, even if the change were adopted in C26. That's unavoidable in
the absence of time machines. On the gripping hand, since it seems that
most existing implementations (well, all of the few I've tried) return a
non-null pointer for malloc(0), it might be reasonable to ignore the few
pre-C26 implementations that return a null pointer.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-01-22 08:12 +0000 |
| Message-ID | <wwvv87lwzuo.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #380593 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> It's trivial to fix that problem: simply require implementations >> to define a preprocessor symbol about how the implementation >> works. Problem solved. >> >> (There are other instances of implementation-defined behavior >> that would benefit from analogous changes along these lines.) > > I tend to agree that such a preprocessor symbol would be an improvement. > > I still think, as I wrote above, that removing the permission to > return a null pointer on a successful zero-sized allocation would be a > greater improvement. Fully agreed. That permission has been grit in the gears for a very long time, for much of which I had the misfortune of having to deal with it in real life thanks to IBM’s bad decisions. Fixing it would have been, what, a 2-line change to the impacted implementations, but apparently it’s better for all the users to deal with the consequences instead. > A preprocessor symbol makes it easier for programmers to work around the > potential difference between implementations. The change I advocate > would make it completely unnecessary. > > Except, of course, that most code would still have to allow for pre-C26 > behavior, even if the change were adopted in C26. That's unavoidable in > the absence of time machines. On the gripping hand, since it seems that > most existing implementations (well, all of the few I've tried) return a > non-null pointer for malloc(0), it might be reasonable to ignore the few > pre-C26 implementations that return a null pointer. “Reasonable” isn’t really relevant (at least in my working environment): either my code has to run on such implementations or it doesn’t. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-22 08:06 -0800 |
| Message-ID | <8734upbbf1.fsf@nosuchdomain.example.com> |
| In reply to | #380612 |
Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> It's trivial to fix that problem: simply require implementations
>>> to define a preprocessor symbol about how the implementation
>>> works. Problem solved.
>>>
>>> (There are other instances of implementation-defined behavior
>>> that would benefit from analogous changes along these lines.)
>>
>> I tend to agree that such a preprocessor symbol would be an improvement.
>>
>> I still think, as I wrote above, that removing the permission to
>> return a null pointer on a successful zero-sized allocation would be a
>> greater improvement.
>
> Fully agreed. That permission has been grit in the gears for a very long
> time, for much of which I had the misfortune of having to deal with it
> in real life thanks to IBM’s bad decisions.
Can you expand on "IBM's bad decisions"?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-01-22 18:17 +0000 |
| Message-ID | <wwvmssxteq0.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #380624 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Richard Kettlewell <invalid@invalid.invalid> writes: >> Fully agreed. That permission has been grit in the gears for a very long >> time, for much of which I had the misfortune of having to deal with it >> in real life thanks to IBM’s bad decisions. > > Can you expand on "IBM's bad decisions"? AIX is one of the platforms that returns NULL for malloc(0) even when there’s some memory available (in fact the only one I know). -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-22 18:43 +0000 |
| Message-ID | <_GyrN.373000$83n7.225494@fx18.iad> |
| In reply to | #380630 |
Richard Kettlewell <invalid@invalid.invalid> writes: >Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> Richard Kettlewell <invalid@invalid.invalid> writes: >>> Fully agreed. That permission has been grit in the gears for a very long >>> time, for much of which I had the misfortune of having to deal with it >>> in real life thanks to IBM’s bad decisions. >> >> Can you expand on "IBM's bad decisions"? > >AIX is one of the platforms that returns NULL for malloc(0) even when >there’s some memory available (in fact the only one I know). AIX had this odd 'overcommit' feature, which allowed the system to overcommit memory resources. It would allocate virtual address space (via malloc) even if there wasn't enough memory + backing store to support it, and would take a SIGSEGV when referenced if, at the time of reference, there was still insufficient memory and/or backing store to support allocating a physical page to that portion of the VA space. Linux can be configured to operate in the same way. I don't believe AIX ever returned NULL from malloc() while still allocating VA space for the allocation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-01-22 19:11 +0000 |
| Message-ID | <wwvfrypyyhm.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #380631 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>>AIX is one of the platforms that returns NULL for malloc(0) even when
>>there’s some memory available (in fact the only one I know).
>
> AIX had this odd 'overcommit' feature, which allowed the system to
> overcommit memory resources. It would allocate virtual address space
> (via malloc) even if there wasn't enough memory + backing store to
> support it, and would take a SIGSEGV when referenced if, at the time
> of reference, there was still insufficient memory and/or backing store
> to support allocating a physical page to that portion of the VA space.
>
> Linux can be configured to operate in the same way.
Indeed, Linux defaults to overcommit for most allocations.
> I don't believe AIX ever returned NULL from malloc() while still
> allocating VA space for the allocation.
I don’t really see the relevance. malloc(0) is NULL on AIX[1] because
that’s what they’ve chosen to do in the C library’s malloc
implementation, nothing to do with the kernel’s overcommit policies.
[1] I see from the man page that they’ve added a macro to enable more
sensible behaviour. Too late for us, we stopped supporting it years
ago.
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-24 02:46 +0000 |
| Message-ID | <uoptlg$1hdq3$3@dont-email.me> |
| In reply to | #380631 |
On Mon, 22 Jan 2024 18:43:06 GMT, Scott Lurndal wrote: > AIX had this odd 'overcommit' feature, which allowed the system to > overcommit memory resources. It would allocate virtual address space > (via malloc) even if there wasn't enough memory + backing store to > support it, and would take a SIGSEGV when referenced if, at the time of > reference, there was still insufficient memory and/or backing store to > support allocating a physical page to that portion of the VA space. > > Linux can be configured to operate in the same way. Not quite the same. Linux overcommit means “never having to say no”. If the system runs short of memory, then this wakes up the Dreaded OOM Killer, which starts scoring processes on their hunger for memory, and killing the ones that are the biggest memory hogs.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-24 14:54 +0000 |
| Message-ID | <yw9sN.327980$p%Mb.186466@fx15.iad> |
| In reply to | #380746 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Mon, 22 Jan 2024 18:43:06 GMT, Scott Lurndal wrote: > >> AIX had this odd 'overcommit' feature, which allowed the system to >> overcommit memory resources. It would allocate virtual address space >> (via malloc) even if there wasn't enough memory + backing store to >> support it, and would take a SIGSEGV when referenced if, at the time of >> reference, there was still insufficient memory and/or backing store to >> support allocating a physical page to that portion of the VA space. >> >> Linux can be configured to operate in the same way. > >Not quite the same. Linux overcommit means “never having to say no”. If >the system runs short of memory, then this wakes up the Dreaded OOM >Killer, which starts scoring processes on their hunger for memory, and >killing the ones that are the biggest memory hogs. The behavior of overcommit is configurable in linux. That's just one possibility.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-22 20:08 -0800 |
| Message-ID | <86le8gg08t.fsf@linuxsc.com> |
| In reply to | #380612 |
Richard Kettlewell <invalid@invalid.invalid> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> It's trivial to fix that problem: simply require implementations >>> to define a preprocessor symbol about how the implementation >>> works. Problem solved. >>> >>> (There are other instances of implementation-defined behavior >>> that would benefit from analogous changes along these lines.) >> >> I tend to agree that such a preprocessor symbol would be an >> improvement. >> >> I still think, as I wrote above, that removing the permission to >> return a null pointer on a successful zero-sized allocation would >> be a greater improvement. > > Fully agreed. That permission has been grit in the gears for a > very long time, for much of which I had the misfortune of having > to deal with it in real life thanks to IBM's bad decisions. > > Fixing it would have been, what, a 2-line change to the impacted > implementations, [...] Again you are assuming that one choice is good for everyone. The people who wrote the C standard considered the question at length and reached a different conclusion. Incidentally, the change needed is a lot more than two lines.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-23 19:28 -0800 |
| Message-ID | <86r0i7e7fd.fsf@linuxsc.com> |
| In reply to | #380593 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>>> I think I would have *liked* to see C23 drop the special permission
>>>> to return a null pointer for a requested size of zero. C11 says (and
>>>> this applies to malloc, realloc, and all other allocation functions):
>>>> [...]
>>>>
>>>> Note that malloc(0) or realloc(ptr, 0) can still fail and return
>>>> a null pointer if no space can be allocated, so all allocations
>>>> should still be checked. But with this proposed change, code
>>>> could rely on realloc(ptr, 0) returning a non-null pointer *unless*
>>>> available memory is critically low -- pretty much the same as in C11,
>>>> except that a null pointer would be an indication that something
>>>> is seriously wrong.
>>>>
>>>> (I remember seeing a discussion about making the behavior of
>>>> realloc(ptr, 0) undefined. I'm making inquiries, and I'll follow
>>>> up if I learn anything relevant.)
>>>
>>> I got a response from JeanHeyd Meneide.
>>>
>>> If realloc(ptr, 0) returns a null pointer there's no way to tell
>>> whether allocation failed (and ptr has not been freed), or the
>>> implementation returns a null pointer for zero-sized allocations
>>> (and ptr has been freed). Some implementations set errno, but C
>>> doesn't require it.
(Let me mention in passing that there is a way to tell that
should work in practice on any non-malicious implementation.)
>> It's trivial to fix that problem: simply require implementations
>> to define a preprocessor symbol about how the implementation
>> works. Problem solved.
>>
>> (There are other instances of implementation-defined behavior
>> that would benefit from analogous changes along these lines.)
>
> I tend to agree that such a preprocessor symbol would be an
> improvement.
>
> I still think, as I wrote above, that removing the permission to
> return a null pointer on a successful zero-sized allocation would
> be a greater improvement.
>
> A preprocessor symbol makes it easier for programmers to work
> around the potential difference between implementations. The
> change I advocate would make it completely unnecessary.
>
> Except, of course, that most code would still have to allow for
> pre-C26 behavior, even if the change were adopted in C26. That's
> unavoidable in the absence of time machines. On the gripping
> hand, since it seems that most existing implementations (well, all
> of the few I've tried) return a non-null pointer for malloc(0), it
> might be reasonable to ignore the few pre-C26 implementations that
> return a null pointer.
I have an observation worth mentioning. Using glibc (tested in
Ubuntu), these assignments
void *x = malloc( 0 );
void *y = malloc( 1 );
both return a non-null pointer. Following that, however, these
calls
void *xx = realloc( x, 0 );
void *yy = realloc( y, 0 );
both return a null pointer, and subsequent code shows that both x
and y have indeed been deallocated. (Both gcc and clang give the
same result, which isn't surprising since both are using glibc.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-24 06:33 +0000 |
| Message-ID | <uoqave$1mu4a$3@dont-email.me> |
| In reply to | #380748 |
On Tue, 23 Jan 2024 19:28:38 -0800, Tim Rentsch wrote: > ... however, these calls > > void *xx = realloc( x, 0 ); > void *yy = realloc( y, 0 ); > > both return a null pointer, and subsequent code shows that both x and y > have indeed been deallocated. (Both gcc and clang give the same result, > which isn't surprising since both are using glibc.) You could have just read the docs <https://manpages.debian.org/3/realloc.en.html>. But remember, there is no requirement for gcc, at least, to use glibc. You can build programs with it that link to alternatives C runtimes.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-24 07:46 +0000 |
| Message-ID | <20240123234423.296@kylheku.com> |
| In reply to | #380757 |
On 2024-01-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: > You could have just read the docs ><https://manpages.debian.org/3/realloc.en.html>. You're mistaken; those are not the docs. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-24 07:44 +0000 |
| Message-ID | <20240123233837.825@kylheku.com> |
| In reply to | #380748 |
On 2024-01-24, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > I have an observation worth mentioning. Using glibc (tested in > Ubuntu), these assignments > > void *x = malloc( 0 ); > void *y = malloc( 1 ); > > both return a non-null pointer. Following that, however, these > calls > > void *xx = realloc( x, 0 ); > void *yy = realloc( y, 0 ); > > both return a null pointer, and subsequent code shows that both x > and y have indeed been deallocated. (Both gcc and clang give the > same result, which isn't surprising since both are using glibc.) The behavior is documented by Glibc. https://www.gnu.org/software/libc/manual/html_node/Changing-Block-Size.html "If you pass a null pointer for ptr, realloc behaves just like ‘malloc (newsize)’. Otherwise, if newsize is zero realloc frees the block and returns NULL." (It'a also documented sloppily by that hapless source of misinformation known as the Linux man pages project, which says that realloc(ptr, 0) is equivalent to free(ptr). neglecting to make any remarks on the return value. For a good laugh, check out the inane diatribes in "man 7 regex".) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-24 10:41 +0100 |
| Message-ID | <uoqm0i$1og8m$2@dont-email.me> |
| In reply to | #380748 |
On 24/01/2024 04:28, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> I got a response from JeanHeyd Meneide. >>>> >>>> If realloc(ptr, 0) returns a null pointer there's no way to tell >>>> whether allocation failed (and ptr has not been freed), or the >>>> implementation returns a null pointer for zero-sized allocations >>>> (and ptr has been freed). Some implementations set errno, but C >>>> doesn't require it. > > (Let me mention in passing that there is a way to tell that > should work in practice on any non-malicious implementation.) > No, let's not let you mention that in passing. It will lead to another endless thread where people ask for an explanation of your method, while you pop by for a few days a month to tell us what you mean by "non-malicious". I cannot be alone in being curious as to what this method is, and when it might or might not be applicable. Please either explain yourself, or stop making such claims. (Note to others - Tim either does not read my posts, or actively refuses to reply to them. If anyone else wants to know his method, they will need to reply themselves.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-24 08:34 -0800 |
| Message-ID | <877cjy7ks0.fsf@nosuchdomain.example.com> |
| In reply to | #380780 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/01/2024 04:28, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> I got a response from JeanHeyd Meneide.
>>>>>
>>>>> If realloc(ptr, 0) returns a null pointer there's no way to tell
>>>>> whether allocation failed (and ptr has not been freed), or the
>>>>> implementation returns a null pointer for zero-sized allocations
>>>>> (and ptr has been freed). Some implementations set errno, but C
>>>>> doesn't require it.
To avoid any confusion, I wrote the above paragraph; JeanHeyd Meneide
(the editor for C23 standard) did not.
>> (Let me mention in passing that there is a way to tell that
>> should work in practice on any non-malicious implementation.)
>
> No, let's not let you mention that in passing. It will lead to
> another endless thread where people ask for an explanation of your
> method, while you pop by for a few days a month to tell us what you
> mean by "non-malicious".
>
> I cannot be alone in being curious as to what this method is, and when
> it might or might not be applicable.
>
> Please either explain yourself, or stop making such claims.
>
> (Note to others - Tim either does not read my posts, or actively
> refuses to reply to them. If anyone else wants to know his method,
> they will need to reply themselves.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-10 02:47 -0800 |
| Message-ID | <861q9k61fu.fsf@linuxsc.com> |
| In reply to | #380806 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > David Brown <david.brown@hesbynett.no> writes: > >> On 24/01/2024 04:28, Tim Rentsch wrote: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>> >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>>> >>>>>> I got a response from JeanHeyd Meneide. >>>>>> >>>>>> If realloc(ptr, 0) returns a null pointer there's no way to tell >>>>>> whether allocation failed (and ptr has not been freed), or the >>>>>> implementation returns a null pointer for zero-sized allocations >>>>>> (and ptr has been freed). Some implementations set errno, but C >>>>>> doesn't require it. > > To avoid any confusion, I wrote the above paragraph; JeanHeyd Meneide > (the editor for C23 standard) did not. Thank you, I appreciate the clarification.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-01-24 12:23 -0500 |
| Message-ID | <uorh39$1sonk$1@dont-email.me> |
| In reply to | #380780 |
On 1/24/24 04:41, David Brown wrote: > On 24/01/2024 04:28, Tim Rentsch wrote: ... >> (Let me mention in passing that there is a way to tell that >> should work in practice on any non-malicious implementation.) ... > Please either explain yourself, or stop making such claims. As we all know, Tim will do neither of those things. > (Note to others - Tim either does not read my posts, or actively > refuses to reply to them. If anyone else wants to know his method, > they will need to reply themselves.) He still seems to be reading at least some of mine.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web