Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #157279 > unrolled thread

A defer mechanism for C

Back to article view | Back to comp.lang.c

Contents

  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 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15  Next page →

#157536

On Saturday, December 19, 2020 at 4:37:13 PM UTC-3, Anton Shepelev wrote:
> 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 );
> } 

Did you mean?

*sz < count && !ferror( stream )

This is the code we think it is so clever and I didn't understand or wrong 
maybe you can help  ... :)

Following the documentation

*sz == count is success.
*sz < count  maybe is success if eof or it is error if ferror

then ..

 bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz) 
 { 
   *sz = fread( buffer, size, count, stream );
   return (*sz == count)  || //success
               (*sz < count && eof( stream )) //success
              );
 } 


(google groups is removing spaces) 

[toc] | [prev] | [next] | [standalone]

#157561

Thiago Adams to Anton Shepelev:

> > 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 );
> > }
>
> Did you mean?
>
> *sz < count && !ferror( stream )

No. I wrote the criterium of error instead of success and
mistyped feof().  The criteria of success is be the negation
of it:
              *sz == count || feof( stream );

I was playing by your rules and avoiding ferror().  But
observe that your original solution of BOM handling may not
work correctly if the file size has increased immediately
after you measured its size.

> This is the code we think it is so clever and I didn't
> understand or wrong maybe you can help  ... :)

I don't think it is too clever.

> Following the documentation
>
> *sz == count is success.
> *sz < count  maybe is success if eof or it is error if ferror
>
> then ..
>
>  bool fread2(void* buffer, size_t size, size_t count, FILE* stream, size_t* sz)
>  {
>    *sz = fread( buffer, size, count, stream );
>    return (*sz == count)  || //success
>                (*sz < count && eof( stream )) //success
>               );
>  }

If you observe that (*sz == count) and (*sz < count) are
mutually exclusive and that

                  a || (!a && b) == a || b

you will end up with my version above. It is a natural
boolean simplification, and now fread2() is just two lines!

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157562

Anton Shepelev:

> I wrote the criterium of error instead of success.

criterion.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157566

I wrote:

> I wrote the criterion of error instead of success and
> mistyped feof().  The criterion of success is the
> negation of it:
>
>              *sz == count || feof( stream );
>
> It is a natural boolean simplification

So natural that it is easily read in English: the file read
operation is successful if it has read the requested amount
of data or reached the end of file.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157570

On Monday, December 21, 2020 at 6:08:12 AM UTC-3, Anton Shepelev wrote:
> I wrote: 
> 
> > I wrote the criterion of error instead of success and 
> > mistyped feof(). The criterion of success is the
> > negation of it: 
> > 
> > *sz == count || feof( stream ); 
> >
> > It is a natural boolean simplification
> So natural that it is easily read in English: the file read 
> operation is successful if it has read the requested amount 
> of data or reached the end of file.

ok! now  it makes sense ant it is smaller.
I liked it.

[toc] | [prev] | [next] | [standalone]

#157438

On 18/12/2020 18:59, Thiago Adams wrote:

> 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;
> }

That's a lot of indentation. Two levels of it, blocks conditional on 
results of malloc and fopen, can easily be elimimated. But it was still 
a little complicated, I think because of the need to eliminate a BOM 
sequence at the start of the file.

In the following version, it just reads everything including BOM, then 
checks for BOM, and if found it moves the rest of the text down:


---------------------------------------------------

char* readfile(const char* path)
{
     size_t n;
     char bom[3]={0xEF, 0xBB, 0xBF};

     struct stat info;
     if (stat(path, &info) != 0) return NULL;

     char* data = (char*)malloc(sizeof(char) * info.st_size + 1);
     if (data == NULL) {
         return NULL;
     }

     FILE* file = fopen(path, "r");
     if (file == NULL) {
         free(data);
         return NULL;
     }

     if (fread2(data, 1, info.st_size, file, &n)) {
         if (n >= 3 && memcmp(data, bom, 3)==0) {
             n-=3;
             memmove(&data[0],&data[3],n);
         }
         data[n] = 0;
     } else {
         data[0]=0;
     }
     fclose(file);

     return data;
}

---------------------------------------------------

It's not clear why your version needs to free the data it's allocated, 
so I got rid of that part. On a data-read error, it returns an empty 
string (inside the allocated block).

[toc] | [prev] | [next] | [standalone]

#157444

