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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-22 11:27 +0000 |
| Message-ID | <uoljea$n2pc$1@dont-email.me> |
| In reply to | #380617 |
On 22/01/2024 10:22, Richard Kettlewell wrote:
> bart <bc@freeuk.com> writes:
>> malloc has sort of created a rod for its own back by needing to store
>> the size of the allocation. That will take up some space even when
>> malloc(0) is called, if NULL is not being returned.
>
> The alternative is making a rod for the back of every single caller
> (i.e. all consumers must track allocation sizes).
Not at all. Let's first emulate a pair of functions where the caller is
expected to remember the size:
void* malloc_s (size_t n) {return malloc(n);}
void free_s (void* p, size_t n) {free(p);}
Then a typical alloc/dealloc sequence might look like this:
typedef struct {int d,m,y;}Date;
Date* p;
p=malloc_s(sizeof(*p));
...
free_s(p, sizeof(*p));
Is that particularly onerous? If you have a fixed-size object like a
struct, then you will always know its size.
For variable-sized objects, then yes you need to keep a record of the
size, but the chances are you have to do that anyway. For example to be
able to iterate over that dynamic array.
But if you really wanted (for example when allocating variable length,
zero-terminated strings), you can write a couple of wrappers around
malloc_s and free_s to emulate what malloc and free provide in terms of
not needing to remember the allocation size:
typedef long long int i64;
void* malloc2(i64 n) {
void* p;
p=malloc_s(n+sizeof(i64));
if (p==NULL) return NULL;
*((i64*)p) = n;
return (char*)p+sizeof(i64);
}
void free2(void* p) {
i64* q = (i64*)((char*)p-sizeof(i64));
i64 size = *q;
free_s(q, *q);
}
Untested code, it's to demonstrate what's involved: you ask for an
allocation 8 bytes bigger, use the 8 bytes at the beginning to store the
size, and return a pointer to just after those 8 bytes. (I'm assuming
8-byte alignment will suffice.)
Now you can do this:
p=malloc2(sizeof(*p));
...
free2(p);
> I think the design of malloc got this one right.
I think it got it wrong. Now everyone is lumbered with an allocation
scheme that will ALWAYS have to store the size of that struct, perhaps
taking as much space as the struct itself.
Imagine allocating 100M of those structs, and also storing 100M copies
of sizeof(Date) or whatever metadata is needed.
Getting around that, by writing your own small-object allocator on top
of malloc, is a lot harder that adding your own size-tracking on top of
a malloc that does not store any extra data. As I've shown.
(This is also a scheme where, if a user needs to get the size of an
allocation block, it can do so:
i64 size_s(void* p) {
i64* q = (i64*)((char*)p-sizeof(i64));
return *q;
}
But this will be the requested size not the capacity of the allocated
block. That would depend on how malloc_s/free_s are implemented.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-22 19:36 +0000 |
| Message-ID | <20240122105444.667@kylheku.com> |
| In reply to | #380618 |
On 2024-01-22, bart <bc@freeuk.com> wrote: > On 22/01/2024 10:22, Richard Kettlewell wrote: >> I think the design of malloc got this one right. > > I think it got it wrong. Now everyone is lumbered with an allocation > scheme that will ALWAYS have to store the size of that struct, perhaps > taking as much space as the struct itself. Implementations of malloc have special strategies for small objects, to allocate them compactly, with minimal overhead and fragmentation. It is not necessary to store the size in every such object. > Imagine allocating 100M of those structs, and also storing 100M copies > of sizeof(Date) or whatever metadata is needed. For the size to take up as much object as the struct itself, it has to be a struct that whose size is sizeof(size_t), which is tiny: often 8 bytes nowadays, or possibly 4. An object that is as small as size_t should just be passed around by value. It likely fits into a machine register, and so dynamically allocating it is inefficient. Every such allocation results in a pointer. The program has to retain at least one copy of that pointer. The pointer is probably also 8 bits wide, so even if those objects are allocated compactly without storing a size field, it takes double the space just to retain pointers to them. > Getting around that, by writing your own small-object allocator on top > of malloc, is a lot harder that adding your own size-tracking on top of > a malloc that does not store any extra data. As I've shown. Writing small-object allocators on malloc is mostly a fool's errand, in the absence of special justification. -- 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 | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2024-01-22 20:40 +0000 |
| Message-ID | <uomjsr$su3k$1@dont-email.me> |
| In reply to | #380635 |
Kaz Kylheku <433-929-6894@kylheku.com> wrote: > [...] Every such allocation results in a pointer. The > program has to retain at least one copy of that pointer. > The pointer is probably also 8 bits wide, so [...] Surely you meant to write 8 *bytes* wide. br, KK
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-01-22 22:14 +0000 |
| Message-ID | <uompcq$tsij$1@dont-email.me> |
| In reply to | #380635 |
On 22/01/2024 19:36, Kaz Kylheku wrote:
> On 2024-01-22, bart <bc@freeuk.com> wrote:
>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>> I think the design of malloc got this one right.
>>
>> I think it got it wrong. Now everyone is lumbered with an allocation
>> scheme that will ALWAYS have to store the size of that struct, perhaps
>> taking as much space as the struct itself.
>
> Implementations of malloc have special strategies for small objects,
> to allocate them compactly, with minimal overhead and fragmentation.
> It is not necessary to store the size in every such object.
>
>> Imagine allocating 100M of those structs, and also storing 100M copies
>> of sizeof(Date) or whatever metadata is needed.
>
> For the size to take up as much object as the struct itself, it
> has to be a struct that whose size is sizeof(size_t), which is tiny:
> often 8 bytes nowadays, or possibly 4.
>
> An object that is as small as size_t should just be passed around
> by value. It likely fits into a machine register, and so dynamically
> allocating it is inefficient.
>
> Every such allocation results in a pointer. The program has to retain at
> least one copy of that pointer. The pointer is probably also 8 bits
> wide, so even if those objects are allocated compactly without storing a
> size field, it takes double the space just to retain pointers to them.
You keep talking about all the clever, space-efficient ways that malloc
/could/ manage memory. Unfortunately the people who write the mallocs I
use haven't got the memo.
If I go back to the program I posted earlier and allocate 8 bytes at a
time, then successive values from malloc are 32 bytes apart (when
allocations are clearly consecutive).
If my struct actually needs 32 bytes, then it will allocate 48 bytes: a
50% overhead.
Do you have an actual transcript from your machine where it does
anything different?
--------------------------
#include <stdio.h>
#include <stdlib.h>
enum {n=32};
int main(void) {
char* lastp=malloc(n);
char* p;
for (int i=0; i<10; ++i) {
p=malloc(n);
printf("%p %zu\n", p, p-lastp);
lastp=p;
}
}
--------------------------
>> Getting around that, by writing your own small-object allocator on top
>> of malloc, is a lot harder that adding your own size-tracking on top of
>> a malloc that does not store any extra data. As I've shown.
>
> Writing small-object allocators on malloc is mostly a fool's errand,
> in the absence of special justification.
>
On the Binary Tree benchmark, using a small-object allocator on top of
malloc makes it three times as fast as just using malloc.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-22 14:38 -0800 |
| Message-ID | <uomqpn$ttrm$2@dont-email.me> |
| In reply to | #380646 |
On 1/22/2024 2:14 PM, bart wrote: > On 22/01/2024 19:36, Kaz Kylheku wrote: >> On 2024-01-22, bart <bc@freeuk.com> wrote: >>> On 22/01/2024 10:22, Richard Kettlewell wrote: >>>> I think the design of malloc got this one right. [...] > > On the Binary Tree benchmark, using a small-object allocator on top of > malloc makes it three times as fast as just using malloc. Fwiw, it is not unheard of to use malloc to implement a scheme that can free things by rounding an address down to a large boundary, where access to a header is right there... Basically, avoid as many calls to malloc as you can. The over head is that all memory allocations must be at least the size of a word where sizeof(word) == sizeof(word*). This pointer is used to link memory into linked lists whose heads are contained in the header sitting on a large alignment boundary. One time I put the head right before the boundary. To get at the header: free would round address down and subtract the size of the header to get at it. The free could link the freed memory into a FIFO list or something. Sometimes the header would have a region allocator as well... If the allocator had to free a aligned main block, it could just free it using free. Per thread blocks were also heavily used. So, wrapping up malloc/free can be a good thing, indeed! :^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-22 14:40 -0800 |
| Message-ID | <uomqsa$ttrm$3@dont-email.me> |
| In reply to | #380649 |
On 1/22/2024 2:38 PM, Chris M. Thomasson wrote: > On 1/22/2024 2:14 PM, bart wrote: >> On 22/01/2024 19:36, Kaz Kylheku wrote: >>> On 2024-01-22, bart <bc@freeuk.com> wrote: >>>> On 22/01/2024 10:22, Richard Kettlewell wrote: >>>>> I think the design of malloc got this one right. > [...] >> >> On the Binary Tree benchmark, using a small-object allocator on top of >> malloc makes it three times as fast as just using malloc. > > Fwiw, it is not unheard of to use malloc to implement a scheme that can > free things by rounding an address down to a large boundary, where > access to a header is right there... Basically, avoid as many calls to > malloc as you can. The over head is that all memory allocations must be > at least the size of a word where sizeof(word) == sizeof(word*). This > pointer is used to link memory into linked lists whose heads are > contained in the header sitting on a large alignment boundary. One time > I put the head right before the boundary. To get at the header: > > free would round address down and subtract the size of the header to get > at it. The free could link the freed memory into a FIFO list or > something. Sometimes the header would have a region allocator as well... > > If the allocator had to free a aligned main block, it could just free it > using free. Per thread blocks were also heavily used. So, wrapping up > malloc/free can be a good thing, indeed! > > :^) Basically use standard malloc/free as a slow path..... ;^)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-22 22:45 +0000 |
| Message-ID | <9eCrN.252977$PuZ9.141471@fx11.iad> |
| In reply to | #380635 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: >On 2024-01-22, bart <bc@freeuk.com> wrote: >> On 22/01/2024 10:22, Richard Kettlewell wrote: >>> I think the design of malloc got this one right. >> >> I think it got it wrong. Now everyone is lumbered with an allocation >> scheme that will ALWAYS have to store the size of that struct, perhaps >> taking as much space as the struct itself. > >Implementations of malloc have special strategies for small objects, >to allocate them compactly, with minimal overhead and fragmentation. >It is not necessary to store the size in every such object. > >> Imagine allocating 100M of those structs, and also storing 100M copies >> of sizeof(Date) or whatever metadata is needed. > >For the size to take up as much object as the struct itself, it >has to be a struct that whose size is sizeof(size_t), which is tiny: >often 8 bytes nowadays, or possibly 4. > >An object that is as small as size_t should just be passed around >by value. It likely fits into a machine register, and so dynamically >allocating it is inefficient. Given the alignment requirements associated with various application binary interfaces, malloc must generally return an address aligned to an ABI specified boundary (often 16-byte). Such an allocator will often round the allocation size up to the next 16-byte boundary. "The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable"
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-22 14:54 -0800 |
| Message-ID | <uomrm9$u6ed$1@dont-email.me> |
| In reply to | #380651 |
On 1/22/2024 2:45 PM, Scott Lurndal wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-01-22, bart <bc@freeuk.com> wrote:
>>> On 22/01/2024 10:22, Richard Kettlewell wrote:
>>>> I think the design of malloc got this one right.
>>>
>>> I think it got it wrong. Now everyone is lumbered with an allocation
>>> scheme that will ALWAYS have to store the size of that struct, perhaps
>>> taking as much space as the struct itself.
>>
>> Implementations of malloc have special strategies for small objects,
>> to allocate them compactly, with minimal overhead and fragmentation.
>> It is not necessary to store the size in every such object.
>>
>>> Imagine allocating 100M of those structs, and also storing 100M copies
>>> of sizeof(Date) or whatever metadata is needed.
>>
>> For the size to take up as much object as the struct itself, it
>> has to be a struct that whose size is sizeof(size_t), which is tiny:
>> often 8 bytes nowadays, or possibly 4.
>>
>> An object that is as small as size_t should just be passed around
>> by value. It likely fits into a machine register, and so dynamically
>> allocating it is inefficient.
>
> Given the alignment requirements associated with various
> application binary interfaces, malloc must generally
> return an address aligned to an ABI specified boundary
> (often 16-byte). Such an allocator will often round the allocation
> size up to the next 16-byte boundary.
>
> "The malloc() and calloc() functions return a pointer to the
> allocated memory that is suitably aligned for any kind of variable"
Fwiw, then there is this little region allocator "thing" I made, that
can be fed with memory from malloc, iirc in this example it is using
stack memory... It does use some hack(s), but it does properly align
things to their lowest alignment requirements. It was a while back:
Link to raw text:
https://pastebin.com/raw/f37a23918
Where I "think" I first mentioned it:
https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ
An interesting macro in here is:
________________
#define RALLOC_ALIGN_OF(mp_type) \
offsetof( \
struct { \
char pad_RALLOC_ALIGN_OF; \
mp_type type_RALLOC_ALIGN_OF; \
}, \
type_RALLOC_ALIGN_OF \
)
________________
;^D
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2024-01-22 23:05 +0000 |
| Message-ID | <wwv7ck1arzf.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #380618 |
bart <bc@freeuk.com> writes: > Imagine allocating 100M of those structs, and also storing 100M copies > of sizeof(Date) or whatever metadata is needed. I’m comfortable with that. It’s a general-purpose interface, it doesn’t have to be the most efficient conceivable option in any particular specialized use case. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-21 04:04 -0800 |
| Message-ID | <861qaaj3k9.fsf@linuxsc.com> |
| In reply to | #380521 |
Kaz Kylheku <433-929-6894@kylheku.com> writes: [...] > Not requiring the non-null return from malloc(0) to be distinct > from previous malloc(0) return values (whether they were freed or not), > could help to "sell" the idea of taking away the null return value. > > Some implementors might grumble that null return allowed malloc(0) to be > efficient by not allocating anything. If they were allowed to return > (void *) -1 or something, that would placate that concern. [...] You have the tail wagging the dog here. If the results of different malloc(0) calls don't need to be distinguishable, they might just as well all be null.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-22 12:36 +0000 |
| Message-ID | <uolngi$nke1$2@dont-email.me> |
| In reply to | #380567 |
On 21/01/2024 12:04, Tim Rentsch wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
> [...]
>
>> Not requiring the non-null return from malloc(0) to be distinct
>> from previous malloc(0) return values (whether they were freed or not),
>> could help to "sell" the idea of taking away the null return value.
>>
>> Some implementors might grumble that null return allowed malloc(0) to be
>> efficient by not allocating anything. If they were allowed to return
>> (void *) -1 or something, that would placate that concern. [...]
>
> You have the tail wagging the dog here. If the results of
> different malloc(0) calls don't need to be distinguishable,
> they might just as well all be null.
No, because it's natural to write
employees = malloc(Nemployees * sizeof(EMPLOYEE));
if (!employees)
goto out_of_memory;
You don't want to have to special case Nemployees == 0.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-22 08:23 -0800 |
| Message-ID | <87y1ch9w1q.fsf@nosuchdomain.example.com> |
| In reply to | #380621 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 21/01/2024 12:04, Tim Rentsch wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> [...]
>>
>>> Not requiring the non-null return from malloc(0) to be distinct
>>> from previous malloc(0) return values (whether they were freed or not),
>>> could help to "sell" the idea of taking away the null return value.
>>>
>>> Some implementors might grumble that null return allowed malloc(0) to be
>>> efficient by not allocating anything. If they were allowed to return
>>> (void *) -1 or something, that would placate that concern. [...]
>> You have the tail wagging the dog here. If the results of
>> different malloc(0) calls don't need to be distinguishable,
>> they might just as well all be null.
> No, because it's natural to write
>
> employees = malloc(Nemployees * sizeof(EMPLOYEE));
> if (!employees)
> goto out_of_memory;
>
> You don't want to have to special case Nemployees == 0.
There are three scenarios being considered.
1. malloc(0) always returns a null pointer.
2. All malloc(0) calls return the same non-null pointer, perhaps to a
single pre-allocated object.
3. malloc(0) acts like malloc(1), returning a null pointer only if
memory has been exhausted.
Implementations currently choose between 1 and 3; 2 would be
non-conforming. Kaz suggested allowing (or requiring?) 2. (I advocate
requiring 3, which is the current behavior of all the implementations
I've tried.)
Tim is talking about scenario 2, wh
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-22 08:27 -0800 |
| Message-ID | <87ttn59vvc.fsf@nosuchdomain.example.com> |
| In reply to | #380621 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 21/01/2024 12:04, Tim Rentsch wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> [...]
>>
>>> Not requiring the non-null return from malloc(0) to be distinct
>>> from previous malloc(0) return values (whether they were freed or not),
>>> could help to "sell" the idea of taking away the null return value.
>>>
>>> Some implementors might grumble that null return allowed malloc(0) to be
>>> efficient by not allocating anything. If they were allowed to return
>>> (void *) -1 or something, that would placate that concern. [...]
>> You have the tail wagging the dog here. If the results of
>> different malloc(0) calls don't need to be distinguishable,
>> they might just as well all be null.
> No, because it's natural to write
>
> employees = malloc(Nemployees * sizeof(EMPLOYEE));
> if (!employees)
> goto out_of_memory;
>
> You don't want to have to special case Nemployees == 0.
[Ignore my previous followup. I accidentally posted it before I
finished writing it.]
There are three scenarios being considered.
1. malloc(0) always returns a null pointer.
2. All malloc(0) calls return the same non-null pointer, perhaps to a
single pre-allocated object.
3. malloc(0) acts like malloc(1), returning a null pointer only if
memory has been exhausted.
Implementations currently choose between 1 and 3; 2 would be
non-conforming. Kaz suggested allowing (or requiring?) 2. (I advocate
requiring 3, which is the current behavior of all the implementations
I've tried.)
Tim is talking about scenario 2. Your code sample would work correctly
in that scenario.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-22 16:34 +0000 |
| Message-ID | <POwrN.323725$p%Mb.106787@fx15.iad> |
| In reply to | #380621 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 21/01/2024 12:04, Tim Rentsch wrote: >> Kaz Kylheku <433-929-6894@kylheku.com> writes: >> >> [...] >> >>> Not requiring the non-null return from malloc(0) to be distinct >>> from previous malloc(0) return values (whether they were freed or not), >>> could help to "sell" the idea of taking away the null return value. >>> >>> Some implementors might grumble that null return allowed malloc(0) to be >>> efficient by not allocating anything. If they were allowed to return >>> (void *) -1 or something, that would placate that concern. [...] >> >> You have the tail wagging the dog here. If the results of >> different malloc(0) calls don't need to be distinguishable, >> they might just as well all be null. >No, because it's natural to write > >employees = malloc(Nemployees * sizeof(EMPLOYEE)); >if (!employees) > goto out_of_memory; > >You don't want to have to special case Nemployees == 0. I see no problem in special casing it.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-24 04:42 +0000 |
| Message-ID | <uoq4fb$1m5ka$2@dont-email.me> |
| In reply to | #380628 |
On Mon, 22 Jan 2024 16:34:55 GMT, Scott Lurndal wrote: > I see no problem in special casing [zero]. Special-casing zero is something I thought we had left behind in the bad old days of FORTRAN IV.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2024-01-22 19:23 +0000 |
| Message-ID | <LSFRupcoMc1QvVkCJ@bongo-ra.co> |
| In reply to | #380621 |
On Mon, 22 Jan 2024 12:36:34 +0000 Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > No, because it's natural to write > > employees = malloc(Nemployees * sizeof(EMPLOYEE)); > if (!employees) > goto out_of_memory; > > You don't want to have to special case Nemployees == 0. I cannot think of a realistic application where you would not have to treat as a special case Nemployees == 0 anyway for reasons completely unrelated to the behaviour of malloc() .Code (of a realistic application) referring to employees would need to do something involved and your code above would be part of that greater involved code so that code should not be called at all if Nemployees == 0 .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-22 20:20 -0800 |
| Message-ID | <86h6j4fzo4.fsf@linuxsc.com> |
| In reply to | #380621 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 21/01/2024 12:04, Tim Rentsch wrote:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>> [...]
>>
>>> Not requiring the non-null return from malloc(0) to be distinct
>>> from previous malloc(0) return values (whether they were freed or not),
>>> could help to "sell" the idea of taking away the null return value.
>>>
>>> Some implementors might grumble that null return allowed malloc(0) to be
>>> efficient by not allocating anything. If they were allowed to return
>>> (void *) -1 or something, that would placate that concern. [...]
>>
>> You have the tail wagging the dog here. If the results of
>> different malloc(0) calls don't need to be distinguishable,
>> they might just as well all be null.
>
> No, because it's natural to write
>
> employees = malloc(Nemployees * sizeof(EMPLOYEE));
> if (!employees)
> goto out_of_memory;
>
> You don't want to have to special case Nemployees == 0.
(A) You misunderstood the point I was making (as Keith's
followups more or less explained).
(B) Handling both implementation choices is trivial:
employees = malloc(Nemployees * sizeof(EMPLOYEE));
if (!employees && Nemployees)
goto out_of_memory;
(C) Alternatively, it is quite straightforward to write
a wrapper to malloc() and free() that returns a non-null
pointer for a size of zero (and that is a lower cost
path in terms of cycles used and memory resources needed
than the behavior implementations are required to provide
if they return a non-null pointer).
(D) The code you suggest is "natural" for people who are
lazy programmers who don't care about their code being
correct. There are easy ways around the deficiencies
of your example and any competent developer will use them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-01-21 06:55 -0800 |
| Message-ID | <86plxuhh2w.fsf@linuxsc.com> |
| In reply to | #380520 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[.. considering the definition of malloc(0) ..]
> I dislike the fact that the behavior is currently
> implementation-defined. I think requiring malloc(0) to return a
> null pointer would be an improvement over the current (C11)
> specification, though it would be an odd special case; a null
> pointer would mean either that the allocation failed (and the
> system is likely in a bad state) or that the requested size was 0.
> Note that an application might call malloc() with a variable
> argument whose value can just happen to be zero. [...]
First I think it is worth going back and re-reading the Rationale
where it talks about malloc() and friends.
I'm sympathetic to the reaction about malloc() and friends having
different behavior in different implemenations. On the other
hand let's look at it from the point of view of implementations:
(A) For malloc(0) returning non-null: that can be a convenience
for some applications, and can be supplied in a way that client
code cannot provide.
(B) For malloc(0) returning null: most programs don't allocate
zero-sized objects, except perhaps inadvertently; in most uses
code will work without needing to distinguish, and in those cases
where the distinction is important it isn't hard to write code
that works for both allowed behaviors; being able to return null
for zero-size requests both simplifies the code and uses less
resource than choice (A). In small systems the added resource
demands may very well be the deciding factor between choosing (A)
and choosing (B).
For most aspects, client code can ignore the distinction between
behavior (A) and behavior (B). The big exception to that is how
to detect errors. If we think the C standard should continue to
allow both possibilities (and personally I think it should), a
way around the problem is to provide a testable macro symbol, as
for example
#if __MALLOC_0_GIVES_NULL
...
#elif __MALLOC_0_GIVES_NONNULL
...
#else
... deal with uncertainty in some way
... (not hard although it may involve a run-time cost)
#endif
If some such macros were provided it isn't hard to define a macro
that does error checking in both kinds of environments, so there
could be code like this:
Foo *p = malloc( n * sizeof *p );
if( MALLOC_FAILED( p, n ) ) ...
where the MALLOC_FAILED() macro would either simply test '!p' or
would test '!p && n > 0', depending on whether the code is
running in an (A) regime or a (B) regime.
Personally I would like to see the memory allocation functions
augmented to be explicit about which behavior is wanted:
void *malloc0( size_t ); /* returns NULL for size of 0 */
void *malloc1( size_t ); /* returns NULL only on failure */
along with analogous changes for calloc(), realloc(), etc.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-20 19:50 -0800 |
| Message-ID | <87msszbb08.fsf@nosuchdomain.example.com> |
| In reply to | #380450 |
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.
C17 added this in 7.31.11, Future library directions:
Invoking realloc with a size argument equal to zero is an
obsolescent feature.
More references:
DR 400 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400>
"realloc with size zero problems"
N2438 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm>
"Clarification Request", "Realloc with size 0 ambiguity"
N2464 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf>
This is the paper that proposed making realloc(?, 0) undefined behavior,
whether the first argument is null or not. Part of the rationale was to
allow POSIX to define it however they please.
N2665 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2665.pdf>
Not directly relevant; it just removes the statement that zero-sized
reallocations are obsolescent, since it's no longer necessary.
Personally, I still think it would have been cleaner to remove the
permission for any allocation functions to return a null pointer, even
with a requested size of 0, unless there isn't enough memory for the
allocation to succeed.
--
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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-21 05:11 +0000 |
| Message-ID | <uoi92j$2gjc$1@dont-email.me> |
| In reply to | #380556 |
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.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web