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 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-12-20 10:11 -0800 |
| Message-ID | <eca65bb2-a95a-41a3-96a1-0110e2196ca8n@googlegroups.com> |
| In reply to | #157519 |
On Sunday, 20 December 2020 at 17:45:25 UTC, David Brown wrote:
> On 20/12/2020 18:07, Malcolm McLean wrote:
> > On Sunday, 20 December 2020 at 16:46:55 UTC, 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.
> >>
> > Most dymanic allocations are in fact arranged in a stack.
> That is a very questionable assumption.
> > Allocation
> > and free are in the same scope, and they are either nested or easy
> > to make nested.
> > So you can write a very fast and efficient allocator.
> That would be a different kind of allocator - one for which free does
> something, and memory will be re-used, as long as freeing is done in the
> reverse order from malloc'ing. Such allocators are also found, and are
> also useful - they are a great deal more efficient than general malloc
> systems, while being a bit more flexible than the "free is a no-op"
> allocator I described. (The "free is a no-op" is faster and more memory
> efficient, however.)\>
It is, but very marginally. free() is just
unsigned char stack{POOLSIZE];
unsigned char *stacktop = stack;
void free(void *ptr)
{
stacktop = ptr;
}
malloc is
void * malloc(size_t N)
{
void *answer = stacktop;
stacktop += N;
return answer;
}
Not quite no-ops, but you've got to be very squeezed indeed for cycles
if the difference matters to you.
> > However I must admit that I've never actually used such an allocator
> > in a real project.
> >
> I have. Yes, they are useful. They require more discipline from the
> programmer, but small-systems embedded programmers are used to having
> restrictions that are not found on big systems.
>
Yes, you do more small systems work than I do.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-20 14:58 -0800 |
| Message-ID | <bc324380-b44a-4d6b-b9d7-6c62fd8e2f56n@googlegroups.com> |
| In reply to | #157519 |
On Sunday, December 20, 2020 at 2:45:25 PM UTC-3, David Brown wrote: ... > I have. Yes, they are useful. They require more discipline from the > programmer, but small-systems embedded programmers are used to having > restrictions that are not found on big systems. Just curious.. How did you use them? - Global replacement of malloc/free - Something defined by type Only some types using the special allocators.. - Something defined by instance instead of type Did you use allocator for strings?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-21 08:58 +0100 |
| Message-ID | <rrpkj7$img$1@dont-email.me> |
| In reply to | #157535 |
On 20/12/2020 23:58, Thiago Adams wrote: > On Sunday, December 20, 2020 at 2:45:25 PM UTC-3, David Brown wrote: > ... >> I have. Yes, they are useful. They require more discipline from the >> programmer, but small-systems embedded programmers are used to having >> restrictions that are not found on big systems. > > Just curious.. How did you use them? > > - Global replacement of malloc/free > Sometimes in small embedded systems (by "small embedded systems", I mean "small resources" rather than physically small - there's some rather tiny Linux systems out there, but that is not the kind of system I am talking about) you have your own replacements for malloc/free. It's not uncommon to have them cause a trap of some sort so that if you unintentionally use them in code, the mistake is found quickly. Normally dynamic memory allocation is a major sin in such programming. Mostly you'll use "home made" allocation functions in order to be sure you are clear about exactly what is happening, and to keep separate allocators for different purposes. Usually a failure to allocate memory is simply unacceptable in such systems, at least for major parts of the program, so you have to design in a way that this cannot happen. A typical use of a no-op free allocator will be for an RTOS where you need to allocate memory for thread stacks, queues, etc., when the program starts - but these are never released as the program does not stop. (It's better if you can use static allocation, since you get clear information about memory usage at link time, but that's not always possible.) > - Something defined by type Type-specific allocators are certainly important. > Only some types using the special allocators.. > > - Something defined by instance instead of type > > Did you use allocator for strings? > Why would I have an allocator for strings? This is not PC programming - strings are rarely a big part of these kinds of programs (other than for a debug port output), and when they are, you usually have fixed size buffers because you know the maximum size of the strings. You don't need dynamic allocation if you know your LCD screen is twenty characters wide.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 18:41 +0100 |
| Message-ID | <rro2d1$d7m$1@dont-email.me> |
| In reply to | #157511 |
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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 18:45 +0100 |
| Message-ID | <rro2jb$dgj$2@dont-email.me> |
| In reply to | #157517 |
> If it gives memory when you call malloc, it is entirely fine. > There are no specifications that require heap memory to be re-usable. No one would call a malloc()-implementation without free a malloc() -implementation. > 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). ... That's a totally differnt thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-20 20:25 +0100 |
| Message-ID | <rro8ev$qcm$1@dont-email.me> |
| In reply to | #157520 |
On 20/12/2020 18:45, Bonita Montero wrote: >> If it gives memory when you call malloc, it is entirely fine. >> There are no specifications that require heap memory to be re-usable. > > No one would call a malloc()-implementation without free a malloc() > -implementation. Sorry, but you are wrong. One would certainly qualify it by describing it as a minimal and restricted implementation, but it is still very much a useful algorithm. > >> 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). ... > > That's a totally differnt thing. We've been in the world of small embedded systems since Malcolm first posted his code for a "mutex". /You/ live in a world of Windows programming, AFAIK, but many other people do not.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-20 22:34 +0300 |
| Message-ID | <20201220223425.18a02c4b2b421c072b0d303c@gmail.com> |
| In reply to | #157524 |
David Brown to Bonita Montero: > > No one would call a malloc()-implementation without free > > a malloc()-implementation. > > Sorry, but you are wrong. One would certainly qualify it > by describing it as a minimal and restricted > implementation, but it is still very much a useful > algorithm. Of course, it is useful, e.g. for non-interactive command- line programs such as those that consitute the Netpbm and ImageMagick suites, or LaTeX and Troff document processors... -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 20:52 +0100 |
| Message-ID | <rroa1p$53d$1@dont-email.me> |
| In reply to | #157524 |
>> No one would call a malloc()-implementation without free a malloc() >> -implementation. > Sorry, but you are wrong. One would certainly qualify it by describing > it as a minimal and restricted implementation, but it is still very much > a useful algorithm. C dynamic memory management needs malloc as well as free ! https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-20 12:37 -0800 |
| Message-ID | <87v9cwb4di.fsf@nosuchdomain.example.com> |
| In reply to | #157517 |
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.
--
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-21 08:42 +0100 |
| Message-ID | <rrpjlc$dv9$1@dont-email.me> |
| In reply to | #157532 |
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.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-21 09:19 -0500 |
| Message-ID | <rrqau0$7f9$1@dont-email.me> |
| In reply to | #157558 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-12-21 10:18 -0500 |
| Message-ID | <813EH.2534$qi2.1134@fx20.iad> |
| In reply to | #157581 |
On 12/21/20 9:19 AM, 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. > It isn't behavior not defined by the Standard, but the Standard allows for multiple behaviors, one of which is malloc always returns NULL, the other is that it returns a block of memory that meets a number of specifications.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-21 11:06 -0500 |
| Message-ID | <rrqh5h$p6e$1@dont-email.me> |
| In reply to | #157585 |
On 12/21/20 10:18 AM, Richard Damon wrote: > On 12/21/20 9:19 AM, 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 isn't behavior not defined by the Standard, but the Standard allows > for multiple behaviors, one of which is malloc always returns NULL, the > other is that it returns a block of memory that meets a number of > specifications. The standard defines the legal options; it doesn't define which option must be chosen.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-21 17:31 +0100 |
| Message-ID | <rrqilo$5ie$2@dont-email.me> |
| In reply to | #157588 |
On 21/12/2020 17:06, James Kuyper wrote: > On 12/21/20 10:18 AM, Richard Damon wrote: >> On 12/21/20 9:19 AM, 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 isn't behavior not defined by the Standard, but the Standard allows >> for multiple behaviors, one of which is malloc always returns NULL, the >> other is that it returns a block of memory that meets a number of >> specifications. > > The standard defines the legal options; it doesn't define which option > must be chosen. > That would surely be unspecified behaviour, rather than undefined behaviour?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-21 13:09 -0500 |
| Message-ID | <rrqod0$huk$1@dont-email.me> |
| In reply to | #157597 |
On 12/21/20 11:31 AM, David Brown wrote: > On 21/12/2020 17:06, James Kuyper wrote: >> On 12/21/20 10:18 AM, Richard Damon wrote: >>> On 12/21/20 9:19 AM, 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 isn't behavior not defined by the Standard, but the Standard allows >>> for multiple behaviors, one of which is malloc always returns NULL, the >>> other is that it returns a block of memory that meets a number of >>> specifications. >> >> The standard defines the legal options; it doesn't define which option >> must be chosen. >> > > That would surely be unspecified behaviour, rather than undefined behaviour? That's why I said "behavior not defined by the standard", to indicate that the standard fails to defined the behavior, which does apply to this case, rather than "undefined behavior", which is a phrase defined by the standard to mean "the standard imposes no requirements", which does not apply to this case. If your phrase "standards-defined behavior" refers only to code with no undefined behavior, than the program I described in my earlier message does indeed have standards-defined behavior, and can in fact be used to distinguish between the two implementations you described.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-21 17:13 +0100 |
| Message-ID | <rrqhjk$teh$1@dont-email.me> |
| In reply to | #157585 |
> It isn't behavior not defined by the Standard, but the Standard allows > for multiple behaviors, one of which is malloc always returns NULL, ... Idiots discussing nonsense.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-21 17:31 +0100 |
| Message-ID | <rrqik8$5ie$1@dont-email.me> |
| In reply to | #157581 |
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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-21 13:18 -0500 |
| Message-ID | <rrqotq$mb6$1@dont-email.me> |
| In reply to | #157595 |
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 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? :-) No, I'm talking about detecting a certain kind of non-conformance, not proving conformance, which would be a lot harder. > I don't think "runs forever" and "runs for a long time" can be reliably > distinguished. 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.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-12-23 17:26 -0700 |
| Message-ID | <1b35zwrquu.fsf@pfeifferfamily.net> |
| In reply to | #157607 |
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 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? :-) > > No, I'm talking about detecting a certain kind of non-conformance, not > proving conformance, which would be a lot harder. > >> I don't think "runs forever" and "runs for a long time" can be reliably >> distinguished. > > 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".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-24 00:47 -0500 |
| Message-ID | <rs1a19$llr$1@dont-email.me> |
| In reply to | #157668 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 15 — ← Prev page 1 2 3 [4] 5 6 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web