On Friday, December 18, 2020 at 10:41:16 PM UTC-3, Bart wrote:
> On 18/12/2020 18:59, Thiago Adams wrote: 
> 
> > 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; 
> > } 
> 
> That's a lot of indentation. Two levels of it, blocks conditional on 
> results of malloc and fopen, can easily be elimimated. But it was still 
> a little complicated, I think because of the need to eliminate a BOM 
> sequence at the start of the file. 
> 
> In the following version, it just reads everything including BOM, then 
> checks for BOM, and if found it moves the rest of the text down: 
> 
> 
> --------------------------------------------------- 
> 
> char* readfile(const char* path) 
> { 
> size_t n; 
> char bom[3]={0xEF, 0xBB, 0xBF}; 
> 
> struct stat info; 
> if (stat(path, &info) != 0) return NULL; 
> 
> char* data = (char*)malloc(sizeof(char) * info.st_size + 1); 
> if (data == NULL) { 
> return NULL; 
> } 
> 
> FILE* file = fopen(path, "r"); 
> if (file == NULL) { 
> free(data); 
> return NULL; 
> } 
> 
> if (fread2(data, 1, info.st_size, file, &n)) { 
> if (n >= 3 && memcmp(data, bom, 3)==0) { 
> n-=3; 
> memmove(&data[0],&data[3],n); 
> } 
> data[n] = 0; 
> } else { 
> data[0]=0; 
> } 
> fclose(file); 
> 
> return data; 
> } 
> 
> --------------------------------------------------- 
> 
> It's not clear why your version needs to free the data it's allocated, 
> so I got rid of that part. On a data-read error, it returns an empty 
> string (inside the allocated block).

You need an extra free(data); in your code if fread2 fails.

My code has a free that always delete data. but on success
data is "moved" to result and becomes 0. this avoids one extra if that is
already inside free.

your suggestion of write BOM and then delete the BOM simplifies
the code. I am not sure about performance of memmove 
compared against extra ifs I have to check estate.

[toc] | [prev] | [next] | [standalone]

#157445

Bart to Thiago Adams:

> That's a lot of indentation.

I agree.

> In the following version, it just reads everything
> including BOM, then checks for BOM, and if found it moves
> the rest of the text down:

Yes, that is easy to do, but I don't like the idea of
rewriting everything you have read merely to account for
BOM. It is not a beautiful solution, nor production-level.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157448

On Saturday, December 19, 2020 at 9:02:54 AM UTC-3, Anton Shepelev wrote:
> Bart to Thiago Adams:
> > That's a lot of indentation.
> I agree.

I avoid returns in the middle of C code.
Sometimes I have then at the begging for arguments
before any state change .

[toc] | [prev] | [next] | [standalone]

#157453

Thiago Adams:

> I avoid returns in the middle of C code.

So do I, although I will routinely jump the end.

> Sometimes I have then at the begging for arguments before
> any state change .

Indeed. Early tests at the beginning are most noticeable and
safe, but since I value aesthetics so much, downward goto's
from the middle of a function are my Scylla and deep nesting
my Charybdis.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157451

On 19/12/2020 12:02, Anton Shepelev wrote:
> Bart to Thiago Adams:
> 
>> That's a lot of indentation.
> 
> I agree.
> 
>> In the following version, it just reads everything
>> including BOM, then checks for BOM, and if found it moves
>> the rest of the text down:
> 
> Yes, that is easy to do, but I don't like the idea of
> rewriting everything you have read merely to account for
> BOM. It is not a beautiful solution, nor production-level.
> 

I do all sorts of such things for production code...

Shifting down the whole text for 3 characters I've measured as slowing 
down reading the file by about 10%. However, reading the file is itself 
is usually the fastest, least significant part of the whatever it is you 
end up doing with the file.

For a 25 million line file, it took 0.2 seconds longer to read when BOM 
was present. So for a 2500-line source module for example, it would take 
20us longer.

There are other ways to handle this, eg returning data+3 when BOM is 
present, but is more fiddly to free the data. (With a BOM you would 
normally want the caller to know it was present.)

The original approach of reading 3 bytes then the rest can still be used 
of course, but it could be made more compact.

[toc] | [prev] | [next] | [standalone]

#157456

Bart:

