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


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

How to read a data file whose size is unknown in C?

Started byfl <rxjwg98@gmail.com>
First post2015-08-12 15:28 -0700
Last post2015-08-14 09:03 -0700
Articles 20 on this page of 164 — 27 participants

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


Contents

  How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 15:28 -0700
    Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 23:52 +0100
      Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:13 -0700
        Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 00:33 +0100
        Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:06 +0000
          Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-13 20:50 +0000
            Re: How to read a data file whose size is unknown in C? Stephen Sprunk <stephen@sprunk.org> - 2015-08-17 13:38 -0500
              Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-17 14:48 -0400
              Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-18 11:10 +0100
                Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 15:01 +0100
        Re: How to read a data file whose size is unknown in C? gordonb.8n5lc@burditt.org (Gordon Burditt) - 2015-08-14 02:33 -0500
          Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-14 10:06 +0200
            Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 09:14 +0100
              Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-14 21:27 +0000
                Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:52 +0200
            Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-15 01:17 +0100
              Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 10:27 +0200
                Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 18:09 +0000
                  Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:05 +0200
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:17 -0700
                Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 13:50 -0700
                  Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 21:37 +0100
                    Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:33 +0200
                      Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 22:58 +0100
                        Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:08 +0200
                          Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 00:40 +0100
                            Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:23 +0200
                              Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:37 -0700
                            Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:35 +0000
                              Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 10:31 -0700
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:21 -0700
                  Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:31 +0200
                  Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 03:38 -0700
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:29 -0700
                      Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:46 -0700
                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:03 -0700
                Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-16 03:23 +0100
                Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 00:56 -0700
                  Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 01:08 -0700
                  Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-17 10:20 +0200
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:01 -0700
              Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 11:31 +0100
                Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 14:01 -0700
                  Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 22:28 +0100
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:29 -0700
                      Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-16 10:50 +0100
                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:40 -0700
                          Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-16 20:22 -0700
                            Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 21:27 -0700
                              Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:31 -0700
                              Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:25 +0000
                                Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 16:29 -0700
                                  Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 23:43 +0000
                                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 18:20 -0700
                              Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-17 19:10 -0700
                                Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-18 05:26 +0000
                                  Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:23 +0000
                                Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-18 04:23 -0700
                                  Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:39 -0700
                                Re: How to read a data file whose size is unknown in C? Ike Naar <ike@iceland.freeshell.org> - 2015-08-18 16:49 +0000
                                  Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:42 -0700
                                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-18 19:57 -0700
                                      Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-19 16:12 -0700
                                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-19 18:04 -0700
                                          Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-20 16:52 -0700
                                            Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-20 18:18 -0700
                                            Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-21 20:39 +0000
                                              Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-21 17:17 -0700
                                                Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-21 19:35 -0700
                                                  Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:28 -0700
                                                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-22 22:43 -0700
                                                Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 00:07 -0400
                                                  Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:59 -0700
                                                    Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:22 -0400
                                                      Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 19:17 -0700
                                                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-23 21:35 -0700
                                                          Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 16:59 -0700
                                                            Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-24 17:57 -0700
                                                              Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-25 01:09 -0700
                                                                Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-25 19:03 -0700
                                                                  Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-25 22:16 -0400
                                                                    Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-26 14:29 -0700
                                                                      Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 18:28 -0400
                                                                        Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 19:25 -0700
                                                                          Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:07 +0200
                                                                          Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 09:18 -0700
                                                                            Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 18:04 +0000
                                                                              Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 11:15 -0700
                                                                                Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 21:10 +0000
                                                                              Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 15:54 -0700
                                                                              Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:28 +0200
                                                                            Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-27 13:12 -0600
                                                                              Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:35 +0200
                                                              Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 04:28 -0700
                                                        Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:19 -0400
                                                        Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:31 -0700
                                                          Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:06 -0700
                                                Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:25 +0000
                                                Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 10:45 -0400
                                            Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-21 17:40 -0400
                                    Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 00:40 -0400
                                      Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-19 05:38 +0000
                                        Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 10:20 -0400
                    Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:22 +0000
            Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:21 +0000
          Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:48 -0400
      Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:21 -0700
        Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-12 19:44 -0600
        Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-12 22:04 -0400
      Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 00:44 +0100
        Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 01:04 +0100
          Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 11:31 +0100
            Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 11:51 +0100
            Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 08:49 -0700
              Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 17:45 +0100
                Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:11 +0100
                  Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:34 +0100
                    Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 12:21 -0500
                      Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:07 +0100
                        Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 16:08 -0500
                          Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:51 +0200
                            Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-15 12:36 -0700
                              Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:26 +0200
                              Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:26 +0000
                                Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 08:11 -0700
                            Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-16 00:05 -0500
                              Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-16 09:08 -0400
                                Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:22 +0000
                              Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:28 -0700
                  Re: How to read a data file whose size is unknown in C? Tonton Th <tTh@nowhere.invalid> - 2015-08-14 11:06 +0000
                  Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:28 -0700
            Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 18:56 +0000
              Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 13:39 -0700
              Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 00:21 +0100
                Re: How to read a data file whose size is unknown in C? Ian Collins <ian-news@hotmail.com> - 2015-08-14 12:26 +1200
                  Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:00 +0100
                    Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:30 +0100
                      Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 12:31 +0100
                        Re: How to read a data file whose size is unknown in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 04:51 -0700
                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:21 -0700
                    Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:23 -0700
                      Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-14 16:57 -0700
                      Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-15 14:49 -0600
                        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:31 -0700
                Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 00:35 +0100
                Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 08:57 -0700
                  Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 17:28 +0100
        Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:12 +0000
    Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 07:03 +0200
    Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 12:38 +0200
      Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:32 +0100
        Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 14:49 +0200
          Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 14:05 +0100
          Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:50 +0100
          Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:14 -0700
          Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:42 -0400
      Re: How to read a data file whose size is unknown in C? Ken Brody <kenbrody@spamcop.net> - 2015-08-13 10:56 -0400
        Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:16 -0700
          Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-13 18:12 +0200
            Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:50 -0400
              Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 20:07 +0200
                Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 14:38 -0400
    Re: How to read a data file whose size is unknown in C? John Bode <jfbode1029@gmail.com> - 2015-08-13 09:30 -0700
      Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-14 09:03 -0700

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →


