Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #157279 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-12-15 13:57 -0800 |
| Last post | 2020-12-21 22:17 +0100 |
| Articles | 20 on this page of 300 — 18 participants |
Back to article view | Back to comp.lang.c
A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-15 13:57 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-16 02:11 +0300
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 01:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 10:48 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 04:16 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:04 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 16:06 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 15:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 19:32 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 21:12 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-17 13:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:35 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 06:05 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 15:28 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 08:49 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 18:24 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 10:31 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 16:53 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:33 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:06 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:55 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:09 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-18 15:39 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:55 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 17:05 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 17:12 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:41 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 10:13 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:28 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 11:35 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:45 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 13:26 -0500
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 11:31 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 20:41 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 19:57 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:05 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 20:26 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:59 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 15:23 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 17:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:21 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 20:13 +0000
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:37 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 16:26 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-25 00:55 +0000
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 12:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 14:01 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 16:32 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 07:42 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 16:07 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:38 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 17:25 +0100
Re: A defer mechanism for C Christian Hanné <the.hanne@gmail.com> - 2020-12-20 17:46 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 09:07 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:43 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 10:11 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 14:58 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:58 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:41 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 20:25 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 22:34 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 20:52 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-20 12:37 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:42 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:19 -0500
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-21 10:18 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 11:06 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:09 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:13 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:18 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:26 -0700
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:47 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:59 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:25 -0700
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-21 14:23 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-22 09:58 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:57 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:19 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-27 11:24 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 22:45 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 00:33 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 11:31 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-29 17:24 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 18:43 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 11:32 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 03:34 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 21:06 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-29 20:40 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 02:56 -0800
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:22 -0700
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 02:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 06:49 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-24 03:16 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:38 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:37 -0800
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-25 11:39 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:34 -0800
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:48 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:51 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 22:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 09:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:18 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:32 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:55 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:16 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 22:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:42 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 05:53 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:40 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:19 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 11:01 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 03:45 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 13:25 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 06:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 15:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 07:05 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:13 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:21 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:06 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 08:57 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:43 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-16 12:05 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 14:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 15:57 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:49 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 11:33 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:05 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:52 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 10:59 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 20:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 19:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 21:56 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:03 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 12:30 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:16 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:39 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 13:44 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 06:54 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 13:28 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:14 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:16 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:19 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:26 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 17:07 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 18:18 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 18:34 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:40 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 21:16 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 22:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 21:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:25 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:01 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 02:45 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 13:33 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:24 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:28 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 21:55 -0800
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:38 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:51 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-25 20:00 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:19 +0100
Re: A defer mechanism for C Öö Tiib <ootiib@hot.ee> - 2020-12-26 19:10 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:42 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 02:29 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:11 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 09:33 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 18:50 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-26 07:40 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:36 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:49 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:39 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:25 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 01:55 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:16 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:55 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:10 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 16:47 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:22 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:09 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:25 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 08:02 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:55 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 21:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 23:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:40 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:59 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:10 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:46 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:46 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:00 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 10:59 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 11:12 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:18 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 16:25 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 19:24 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 09:07 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:36 +0300
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-19 15:54 -0500
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 01:21 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 15:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:53 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:55 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 12:07 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 03:38 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:40 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:00 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:02 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:43 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:34 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:11 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 17:22 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:08 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:26 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:36 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:54 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:12 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 15:13 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 12:45 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 16:25 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 13:38 +0000
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:26 -0500
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 20:30 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 21:41 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:14 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:25 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:38 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:44 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:07 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 00:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:51 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 06:15 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 06:25 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:43 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:55 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:52 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 00:40 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:46 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:22 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:31 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 22:27 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 09:36 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-21 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:24 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:07 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-16 18:35 -0800
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 04:08 +0000
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 23:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 20:29 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:26 +0300
Re: A defer mechanism for C fir <profesor.fir@gmail.com> - 2020-12-21 05:02 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 15:03 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 06:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 16:51 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:17 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:22 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:46 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:04 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 10:57 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:10 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 11:39 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:48 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:34 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:15 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:26 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:45 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 20:15 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:28 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 20:49 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:17 +0100
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-24 00:59 -0500 |
| Message-ID | <rs1aof$pqs$1@dont-email.me> |
| In reply to | #157678 |
On 12/24/20 12:47 AM, James Kuyper wrote: > On 12/23/20 7:26 PM, Joe Pfeiffer wrote: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> On 12/21/20 11:31 AM, David Brown wrote: >>>> On 21/12/2020 15:19, James Kuyper wrote: >>>>> On 12/21/20 2:42 AM, David Brown wrote: >>>>> ... >>>>>> Is it possible to write a program that uses only standards-defined >>>>>> behaviour and could tell the difference between a malloc/free >>>>>> implementation that recycles freed memory, and one where free is a >>>>>> no-op? > ... >>> No, but you can reliably distinguish "fails rather quickly" from "runs >>> forever", just by waiting long enough for the second implementation of >>> malloc()/free() to fail, an amount of time that can be estimated with at >>> least order-of-magnitude accuracy from tests to see how long a small >>> number of allocations take to be executed, so long as you know how much >>> memory is available. >> >> It would require you to be able to distinguish between "hasn't >> terminated yet" and "won't terminate". > > No, to make the distinction specified, it's sufficient to distinguish > "Has terminated after a certain amount of time T" and "Hasn't terminated > after a certain amount of time T", which is, quite literally, infinitely > easier to do. The trickiest part is determining a reasonable value of T, > but that can be estimated with sufficient accuracy by knowing the amount > of memory installed and monitoring the progress of the test as it goes > along. By the time your test has done 4 allocations, it can estimate the > value of T within a factor of 2. I wasn't thinking about the problem properly when I wrote that, The right answer is "... it's sufficient to distinguish 'fails before allocating a total of N bytes' from 'successfully allocates a total of N bytes', where N is the total amount of memory available, and the test routine free()s each allocation before performing the next. That is literally infinitely easier than making the distinction you suggest."
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-12-23 17:25 -0700 |
| Message-ID | <1b7dp8rqwk.fsf@pfeifferfamily.net> |
| In reply to | #157595 |
David Brown <david.brown@hesbynett.no> writes: > On 21/12/2020 15:19, James Kuyper wrote: >> On 12/21/20 2:42 AM, David Brown wrote: >> ... >>> Is it possible to write a program that uses only standards-defined >>> behaviour and could tell the difference between a malloc/free >>> implementation that recycles freed memory, and one where free is a >>> no-op? >> >> No, but for a reason that you should have mentioned when making that >> comment, since it's a little obscure. The standard never specifies any >> condition under which malloc() is required to succeed, so any program >> that calls malloc() has behavior not defined by the standard. >> >> It's trivial to write a program that has no syntax errors, no constraint >> violations, and no undefined behavior, which can tell the difference. >> Any program which repeatedly allocates memory, uses that memory in a way >> that cannot be optimized away, and then free()s it, can run forever on >> the first implementation if the allocations are small enough; malloc() >> will eventually fail when using the second one. >> > > Are you sure you are not trying to solve the halting problem here? :-) > > I don't think "runs forever" and "runs for a long time" can be reliably > distinguished. Where is Peter Olcott when we need him? (gd&r)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-21 14:23 -0800 |
| Message-ID | <87zh26ajdu.fsf@nosuchdomain.example.com> |
| In reply to | #157558 |
David Brown <david.brown@hesbynett.no> writes:
> On 20/12/2020 21:37, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/12/2020 17:46, Christian Hanné wrote:
>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>>>> the size of the blocks or the number of them, and it will not waste any
>>>>>> space beyond what you might need for alignment. It will beat any
>>>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>>>> is a no-op.
>>>>
>>>> Forget it, a malloc()-implementation without free isn't a
>>>> malloc()-implementation.
>>>
>>> If it gives memory when you call malloc, it is entirely fine. There are
>>> no specifications that require heap memory to be re-usable.
>>
>> Well, there's the C standard, which says:
>>
>> The free function causes the space pointed to by ptr to be
>> deallocated, that is, made available for further allocation.
>>
>>> There are a great many programs that allocate memory dynamically at
>>> startup or early on, and never need to free anything until the end of
>>> the program (or for many embedded systems, simply never end and never
>>> need to free anything). For hosted systems, the OS will clear up the
>>> memory when the program ends. Any effort made by the program or
>>> libraries to track the allocated memory, re-use memory, or free it is
>>> then wasted effort.
>>
>> An implementation in which free() is a no-op might be useful, but it's
>> not conforming.
>
> Is it possible to write a program that uses only standards-defined
> behaviour and could tell the difference between a malloc/free
> implementation that recycles freed memory, and one where free is a
> no-op? I don't think so - but I might be missing something. And if
> there is no way to tell the difference, how could it not be conforming?
>
> The /intention/ of how free should behave is clear in the standards, and
> a no-op free doesn't follow that.
>
> (The usefulness of a no-op free implementation is primarily in cases
> where you either don't call "free" until the end of the program, or the
> program never ends and you don't call "free" at all. In such code,
> since you don't ask for more memory afterwards, there is no difference
> in how free behaves.)
Well, there's some wiggle room. If the standard states that something
is a requirement, I tend to think that it's a requirement, even if
it's difficult to write a program that can tell the difference.
On the other hand, N1570 5.1.2.3p6 defines the "least requirements
on a conforming implementation" in terms of observable behavior.
On the other other hand, as James Kuyper points out, a program that
repeated mallocs and frees a chunk of memory will eventually crash if
free is a no-op, but should run indefinitely if it works as required.
A number of allocations equal to 2**N, where N is the number of
bits in a void*, should suffice (as long as the allocations can't
be optimized away). But at one allocation per nanosecond, that could
take nearly 6 centuries on a 64-bit system.
Finally, malloc and free are not required for freestanding
implementations (which can, I believe, define functions with the
same names that behave differently).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-22 09:58 +0100 |
| Message-ID | <rrscfn$auo$1@dont-email.me> |
| In reply to | #157623 |
On 21/12/2020 23:23, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 20/12/2020 21:37, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 20/12/2020 17:46, Christian Hanné wrote: >>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc >>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's >>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of >>>>>>> the size of the blocks or the number of them, and it will not waste any >>>>>>> space beyond what you might need for alignment. It will beat any >>>>>>> size-specific pool-based system. However, it has one weakness - "free" >>>>>>> is a no-op. >>>>> >>>>> Forget it, a malloc()-implementation without free isn't a >>>>> malloc()-implementation. >>>> >>>> If it gives memory when you call malloc, it is entirely fine. There are >>>> no specifications that require heap memory to be re-usable. >>> >>> Well, there's the C standard, which says: >>> >>> The free function causes the space pointed to by ptr to be >>> deallocated, that is, made available for further allocation. >>> >>>> There are a great many programs that allocate memory dynamically at >>>> startup or early on, and never need to free anything until the end of >>>> the program (or for many embedded systems, simply never end and never >>>> need to free anything). For hosted systems, the OS will clear up the >>>> memory when the program ends. Any effort made by the program or >>>> libraries to track the allocated memory, re-use memory, or free it is >>>> then wasted effort. >>> >>> An implementation in which free() is a no-op might be useful, but it's >>> not conforming. >> >> Is it possible to write a program that uses only standards-defined >> behaviour and could tell the difference between a malloc/free >> implementation that recycles freed memory, and one where free is a >> no-op? I don't think so - but I might be missing something. And if >> there is no way to tell the difference, how could it not be conforming? >> >> The /intention/ of how free should behave is clear in the standards, and >> a no-op free doesn't follow that. >> >> (The usefulness of a no-op free implementation is primarily in cases >> where you either don't call "free" until the end of the program, or the >> program never ends and you don't call "free" at all. In such code, >> since you don't ask for more memory afterwards, there is no difference >> in how free behaves.) > > Well, there's some wiggle room. If the standard states that something > is a requirement, I tend to think that it's a requirement, even if > it's difficult to write a program that can tell the difference. > > On the other hand, N1570 5.1.2.3p6 defines the "least requirements > on a conforming implementation" in terms of observable behavior. > > On the other other hand, as James Kuyper points out, a program that > repeated mallocs and frees a chunk of memory will eventually crash if > free is a no-op, but should run indefinitely if it works as required. > A number of allocations equal to 2**N, where N is the number of > bits in a void*, should suffice (as long as the allocations can't > be optimized away). But at one allocation per nanosecond, that could > take nearly 6 centuries on a 64-bit system. > I suppose that is getting rather hypothetical - especially if the program uses the memory in some way (like a volatile write) that can't be skipped. > Finally, malloc and free are not required for freestanding > implementations (which can, I believe, define functions with the > same names that behave differently). > For the kind of uses I have of such unusual allocators, they are certainly freestanding systems and not hosted, and so these allocators will be conforming. And on programs on hosted systems where a no-op free would work fine, the theoretical efficiency difference is not going to make any measurable difference in practice.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-27 04:57 -0800 |
| Message-ID | <86tus7wgn2.fsf@linuxsc.com> |
| In reply to | #157623 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 20/12/2020 21:37, Keith Thompson wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 20/12/2020 17:46, Christian Hanne wrote:
>>>>
>>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>>>>> the size of the blocks or the number of them, and it will not waste any
>>>>>>> space beyond what you might need for alignment. It will beat any
>>>>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>>>>> is a no-op.
>>>>>
>>>>> Forget it, a malloc()-implementation without free isn't a
>>>>> malloc()-implementation.
>>>>
>>>> If it gives memory when you call malloc, it is entirely fine. There are
>>>> no specifications that require heap memory to be re-usable.
>>>
>>> Well, there's the C standard, which says:
>>>
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>>
>>>> There are a great many programs that allocate memory dynamically at
>>>> startup or early on, and never need to free anything until the end of
>>>> the program (or for many embedded systems, simply never end and never
>>>> need to free anything). For hosted systems, the OS will clear up the
>>>> memory when the program ends. Any effort made by the program or
>>>> libraries to track the allocated memory, re-use memory, or free it is
>>>> then wasted effort.
>>>
>>> An implementation in which free() is a no-op might be useful, but it's
>>> not conforming.
>>
>> Is it possible to write a program that uses only standards-defined
>> behaviour and could tell the difference between a malloc/free
>> implementation that recycles freed memory, and one where free is a
>> no-op? I don't think so - but I might be missing something. And if
>> there is no way to tell the difference, how could it not be conforming?
>>
>> The /intention/ of how free should behave is clear in the standards, and
>> a no-op free doesn't follow that.
>>
>> (The usefulness of a no-op free implementation is primarily in cases
>> where you either don't call "free" until the end of the program, or the
>> program never ends and you don't call "free" at all. In such code,
>> since you don't ask for more memory afterwards, there is no difference
>> in how free behaves.)
>
> Well, there's some wiggle room. If the standard states that something
> is a requirement, I tend to think that it's a requirement, even if
> it's difficult to write a program that can tell the difference.
The question is What /is/ the requirement? Calling free() with a
pointer to some previously malloc()'ed memory doesn't require
that a subsequent malloc() call be able to re-use that memory.
Under the as-if rule, free() doing nothing satisfies the stated
specifications.
> On the other hand, N1570 5.1.2.3p6 defines the "least requirements
> on a conforming implementation" in terms of observable behavior.
Exactly.
> On the other other hand, as James Kuyper points out, a program that
> repeated mallocs and frees a chunk of memory will eventually crash if
> free is a no-op, but should run indefinitely if it works as required.
> A number of allocations equal to 2**N, where N is the number of
> bits in a void*, should suffice (as long as the allocations can't
> be optimized away). But at one allocation per nanosecond, that could
> take nearly 6 centuries on a 64-bit system.
His argument is unsound. Consider the following implementation
of malloc() and free():
malloc():
make an OS call to get some memory
if we got some, return a pointer to that
otherwise, return NULL
free():
if the argument is NULL, nothing
otherwise, make an OS call to return the allocated
space to the OS pool
This implementation satisfies both the letter and the spirit of
what the C standard says about malloc() and free(). Yet a call
to malloc() may fail at any time, for reasons having nothing to
do with what our C program is doing. Any sequence of calls to
malloc() and free(), with any results from the malloc() calls,
cannot be distinguished from an identical sequence of calls that
is possible on this implementation. Since malloc() and free() as
shown above are conforming, no conclusion can be drawn from any
sequence of results from malloc()/free() calls as to whether the
implementation is conforming. As far as observable behavior
goes, free() can do anything at all, including nothing, as long
as malloc() returns either NULL or a valid pointer to allocated
space.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-27 04:19 -0800 |
| Message-ID | <86y2hjwiec.fsf@linuxsc.com> |
| In reply to | #157532 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > David Brown <david.brown@hesbynett.no> writes: > >> On 20/12/2020 17:46, Christian Hanne wrote: >> >>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc >>>>> implementation you will ever see is the algorithm used by FreeRTOS's >>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of >>>>> the size of the blocks or the number of them, and it will not waste any >>>>> space beyond what you might need for alignment. It will beat any >>>>> size-specific pool-based system. However, it has one weakness - "free" >>>>> is a no-op. >>> >>> Forget it, a malloc()-implementation without free isn't a >>> malloc()-implementation. >> >> If it gives memory when you call malloc, it is entirely fine. There are >> no specifications that require heap memory to be re-usable. > > Well, there's the C standard, which says: > > The free function causes the space pointed to by ptr to be > deallocated, that is, made available for further allocation. > >> There are a great many programs that allocate memory dynamically at >> startup or early on, and never need to free anything until the end of >> the program (or for many embedded systems, simply never end and never >> need to free anything). For hosted systems, the OS will clear up the >> memory when the program ends. Any effort made by the program or >> libraries to track the allocated memory, re-use memory, or free it is >> then wasted effort. > > An implementation in which free() is a no-op might be useful, but it's > not conforming. I believe that the view of the C standard's authors is that this choice is one of quality-of-implementation, and not one that affects conformance.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-27 11:24 -0800 |
| Message-ID | <87y2hj8323.fsf@nosuchdomain.example.com> |
| In reply to | #157810 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/12/2020 17:46, Christian Hanne wrote:
>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>>>> the size of the blocks or the number of them, and it will not waste any
>>>>>> space beyond what you might need for alignment. It will beat any
>>>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>>>> is a no-op.
>>>>
>>>> Forget it, a malloc()-implementation without free isn't a
>>>> malloc()-implementation.
>>>
>>> If it gives memory when you call malloc, it is entirely fine. There are
>>> no specifications that require heap memory to be re-usable.
>>
>> Well, there's the C standard, which says:
>>
>> The free function causes the space pointed to by ptr to be
>> deallocated, that is, made available for further allocation.
>>
>>> There are a great many programs that allocate memory dynamically at
>>> startup or early on, and never need to free anything until the end of
>>> the program (or for many embedded systems, simply never end and never
>>> need to free anything). For hosted systems, the OS will clear up the
>>> memory when the program ends. Any effort made by the program or
>>> libraries to track the allocated memory, re-use memory, or free it is
>>> then wasted effort.
>>
>> An implementation in which free() is a no-op might be useful, but it's
>> not conforming.
>
> I believe that the view of the C standard's authors is that
> this choice is one of quality-of-implementation, and not one
> that affects conformance.
How does the unconditional statement:
The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation.
express that view?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-28 22:45 -0800 |
| Message-ID | <868s9hw1os.fsf@linuxsc.com> |
| In reply to | #157823 |
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:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 20/12/2020 17:46, Christian Hanne wrote:
>>>>
>>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>>>>> the size of the blocks or the number of them, and it will not waste any
>>>>>>> space beyond what you might need for alignment. It will beat any
>>>>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>>>>> is a no-op.
>>>>>
>>>>> Forget it, a malloc()-implementation without free isn't a
>>>>> malloc()-implementation.
>>>>
>>>> If it gives memory when you call malloc, it is entirely fine. There are
>>>> no specifications that require heap memory to be re-usable.
>>>
>>> Well, there's the C standard, which says:
>>>
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>>
>>>> There are a great many programs that allocate memory dynamically at
>>>> startup or early on, and never need to free anything until the end of
>>>> the program (or for many embedded systems, simply never end and never
>>>> need to free anything). For hosted systems, the OS will clear up the
>>>> memory when the program ends. Any effort made by the program or
>>>> libraries to track the allocated memory, re-use memory, or free it is
>>>> then wasted effort.
>>>
>>> An implementation in which free() is a no-op might be useful, but it's
>>> not conforming.
>>
>> I believe that the view of the C standard's authors is that
>> this choice is one of quality-of-implementation, and not one
>> that affects conformance.
>
> How does the unconditional statement:
> The free function causes the space pointed to by ptr to be
> deallocated, that is, made available for further allocation.
> express that view?
AFAICT there is no explicit expression of QOI in any normative
text in the C standard. A search of the C11 standard turns up
just one occurrence of the word "quality", in a footnote for one
of the "Description" paragraphs (specifically, 7.22.2.1 p2) for
the rand() function.
What we do have however is unspecified behavior. There is no
statement of Semantics for memory management library functions,
only Descriptions. Many or maybe even most library functions
have some amount of unspecified behavior; certainly malloc() and
free() do. The Rationale document says the following (note in
particular the last part of the last sentence):
The terms unspecified behavior, undefined behavior, and
implementation-defined behavior are used to categorize the
result of writing programs whose properties the Standard does
not, or cannot, completely describe. The goal of adopting
this categorization is to allow a certain variety among
implementations which permits quality of implementation to be
an active force in the marketplace as well as to allow
certain popular extensions, without removing the cachet of
conformance to the Standard. [...]
Note furthermore that library function do sometimes have clear
statements of requirements, and these are expressed using more
direct language. An example may be found in 7.21.6 p1:
The formatted input/output functions shall behave as if
there is a sequence point after the actions associated
with each specifier.
There is no doubt here that this statement imposes a specific
requirement on a conforming implementation. An important part
of that is specificity: there is no question about what
behavior is required. Because malloc() and free() give only
broad descriptions, and not specific statements of behavior,
those functions certainly fall into the realm of unspecified
behavior. Without any sort of explicit statement to the
contrary, that says to me that the description is meant to
give the widest possible latitude, in keeping with what the
Standard's authors say in the Rationale document.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-29 00:33 -0800 |
| Message-ID | <87lfdh8116.fsf@nosuchdomain.example.com> |
| In reply to | #157861 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 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:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 20/12/2020 17:46, Christian Hanne wrote:
>>>>>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>>>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>>>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>>>>>> the size of the blocks or the number of them, and it will not waste any
>>>>>>>> space beyond what you might need for alignment. It will beat any
>>>>>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>>>>>> is a no-op.
>>>>>>
>>>>>> Forget it, a malloc()-implementation without free isn't a
>>>>>> malloc()-implementation.
>>>>>
>>>>> If it gives memory when you call malloc, it is entirely fine. There are
>>>>> no specifications that require heap memory to be re-usable.
>>>>
>>>> Well, there's the C standard, which says:
>>>>
>>>> The free function causes the space pointed to by ptr to be
>>>> deallocated, that is, made available for further allocation.
>>>>
>>>>> There are a great many programs that allocate memory dynamically at
>>>>> startup or early on, and never need to free anything until the end of
>>>>> the program (or for many embedded systems, simply never end and never
>>>>> need to free anything). For hosted systems, the OS will clear up the
>>>>> memory when the program ends. Any effort made by the program or
>>>>> libraries to track the allocated memory, re-use memory, or free it is
>>>>> then wasted effort.
>>>>
>>>> An implementation in which free() is a no-op might be useful, but it's
>>>> not conforming.
>>>
>>> I believe that the view of the C standard's authors is that
>>> this choice is one of quality-of-implementation, and not one
>>> that affects conformance.
>>
>> How does the unconditional statement:
>> The free function causes the space pointed to by ptr to be
>> deallocated, that is, made available for further allocation.
>> express that view?
>
> AFAICT there is no explicit expression of QOI in any normative
> text in the C standard. A search of the C11 standard turns up
> just one occurrence of the word "quality", in a footnote for one
> of the "Description" paragraphs (specifically, 7.22.2.1 p2) for
> the rand() function.
>
> What we do have however is unspecified behavior. There is no
> statement of Semantics for memory management library functions,
> only Descriptions. Many or maybe even most library functions
> have some amount of unspecified behavior; certainly malloc() and
> free() do. The Rationale document says the following (note in
> particular the last part of the last sentence):
>
> The terms unspecified behavior, undefined behavior, and
> implementation-defined behavior are used to categorize the
> result of writing programs whose properties the Standard does
> not, or cannot, completely describe. The goal of adopting
> this categorization is to allow a certain variety among
> implementations which permits quality of implementation to be
> an active force in the marketplace as well as to allow
> certain popular extensions, without removing the cachet of
> conformance to the Standard. [...]
>
> Note furthermore that library function do sometimes have clear
> statements of requirements, and these are expressed using more
> direct language. An example may be found in 7.21.6 p1:
>
> The formatted input/output functions shall behave as if
> there is a sequence point after the actions associated
> with each specifier.
>
> There is no doubt here that this statement imposes a specific
> requirement on a conforming implementation. An important part
> of that is specificity: there is no question about what
> behavior is required. Because malloc() and free() give only
> broad descriptions, and not specific statements of behavior,
> those functions certainly fall into the realm of unspecified
> behavior. Without any sort of explicit statement to the
> contrary, that says to me that the description is meant to
> give the widest possible latitude, in keeping with what the
> Standard's authors say in the Rationale document.
How, if at all, would the meaning of the standard change if that
sentence:
The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation.
were simply deleted?
I agree that the exact meaning is ambiguous, but I do not believe
that this or any other straightforward sentence in the standard is
merely decorative.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-29 11:31 -0500 |
| Message-ID | <%RIGH.27563$ay6.6081@fx03.iad> |
| In reply to | #157863 |
On 12/29/20 3:33 AM, Keith Thompson wrote: > How, if at all, would the meaning of the standard change if that > sentence: > > The free function causes the space pointed to by ptr to be > deallocated, that is, made available for further allocation. > > were simply deleted? > > I agree that the exact meaning is ambiguous, but I do not believe > that this or any other straightforward sentence in the standard is > merely decorative. > Because without that sentence I don't think anything else would ALLOW malloc to reuse the space. malloc gave control of the memory to the program, so until that control was relinquished, it can't be used again. There is undefined behavior still present if the program itself uses that memory or that pointer after the free, but there ARE tricks a program can use to possibly detect the reuse of the memory, so it would not be allowed (like stashing the pointer value into a uintptr_t variable or an array of unsigned char before calling free).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-29 17:24 +0000 |
| Message-ID | <20201229091749.782@kylheku.com> |
| In reply to | #157866 |
On 2020-12-29, Richard Damon <Richard@Damon-Family.org> wrote: > On 12/29/20 3:33 AM, Keith Thompson wrote: > >> How, if at all, would the meaning of the standard change if that >> sentence: >> >> The free function causes the space pointed to by ptr to be >> deallocated, that is, made available for further allocation. >> >> were simply deleted? >> >> I agree that the exact meaning is ambiguous, but I do not believe >> that this or any other straightforward sentence in the standard is >> merely decorative. >> > > Because without that sentence I don't think anything else would ALLOW > malloc to reuse the space. Yes, something would allow that: the fact that the deleted object disappeared to the point of any uses of the pointer becoming indeterminate behavior. The above sentence's presence in the standard is downright defective. It presents a requirement which is not directly testable. What is "space"? Suppose we have a vast, 128 bit address space, such that malloc always returns a new address. Unused memory is returned to the operating system via unmapping it (whenever an unused allocation causes one or more VM pages to be completely disused). Does that implementation fail to return space, because pointer values are not recycled? -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-29 18:43 +0100 |
| Message-ID | <rsfps0$ead$1@dont-email.me> |
| In reply to | #157869 |
> What is "space"? Suppose we have a vast, 128 bit address space, such > that malloc always returns a new address. ... There will never be a CPU with a 128 bit logical or physical address -space. 64 bit is 16 billion gigabytes, this will never been efficiently handled by a shared memory system. https://en.wikipedia.org/wiki/128-bit_computing > Unused memory is returned > the operating system via unmapping it (whenever an unused allocation > causes one or more VM pages to be completely disused). That would be too slow.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-29 11:32 -0800 |
| Message-ID | <878s9g8l29.fsf@nosuchdomain.example.com> |
| In reply to | #157869 |
Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2020-12-29, Richard Damon <Richard@Damon-Family.org> wrote:
>> On 12/29/20 3:33 AM, Keith Thompson wrote:
>>
>>> How, if at all, would the meaning of the standard change if that
>>> sentence:
>>>
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>>
>>> were simply deleted?
>>>
>>> I agree that the exact meaning is ambiguous, but I do not believe
>>> that this or any other straightforward sentence in the standard is
>>> merely decorative.
>>>
>>
>> Because without that sentence I don't think anything else would ALLOW
>> malloc to reuse the space.
>
> Yes, something would allow that: the fact that the deleted object
> disappeared to the point of any uses of the pointer becoming
> indeterminate behavior.
>
> The above sentence's presence in the standard is downright defective.
>
> It presents a requirement which is not directly testable.
Yes, it does, but I'm not convinced that's a defect.
> What is "space"? Suppose we have a vast, 128 bit address space, such
> that malloc always returns a new address. Unused memory is returned to
> the operating system via unmapping it (whenever an unused allocation
> causes one or more VM pages to be completely disused).
>
> Does that implementation fail to return space, because pointer values
> are not recycled?
Even with a 128-bit address space, if you call free(malloc(1))
in a loop, you'll *eventually* get, if not the same address,
an address with the same bit representation. On the other hand,
the heat death of the universe is likely to happen first.
I suggest that there needs to be *something* in the standard that
says that free() does something useful beyond making the address
indeterminate. I *should* be able to call malloc and free in a
loop and not worry about resource exhaustion. Given the variations
in permissible memory management schemes (and we *want* to permit
wide variations), I can't think of a better way to express that
than what the standard says now.
But I could probably get behind the idea that it should be a note
rather than normative text.
There's no (explicit) meta-requirement that all requirements in the
standard need to be directly testable. Should there be? I think it
would take a *lot* of work to rewrite the standard to satisfy that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-31 03:34 -0800 |
| Message-ID | <86o8iatdjo.fsf@linuxsc.com> |
| In reply to | #157871 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Kaz Kylheku <563-365-8930@kylheku.com> writes: > >> On 2020-12-29, Richard Damon <Richard@Damon-Family.org> wrote: >> >>> On 12/29/20 3:33 AM, Keith Thompson wrote: >>> >>>> How, if at all, would the meaning of the standard change if that >>>> sentence: >>>> >>>> The free function causes the space pointed to by ptr to be >>>> deallocated, that is, made available for further allocation. >>>> >>>> were simply deleted? >>>> >>>> I agree that the exact meaning is ambiguous, but I do not believe >>>> that this or any other straightforward sentence in the standard is >>>> merely decorative. >>> >>> Because without that sentence I don't think anything else would ALLOW >>> malloc to reuse the space. >> >> Yes, something would allow that: the fact that the deleted object >> disappeared to the point of any uses of the pointer becoming >> indeterminate behavior. >> >> The above sentence's presence in the standard is downright defective. >> >> It presents a requirement which is not directly testable. > > Yes, it does, but I'm not convinced that's a defect. > >> What is "space"? Suppose we have a vast, 128 bit address space, such >> that malloc always returns a new address. Unused memory is returned to >> the operating system via unmapping it (whenever an unused allocation >> causes one or more VM pages to be completely disused). >> >> Does that implementation fail to return space, because pointer values >> are not recycled? > > Even with a 128-bit address space, if you call free(malloc(1)) > in a loop, you'll *eventually* get, if not the same address, > an address with the same bit representation. On the other hand, > the heat death of the universe is likely to happen first. > > I suggest that there needs to be *something* in the standard that > says that free() does something useful beyond making the address > indeterminate. I *should* be able to call malloc and free in a > loop and not worry about resource exhaustion. I don't necessarily agree that this guarantee should apply to every implementation (in some category), but even if it should the C standard is not the right place to express it. > Given the variations > in permissible memory management schemes (and we *want* to permit > wide variations), I can't think of a better way to express that > than what the standard says now. > > But I could probably get behind the idea that it should be a note > rather than normative text. > > There's no (explicit) meta-requirement that all requirements in the > standard need to be directly testable. Should there be? No, because it isn't practical.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-29 21:06 -0500 |
| Message-ID | <HgRGH.68016$r%1.53724@fx34.iad> |
| In reply to | #157869 |
On 12/29/20 12:24 PM, Kaz Kylheku wrote: > On 2020-12-29, Richard Damon <Richard@Damon-Family.org> wrote: >> On 12/29/20 3:33 AM, Keith Thompson wrote: >> >>> How, if at all, would the meaning of the standard change if that >>> sentence: >>> >>> The free function causes the space pointed to by ptr to be >>> deallocated, that is, made available for further allocation. >>> >>> were simply deleted? >>> >>> I agree that the exact meaning is ambiguous, but I do not believe >>> that this or any other straightforward sentence in the standard is >>> merely decorative. >>> >> >> Because without that sentence I don't think anything else would ALLOW >> malloc to reuse the space. > > Yes, something would allow that: the fact that the deleted object > disappeared to the point of any uses of the pointer becoming > indeterminate behavior. > > The above sentence's presence in the standard is downright defective. > > It presents a requirement which is not directly testable. > > What is "space"? Suppose we have a vast, 128 bit address space, such > that malloc always returns a new address. Unused memory is returned to > the operating system via unmapping it (whenever an unused allocation > causes one or more VM pages to be completely disused). > > Does that implementation fail to return space, because pointer values > are not recycled? > But, if we remove the statement that free causes the space to be deallocated, this is, made available for further alllocations, and just hand it make access to the object undefined behavior, then the statement that the lifetime of the disjoint object allocated goes from the allocation to the deallocation, says that if we don't do that deallocation, we can't reuse that object address. Note that if we allocate 0 byte objects (and malloc returns addresses, not NULLs) then each allocation need to return a unique address, even though we can not access these object that sort of don't exist (being 0 bytes in size) Now, most of the effects of accessing the object happen BECAUSE the object got deallocated, but even if the wording of the standard kept all those effects, if it removed the effect of actually deallocating the object in free, then the wording of the conditions on malloc would prevent it from reusing that address by specific wording of the standard.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-12-29 20:40 -0800 |
| Message-ID | <rsh0bl$amf$1@gioia.aioe.org> |
| In reply to | #157876 |
On 12/29/2020 6:06 PM, Richard Damon wrote: > On 12/29/20 12:24 PM, Kaz Kylheku wrote: >> On 2020-12-29, Richard Damon <Richard@Damon-Family.org> wrote: >>> On 12/29/20 3:33 AM, Keith Thompson wrote: >>> >>>> How, if at all, would the meaning of the standard change if that >>>> sentence: >>>> >>>> The free function causes the space pointed to by ptr to be >>>> deallocated, that is, made available for further allocation. >>>> >>>> were simply deleted? >>>> >>>> I agree that the exact meaning is ambiguous, but I do not believe >>>> that this or any other straightforward sentence in the standard is >>>> merely decorative. >>>> >>> >>> Because without that sentence I don't think anything else would ALLOW >>> malloc to reuse the space. >> >> Yes, something would allow that: the fact that the deleted object >> disappeared to the point of any uses of the pointer becoming >> indeterminate behavior. >> >> The above sentence's presence in the standard is downright defective. >> >> It presents a requirement which is not directly testable. >> >> What is "space"? Suppose we have a vast, 128 bit address space, such >> that malloc always returns a new address. Unused memory is returned to >> the operating system via unmapping it (whenever an unused allocation >> causes one or more VM pages to be completely disused). >> >> Does that implementation fail to return space, because pointer values >> are not recycled? >> > > But, if we remove the statement that free causes the space to be > deallocated, this is, made available for further alllocations, and just > hand it make access to the object undefined behavior[...] Sounds good to me right there. :^) >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-31 02:56 -0800 |
| Message-ID | <86sg7mtfa2.fsf@linuxsc.com> |
| In reply to | #157863 |
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:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 20/12/2020 17:46, Christian Hanne wrote:
>>>>>>
>>>>>>>>> I can guarantee, without any doubt whatsoever, that the
>>>>>>>>> fastest malloc implementation you will ever see is the
>>>>>>>>> algorithm used by FreeRTOS's "heap_1" allocator. It will
>>>>>>>>> easily beat MS's algorithm, regardless of the size of the
>>>>>>>>> blocks or the number of them, and it will not waste any
>>>>>>>>> space beyond what you might need for alignment. It will
>>>>>>>>> beat any size-specific pool-based system. However, it has
>>>>>>>>> one weakness - "free" is a no-op.
>>>>>>>
>>>>>>> Forget it, a malloc()-implementation without free isn't a
>>>>>>> malloc()-implementation.
>>>>>>
>>>>>> If it gives memory when you call malloc, it is entirely fine.
>>>>>> There are no specifications that require heap memory to be
>>>>>> re-usable.
>>>>>
>>>>> Well, there's the C standard, which says:
>>>>>
>>>>> The free function causes the space pointed to by ptr to be
>>>>> deallocated, that is, made available for further allocation.
>>>>>
>>>>>> There are a great many programs that allocate memory
>>>>>> dynamically at startup or early on, and never need to free
>>>>>> anything until the end of the program (or for many embedded
>>>>>> systems, simply never end and never need to free anything).
>>>>>> For hosted systems, the OS will clear up the memory when the
>>>>>> program ends. Any effort made by the program or libraries to
>>>>>> track the allocated memory, re-use memory, or free it is then
>>>>>> wasted effort.
>>>>>
>>>>> An implementation in which free() is a no-op might be useful,
>>>>> but it's not conforming.
>>>>
>>>> I believe that the view of the C standard's authors is that
>>>> this choice is one of quality-of-implementation, and not one
>>>> that affects conformance.
>>>
>>> How does the unconditional statement:
>>> The free function causes the space pointed to by ptr to be
>>> deallocated, that is, made available for further allocation.
>>> express that view?
>>
>> AFAICT there is no explicit expression of QOI in any normative
>> text in the C standard. A search of the C11 standard turns up
>> just one occurrence of the word "quality", in a footnote for one
>> of the "Description" paragraphs (specifically, 7.22.2.1 p2) for
>> the rand() function.
>>
>> What we do have however is unspecified behavior. There is no
>> statement of Semantics for memory management library functions,
>> only Descriptions. Many or maybe even most library functions
>> have some amount of unspecified behavior; certainly malloc() and
>> free() do. The Rationale document says the following (note in
>> particular the last part of the last sentence):
>>
>> The terms unspecified behavior, undefined behavior, and
>> implementation-defined behavior are used to categorize the
>> result of writing programs whose properties the Standard does
>> not, or cannot, completely describe. The goal of adopting
>> this categorization is to allow a certain variety among
>> implementations which permits quality of implementation to be
>> an active force in the marketplace as well as to allow
>> certain popular extensions, without removing the cachet of
>> conformance to the Standard. [...]
>>
>> Note furthermore that library function do sometimes have clear
>> statements of requirements, and these are expressed using more
>> direct language. An example may be found in 7.21.6 p1:
>>
>> The formatted input/output functions shall behave as if
>> there is a sequence point after the actions associated
>> with each specifier.
>>
>> There is no doubt here that this statement imposes a specific
>> requirement on a conforming implementation. An important part
>> of that is specificity: there is no question about what
>> behavior is required. Because malloc() and free() give only
>> broad descriptions, and not specific statements of behavior,
>> those functions certainly fall into the realm of unspecified
>> behavior. Without any sort of explicit statement to the
>> contrary, that says to me that the description is meant to
>> give the widest possible latitude, in keeping with what the
>> Standard's authors say in the Rationale document.
>
> How, if at all, would the meaning of the standard change if that
> sentence:
>
> The free function causes the space pointed to by ptr to be
> deallocated, that is, made available for further allocation.
>
> were simply deleted?
It would change in that there would be no expression of the
function's intended purpose.
> I agree that the exact meaning is ambiguous, but I do not believe
> that this or any other straightforward sentence in the standard is
> merely decorative.
The primary purpose of the C standard is to define the language.
Expressing the intended purpose of library functions helps do
that.
The C standard is not meant to define a threshold (except a very
weak one) so we may judge the "goodness" of an implementation.
That this assertion is true may be seen from the famous codicil
of 5.2.4.1 p1
The implementation shall be able to translate and execute at
least one program that contains at least one instance of
every one of the following limits: [...]
This statement, along with what the Rationale document has to say
on the matter, clearly shows that the authors are not interested
in setting a bar for implementations except as it may help sharpen
the definition of the language. The current description of free()
is all that is needed to define the language. Any more stringent
rule, just to limit implementations, is not needed.
I know some people are not happy with this state of affairs, and
would like the C standard to provide more guarantees about how
implementations will behave. The standard's authors, at least in
aggregate, feel otherwise. Personally I think that is a good
decision (at least for C - other languages might be different,
and I haven't thought about the question more broadly). More
importantly though I recognize the decision as reflecting the
authors' idea of what the C standard is meant to express.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-12-23 17:22 -0700 |
| Message-ID | <1bblekrr2h.fsf@pfeifferfamily.net> |
| In reply to | #157511 |
Christian Hanné <the.hanne@gmail.com> writes: >>> I can guarantee, without any doubt whatsoever, that the fastest malloc >>> implementation you will ever see is the algorithm used by FreeRTOS's >>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of >>> the size of the blocks or the number of them, and it will not waste any >>> space beyond what you might need for alignment. It will beat any >>> size-specific pool-based system. However, it has one weakness - "free" >>> is a no-op. > > Forget it, a malloc()-implementation without free isn't a > malloc()-implementation. How would it be possible to detect, from external behavior, that free() was a no-op?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-24 02:13 +0000 |
| Message-ID | <20201223180153.625@kylheku.com> |
| In reply to | #157666 |
On 2020-12-24, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Christian Hanné <the.hanne@gmail.com> writes:
>
>>>> I can guarantee, without any doubt whatsoever, that the fastest malloc
>>>> implementation you will ever see is the algorithm used by FreeRTOS's
>>>> "heap_1" allocator. It will easily beat MS's algorithm, regardless of
>>>> the size of the blocks or the number of them, and it will not waste any
>>>> space beyond what you might need for alignment. It will beat any
>>>> size-specific pool-based system. However, it has one weakness - "free"
>>>> is a no-op.
>>
>> Forget it, a malloc()-implementation without free isn't a
>> malloc()-implementation.
>
> How would it be possible to detect, from external behavior, that free()
> was a no-op?
To gather evidence indicating that free is a NOOP we could investigate
in various ways like:
1. This program gobbling up all memory (and extermally visible behavior
affecting the system):
int main()
{
for (;;)
free(malloc(1));
}
2. A replacement malloc that immediately frees everything it mallocs:
void *my_malloc(size_t size)
{
void *ptr = malloc(size);
free(ptr);
return ptr;
}
If free is a no-op, then we can drop this allocator wrapper into
all kinds of known-reliable programs, test until we are blue in the face,
and not and not see an ounce of instability.
3. Do high precision timings of free calls and show that they require
too little time to do anything, relative to the execution speed of
the system in question. E.g the system can issue a billion
instructions per second at most, and the function always returns in
two or three nanoseconds.
1 would give us evidence that not only is free a noop, but there is no
garbage collector under malloc to make up for it. It's not conclusive
because a twisted case could be made for blaming fragmentation. I.e.
free is doing somehing but not doing it very well, so that memory is
fragmenting.
2 and 3 don't provide evidence that there is no freeing; there could be
a garbage collector alongside a no-op free.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-24 06:49 +0100 |
| Message-ID | <rs1a4p$msr$1@dont-email.me> |
| In reply to | #157666 |
>> Forget it, a malloc()-implementation without free isn't a >> malloc()-implementation. > How would it be possible to detect, from external behavior, that free() > was a no-op? C requires a free() that frees the memory.
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web