> Shifting down the whole text for 3 characters I've
> measured as slowing down reading the file by about 10%.
> However, reading the file is itself is usually the
> fastest, least significant part of the whatever it is you
> end up doing with the file.
>
> For a 25 million line file, it took 0.2 seconds longer to
> read when BOM was present. So for a 2500-line source
> module for example, it would take 20us longer.

Then I was wrong (as long as the file is on disk).  I still
consider shifting large memory blocks as a means of skpping
a prefix inelegant.

> There are other ways to handle this, eg returning data+3
> when BOM is present, but is more fiddly to free the data.
> (With a BOM you would normally want the caller to know it
> was present.)

That occurred to me, too. I thought to propose returning a
struct, possibly opaque, with the pointer to the useful data
and an internal pointer for freeing but considered it too
clumsy for so simple a task.

> The original approach of reading 3 bytes then the rest can
> still be used of course, but it could be made more
> compact.

Yes, I am going to post my attempt.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157478

On 19/12/2020 14:11, Anton Shepelev wrote:
> Bart:
> 
>> Shifting down the whole text for 3 characters I've
>> measured as slowing down reading the file by about 10%.
>> However, reading the file is itself is usually the
>> fastest, least significant part of the whatever it is you
>> end up doing with the file.
>>
>> For a 25 million line file, it took 0.2 seconds longer to
>> read when BOM was present. So for a 2500-line source
>> module for example, it would take 20us longer.
> 
> Then I was wrong (as long as the file is on disk).  I still
> consider shifting large memory blocks as a means of skpping
> a prefix inelegant.

My timings probably took advantage of file cacheing. But that would 
exaggerate the memmove overhead compared to file-loading. Additionally, 
a more typical file would probably fit entirely into cache memory. My 
test file was 800MB.

> 
>> There are other ways to handle this, eg returning data+3
>> when BOM is present, but is more fiddly to free the data.
>> (With a BOM you would normally want the caller to know it
>> was present.)
> 
> That occurred to me, too. I thought to propose returning a
> struct, possibly opaque, with the pointer to the useful data
> and an internal pointer for freeing but considered it too
> clumsy for so simple a task.

With higher-level types, this is the sort of thing you'd do. Example in 
my script language:

     function readfile(file)=
         s:=readstrfile(file)
         if s=0 then return 0 fi

         if leftstr(s,3)="\xEF\xBB\xBF" then
             return rightstr(s,-3)
         else
             return s
         fi
     end

(readstrfile() is a library function to read not just any text file, but 
any binary file, into a string object, which returns integer 0 on error. 
It's based on the script equivalent of the first C code I posted.

The function returns a slice or view into the string when it starts with 
the BOM mark. The built-in ref-counting takes care of memory management.)

[toc] | [prev] | [next] | [standalone]

#157446

Bart:

> It's not clear why your version needs to free the data
> it's allocated, so I got rid of that part. On a data-read
> error, it returns an empty string (inside the allocated
> block).

That is natural for a function to be atomic and free of side
effects it if fails.  It should not leave random unused
allocated memory after each unsuccessful invocation.  Thiago
used a trick conditionally to free data using an
unconditional call to free(), which exists silently if
passed NULL. In other words, free( p ) is equivalent to
if( p != NULL ) free ( p ) .

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157449

Thiago Adams:

> The distance between malloc/free end fopen/fclose is big.
> I will try defer and see the difference.

The first, simlest, and most obvious amendment of that
undesirable property is to extract the intervening code into
a separate "internal" subrounine, readfile_int():

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)
            {
                readfile_int( file, info.st_size, *data, *result );
                flose( file );
            }
            free(data);
        }
    }
    return result;
}

The advantages of this modification are that it

  1.  being purely mechanical, is easy and lazy to do,

  2.  preserves the original flow of control to the letter,

  3.  efficiently decreases both dimensions of complexity:
      vertial (lines per function) and horisontal
      (indentation per function).

  4.  keeps the code sequence chronological, i.e. requires
      no defer.

  5.  emphasizes the principle of single responsibility,
      separating resource management and logic.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157452