#67230 — How to read a data file whose size is unknown in C?

Fromfl <rxjwg98@gmail.com>
Date2015-08-12 15:28 -0700
SubjectHow to read a data file whose size is unknown in C?
Message-ID<7b7a215a-b72a-48ba-bbdc-ddc22ad8c5b7@googlegroups.com>
Hi,

I had a test and I don't know what is the catch:

How to read a data file whose size is unknown in C?


The data file could be a .img file.

I thought about fseek(), etc., but I was not sure at all and didn't say
anything about it. Whether is it about some function on the end of the file?


Thanks,

[toc] | [next] | [standalone]


#67233

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-08-12 23:52 +0100
Message-ID<mqgijl$932$1@dont-email.me>
In reply to#67230
On 12/08/15 23:28, fl wrote:
> Hi,
>
> I had a test and I don't know what is the catch:
>
> How to read a data file whose size is unknown in C?

man realloc

Start by malloc()ing some memory - say, 128 bytes. Keep track of how 
much storage you have.

while reading the file continues to succeed
   is there enough memory to store the new data just read in?
   if not
     use realloc to allocate some more (keep track!) - be ready
                 to deal with a null pointer return from realloc
   endif
   add the new data to the memory you allocated
endwhile

You may want to use a geometric progression to grow the buffer.

No, there is no standard way to find out the size of a file. Someone 
once cobbled together a bodge using fseek and ftell, which is not only 
not guaranteed to work but is actually an appalling misuse of those 
functions. The best way really is to keep reading it until you've read 
it, growing the storage area as you go.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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


#67238

