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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-19 00:40 -0400 |
| Message-ID | <mr1183$9nc$1@dont-email.me> |
| In reply to | #67777 |
On 08/18/2015 08:42 PM, David Kleinecke wrote: > On Tuesday, August 18, 2015 at 9:51:00 AM UTC-7, Ike Naar wrote: >> On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: >>> Alternativly I could some other non-ASCII character (CTRL-Z, for example >>> for soft EOL. >> >> CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)). > > As elsewhere - a bag of tells. What's your name for the letters we > actually use (hint: not printable)? Letters? I've had a long day, and possibly the point you're trying to make is too subtle for me to understand when I'm this tired. Could you explain it in a less subtle fashion? My best guess is that you're objecting to him calling code point 26 a character, the only alternative I can come up with is that you're standing by your original claim that it's non-ASCII, which is trivially refuted by a quick inspection of any table of ASCII characters. The C standard defines "character" in a way that's consistent with Ike's usage, and does itself use the term when talking about control characters. I don't have a copy of the ASCII standard, so I can't be sure, but I suspect you'll find that it does the same. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-19 05:38 +0000 |
| Message-ID | <mr14oo$qek$1@speranza.aioe.org> |
| In reply to | #67781 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 08/18/2015 08:42 PM, David Kleinecke wrote: (snip) >> As elsewhere - a bag of tells. What's your name for the letters we >> actually use (hint: not printable)? > Letters? > I've had a long day, and possibly the point you're trying to make is too > subtle for me to understand when I'm this tired. Could you explain it in > a less subtle fashion? > > My best guess is that you're objecting to him calling code point 26 a > character, the only alternative I can come up with is that you're > standing by your original claim that it's non-ASCII, which is trivially > refuted by a quick inspection of any table of ASCII characters. > The C standard defines "character" in a way that's consistent with Ike's > usage, and does itself use the term when talking about control > characters. I don't have a copy of the ASCII standard, so I can't be > sure, but I suspect you'll find that it does the same. Last I knew, C didn't require the execution character set to be ASCII. EBCDIC also has SUB, which is at X'3F', and EOT (ASCII control-D) X'37'. I don't know any systems that use those for the purposes in this discussion. Linux/390, running on IBM mainframes, uses ASCII. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-19 10:20 -0400 |
| Message-ID | <mr2380$vd0$1@dont-email.me> |
| In reply to | #67782 |
On 08/19/2015 01:38 AM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: >> On 08/18/2015 08:42 PM, David Kleinecke wrote: > (snip) >>> As elsewhere - a bag of tells. What's your name for the letters we >>> actually use (hint: not printable)? > >> Letters? > >> I've had a long day, and possibly the point you're trying to make is too >> subtle for me to understand when I'm this tired. Could you explain it in >> a less subtle fashion? >> >> My best guess is that you're objecting to him calling code point 26 a >> character, the only alternative I can come up with is that you're >> standing by your original claim that it's non-ASCII, which is trivially >> refuted by a quick inspection of any table of ASCII characters. > >> The C standard defines "character" in a way that's consistent with Ike's >> usage, and does itself use the term when talking about control >> characters. I don't have a copy of the ASCII standard, so I can't be >> sure, but I suspect you'll find that it does the same. > > Last I knew, C didn't require the execution character set to be ASCII. Correct. But it does allow it to be ASII - and it defines "character" in a way that fails to distinguish between letters, numbers, punctuation, whitespace and control characters. Therefore, on a implementation which fully supports ASCII, SUB is a character. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:22 +0000 |
| Message-ID | <55d8855b.20289609@news.xs4all.nl> |
| In reply to | #67471 |
Bartc <bc@freeuk.com> wrote: > On 15/08/2015 22:01, Keith Thompson wrote: > > Bartc <bc@freeuk.com> writes: > > >> I haven't paid attention to text mode for a while, so was going to > >> suggest that you were wrong, and that, for reading, text mode expands LF > >> to CRLF, rather than compresses it. > >> > >> But I've just done some tests and, astonishingly, you seem to be right! > > > > I'm surprised that you're astonished. > > > > Windows and Unix use different on-disk representations for text files. > > Windows uses a CRLF pair to represent the end of a line; Unix uses a > > single LF character. > > That's not really relevant any more. A text file on disk (especially > after downloading from somewhere else) is going to have line-endings of > LF or CRLF, whatever the local OS is. (Sometimes, CR, but I haven't seen > those for a while. Maybe others too but I've never come across them at all.) > > I use binary mode and try and cope with any of the main 3 combinations > on input. A better solution is to use text mode and a decent text conversion tool. Most text editors can, these days, function as the latter. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:21 +0000 |
| Message-ID | <55d88475.20060359@news.xs4all.nl> |
| In reply to | #67362 |
jacobnavia <jacob@jacob.remcomp.fr> 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. Erm. 35 years ago was 1980. I assure you that CP/M was alive and well until the late 1980s, on the *hack*spit* Amstrad CPC at least. Children who didn't grow up until the 2000s seem to think that it was MS-DOS which killed CP/M, but the final straw was really another Microsoft product, MSX. Not that that was any better... > 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. No, it's an example of "not everything in this world is required to conform to your limited knowledge of it". Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-14 08:48 -0400 |
| Message-ID | <mqknvm$24r$1@dont-email.me> |
| In reply to | #67360 |
On 08/14/2015 03:33 AM, Gordon Burditt wrote: [missing attribution line inserted] On 08/12/2015 07:13 PM, fl wrote: ... >> 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()) Why are you singling out binary files? What the standard says about text files is even less useful for this purpose. > 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. Sure, on any system which allows multiple processes to run at the same time, it's possible for a file's size to change while the program reading it, but in my experience it's a fairly common occurrence that you can rely upon the file size not changing from external causes during your program's run, and if it does, you can treat it as an error condition that can justify terminating your program. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | fl <rxjwg98@gmail.com> |
|---|---|
| Date | 2015-08-12 16:21 -0700 |
| Message-ID | <20057489-7f13-41f4-8067-d620f09ece88@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 When does this requirement (read file unknown size) happen? Thanks
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-08-12 19:44 -0600 |
| Message-ID | <1bwpx03qtz.fsf@pfeifferfamily.net> |
| In reply to | #67239 |
fl <rxjwg98@gmail.com> writes: > > When does this requirement (read file unknown size) happen? > Thanks In my experience, just about whenever I'm reading a file because I don't typically have any reason to care how big it is before I start. I'm normally reading and doing some sort of processing on it as I go, so I just keep reading until I'm done.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-12 22:04 -0400 |
| Message-ID | <mqgtt5$1ba$1@dont-email.me> |
| In reply to | #67239 |
On 08/12/2015 07:21 PM, fl wrote: > 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 > > When does this requirement (read file unknown size) happen? In my own personal experience, files of unknown size are by far the most common kind, and how to deal with that fact varies depending upon the context. For instance, one of the file types my programs read contains a long series of packets. Each packet contains a field indicating how long the packet is. As a result, you can't know where the N+1st packet starts until you've read every single one of the previous N records, and a single corrupted packet could render the entire rest of the file unreadable. (I didn't have anything to do with the design of this file format - I just have to write code that reads and writes it). My programs read the primary header, which contains the packet length, and then know how many bytes should be read by the second fread(). Normal end of file is detected if the primary header fread() returns 0 and ferror() is false. Premature end of file is detected if the primary header fread() returns anything other than 0 or the specified number of bytes, or if the other fread() returns anything other than the specified number of bytes. Four of my programs read files in this format, and of those four, three of them never need to have more than one packet of data in memory at a time, and that's precisely how they're written. The fourth program has to read all of the packets that make up a single scan of data (typically about 3000), extract data from those packets, rearrange it, and then write one scan of data to the output file. Then it can discard most of the data it collected, and read in the next scan. It never needs to keep more than one scan of data in memory at any given time, and it doesn't. The answer that Richard gave you is for storing the entire file in memory at one time, and that's a reasonable approach for small files on systems with enough memory. That's not a workable approach for the files I'm working on, nor is it necessary for these programs. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-13 00:44 +0100 |
| Message-ID | <mqgllb$hsn$1@dont-email.me> |
| In reply to | #67233 |
On 12/08/2015 23:52, Richard Heathfield wrote: > On 12/08/15 23:28, fl wrote: >> How to read a data file whose size is unknown in C? > 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. Suppose you started to read a book but wanted to find out how many pages you had ahead of you; what is wrong with looking at the end of the book and glancing at the page number, then going back to the beginning? The best way really is to keep reading it until you've read > it, growing the storage area as you go. Except the file itself could grow, shrink or be updated at the same time. Reading a file into memory could actually be impossible! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-13 01:04 +0100 |
| Message-ID | <mqgmqj$l3f$1@dont-email.me> |
| In reply to | #67241 |
On 13/08/15 00:44, Bartc wrote: > On 12/08/2015 23:52, Richard Heathfield wrote: >> On 12/08/15 23:28, fl wrote: > >>> How to read a data file whose size is unknown in C? > >> 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. > > Suppose you started to read a book but wanted to find out how many pages > you had ahead of you; what is wrong with looking at the end of the book > and glancing at the page number, then going back to the beginning? Nothing's wrong with that, but files are not books (although books might be files). Analogies aren't always very helpful. The Standard says that "A binary stream need not meaningfully support fseek calls with a whence value of SEEK_END." (7.21.9.2(3) of N1570) The Standard further says that "For a text stream, its file position indicator contains unspecified information, usable by the fseek function for returning the file position indicator for the stream to its position at the time of the ftell call; the difference between two such return values is not necessarily a meaningful measure of the number of characters written or read." (7.21.9.4(2)) So, from an ISO point of view, you're stuffed either way... and that's why implementations provide file size functions. > The best way really is to keep reading it until you've read >> it, growing the storage area as you go. > > Except the file itself could grow, shrink or be updated at the same > time. Reading a file into memory could actually be impossible! Right. Again, that's why this is very OS-specific. My original answer was based on the assumption that the file is well-behaved and stands still while you're trying to measure it. -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-13 11:31 +0100 |
| Message-ID | <mqhrj0$uru$1@dont-email.me> |
| In reply to | #67242 |
On 13/08/2015 01:04, Richard Heathfield wrote: > On 13/08/15 00:44, Bartc wrote: >> Except the file itself could grow, shrink or be updated at the same >> time. Reading a file into memory could actually be impossible! > > Right. Again, that's why this is very OS-specific. My original answer > was based on the assumption that the file is well-behaved and stands > still while you're trying to measure it. But if we're making assumptions, why not also that fseek and ftell work as expected? We don't really want to bypass the C runtime and start using the OS instead. (And I've had problems trying to use stat, fstat, _fstat, fstati64 or whatever it might currently be.) If ftell/fseek work on the platforms we're interested in, and the files of interest are ordinary fixed-size, static disk files, then why not use them? They would be inside a getfilesize() function similar to yours anyway. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-13 11:51 +0100 |
| Message-ID | <mqhsp1$2ru$1@dont-email.me> |
| In reply to | #67265 |
On 13/08/15 11:31, Bartc wrote: > On 13/08/2015 01:04, Richard Heathfield wrote: >> On 13/08/15 00:44, Bartc wrote: > >>> Except the file itself could grow, shrink or be updated at the same >>> time. Reading a file into memory could actually be impossible! >> >> Right. Again, that's why this is very OS-specific. My original answer >> was based on the assumption that the file is well-behaved and stands >> still while you're trying to measure it. > > But if we're making assumptions, why not also that fseek and ftell work > as expected? "As expected", to me, means "as the Standard requires". The Standard does not require that fseek and ftell must be able to be pressed into service as a poor man's _filelength(). You're right to question the assumption I made. Without it, the task is impossible without an OS call (and maybe not possible even then). > We don't really want to bypass the C runtime and start using the OS > instead. (And I've had problems trying to use stat, fstat, _fstat, > fstati64 or whatever it might currently be.) > > If ftell/fseek work on the platforms we're interested in, and the files > of interest are ordinary fixed-size, static disk files, then why not use > them? They would be inside a getfilesize() function similar to yours anyway. Well, feel free, but that's not really what those functions are for. It's like using a hammer to drive a screw. Yes, of course it works (except when it doesn't), but that doesn't make it right. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-13 08:49 -0700 |
| Message-ID | <lnzj1vb343.fsf@kst-u.example.com> |
| In reply to | #67265 |
Bartc <bc@freeuk.com> writes:
[...]
> But if we're making assumptions, why not also that fseek and ftell work
> as expected?
If we're making assumptions, why not assume that fstat() works as
expected?
If your program already depends on POSIX, it would be silly to use the
fseek/ftell trick rather than calling fstat. Likewise for the Windows
equivalent.
The fseek/ftell trick is likely to work on both POSIX and Windows
systems, which is a (small) advantage I suppose.
Speaking of Windows, if you're reading the file as text, the "size" of
the file doesn't necessarily correspond to the number of characters
you'll read.
> We don't really want to bypass the C runtime and start using the OS
> instead. (And I've had problems trying to use stat, fstat, _fstat,
> fstati64 or whatever it might currently be.)
>
> If ftell/fseek work on the platforms we're interested in, and the files
> of interest are ordinary fixed-size, static disk files, then why not use
> them? They would be inside a getfilesize() function similar to yours anyway.
How do you know it's a fixed-size static disk file? Imagine the file
refers to a tape drive, and fseek() causes the drive to wind to the end
of the tape, which could take a while. Though that's probably not a
likely scenario these days.
--
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]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-13 17:45 +0100 |
| Message-ID | <mqihgt$j91$1@dont-email.me> |
| In reply to | #67301 |
On 13/08/2015 16:49, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> But if we're making assumptions, why not also that fseek and ftell work >> as expected? > > If we're making assumptions, why not assume that fstat() works as > expected? I remember using stat or fstat, but also remember a lot of problems (although not what they were). Looking at the MSDN docs now, there are a plethora of different versions, each with a corresponding statxx descriptor incompatible with others. They also take an 'int' file descriptor instead of a FILE*, which is a little confusing. (Usually I also had to call fstat as a foreign function which meant creating a duplicate stat structure in a different language that was exactly compatible.) In short, it's a lot easier to use fseek/ftell which seems to work perfectly well. (And when it doesn't, then if they are only used inside a getfilesize() function, it's easy to change.) >> If ftell/fseek work on the platforms we're interested in, and the files >> of interest are ordinary fixed-size, static disk files, then why not use >> them? They would be inside a getfilesize() function similar to yours anyway. > > How do you know it's a fixed-size static disk file? It just will be. Source code files, documents, configuration files, any sort of text file, image files, CAD files, video files, dump files... At least 99% of files I'm likely to read from a local drive will be a simple file of this kind. I don't know about reading stuff from the other end of a network link, and I don't use pipes. If I need to use stdin, then I treat that differently from a disk file. Which is as it should be; why this preoccupation with having to treat every kind of input in the exactly the same way? If the majority of input /is/ likely to be from well-behaved, local disk files of a fixed bounded size, why shouldn't it be possible to use streamlined, convenient methods that work on those? > Imagine the file > refers to a tape drive, and fseek() causes the drive to wind to the end > of the tape, which could take a while. Though that's probably not a > likely scenario these days. The last file I read from a mag-tape drive was in 1979 so you're probably right. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-14 11:11 +0100 |
| Message-ID | <mqkeq2$22r$1@dont-email.me> |
| In reply to | #67313 |
On 13/08/2015 17:45, Bartc wrote: > On 13/08/2015 16:49, Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: >> [...] >>> But if we're making assumptions, why not also that fseek and ftell work >>> as expected? >> >> If we're making assumptions, why not assume that fstat() works as >> expected? > > I remember using stat or fstat, but also remember a lot of problems > (although not what they were). I've just tried using stat or fstat. In the case of Windows, I think they are called _stat and _fstat, which might be different on other OS (I got the idea that stat() etc are library functions, but can't find them in the standard). fstat() apparently takes an int argument, not a FILE*, which needs to be obtained with _open(), not fopen(). While stat() takes a char* argument, not FILE*. It doesn't seem to be possible to take an active FILE* handle and use it with stat(). That must be just one of the problems. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 11:34 +0100 |
| Message-ID | <87io8iyx8u.fsf@bsb.me.uk> |
| In reply to | #67375 |
Bartc <bc@freeuk.com> writes: <snip> > I've just tried using stat or fstat. In the case of Windows, I think > they are called _stat and _fstat, which might be different on other OS > (I got the idea that stat() etc are library functions, but can't find > them in the standard). > > fstat() apparently takes an int argument, not a FILE*, which needs to > be obtained with _open(), not fopen(). > > While stat() takes a char* argument, not FILE*. > > It doesn't seem to be possible to take an active FILE* handle and use > it with stat(). On POSIX systems you can use fileno(fp) get the integer "file number" from an open FILE *. Presumably Windows has something similar. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-14 12:21 -0500 |
| Message-ID | <4h8ssat0t2qlto9fbfahpbo64puhe6ta6c@4ax.com> |
| In reply to | #67379 |
On Fri, 14 Aug 2015 11:34:25 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >Bartc <bc@freeuk.com> writes: ><snip> >> I've just tried using stat or fstat. In the case of Windows, I think >> they are called _stat and _fstat, which might be different on other OS >> (I got the idea that stat() etc are library functions, but can't find >> them in the standard). >> >> fstat() apparently takes an int argument, not a FILE*, which needs to >> be obtained with _open(), not fopen(). >> >> While stat() takes a char* argument, not FILE*. >> >> It doesn't seem to be possible to take an active FILE* handle and use >> it with stat(). > >On POSIX systems you can use fileno(fp) get the integer "file number" >from an open FILE *. Presumably Windows has something similar. Not too surprisingly, on windows it's _ftell(). Something to remember on Windows, however, is that unlike *nix, the fds from _open() and friends are not actual OS handles, but are their own mapping of such. You can further convert fds to OS handles with _get_osfhandle().
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-14 19:07 +0100 |
| Message-ID | <8737zlzquo.fsf@bsb.me.uk> |
| In reply to | #67406 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Fri, 14 Aug 2015 11:34:25 +0100, Ben Bacarisse > <ben.usenet@bsb.me.uk> wrote: <snip> >>On POSIX systems you can use fileno(fp) get the integer "file number" >>from an open FILE *. Presumably Windows has something similar. > > Not too surprisingly, on windows it's _ftell(). Well that is a little surprising to me, maybe just because the name looks like ftell. A web search (and at least one other poster) suggest _fileno is available too. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-14 16:08 -0500 |
| Message-ID | <j2mssapl0aud63a1hhoekc1q9knmtt9da5@4ax.com> |
| In reply to | #67411 |
On Fri, 14 Aug 2015 19:07:11 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Fri, 14 Aug 2015 11:34:25 +0100, Ben Bacarisse >> <ben.usenet@bsb.me.uk> wrote: ><snip> >>>On POSIX systems you can use fileno(fp) get the integer "file number" >>>from an open FILE *. Presumably Windows has something similar. >> >> Not too surprisingly, on windows it's _ftell(). > >Well that is a little surprising to me, maybe just because the name >looks like ftell. A web search (and at least one other poster) suggest >_fileno is available too. > ><snip> *Sigh* What a brainfart...
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web