On Saturday, December 19, 2020 at 9:26:40 AM UTC-3, Anton Shepelev wrote:
> Thiago Adams: 
> 
> > The distance between malloc/free end fopen/fclose is big. 
> > I will try defer and see the difference. 
> 
> The first, simlest, and most obvious amendment of that 
> undesirable property is to extract the intervening code into 
> a separate "internal" subrounine, readfile_int():
> 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) 
> {
> readfile_int( file, info.st_size, *data, *result ); 
> flose( file ); 
> } 
> free(data); 
> } 
> } 
> return result; 
> } 
> 
> The advantages of this modification are that it 
> 
> 1. being purely mechanical, is easy and lazy to do, 
> 
> 2. preserves the original flow of control to the letter, 
> 
> 3. efficiently decreases both dimensions of complexity: 
> vertial (lines per function) and horisontal 
> (indentation per function). 
> 
> 4. keeps the code sequence chronological, i.e. requires 
> no defer. 
> 
> 5. emphasizes the principle of single responsibility, 
> separating resource management and logic.

I generally do like this. Some "inner code" are  easier to 
refactoring in a new function than others.
The refactored function sometimes can be ugly as well
because alone it does not make sense.

[toc] | [prev] | [next] | [standalone]

#157455

Thiago Adams:

> I generally do like this. Some "inner code" are  easier to
> refactoring in a new function than others.  The refactored
> function sometimes can be ugly as well because alone it
> does not make sense.

Of course, and sometimes it takes great effort to find a
sufficiently narrow narrow place in that deformed sossiage
where it is the easest to cut in two without making a mess.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157486

Thiago Adams:

> 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;
> }

Here are a couple of my solutions:

char* fread_bom_1( const char* path )
{   const  int THREE = 3;

    char   ok;
    char   *buf, *result;
    FILE*  f;
    size_t bs, n, read;

    ok     = 0;
    result = NULL;
    buf    = NULL;
    bs     = THREE + 1;
    read   = 0;
    f      = fopen( path, "r" );

    if( f != NULL )
    while( 1 )
    {   ok  = 0;
        buf = realloc( buf, bs );
        if( buf == NULL ) break;

        n = fread  ( buf + read, 1, bs - read - 1, f );
        if( ferror( f ) ) break;
        read = read + n;

        if( bs - read == 1 &&
            buf[0] == 0xEF &&
            buf[1] == 0xBB &&
            buf[2] == 0xBF  )
        {   read = 0;  }
        ok = 1;
        if( feof( f ) ) break;
        bs = bs * 2;
    }
    if( f != NULL ) fclose( f );
    buf = realloc( buf, read + 1 ); /* can shrink fail? */
    buf[read] = '\0';
    if( ok ) result = buf;
    else     free( buf );

    return result;
}

char* fread_bom_2( const char* path )
{   const  int THREE = 3;

    char   ok;
    char   *buf, *result;
    FILE*  f;
    size_t n, toread, ofs, read;
    struct stat info;

    ok     = 0;
    result = NULL;

    printf("Start\n");
    while( 1 )
    {   if( stat( path, &info ) != 0 ) break;

        f      = fopen( path, "r" );
        if( f == NULL ) break;

        buf = malloc( info.st_size + 1 );
        if( buf == NULL ) break;

        ok = 1;
        break;
    }

    toread = THREE;
    read   = 0;
    ofs    = 0;
    while( ok )
    {   ok  = 0;
        n = fread( buf + read - ofs, 1, toread, f );
        if( ferror( f )  ) break;
        read = read + n;

        if( read   == THREE &&
            buf[0] == 0xEF  &&
            buf[1] == 0xBB  &&
            buf[2] == 0xBF
        )
        {   ofs = THREE;  }

        ok = 1;
        if( toread == info.st_size ) break;
        if( feof( f )              ) break;
        if( read > THREE           ) break;

        toread = info.st_size - THREE;
    }
    if( f != NULL ) fclose( f );
    buf[read-ofs] = '\0';
    if( ok ) result = buf;
    else     free( buf );
    return result;
}

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157571

I wrote:

> Here are a couple of my solutions:
> [...]

Now that I have though some more about it, I see no reason
to use fread() at all.  An algorithm using fgetc() should be
simpler.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#157573

On 21/12/2020 12:13, Anton Shepelev wrote:
> I wrote:
> 
>> Here are a couple of my solutions:
>> [...]
> 
> Now that I have though some more about it, I see no reason
> to use fread() at all.  An algorithm using fgetc() should be
> simpler.
> 

When I tried using an fgetc() loop instead of fread(), my 800MB test 
file took 50 seconds to read in instead of 3 seconds.

[toc] | [prev] | [next] | [standalone]

Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15  Next page →

Back to top | Article view | comp.lang.c

csiph-web