Fromfl <rxjwg98@gmail.com>
Date2015-08-12 16:13 -0700
Message-ID<7e938b78-786d-47f9-90b4-9ed825b434a0@googlegroups.com>
In reply to#67233
On Wednesday, August 12, 2015 at 3:52:17 PM UTC-7, Richard Heathfield wrote:
> On 12/08/15 23:28, fl wrote:
> > Hi,
> >
> > I had a test and I don't know what is the catch:
> >
> > How to read a data file whose size is unknown in C?
> 
> man realloc
> 
> Start by malloc()ing some memory - say, 128 bytes. Keep track of how 
> much storage you have.
> 
> while reading the file continues to succeed
>    is there enough memory to store the new data just read in?
>    if not
>      use realloc to allocate some more (keep track!) - be ready
>                  to deal with a null pointer return from realloc
>    endif
>    add the new data to the memory you allocated
> endwhile
> 
> You may want to use a geometric progression to grow the buffer.
> 
> No, there is no standard way to find out the size of a file. Someone 
> once cobbled together a bodge using fseek and ftell, which is not only 
> not guaranteed to work but is actually an appalling misuse of those 
> functions. The best way really is to keep reading it until you've read 
> it, growing the storage area as you go.
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

Thanks for your reply.
I am even new to the origin of the question. Why would file size be not known? File size information is supported by a file open? My view is totally wrong?

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


#67240

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-08-13 00:33 +0100
Message-ID<mqgl0h$g4s$1@dont-email.me>
In reply to#67238
On 13/08/15 00:13, fl wrote:

<snip>

> Thanks for your reply.
> I am even new to the origin of the question. Why would file size be not known?

Well, of course it /is/ known, very often. I'll bet you half a dollar 
that the OS knows the file size.

Unfortunately, C doesn't, except by calling that OS function (or doing 
it the way I suggested) - and that OS function will differ from one OS 
to another. If you don't have a problem with your code being tied to one 
OS, you could simply call that OS's "function-to-find-file-length".

On Windows, it's something like _filelength() (Borland) or 
FunctionWithRidiculouslyLongNameAndUnreadableArgumentList() (Microsoft). 
On Linux, man stat. On other systems, Read The Manual.

Here's how I find out the file length when I'm feeling lazy:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

size_t get_file_length(const char *filename)
{
   struct stat st;
   stat(filename, &st);
   return st.st_size;
}

