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 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 07:25 +0100 |
| Message-ID | <rrhi0a$hhf$1@dont-email.me> |
| In reply to | #157364 |
> vector<char> readFile( char const *path )
> {
> uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
> path + strlen( path ) ) );
> if( fileSize > numeric_limits<size_t>::max() )
> throw bad_alloc();
> vector<char> data( (size_t)fileSize + 1 );
> ifstream ifs;
> ifs.exceptions( ifstream::failbit | ifstream::badbit );
> try
> {
> ifs.open( path, ifstream::binary );
> ifs.read( &data[0], (size_t)fileSize );
> }
> catch( ios_base::failure & )
> {
> data[(size_t)fileSize] = 0;
> }
> return data;
> }
So this is the correct code:
vector<char> readFile( char const *path )
{
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path +
strlen( path ) ) );
if( fileSize + 1 > numeric_limits<size_t>::max() )
throw bad_alloc();
vector<char> data( (size_t)fileSize + 1 );
ifstream ifs;
ifs.exceptions( ifstream::failbit | ifstream::badbit );
try
{
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
}
catch( ios_base::failure & )
{
}
return data;
}
I forgot to compare fileSize __+1__ against the maximum of size_t,
so I didn't prevent a potential overflow on 32-bit-systems with a
64 bit filesystem.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 08:02 +0100 |
| Message-ID | <rrhk5h$qvq$1@dont-email.me> |
| In reply to | #157379 |
The exceptions doesn't need to be caught.
::open() and ::read() might silently fail:
vector<char> readFile( char const *path )
{
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path +
strlen( path ) ) );
if( fileSize + 1 > numeric_limits<size_t>::max() )
throw bad_alloc();
vector<char> data( (size_t)fileSize + 1 );
ifstream ifs;
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
return data;
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 22:55 +0100 |
| Message-ID | <rrgk3s$g6a$3@dont-email.me> |
| In reply to | #157363 |
> vector<char> readFile(char const* path)
> {
> uint64_t fileSize = (uint64_t)file_size(filesystem::path(path,
> path + strlen(path)));
>
> vector<char> data((size_t)fileSize + 1);
>
> ifstream ifs;
> ifs.exceptions(ifstream::failbit | ifstream::badbit);
> ifs.open(path, ifstream::binary);
> ifs.read(&data[0], (size_t)fileSize);
> return data;
> }
Ok, setting the zero beyond the file-size isn't really
necessary since the vector is default-initialized anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-17 21:58 +0000 |
| Message-ID | <FwQCH.139713$oT47.35498@fx20.ams4> |
| In reply to | #157360 |
On 17/12/2020 21:16, Bonita Montero wrote:
> vector<char> readFile( char const *path )
> {
> uint64_t fileSize = (uint64_t)file_size( filesystem::path(
> path, path + strlen( path ) ) );
> vector<char> data( (size_t)fileSize + 1 );
> ifstream ifs;
> ifs.exceptions( ifstream::failbit | ifstream::badbit );
> try
> {
> ifs.open( path, ifstream::binary );
> ifs.read( &data[0], (size_t)fileSize );
> }
> catch( ios_base::failure & )
> {
> data[(size_t)fileSize] = 0;
> }
> return data;
> }
My C version is:
----------------------------
char* readstrfile(char* filespec) {
FILE* f;
char* m;
int64 size;
f=fopen(filespec, "rb");
if (f==NULL) return NULL;
rsfsize=size=getfilesize(f);
m=malloc(size+1);
if (m==NULL) return NULL;
readrandom(f,m,0,size);
*(m+size)=0;
fclose(f);
return m;
}
----------------------------
About 14 non-blank lines, exactly the same as your C++ (when lines with
only "{" are ignored). It uses a couple of support routines, about a
dozen more lines, but those are used elsewhere too.
The error checking done by the caller is whether it returns NULL or not.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 23:05 +0100 |
| Message-ID | <rrgkmp$l4q$1@dont-email.me> |
| In reply to | #157366 |
> ----------------------------
> char* readstrfile(char* filespec) {
> FILE* f;
> char* m;
> int64 size;
>
> f=fopen(filespec, "rb");
> if (f==NULL) return NULL;
>
> rsfsize=size=getfilesize(f);
>
> m=malloc(size+1);
> if (m==NULL) return NULL;
And where do you close the file ?
>
> readrandom(f,m,0,size);
> *(m+size)=0;
>
> fclose(f);
> return m;
> }
> About 14 non-blank lines, exactly the same as your C++ (when lines with
> only "{" are ignored). It uses a couple of support routines, about a
> dozen more lines, but those are used elsewhere too.
The C++ code is more convenient since you don't have to deal
with error-handling at the point where you call the code but
at a outer scope.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-18 01:40 +0300 |
| Message-ID | <20201218014012.98b7f7c38c427a36f1a6c688@gmail.com> |
| In reply to | #157368 |
Bonita Montero:
> The C++ code is more convenient since you don't have to
> deal with error-handling at the point where you call the
> code but at a outer scope.
The lack of immediate error handling may be viewed as a
defect in that it conceals important information from the
programmer and introduces hidden changes to control flow.
Error handling may be viewed as as integral part of an
algorithm rather than an invisible orthogonal control
structure existing in a parallel universe of try and catch.
I entirely agree with Joel Spolky that errors and exceptions
must be handled as early as possible, that is at the place
where they appear:
Joel about his usage of exceptions in C++:
https://www.joelonsoftware.com/2003/10/13/13/
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-17 22:59 +0000 |
| Message-ID | <CpRCH.459942$b5kb.316408@fx15.ams4> |
| In reply to | #157368 |
On 17/12/2020 22:05, Bonita Montero wrote:
>> ----------------------------
>> char* readstrfile(char* filespec) {
>> FILE* f;
>> char* m;
>> int64 size;
>>
>> f=fopen(filespec, "rb");
>> if (f==NULL) return NULL;
>>
>> rsfsize=size=getfilesize(f);
>>
>> m=malloc(size+1);
>> if (m==NULL) return NULL;
>
> And where do you close the file ?
If malloc() ever returns NULL, then having a file left open until the
program terminates (probably very shortly after), would be the least of
the problems! (If an attempt is made to open a very large file, then the
system may just become unstable rather than return NULL.)
But yes, it would be better to close it:
if (m==NULL) {fclose(f); return NULL;}
>>
>> readrandom(f,m,0,size);
>> *(m+size)=0;
>>
>> fclose(f);
>> return m;
>> }
>
>> About 14 non-blank lines, exactly the same as your C++ (when lines
>> with only "{" are ignored). It uses a couple of support routines,
>> about a dozen more lines, but those are used elsewhere too.
>
> The C++ code is more convenient since you don't have to deal
> with error-handling at the point where you call the code but
> at a outer scope.
>
No, you need the caller to check the return value, because it needs to
be reported.
The most likely error is a wrong file name, or a file not existing,
which is more than likely due to incorrect user input.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-18 01:10 +0300 |
| Message-ID | <20201218011054.545265fc56a561bb701886f2@gmail.com> |
| In reply to | #157366 |
Bart:
> char* readstrfile(char* filespec) {
> FILE* f;
> char* m;
> int64 size;
>
> f=fopen(filespec, "rb");
> if (f==NULL) return NULL;
>
> rsfsize=size=getfilesize(f);
>
> m=malloc(size+1);
> if (m==NULL) return NULL;
>
> readrandom(f,m,0,size);
> *(m+size)=0;
>
> fclose(f);
> return m;
> }
Is int64 a C type? Where is rsfszie declared and for what
purpose? Does your function always close the file it opened?
Does your function handle an error from readrandom()? Can
readramndom() read fewer than `size' bytes (e.g. becuase of
the conversion of \r\n to \n)?
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-17 22:46 +0000 |
| Message-ID | <gdRCH.159642$9X39.73027@fx26.ams4> |
| In reply to | #157370 |
On 17/12/2020 22:10, Anton Shepelev wrote:
> Bart:
>
>> char* readstrfile(char* filespec) {
>> FILE* f;
>> char* m;
>> int64 size;
>>
>> f=fopen(filespec, "rb");
>> if (f==NULL) return NULL;
>>
>> rsfsize=size=getfilesize(f);
>>
>> m=malloc(size+1);
>> if (m==NULL) return NULL;
>>
>> readrandom(f,m,0,size);
>> *(m+size)=0;
>>
>> fclose(f);
>> return m;
>> }
>
> Is int64 a C type? Where is rsfszie declared and for what
> purpose? Does your function always close the file it opened?
> Does your function handle an error from readrandom()? Can
> readramndom() read fewer than `size' bytes (e.g. becuase of
> the conversion of \r\n to \n)?
>
The rest of the complete test program I used is given below, translated
today from code I've long used in my language.
rsfsize is a global, set so that the caller can optionally pick up the size.
It doesn't deal with read errors.
(I've used this approach to file-reading for probably 20 years or so, I
don't recall any issues. Any problems would likely manifest themselves
in other ways.
Things are more likely to go wrong on removeable media, but also when a
file changes size between calculating the size and completing the read.
BM's C++ version may suffer from this too, and there the filesize check
is a separate access. However, other people are welcome to add extra
checks, but some things you just can't do anything about.
As I said I have never identified a problem that the lack of checks has
caused.)
All my reads are in binary so newline conversion doesn't occur (and all
my apps will cope with either cr/lf or lf newlines).
------------------------------------
#include <stdio.h>
#include <stdlib.h>
typedef long long int int64;
int64 rsfsize;
int64 getfilesize(FILE* f) {
int64 p, size;
p=ftell(f);
fseek(f,0,SEEK_END);
size=ftell(f);
fseek(f,p,SEEK_SET);
return size;
}
int64 readrandom(FILE* f, char* mem, int64 offset, int64 size) {
fseek(f,offset, SEEK_SET);
return fread(mem, 1, size, f);
}
char* readstrfile(char* filespec) {
.....
}
int main(void) {
char* s;
s=readstrfile("hello.c");
if (s) puts(s);
}
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-18 01:46 +0300 |
| Message-ID | <20201218014649.a114107d58da02c12fdb3b41@gmail.com> |
| In reply to | #157366 |
Bart to Bonita Montero:
> bout 14 non-blank lines, exactly the same as your C++
> (when lines with only "{" are ignored).
Comparing C and C++ in terms of line counts is mostly a
losing game for C because C++ is about 100 times larger and
1000 more complicated. It is to be expected that it allows
to express the same thing in half the lines it takes in C at
the cost of relying on huge super-powerful standard
libraries. Add a few helper funcions in C and you get the
same line count :-)
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-18 01:00 +0300 |
| Message-ID | <20201218010041.0e8b5f1f24e4eb5eb1ee5bb2@gmail.com> |
| In reply to | #157356 |
Thiago Adams:
> This is the code I like: (standard C)
>
> char* readfile(const char* path)
> {
> char* result = NULL;
>
> struct stat info;
> if(stat(path, &info) == 0)
> {
> char* data = malloc(sizeof(char) * info.st_size + 1);
> if (data)
> {
> FILE* file = fopen(path, "r");
> if (file)
> {
> size_t n = fread(data, 1, info.st_size, file);
> if (n != 0 && n <= info.st_size)
> {
> data[n] = 0;
> result = data;
> data = NULL;
> }
> fclose(file);
> }
> free(data);
> }
> }
>
> return result;
> }
>
It is too deeply nested to my taste. Your trick of setting
data to NULL to avoid release of memory surprised me. Having
glanced at the man page, I think there is no reason
whatsoever to handle a zero read size specially. Here is a
version that I like:
char* readfile( char* path )
{ char* result;
char* data;
struct stat info;
FILE* file;
size_t n;
result = NULL;
if( stat( path, &info ) != 0 ) goto End;
data = malloc( sizeof( char ) * info.st_size + 1 );
if( data == NULL ) goto End;
file = fopen( path, "r" );
if( file == NULL ) goto EndData;
n = fread(data, 1, info.st_size, file);
if( n > info.st_size ) goto EndFile;
data[n] = 0;
result = data;
data = NULL;
EndFile: fclose( file );
EndData: free ( data );
End : return result;
}
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-18 10:59 -0800 |
| Message-ID | <b5ad2629-b81d-49b5-babf-178e25a52e33n@googlegroups.com> |
| In reply to | #157367 |
On Thursday, December 17, 2020 at 7:00:56 PM UTC-3, Anton Shepelev wrote:
> Thiago Adams:
> > This is the code I like: (standard C)
> >
> > char* readfile(const char* path)
> > {
> > char* result = NULL;
> >
> > struct stat info;
> > if(stat(path, &info) == 0)
> > {
> > char* data = malloc(sizeof(char) * info.st_size + 1);
> > if (data)
> > {
> > FILE* file = fopen(path, "r");
> > if (file)
> > {
> > size_t n = fread(data, 1, info.st_size, file);
> > if (n != 0 && n <= info.st_size)
> > {
> > data[n] = 0;
> > result = data;
> > data = NULL;
> > }
> > fclose(file);
> > }
> > free(data);
> > }
> > }
> >
> > return result;
> > }
> >
> It is too deeply nested to my taste. Your trick of setting
> data to NULL to avoid release of memory surprised me. Having
> glanced at the man page, I think there is no reason
> whatsoever to handle a zero read size specially. Here is a
> version that I like:
...
More real world code that can be used to validate defer and other patterns (gotos etc)
The real word file can have BOM. Byte order mark .
The UTF-8 representation of the BOM is the (hexadecimal) byte sequence 0xEF,0xBB,0xBF
https://en.wikipedia.org/wiki/Byte_order_mark
This code was difficult to write and it is the same read file and return the string
but now it skip BOM if present.
The fread interface is also hard to use. I decided to create fread2.
inline bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
{
*sz = 0;//out
bool result = false;
size_t n = fread(buffer, size, count, stream);
if (n == count) {
*sz = n;
result = true;
}
else if (n < count) {
if (feof(stream))
{
*sz = n;
result = true;
}
}
return result;
}
char* readfile(const char* path)
{
char* result = NULL;
struct stat info;
if (stat(path, &info) == 0)
{
char* data = (char*)malloc(sizeof(char) * info.st_size + 1);
if (data != NULL)
{
FILE* file = fopen(path, "r");
if (file != NULL)
{
if (info.st_size >= 3)
{
size_t n = 0;
if (fread2(data, 1, 3, file, &n))
{
if (n == 3)
{
if (data[0] == (char)0xEF &&
data[1] == (char)0xBB &&
data[2] == (char)0xBF)
{
if (fread2(data, 1, info.st_size - 3, file, &n))
{
//ok
data[n] = 0;
result = data; data = 0;
}
}
else
{
if (fread2(data + 3, 1, info.st_size - 3, file, &n))
{
data[3 + n] = 0;
result = data; data = 0;
}
}
}
else
{
data[n] = 0;
result = data; data = 0;
}
}
}
else
{
size_t n = 0;
if (fread2(data, 1, info.st_size, file, &n))
{
data[n] = 0;
result = data; data = 0;
}
}
fclose(file);
}
free(data);
}
}
return result;
}
The distance between malloc/free end fopen/fclose is big. I will try
defer and see the difference.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-18 11:12 -0800 |
| Message-ID | <0789ef23-c439-487e-b38c-746765f754f7n@googlegroups.com> |
| In reply to | #157410 |
On Friday, December 18, 2020 at 3:59:32 PM UTC-3, Thiago Adams wrote:
...
> The distance between malloc/free end fopen/fclose is big. I will try
> defer and see the difference.
Original readfile function : 63 lines.
readfile using if + defer: 54 lines.
char* readfile(const char* path)
{
char* result = NULL;
if (struct stat info; stat(path, &info) == 0)
{
if (char* data = (char*)malloc(sizeof(char) * info.st_size + 1);
data != NULL;
free(data))
{
if (FILE* file = fopen(path, "r");
file != NULL;
fclose(file))
{
if (info.st_size >= 3)
{
if (size_t n = 0; fread2(data, 1, 3, file, &n))
{
if (n == 3)
{
if (data[0] == (char)0xEF &&
data[1] == (char)0xBB &&
data[2] == (char)0xBF)
{
if (fread2(data, 1, info.st_size - 3, file, &n))
{
//ok
data[n] = 0;
result = data; data = 0;
}
}
else if (fread2(data + 3, 1, info.st_size - 3, file, &n))
{
data[3 + n] = 0;
result = data; data = 0;
}
}
else
{
data[n] = 0;
result = data; data = 0;
}
}
}
else if (size_t n = 0; fread2(data, 1, info.st_size, file, &n))
{
data[n] = 0;
result = data; data = 0;
}
}
}
}
return result;
}
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-19 02:18 +0300 |
| Message-ID | <20201219021853.2f4fd8e1253f385c82189c0b@gmail.com> |
| In reply to | #157410 |
Thiago Adams:
> The fread interface is also hard to use. I decided to
> create fread2.
> inline bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
> {
> *sz = 0;//out
>
> bool result = false;
> size_t n = fread(buffer, size, count, stream);
> if (n == count) {
> *sz = n;
> result = true;
> }
> else if (n < count) {
> if (feof(stream))
> {
> *sz = n;
> result = true;
> }
> }
> return result;
> }
Your solution below is too repetitive in my opinion because it
contains four invocations of fread2(). In order for me find
a better way to do it, can you please tell me in what
circumstances can the second (n < count) branch of fread2
execute if you pass the correct count parameter?
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-18 16:25 -0800 |
| Message-ID | <087de73c-d852-4d7b-bd1b-c6e612e9bf1en@googlegroups.com> |
| In reply to | #157430 |
On Friday, December 18, 2020 at 8:19:08 PM UTC-3, Anton Shepelev wrote:
> Thiago Adams:
>
> > The fread interface is also hard to use. I decided to
> > create fread2.
> > inline bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
> > {
> > *sz = 0;//out
> >
> > bool result = false;
> > size_t n = fread(buffer, size, count, stream);
> > if (n == count) {
> > *sz = n;
> > result = true;
> > }
> > else if (n < count) {
> > if (feof(stream))
> > {
> > *sz = n;
> > result = true;
> > }
> > }
> > return result;
> > }
>
> Your solution below is too repetitive in my opinion because it
> contains four invocations of fread2(). In order for me find
> a better way to do it, can you please tell me in what
> circumstances can the second (n < count) branch of fread2
> execute if you pass the correct count parameter?
https://en.cppreference.com/w/c/io/fread
"Number of objects read successfully, which may be less than
count if an error or end-of-file condition occurs."
"fread does not distinguish between end-of-file and error,
and callers must use feof AND ferror to determine which occurred."
This makes the fread hard to use.
Microsoft documentation says:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
"Use the feof OR ferror function to distinguish a read error from an end-of-file condition."
I created the fread2 to return true for success and false for error.
count is returned in argument.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-19 19:24 +0300 |
| Message-ID | <20201219192428.ffdf81a372553bb652487068@gmail.com> |
| In reply to | #157432 |
Thiago Adams:
> > Thiago Adams to Anton Shepelev:
> >
> > > inline bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
> > > {
> > > *sz = 0;//out
> > >
> > > bool result = false;
> > > size_t n = fread(buffer, size, count, stream);
> > > if (n == count) {
> > > *sz = n;
> > > result = true;
> > > }
> > > else if (n < count) {
> > > if (feof(stream))
> > > {
> > > *sz = n;
> > > result = true;
> > > }
> > > }
> > > return result;
> > > }
> >
> > In order for me find a better way to do it, can you
> > please tell me in what circumstances can the second
> > (n < count) branch of fread2 execute if you pass the
> > correct count parameter?
>
> https://en.cppreference.com/w/c/io/fread
Why use cppreference as C has no documentation of its own?
https://manned.org/ferror.3p
> "Number of objects read successfully, which may be less
> than count if an error or end-of-file condition occurs."
Correct.
> "fread does not distinguish between end-of-file and error,
> and callers must use feof AND ferror to determine which
> occurred."
Not correct. ferror() alone should be enough, and your
function neglects to use it.
> Microsoft documentation says:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
> "Use the feof OR ferror function to distinguish a read
> error from an end-of-file condition."
Correct, assuming that feof() and ferror() are mutually
exclusive. Are they? Is it specific to Microsoft?
Futhermore, the test (n < count) is redundant because it
will always evaluate true. Since the file position upon
failure is unspecified, fread2() may mistake a failure for
success. I think it may be rewritten much shorter and
better:
bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
{
*sz = fread( buffer, size, count, stream );
return !ferror( stream );
}
if the programmer will take care not to use `sz' upon
failure because it makes no sense anyway. What problem do
you see with my fread() that are absent from yours?
P.S.: Do you deliberately flatten my posts by squshing them
to the left wall by a 10-ton concrete slab?
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-19 09:07 -0800 |
| Message-ID | <f6a57aa8-1d75-4c8b-bffa-31b38447dafdn@googlegroups.com> |
| In reply to | #157474 |
On Saturday, December 19, 2020 at 1:24:43 PM UTC-3, Anton Shepelev wrote:
...
> > Microsoft documentation says:
> > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
> > "Use the feof OR ferror function to distinguish a read
> > error from an end-of-file condition."
>
> Correct, assuming that feof() and ferror() are mutually
> exclusive. Are they? Is it specific to Microsoft?
I am using VC++ and reading the documentation it seems
that if I read less than count , I can use feof or ferror to
distingue failure or success. I choose feof.
> Futhermore, the test (n < count) is redundant because it
> will always evaluate true. Since the file position upon
> failure is unspecified, fread2() may mistake a failure for
> success. I think it may be rewritten much shorter and
> better:
>
> bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
> {
> *sz = fread( buffer, size, count, stream );
> return !ferror( stream );
> }
I generally use ferror or errno when the result tell me
that I can do that. (in this case if reading less than count)
maybe someone forgot to clear the error before ? (clearerr)
It is difficult to know how this state is controlled.
Probably it is ok..but this was the reason I didn't checked
ferror directly without checking the result.
> if the programmer will take care not to use `sz' upon
> failure because it makes no sense anyway. What problem do
> you see with my fread() that are absent from yours?
fread or fread2? did you post fread?
> P.S.: Do you deliberately flatten my posts by squshing them
> to the left wall by a 10-ton concrete slab?
Sorry, I didn't understand... 10-ton concrete slab?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-19 22:36 +0300 |
| Message-ID | <20201219223659.133a9eb957583c50effdbe5b@gmail.com> |
| In reply to | #157476 |
Thiago Adams:
> > > Microsoft documentation says:
> > > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fread?view=msvc-160
> > > "Use the feof OR ferror function to distinguish a read
> > > error from an end-of-file condition."
> >
> > Correct, assuming that feof() and ferror() are mutually
> > exclusive. Are they? Is it specific to Microsoft?
>
> I am using VC++ and reading the documentation it seems
> that if I read less than count, I can use feof or ferror
> to distingue failure or success. I choose feof.
I thought that feof() and ferror() were not guarranteed to
be mutually exclusive. Futhermore, as one who have found
and fixed(!) errors in Microsoft documentation during my
work as a C# programmer, I must say their documentation is
not very good.
> > bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
> > {
> > *sz = fread( buffer, size, count, stream );
> > return !ferror( stream );
> > }
>
> I generally use ferror or errno when the result tell me
> that I can do that. (in this case if reading less than
> count) maybe someone forgot to clear the error before?
> (clearerr)
I think it is your responsibility not to work upon broken
streams. If you fear an pre-set error flag, add a
corresponding guard clause or reset it at the start of the
function...
> It is difficult to know how this state is controlled.
> Probably it is ok..but this was the reason I didn't
> checked ferror directly without checking the result.
I see. How about this:
bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
{
*sz = fread( buffer, size, count, stream );
return *sz < count && !eof( stream );
}
> > if the programmer will take care not to use `sz' upon
> > failure because it makes no sense anyway. What problem
> > do you see with my fread() that are absent from yours?
>
> fread or fread2? did you post fread?
A typo. I meant fread2() and posted fread2().
> > Do you deliberately flatten my posts by squshing them to
> > the left wall by a 10-ton concrete slab?
>
> Sorry, I didn't understand... 10-ton concrete slab?
When you quote my posts, all indentation is removed, as if
some filter at your side were ignoring all whitespace at
the start of each line. The result is flushing everithing
to the left.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-12-19 15:54 -0500 |
| Message-ID | <rrlp99$t27$1@dont-email.me> |
| In reply to | #157488 |
On 12/19/20 2:36 PM, Anton Shepelev wrote: > Thiago Adams: ... > I thought that feof() and ferror() were not guarranteed to > be mutually exclusive. Futhermore, as one who have found > and fixed(!) errors in Microsoft documentation during my > work as a C# programmer, I must say their documentation is > not very good. "... an error indicator that records whether a read/write error has occurred, and an end-of-file indicator that records whether the end of the file has been reached;" (7.21.1p2). An end-of-file and a read error can be distinguished by use of the feof and ferror functions. "The feof function tests the end-of-file indicator for the stream pointed to by stream." (7.21.10.2p2). "The ferror function tests the error indicator for the stream pointed to by stream." (7.21.10.3p2). All other functions for reading from streams have behavior defined as if they called fgetc(), the description of which says: "If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream is set and the fgetc function returns EOF. Otherwise, the fgetc function returns the next character from the input stream pointed to by stream. If a read error occurs, the error indicator for the stream is set and the fgetc function returns EOF.". As I read that, a single call to fgetc() that leaves the end-of-file indicator does not actually read from the stream, and therefore cannot also set the error indicator. All functions that read multiple bytes of input are defined as stopping the underlying fgetc() as soon as one fails for either reason. The error flag, on the other hand, is sticky. It's only cleared by fopen(), rewind() and clearerr(). If it's already set when fgetc() is called, then the end-of-file indicator can also be set. However, if the error flag has been cleared before the read occurs, I don't see any way for a single call to a standard library input function to result in both the end-of-file indicator and the error indicator being set. >>> Do you deliberately flatten my posts by squshing them to >>> the left wall by a 10-ton concrete slab? >> >> Sorry, I didn't understand... 10-ton concrete slab? > > When you quote my posts, all indentation is removed, as if > some filter at your side were ignoring all whitespace at > the start of each line. The result is flushing everithing > to the left. I suspect that the "10-ton concrete slab" is called "Google Groups".
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-20 01:21 +0300 |
| Message-ID | <20201220012129.ca8426d933bcdbbaaaee29e5@gmail.com> |
| In reply to | #157498 |
James Kuyper: > [...] > As I read that, a single call to fgetc() that leaves the > end-of-file indicator does not actually read from the > stream, and therefore cannot also set the error indicator. Correct. I failed to take that into account. > [...] > The error flag, on the other hand, is sticky. It's only > cleared by fopen(), rewind() and clearerr(). If it's > already set when fgetc() is called, then the end-of-file > indicator can also be set. However, if the error flag has > been cleared before the read occurs, I don't see any way > for a single call to a standard library input function to > result in both the end-of-file indicator and the error > indicator being set. Thank you for the explanation. > Anton Shepelev: > > > > > > Do you deliberately flatten my posts by squshing > > > > > them to the left wall by a 10-ton concrete slab? > > > > > > [...] > I suspect that the "10-ton concrete slab" is called > "Google Groups". Then it is a relatively new "imporovement" in their war against truely plain-text mediums. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
Page 11 of 15 — ← Prev page 1 … 9 10 [11] 12 13 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web