Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67230 > unrolled thread
| Started by | fl <rxjwg98@gmail.com> |
|---|---|
| First post | 2015-08-12 15:28 -0700 |
| Last post | 2015-08-14 09:03 -0700 |
| Articles | 20 on this page of 164 — 27 participants |
Back to article view | Back to comp.lang.c
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 →
| From | fl <rxjwg98@gmail.com> |
|---|---|
| Date | 2015-08-12 15:28 -0700 |
| Subject | How 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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-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]
| From | fl <rxjwg98@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-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]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-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]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-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]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-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]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-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]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-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]
| From | gordonb.8n5lc@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2015-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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-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]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-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]
| From | Nobody <nobody@nowhere.invalid> |
|---|---|
| Date | 2015-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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-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]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-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