So I just call get_file_length(). If the code has to be ported to 
another system, I rewrite the body of get_file_length() to call that 
OS's "how big is this file?" function. The /calls/ to get_file_length() 
remain unchanged. (That's the advantage of abstracting the non-portable 
behaviour into a separate function and indeed a separate file.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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


#67243

Fromglen herrmannsfeldt <gah@ugcs.caltech.edu>
Date2015-08-13 00:06 +0000
Message-ID<mqgn24$7q6$2@speranza.aioe.org>
In reply to#67238
fl <rxjwg98@gmail.com> wrote:

(snip on how to read a file of unknown size)

> Thanks for your reply.
> I am even new to the origin of the question. Why would file 
> size be not known? File size information is supported by a 
> file open? My view is totally wrong?

Some OS don't keep track of the file size, at least not close
enough to answer the question.

-- glen

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


#67337

Fromraltbos@xs4all.nl (Richard Bos)
Date2015-08-13 20:50 +0000
Message-ID<55cd02d3.1624359@news.xs4all.nl>
In reply to#67243
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> fl <rxjwg98@gmail.com> wrote:
> 
> (snip on how to read a file of unknown size)
> 
> > Thanks for your reply.
> > I am even new to the origin of the question. Why would file 
> > size be not known? File size information is supported by a 
> > file open? My view is totally wrong?
> 
> Some OS don't keep track of the file size, at least not close
> enough to answer the question.

And on some OSes, certain pseudo-files can be accessed as if they are
files, but don't _have_ a fixed (or any) file size in the first place.

Richard

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


#67611

FromStephen Sprunk <stephen@sprunk.org>
Date2015-08-17 13:38 -0500
Message-ID<mqt9jm$5du$1@dont-email.me>
In reply to#67337
On 13-Aug-15 15:50, Richard Bos wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> fl <rxjwg98@gmail.com> wrote:
>>> Thanks for your reply. I am even new to the origin of the
>>> question. Why would file size be not known? File size information
>>> is supported by a file open? My view is totally wrong?
>> 
>> Some OS don't keep track of the file size, at least not close 
>> enough to answer the question.
> 
> And on some OSes, certain pseudo-files can be accessed as if they
> are files, but don't _have_ a fixed (or any) file size in the first
> place.

And, even if the file _does_ have a fixed size at the time you asked the
OS, it might have changed by the time you opened it--or between the time
you start and finish reading it.

OTOH, people generally overestimate the importance of knowing the exact
file size; just open the file and read until you reach the end, for
whatever definition of "end" may apply to that file type and OS.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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


#67613

FromJames Kuyper <jameskuyper@verizon.net>
Date2015-08-17 14:48 -0400
Message-ID<55D22C76.3090808@verizon.net>
In reply to#67611
On 08/17/2015 02:38 PM, Stephen Sprunk wrote:
...
> And, even if the file _does_ have a fixed size at the time you asked the
> OS, it might have changed by the time you opened it--or between the time
> you start and finish reading it.
> 
> OTOH, people generally overestimate the importance of knowing the exact
> file size; just open the file and read until you reach the end, for
> whatever definition of "end" may apply to that file type and OS.

The single most common reason I would want to get a file size is so I
can figure out how it will fit in the place that I want to copy/move it
to. Particularly with very large files, I would prefer to find out
before starting the copy/move, rather than as a result of the copy/move
failing. And, for precisely that reason, if there was any danger of the
file getting modified without my knowledge during that process, I'd
prefer to lock the file to prevent it from being modified before I
determine the size, with the lock not being removed until after I'm done
with it. Locking is another feature provided by some operating systems,
but not by C itself.

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


#67697

FromBartc <bc@freeuk.com>
Date2015-08-18 11:10 +0100
Message-ID<mqv07j$so9$1@dont-email.me>
In reply to#67611
On 17/08/2015 19:38, Stephen Sprunk wrote:
> On 13-Aug-15 15:50, Richard Bos wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>>> fl <rxjwg98@gmail.com> wrote:
>>>> Thanks for your reply. I am even new to the origin of the
>>>> question. Why would file size be not known? File size information
>>>> is supported by a file open? My view is totally wrong?
>>>
>>> Some OS don't keep track of the file size, at least not close
>>> enough to answer the question.
>>
>> And on some OSes, certain pseudo-files can be accessed as if they
>> are files, but don't _have_ a fixed (or any) file size in the first
>> place.
>
> And, even if the file _does_ have a fixed size at the time you asked the
> OS, it might have changed by the time you opened it--or between the time
> you start and finish reading it.

If a file is being randomly updated even while you're reading it, then 
the data you're reading in is going to be out of date.

If it's simply being extended as it's being read, then it might grow at 
a faster rate than you can read it!

> OTOH, people generally overestimate the importance of knowing the exact
> file size; just open the file and read until you reach the end, for
> whatever definition of "end" may apply to that file type and OS.

This makes is harder to do something as simple as reading the data from 
a file into a memory block. Sometimes you have to set aside your 
paranoia and assume the file you're reading is well-behaved. An easy way 
is to make this a requirement of your application.

Otherwise, how does a program even do this:

   gcc file.c

when file.c is still in the middle of being edited (by an editor working 
off disk or performing continuous updates), or is likely to be replaced 
by an entirely different file halfway through being read?

Whatever assumptions a program such as gcc makes about its input files, 
or restrictions it might impose, can be done by any application.

-- 
Bartc

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


#67714

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-08-18 15:01 +0100
Message-ID<87a8tod7b5.fsf@bsb.me.uk>
In reply to#67697
Bartc <bc@freeuk.com> writes:

> On 17/08/2015 19:38, Stephen Sprunk wrote:
<snip>
>> OTOH, people generally overestimate the importance of knowing the exact
>> file size; just open the file and read until you reach the end, for
>> whatever definition of "end" may apply to that file type and OS.
>
> This makes is harder to do something as simple as reading the data
> from a file into a memory block. Sometimes you have to set aside your
> paranoia and assume the file you're reading is well-behaved. An easy
> way is to make this a requirement of your application.
>
> Otherwise, how does a program even do this:
>
>   gcc file.c
>
> when file.c is still in the middle of being edited (by an editor
> working off disk or performing continuous updates), or is likely to be
> replaced by an entirely different file halfway through being read?
>
> Whatever assumptions a program such as gcc makes about its input
> files, or restrictions it might impose, can be done by any
> application.

Sure.  gcc does not need to know the size in advance and it does not
need to seek the file (i.e. it can compile from a pipe).  For many
programs (and gcc is one such example -- at least for it's main C source
files), all they need to do is read the data and process it as they go.

-- 
Ben.

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


#67360

Fromgordonb.8n5lc@burditt.org (Gordon Burditt)
Date2015-08-14 02:33 -0500
Message-ID<F8WdnWx5b6N4BFDInZ2dnUU7-QmdnZ2d@posted.internetamerica>
In reply to#67238
> I am even new to the origin of the question. Why would file size
> be not known? 

A file may grow faster than your program can read it.

In any case, if you open the file, get the file size (regardless
of how), allocate that much memory, then read the file in until
EOF, the file might grow between the time you got the size and you
read it in, and you'll overflow the memory.  It's safer to read
until the end of memory you allocated, which won't overflow, but
might miss the tail end of the file.

There are at least a dozen different definitions of "file size",
which give slightly different answers.  The one of interest here
is the number of characters you can read from the file.  Opening
the file, then reading and counting characters is portable but tends
to be slow, especially for video and database files.  Also, the
file size can change while or after you calculated it.

There is no portable way to get the length in bytes of a binary
file, (read the C standard's description of fseek() and ftell())
which may not even *HAVE* a byte-granular file size (example:  CP/M
1.4, where file sizes were in multiples of 128 bytes on IBM
single-density floppies)


> File size information is supported by a file open?

fopen() does not supply file size information, and if it did, it
could be out of date before you get a chance to use it.  A
technique using a fopen()/fseek()/ftell() combination is also
subject to modified file lengths before you can use it.

> My view is totally wrong?

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


#67362

Fromjacobnavia <jacob@jacob.remcomp.fr>
Date2015-08-14 10:06 +0200
Message-ID<mqk7ek$9ia$1@dont-email.me>
In reply to#67360
Le 14/08/2015 09:33, Gordon Burditt a écrit :
> (read the C standard's description of fseek() and ftell())
> which may not even*HAVE*  a byte-granular file size (example:  CP/M
> 1.4, where file sizes were in multiples of 128 bytes on IBM
> single-density floppies)

It *could* be interesting to recall that CP/M doesn't exist since at 
least 35 years. Concerning the IBM single density floppies... well that 
is the same situation. 36 years old.

Of course for software written TODAY it is of paramount importance to be 
compatible with CP/M and single density floppies.

This is an example of the "portability at any cost" attitude.

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


#67363

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-08-14 09:14 +0100
Message-ID<mqk7u6$bkk$1@dont-email.me>
In reply to#67362
On 14/08/15 09:06, jacobnavia wrote:
> Le 14/08/2015 09:33, Gordon Burditt a écrit :
>> (read the C standard's description of fseek() and ftell())
>> which may not even*HAVE*  a byte-granular file size (example:  CP/M
>> 1.4, where file sizes were in multiples of 128 bytes on IBM
>> single-density floppies)
>
> It *could* be interesting to recall that CP/M doesn't exist since at
> least 35 years.

That's not the point. The point is that it's an example of an 
architecture that doesn't behave in the way a lot of people seem to 
expect. Sure, CP/M 1.4 is ancient history. But what do you expect Gordon 
to do - give specific examples of unusual architectures that are going 
to crop up in the 2020s? We look to the past not to dwell in it but to 
learn from it, and one thing we learn from the past is that we're not 
very good at learning from the past, because we keep making the mistake 
of thinking that we can't learn anything from the past. So let's not 
make that mistake again.

> Concerning the IBM single density floppies... well that
> is the same situation. 36 years old.
>
> Of course for software written TODAY it is of paramount importance to be
> compatible with CP/M and single density floppies.

No, for (some) software written *today* it can be of paramount 
importance to be compatible with /future/ systems, and they may not be 
designed quite like we expect them to be designed.

> This is an example of the "portability at any cost" attitude.

No, Gordon's example illustrates that there are Other Ways To Think 
About It than the ways we think about it today. It was different 
yesterday. It will be different tomorrow, too. Plan for tomorrow.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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


#67434

Fromglen herrmannsfeldt <gah@ugcs.caltech.edu>
Date2015-08-14 21:27 +0000
Message-ID<mqlmg5$m4e$1@speranza.aioe.org>
In reply to#67363
Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 14/08/15 09:06, jacobnavia wrote:

(snip)
>> It *could* be interesting to recall that CP/M doesn't exist since at
>> least 35 years.

They might not be selling it, but the existing copies don't
just disappear.
 
> That's not the point. The point is that it's an example of an 
> architecture that doesn't behave in the way a lot of people seem to 
> expect. Sure, CP/M 1.4 is ancient history. But what do you expect Gordon 
> to do - give specific examples of unusual architectures that are going 
> to crop up in the 2020s? We look to the past not to dwell in it but to 
> learn from it, and one thing we learn from the past is that we're not 
> very good at learning from the past, because we keep making the mistake 
> of thinking that we can't learn anything from the past. So let's not 
> make that mistake again.
 
IBM's current z/OS also makes it hard to find file length.

-- glen

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


#67448

Fromjacobnavia <jacob@jacob.remcomp.fr>
Date2015-08-15 09:52 +0200
Message-ID<mqmr0l$9ii$2@dont-email.me>
In reply to#67434
Le 14/08/2015 23:27, glen herrmannsfeldt a écrit :
>>> >>least 35 years.
> They might not be selling it, but the existing copies don't
> just disappear.
>

of course not!

We should all be compatible with CP/M to ensure the portability of our 
applications!

:-)

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


#67443

FromNobody <nobody@nowhere.invalid>
Date2015-08-15 01:17 +0100
Message-ID<pan.2015.08.15.00.18.27.854000@nowhere.invalid>
In reply to#67362
On Fri, 14 Aug 2015 10:06:35 +0200, jacobnavia wrote:

> Le 14/08/2015 09:33, Gordon Burditt a écrit :
>> (read the C standard's description of fseek() and ftell()) which may not
>> even*HAVE*  a byte-granular file size (example:  CP/M 1.4, where file
>> sizes were in multiples of 128 bytes on IBM single-density floppies)
> 
> It *could* be interesting to recall that CP/M doesn't exist since at least
> 35 years. Concerning the IBM single density floppies... well that is the
> same situation. 36 years old.

CP/M is no longer widely used, but various versions of Windows are, and
they still maintain compatibility with certain aspects of CP/M's
filesystem semantics.

Specifically, if a file is opened in text mode (i.e. no "b" in the second
argument to fopen), the implementation will report EOF on encountering a
Ctrl-Z character ('\x1a'). It does this because that's how CP/M indicates
the end of a text file (the filesystem itself only stores file sizes in
terms of the number of blocks, not bytes).

And the value returned by ftell(fp) immediately following a call to
fseek(fp, 0, SEEK_END) won't tell you where the first '\x1a' character is;
it just reads the "size" from the directory entry. It also won't account
for any CRLF ("\r\n") pairs which each get converted to a single '\n'
character when reading from a file opened in text mode.

At least both of these factors result in the fseek+ftell approach
overestimating the size (defined by the number of characters which can be
read) rather than underestimating it. OTOH, reading a file which is being
written by another process may well result in more characters being read
than fseek+ftell would indicate.

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


#67450

Fromjacobnavia <jacob@jacob.remcomp.fr>
Date2015-08-15 10:27 +0200
Message-ID<mqmt2g$g9t$1@dont-email.me>
In reply to#67443
Le 15/08/2015 02:17, Nobody a écrit :
> On Fri, 14 Aug 2015 10:06:35 +0200, jacobnavia wrote:
>
>> Le 14/08/2015 09:33, Gordon Burditt a écrit :
>>> (read the C standard's description of fseek() and ftell()) which may not
>>> even*HAVE*  a byte-granular file size (example:  CP/M 1.4, where file
>>> sizes were in multiples of 128 bytes on IBM single-density floppies)
>>
>> It *could* be interesting to recall that CP/M doesn't exist since at least
>> 35 years. Concerning the IBM single density floppies... well that is the
>> same situation. 36 years old.
>
> CP/M is no longer widely used,

Thanks. At least you acknowledge that.

May I remind you that NOWHERE in your message you mentioned that CP/M is 
no longer used since MSDOS, around 30 years ago?????

For "young" people (under 40 years old) CP/M never existed!

  but various versions of Windows are, and
> they still maintain compatibility with certain aspects of CP/M's
> filesystem semantics.
>

This is also not true. It was MSDOS that (to be compatible with CP/M) 
continued using ctrl-z as EOF marker in its version 1.0. But beginning 
with the version 2.0 of MSDOS (1983, 32 years ago!!!) CTRL-Z was no 
longer any special character!!!

This means that Windows NEVER used Ctrl-z for end of file. Windows uses 
Ctrl-z as the UNDO command.

You are just writing NONSENSE!

> Specifically, if a file is opened in text mode (i.e. no "b" in the second
> argument to fopen), the implementation will report EOF on encountering a
> Ctrl-Z character ('\x1a'). It does this because that's how CP/M indicates
> the end of a text file (the filesystem itself only stores file sizes in
> terms of the number of blocks, not bytes).
>

As I wrote before, this is NOT the case since 1983 !!!!!


> And the value returned by ftell(fp) immediately following a call to
> fseek(fp, 0, SEEK_END) won't tell you where the first '\x1a' character is;
> it just reads the "size" from the directory entry. It also won't account
> for any CRLF ("\r\n") pairs which each get converted to a single '\n'
> character when reading from a file opened in text mode.
>

ftell doesn't always give consistent results in "text" mode. It is 
written in the C standard. That doesn't mean that it can't be used to 
give the file size if you open files in binary mode!


> At least both of these factors result in the fseek+ftell approach
> overestimating the size (defined by the number of characters which can be
> read) rather than underestimating it. OTOH, reading a file which is being
> written by another process may well result in more characters being read
> than fseek+ftell would indicate.
>

Normal. This is by design!

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


#67456

Fromglen herrmannsfeldt <gah@ugcs.caltech.edu>
Date2015-08-15 18:09 +0000
Message-ID<mqnv8s$ctk$1@speranza.aioe.org>
In reply to#67450
jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 15/08/2015 02:17, Nobody a écrit :

(snip)
> May I remind you that NOWHERE in your message you mentioned 
> that CP/M is no longer used since MSDOS, around 30 years ago?????
 
> For "young" people (under 40 years old) CP/M never existed!
 
>>  but various versions of Windows are, and
>> they still maintain compatibility with certain aspects of CP/M's
>> filesystem semantics.
 
> This is also not true. It was MSDOS that (to be compatible with CP/M) 
> continued using ctrl-z as EOF marker in its version 1.0. But beginning 
> with the version 2.0 of MSDOS (1983, 32 years ago!!!) CTRL-Z was no 
> longer any special character!!!

No, it stayed around a lot longer in some places.

At least in MS-DOS 3.2, the print spooler wouldn't print them.

Some programs still check for them, but I don't know the details.
I have seen COPY do it, so use XCOPY to be sure.
 
> This means that Windows NEVER used Ctrl-z for end of file. Windows uses 
> Ctrl-z as the UNDO command.

For CMD, control-z is still the EOF character for programs
reading stdin.
 
> You are just writing NONSENSE!

-- glen

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


#67463

Fromjacobnavia <jacob@jacob.remcomp.fr>
Date2015-08-15 22:05 +0200
Message-ID<mqo5ua$8om$1@dont-email.me>
In reply to#67456
Le 15/08/2015 20:09, glen herrmannsfeldt a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>> Le 15/08/2015 02:17, Nobody a écrit :
>
> (snip)
>> May I remind you that NOWHERE in your message you mentioned
>> that CP/M is no longer used since MSDOS, around 30 years ago?????
>
>> For "young" people (under 40 years old) CP/M never existed!
>
>>>   but various versions of Windows are, and
>>> they still maintain compatibility with certain aspects of CP/M's
>>> filesystem semantics.
>
>> This is also not true. It was MSDOS that (to be compatible with CP/M)
>> continued using ctrl-z as EOF marker in its version 1.0. But beginning
>> with the version 2.0 of MSDOS (1983, 32 years ago!!!) CTRL-Z was no
>> longer any special character!!!
>
> No, it stayed around a lot longer in some places.
>

This was due to the run time libraries of the C compilers of the time 
that added Ctrl-Z processing, in the beginning to be compatible with 
files written for MSDOS 1.x. Borland did it, and other compilers did it.


Then, people thought that the CtrlZ was still used, since many programs 
were written in C. MSDOS from version 2.0 stored BYTE length and not 128 
bytes blocks like CP/M.

Microsoft was getting mad at this and changed its run time library to 
*eliminate* the ctrl-z of any file that was opened in text mode. The 
software would go to the last character in the file and if it was it 
would erase the Ctrl-z from the file!

> At least in MS-DOS 3.2, the print spooler wouldn't print them.
>

Maybe, there are still programs that go on checking for Ctrl-Z in very 
old programs.

But you will agree with me that the print spooler of MSDOS 3.2 is NOT 
relevant TODAY isn't it?

OK

My goal here is to attire your attention to the fact that portability is 
ONE of the parameters for judging or using C code. There are MANY other, 
more important parameters that never are even mentioned here:

1) Correctness. Does the program work at all?

2) Is the program brittle? Or can it accept bad inputs, interrupts and 
other asynchronous events without crashing?

3) Performance. If you write in C and not in python/ruby/whatever is 
because you want EFFICIENT programs.

4) Is the code light to follow? Easy to be understood by any C programmer?


> Some programs still check for them, but I don't know the details.
> I have seen COPY do it, so use XCOPY to be sure.
>

In windows?

Now, please... I am not a Microsoft representative. Relax...

>> This means that Windows NEVER used Ctrl-z for end of file. Windows uses
>> Ctrl-z as the UNDO command.
>
> For CMD, control-z is still the EOF character for programs
> reading stdin.
>

YES. Like Ctrl-D under Unix. You need a character that you can type at 
the keyboard to send an EOF, if not, it is impossible to get out!


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


#67508

FromKeith Thompson <kst-u@mib.org>
Date2015-08-15 19:17 -0700
Message-ID<lnzj1s7z9e.fsf@kst-u.example.com>
In reply to#67463
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> This was due to the run time libraries of the C compilers of the time 
> that added Ctrl-Z processing, in the beginning to be compatible with 
> files written for MSDOS 1.x. Borland did it, and other compilers did it.
>
>
> Then, people thought that the CtrlZ was still used, since many programs 
> were written in C. MSDOS from version 2.0 stored BYTE length and not 128 
> bytes blocks like CP/M.
>
> Microsoft was getting mad at this and changed its run time library to 
> *eliminate* the ctrl-z of any file that was opened in text mode. The 
> software would go to the last character in the file and if it was it 
> would erase the Ctrl-z from the file!

Wait, what?  You make it sound like opening a text file for *reading*
would cause the runtime library to modify the file.  It doesn't really
do that, does it?  Making text editors, for example, remove a trailing
Ctrl-Z when updating a file would make sense; so would omitting a
trailing Ctrl-Z when copying a text file.  (Similarly, some Unix text
editors will add a trailing '\n' to a text file that doesn't have one --
but of course only when updating it.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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


Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

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


csiph-web