Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136032 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2018-10-02 22:37 +0200 |
| Last post | 2018-12-17 15:18 +0000 |
| Articles | 20 on this page of 211 — 33 participants |
Back to article view | Back to comp.lang.c
Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:37 +0200
Re: Counting lines of a file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 16:45 -0400
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 09:51 +1300
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:55 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:31 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:39 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:39 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:49 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:46 -0700
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:04 +0000
Re: Counting lines of a file dave_thompson_2@comcast.net - 2018-12-14 17:52 -0500
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-15 08:14 +0000
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:24 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:32 +0200
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:44 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:17 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:35 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:25 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:54 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:43 +0200
Re: Counting lines of a file Andreas Perstinger <andipersti@gmail.com> - 2018-10-05 11:35 +0000
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 20:56 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:00 +0200
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:13 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:28 +0200
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:48 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 12:07 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:49 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 14:25 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 16:05 +0200
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 14:17 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 16:53 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 16:07 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:12 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:23 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 20:42 +0200
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 12:03 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:45 +0200
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:52 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:26 -0700
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:37 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 15:06 +0100
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 21:48 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:28 +0200
Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 14:16 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 11:09 -0700
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 22:00 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:18 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 20:28 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:59 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:10 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 15:53 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 00:09 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 02:06 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 22:40 +0200
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:13 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 23:09 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:47 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 09:44 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 12:41 +0200
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 16:01 +0200
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-22 13:58 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-22 16:44 +0200
Re: Counting lines of a file jadill33@gmail.com - 2018-10-08 09:10 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 13:17 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-03 11:34 -0700
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:14 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 00:59 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 08:57 +0200
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 20:05 +1300
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 10:58 +0100
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 04:06 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:35 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:48 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:30 +0100
Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-04 21:35 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:35 +0200
Re: Counting lines of a file Ike Naar <ike@sdf.lonestar.org> - 2018-10-06 23:56 +0000
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-07 09:13 +0200
Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-10-11 22:14 +0000
Re: Counting lines of a file Ralf Damaschke <rwspam@gmx.de> - 2018-10-11 23:14 +0000
Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:17 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 13:59 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-02 23:07 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 00:08 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:51 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:47 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 11:57 +0300
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 06:30 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:37 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:20 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:33 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:55 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:33 +0100
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 17:43 -0400
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:49 +0100
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:06 -0400
Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 05:20 +0000
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 02:45 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 14:42 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:27 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 03:40 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:17 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 18:13 +0100
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 17:47 +0000
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 20:49 +0100
Re: Counting lines of a file nobody@example.org (Scott) - 2018-10-05 16:52 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 01:49 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 12:08 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:24 +0100
Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 03:47 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 14:41 +0100
Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 15:05 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 20:08 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 13:02 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 15:51 +0100
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 17:15 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:22 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 22:27 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 11:55 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 00:02 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 12:10 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 01:33 +0100
Re: Counting lines of a file mark.bluemel@gmail.com - 2018-10-08 01:33 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-08 12:20 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 21:51 +0100
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 12:52 -0700
Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 13:01 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 22:01 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:17 -0700
Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:50 +0000
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-05 23:09 +0300
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 04:02 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-07 00:29 +0300
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 13:22 +0000
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:00 -0700
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 15:30 +0000
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:34 -0700
Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 09:27 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:04 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:50 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 11:30 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 15:41 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 00:46 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:01 +1300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 01:22 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:39 +1300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 18:23 -0700
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 13:33 +0100
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:40 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:57 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:19 +0100
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 11:25 +1300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 18:56 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 12:11 +0300
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 23:06 +1300
Re: Counting lines of a file Anton Shepelev <ant0n.txt@gmai1.c0m> - 2018-10-03 14:58 +0300
Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:08 +1300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:06 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:13 +0300
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:26 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 02:59 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:57 +0200
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:59 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:54 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 23:26 +0200
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:41 +0100
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:23 +0100
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 14:59 -0700
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:04 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 09:01 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:01 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:44 +0200
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 15:48 -0400
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-03 23:15 +0300
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:35 -0700
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 00:14 +0300
Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 23:15 +0100
Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 23:28 +0300
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 19:39 -0400
Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-04 15:31 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 01:05 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 14:04 +0200
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:48 +0100
Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 18:29 +0200
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:50 -1000
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:54 -1000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 12:51 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 20:51 +0000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 14:40 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 21:50 +0000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-16 15:38 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 20:29 -0700
Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-18 21:03 +0000
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 21:17 +0000
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 17:13 -1000
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 23:11 -0700
Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 22:05 -1000
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 11:52 -0800
Re: Counting lines of a file luser droog <luser.droog@gmail.com> - 2018-12-17 16:01 -0800
Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 17:35 -0800
Re: Counting lines of a file fir <profesor.fir@gmail.com> - 2018-12-19 15:54 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-17 20:01 -0700
Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-12-18 07:44 +0000
Re: Counting lines of a file nobody@example.org (Scott) - 2018-12-18 09:29 +0000
Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-12-18 13:18 +0100
Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-18 06:10 -0800
Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-18 08:12 -0700
Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-19 07:47 -0800
Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 20:41 +0000
Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-12-17 15:18 +0000
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 11:27 +0100 |
| Message-ID | <kWltD.298360$2v.9625@fx14.am4> |
| In reply to | #136161 |
On 04/10/2018 02:49, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > Unfortunately, there is more and more code being written for Unix > systems by people who have no fully grasped the value of making > inter-working general-purpose tools. Are you suggesting that every program written that deals with files - EVERY program - must be designed to work correctly with everything that is considered a 'file' in Linux (Unix etc), including non-seekable pipes, streams and live input? That may sound reasonable for trivial little utilities, but it quickly falls apart. Take this lc utility, which is designed to process N input files. How many of those input files will be from stdin? Isn't it going to be either 0 or 1 files? But because of that, all N must be processed in the same way just in case? If I use fc (file compare) on Windows, and try to compare the special files "con" or "nil", it sensibly says it can't them. Same with "dir con". In more advanced applications, the idea of dealing with anything other than an actual file becomes nonsensical. MS Word won't let me edit "con", and I can't attach "con" to an email. Anyway it appears that the concept of Linux (Unix etc - how are you supposed to refer to this OS) treating all sorts of things as 'files' colours the thinking of too many people here, and makes it harder for people like me to offer file-only solutions which are perfectly practical. > Please don't make it worse by > pushing the idea that all named readable objects are seekable (or > however it is you choose to determine the size). It may be true on > Windows (though I doubt it) but it's not true everywhere. It doesn't matter. It will be true on the files that people will want to read. If I plug a memory stick into my machine, and run my version of lc on it, it will only see named, readable, seekable files with predetermined sizes. It won't see pipes or redirected stuff from stdin. If you look inside a ZIP file, you will see the same. Everywhere there are actual files. Millions of them. But there is only ever going to be one /dev/tty at any time. Coding everything to do with files as though it was coming from /dev/tty is just ..... >> The right tool, for the right job. > > Absolutely. I want tools like wc to be able work with named pipes, for > example. I don't want to have to special-case some uses. And for the sake of trivial applications like that, it is necessary to cripple file-handling processing in every other program? -- bart
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-10-04 03:40 -0700 |
| Message-ID | <c5c87505-8004-463c-8d33-cc3d20f0331d@googlegroups.com> |
| In reply to | #136173 |
On Thursday, October 4, 2018 at 1:27:40 PM UTC+3, Bart wrote: > > Unix etc - how are you supposed to refer to this OS Most people would not complain if you call it *nix.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 15:17 +0100 |
| Message-ID | <87va6hpzif.fsf@bsb.me.uk> |
| In reply to | #136173 |
Bart <bc@freeuk.com> writes: > On 04/10/2018 02:49, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> Unfortunately, there is more and more code being written for Unix >> systems by people who have no fully grasped the value of making >> inter-working general-purpose tools. > > Are you suggesting that every program written that deals with files - > EVERY program - must be designed to work correctly with everything > that is considered a 'file' in Linux (Unix etc), including > non-seekable pipes, streams and live input? No, I am not suggesting that. Good software design involves lots of judgement calls. > That may sound reasonable for trivial little utilities, but it quickly > falls apart. I want it mainly for utilities, but I want it for the ones that are not trivial as well. AWK, sort, uniq, diff and so on are not trivial. > Take this lc utility, which is designed to process N input files. How > many of those input files will be from stdin? Isn't it going to be > either 0 or 1 files? But because of that, all N must be processed in > the same way just in case? What has stdin got to do with it? All of the inputs might be named non-seekable streams. But I really don't see why you care. You are happy with your tools and I am happy with mine. Why would you want to change the way Unix utilities work when there are a huge number of people who like them as they are. > If I use fc (file compare) on Windows, and try to compare the special > files "con" or "nil", it sensibly says it can't them. Same with "dir > con". And it seems you are happy with that. I am happy that you are happy. Why do you object to diff having more flexibility on what it can read? > In more advanced applications, the idea of dealing with anything other > than an actual file becomes nonsensical. MS Word won't let me edit > "con", and I can't attach "con" to an email. Don't obsess about con. I can send mail from in a script that attaches data read from stdin. It's a small convenience that I appreciate. You don't want it -- fine -- but why do you mind? > Anyway it appears that the concept of Linux (Unix etc - how are you > supposed to refer to this OS) treating all sorts of things as 'files' > colours the thinking of too many people here, and makes it harder for > people like me to offer file-only solutions which are perfectly > practical. Nonsense. You can offer whatever solutions you like. I have no problem with you offering a wc that can't read streams. I just won't replace my wc with yours. >> Please don't make it worse by >> pushing the idea that all named readable objects are seekable (or >> however it is you choose to determine the size). It may be true on >> Windows (though I doubt it) but it's not true everywhere. > > It doesn't matter. It will be true on the files that people will want > to read. Who are these people? Am I not one of them? Maybe you are referring only to Windows users. If so, you may be right that they all want programs to be able to read only seekable (or stat-able) inputs. I can't comment, but maybe other Windows users will chip in. >>> The right tool, for the right job. >> >> Absolutely. I want tools like wc to be able work with named pipes, for >> example. I don't want to have to special-case some uses. > > And for the sake of trivial applications like that, it is necessary to > cripple file-handling processing in every other program? I don't find the Unix tools I use to be crippled, and I certainly don't want you to cripple any of your tools. I can't see why you care so much that Unix offers this other way of working. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 18:13 +0100 |
| Message-ID | <JSrtD.485318$1x.481553@fx22.am4> |
| In reply to | #136192 |
On 04/10/2018 15:17, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Take this lc utility, which is designed to process N input files. How
>> many of those input files will be from stdin? Isn't it going to be
>> either 0 or 1 files? But because of that, all N must be processed in
>> the same way just in case?
>
> What has stdin got to do with it? All of the inputs might be named
> non-seekable streams.
Isn't stdin a FILE* type? Then that would be one of the few non-seekable
sources that I can think of. And doesn't piping (using "|" between
processes on command lines) work by feeding the stdout of one process to
the stdin of another?
> Don't obsess about con. I can send mail from in a script that attaches
> data read from stdin. It's a small convenience that I appreciate. You
> don't want it -- fine -- but why do you mind?
It's the impression I get from years posting code here. That not doing
something the way it's done in Linux is wrong. That it's bad form to
read a file all into memory because you might, you know, run out of
memory even with 10-line file.
> Who are these people? Am I not one of them? Maybe you are referring
> only to Windows users. If so, you may be right that they all want
> programs to be able to read only seekable (or stat-able) inputs. I
> can't comment, but maybe other Windows users will chip in.
If I type 'dir/s' (ie. recurse through subdirectories) at the root of a
drive on Windows, I will see hundreds of thousands of actual files. Is
it that much different in Linux?
All of those files will be seekable. The vast majority.
I understand some of the flexibility you might get allowing a 'file' to
be anything (which also means that working with files, you have one arm
tied behind your back, because you can't advantage of the fact that
99.99% of your files have a stored filesize).
But consider this: in the 1990s I was using a scripting language with a
'print' statement, one that used '#' to direct the output elsewhere. It
worked like this:
print "Hello" To the console
print #f, "Hello" To file f (a handle)
print #^s, "Hello" To string s (^s = pointer-to-string)
print #w, "Hello" To window or button w (a handle)
print #bm, "Hello" To bitmap image bm (a handle)
And this is on Windows with its so primitive filesystem. There are other
ways to get flexibility than rely on the OS.
I like my way of dealing with files because it means you can code like
this very easily:
writestrfile("output",reverse(readstrfile("input")))
(Copy "input" to "output", reversing the byte-order.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-04 17:47 +0000 |
| Message-ID | <zmstD.144959$MK2.22981@fx35.iad> |
| In reply to | #136207 |
Bart <bc@freeuk.com> writes: >On 04/10/2018 15:17, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Take this lc utility, which is designed to process N input files. How >>> many of those input files will be from stdin? Isn't it going to be >>> either 0 or 1 files? But because of that, all N must be processed in >>> the same way just in case? >> >> What has stdin got to do with it? All of the inputs might be named >> non-seekable streams. > >Isn't stdin a FILE* type? The 'stdin' identifier defined in <stdio.h> is defined as a pointer to FILE. Internally, on Unix and unix-like systems, the FILE object contains a file descriptor. That file descriptor can point to pretty much anything: $ mkfifo /tmp/myfifo $ a.out < /tmp/myfifo # stdin is a FIFO (non-seekable) $ cat /tmp/bart | a.out # stdin is a PIPE (non-seekable) $ echo "Bart" > /tmp/a.txt $ a.out < /tmp/a.txt # stdin is a file (seekable) $ a.out # stdin is /dev/tty (non-seekable) $ a.out < /dev/card_reader # stdin is an 80-column card reader (non-seekable) $ a.out < /dev/ttyUSB0 # stdin is an RS-232 serial port (non-seekable) >> Don't obsess about con. I can send mail from in a script that attaches >> data read from stdin. It's a small convenience that I appreciate. You >> don't want it -- fine -- but why do you mind? > >It's the impression I get from years posting code here. That not doing >something the way it's done in Linux is wrong. That it's bad form to >read a file all into memory because you might, you know, run out of >memory even with 10-line file. How can you know a priori the largest file you should support?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 20:49 +0100 |
| Message-ID | <09utD.739419$Ev.334985@fx13.am4> |
| In reply to | #136208 |
On 04/10/2018 18:47, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> It's the impression I get from years posting code here. That not doing >> something the way it's done in Linux is wrong. That it's bad form to >> read a file all into memory because you might, you know, run out of >> memory even with 10-line file. > > How can you know a priori the largest file you should support? Why do you need to know that? If the application requires a file be loaded into memory, a too-large file is going to a problem whatever approach is used to read it. But if you can check the file size in advance, you can report a problem sooner. Before you've read gigabytes of the file, if it's on a slow device, and before the system starts becoming unstable as available memory is exceeded. And also, you don't have to go through the usual palaver with expanding buffers. This is like the difference between zero-terminated strings and counted strings, which have have many advantages. -- bart
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2018-10-05 16:52 +0000 |
| Message-ID | <5bb7912d.1605033640@news.xmission.com> |
| In reply to | #136208 |
On Thu, 04 Oct 2018 17:47:11 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Bart <bc@freeuk.com> writes: >>On 04/10/2018 15:17, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> Take this lc utility, which is designed to process N input files. How >>>> many of those input files will be from stdin? Isn't it going to be >>>> either 0 or 1 files? But because of that, all N must be processed in >>>> the same way just in case? >>> >>> What has stdin got to do with it? All of the inputs might be named >>> non-seekable streams. >> >>Isn't stdin a FILE* type? > >The 'stdin' identifier defined in <stdio.h> is defined as a pointer >to FILE. Internally, on Unix and unix-like systems, the FILE object >contains a file descriptor. That file descriptor can point to pretty >much anything: Story time. Way back in the day when I was first learning about pipes and redirects and such, I was learning it on a PC with MS-DOS. That OS, of course, had no real mechanism to support interprocess pipes, but made do with the kluge of using intermediate files to fake it. That worked well enough, and had the charming side effect of making piped files seekable, rewindable, length-able, just like ordinary files. And every scrap of documentation went out of its way to point out that this was *odd* behavior, *not* a standard way for pipes to work, and it would be a *terrible* idea to get used to doing it that way. The youthful know-it-all I was, I bristled at that, but I listened...and many years later when I started using real OSes with real pipes, it turned out to be to my benefit after all. But that's just me, taking wisdom from my scholarly elders and whatnot. Some people just have to do it themselves. Best of luck to them.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-05 01:49 +0100 |
| Message-ID | <87lg7dnrnv.fsf@bsb.me.uk> |
| In reply to | #136207 |
Bart <bc@freeuk.com> writes:
> On 04/10/2018 15:17, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> Take this lc utility, which is designed to process N input files. How
>>> many of those input files will be from stdin? Isn't it going to be
>>> either 0 or 1 files? But because of that, all N must be processed in
>>> the same way just in case?
>>
>> What has stdin got to do with it? All of the inputs might be named
>> non-seekable streams.
>
> Isn't stdin a FILE* type? Then that would be one of the few
> non-seekable sources that I can think of. And doesn't piping (using
> "|" between processes on command lines) work by feeding the stdout of
> one process to the stdin of another?
The "standard input" is only one possibility. Unix of various flavours
has all sorts of other non-seekable named objects.
>> Don't obsess about con. I can send mail froious rm in a script that attaches
>> data read from stdin. It's a small convenience that I appreciate. You
>> don't want it -- fine -- but why do you mind?
>
> It's the impression I get from years posting code here. That not doing
> something the way it's done in Linux is wrong.
The whole point of a technical debate is to discuss the merits of
various approaches. Your best line of reasoning is to explain why your
way is better. You won't convince everyone, but arguments like "almost
all my files are ordinary seekable ones" just miss the point. You need
to say why your way is better.
> That it's bad form to
> read a file all into memory because you might, you know, run out of
> memory even with 10-line file.
Polemic again. No one has said that. And if they did you have a
knock-down technical reply wouldn't you?
> I understand some of the flexibility you might get allowing a 'file'
> to be anything (which also means that working with files, you have one
> arm tied behind your back, because you can't advantage of the fact
> that 99.99% of your files have a stored filesize).
You need to explain "one arm tied behind your back" in technical terms.
I don't feel I have one arm tied behind my back when I write file
reading code that does not take a pre-determined size.
Remember the context -- we are talking about utilities that are used by
many people many thousands of times. Making them flexible is likely to
be worth a little more work.
It's unfortunate that C does not a have a good mechanism to encapsulate
this stream pattern. In Haskell, and now in recent Python, open files
can be viewed as sequences (I'm skipping some technical matter here) so
anything that process a sequence can be applied to a stream.
> I like my way of dealing with files because it means you can code like
> this very easily:
>
> writestrfile("output",reverse(readstrfile("input")))
There is nothing there that suggests this won't work on non-seekable (or
non-"stat"able files) but I am assuming you find the input size first
and then allocate.
But are you really sure that it's not worth re-writing readstrfile so
that it is usable even with stdin? Would the cost really be so great?
On a Unix-like system, I would put in the half hour or so to do that
because I'd want to be able to read any input into a string.
Aside: just for fun I wrote a stream reverse function:
static void reverse_sz(FILE *in, FILE *out, size_t bsize)
{
char *buf = malloc(bsize);
size_t nb = fread(buf, 1, bsize, in);
if (nb == bsize)
reverse_sz(in, out, 2 * bsize);
while (nb)
fputc(buf[--nb], out);
free(buf);
}
void reverse(FILE *in, FILE *out)
{
reverse_sz(in, out, 1024);
}
I post it only because I think it's a fun solution.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 12:08 +0100 |
| Message-ID | <QCHtD.409685$0L2.344677@fx04.am4> |
| In reply to | #136237 |
On 05/10/2018 01:49, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> I like my way of dealing with files because it means you can code like
>> this very easily:
>>
>> writestrfile("output",reverse(readstrfile("input")))
>
> There is nothing there that suggests this won't work on non-seekable (or
> non-"stat"able files) but I am assuming you find the input size first
> and then allocate.
There are two aspects: reading a file into memory in its entirety before
doing anything with it, and whether that is done a byte at a time, or
the whole file at once.
My 'readstrfile' function could in this case be implemented a byte at a
time (involving a loop with fgetc and an expanding buffer), but it takes
the easy option.
That's not to say that cannot be done at a later point if the need
arises, but that file read has been abstracted away, so there is no
change in user-code.
You, however, seem to like writing file-utilities with low-level file
functions (such as that fgetc which can be inefficient in Windows).
Here, the file is converted into a string object in the language [which
here allows binary data], then you can do what you like with it. Another
option is to read lines into a list of strings. In C, it would be a
char* pointer, and a length.
Once in memory, you can forget about the file system. You don't need a
special reverse() function for a file, you just have one for a string
(or lists of strings etc)
>
> But are you really sure that it's not worth re-writing readstrfile so
> that it is usable even with stdin? Would the cost really be so great?
(It can be, as readstrfile is in interpreted code. But I've just tried
it: reading an 86MB file into a string currently takes 0.25 seconds.
With a fgetc loop, it takes 11 seconds. See sig.
This is partly fgetc itself (such a loop even in optimised C takes 5
seconds) and partly the extensive overheads of calling foreign C
functions from interpreted code. The string appending part is 1 second.)
> On a Unix-like system, I would put in the half hour or so to do that
> because I'd want to be able to read any input into a string.
>
> Aside: just for fun I wrote a stream reverse function:
>
> static void reverse_sz(FILE *in, FILE *out, size_t bsize)
> {
> char *buf = malloc(bsize);
> size_t nb = fread(buf, 1, bsize, in);
> if (nb == bsize)
> reverse_sz(in, out, 2 * bsize);
> while (nb)
> fputc(buf[--nb], out);
> free(buf);
> }
>
> void reverse(FILE *in, FILE *out)
> {
> reverse_sz(in, out, 1024);
> }
>
> I post it only because I think it's a fun solution.
It's hard to understand what it does, so I had to run to see if it did
actually reverse the whole file (I thought you might have mistaken my
byte-reverse comment). It seems to work.
--
bart
function new_readstrfile(filename)=
f:=openfile(filename)
if f = nil then return 0 fi
s := ""
do
c := fgetc(f)
exit when c = c_eof
s +:= c
od
return s
end
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 03:24 +0100 |
| Message-ID | <87o9c7ke1p.fsf@bsb.me.uk> |
| In reply to | #136249 |
Bart <bc@freeuk.com> writes:
> On 05/10/2018 01:49, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> I like my way of dealing with files because it means you can code like
>>> this very easily:
>>>
>>> writestrfile("output",reverse(readstrfile("input")))
>>
>> There is nothing there that suggests this won't work on non-seekable (or
>> non-"stat"able files) but I am assuming you find the input size first
>> and then allocate.
>
> There are two aspects: reading a file into memory in its entirety
> before doing anything with it, and whether that is done a byte at a
> time, or the whole file at once.
... or something in between.
> My 'readstrfile' function could in this case be implemented a byte at
> a time (involving a loop with fgetc and an expanding buffer), but it
> takes the easy option.
But since it's write once, use often, that may not be the best strategy.
The investment in time needed to make it universal is small compared to
what I see as the benefit. I know you see it differently but I
> That's not to say that cannot be done at a later point if the need
> arises, but that file read has been abstracted away, so there is no
> change in user-code.
I am surprised that you have not yet wanted to have "readstrfile" take
its date from stdin. That's a common use in a lot of utilities.
> You, however, seem to like writing file-utilities with low-level file
> functions (such as that fgetc which can be inefficient in Windows).
I would write wc with a byte at a time read loop because that's the
natural way to do what wc does, and the OS I use most often does not get
in the way of doing that.
But I don't particularly favour fgetc. I favour writing utilities that
can read streams.
Just how slow is fgetc? In the days when I wrote C library code, it was
a trivial function that advanced a pointer. Every now and then, a block
read was done. That's many decades ago, and I know things have got more
complicated, but the OS should not be hobbling C programmers like you
describe.
>> But are you really sure that it's not worth re-writing readstrfile so
>> that it is usable even with stdin? Would the cost really be so great?
>
> (It can be, as readstrfile is in interpreted code. But I've just tried
> it: reading an 86MB file into a string currently takes 0.25
> seconds. With a fgetc loop, it takes 11 seconds. See sig.
That (the code in your sig) is not C, and you would not read a stream
into a buffer using fgetc.
I have a "read FILE * data into a string" function too (I must have
written this more than a couple of times over the last 30 years) and I
don't find that it's too expensive to use.
Have you actually tried to do it the other way?
>> Aside: just for fun I wrote a stream reverse function:
>>
>> static void reverse_sz(FILE *in, FILE *out, size_t bsize)
>> {
>> char *buf = malloc(bsize);
>> size_t nb = fread(buf, 1, bsize, in);
>> if (nb == bsize)
>> reverse_sz(in, out, 2 * bsize);
>> while (nb)
>> fputc(buf[--nb], out);
>> free(buf);
>> }
>>
>> void reverse(FILE *in, FILE *out)
>> {
>> reverse_sz(in, out, 1024);
>> }
>>
>> I post it only because I think it's a fun solution.
>
> It's hard to understand what it does,
Are you sure it is intrinsically hard to understand? I would imagine
that many programmers with my sort of background would find it easy to
understand, but I am not sure of that claim either.
But there are two interesting technical questions you (or other Windows
users) can help with.
(A) Is fgetc so slow that it would put someone off using when it's the
natural way to process some input? To answer that we need to know how
slow it is.
(B) Is reading a whole file into memory, without knowing the size in
advance, in some way expensive? Is it so much so that limiting a
function to reading files whose size can be guessed before reading is
worth any inconvenience.
Here's a program you can compile with either -DUSE_FGETC, -DUSE_SIZE or
-DUSE_REALLOC to get three versions that sum the bytes in a file. The
fgetc version just loops calling fegtc. The other two read the whole
file into memory, but one makes use of the size and the other grows a
buffer.
With a 1G file (it's alternating copies of the complete works
of Mark Twain and of Shakespeare) the realloc version is fractionally
slower. The fgetc version is definitely slower and ties up the CPU.
With gcc -O2 the times, averaged over five runs, were:
USE_FGETC 3.14
USE_SIZE 1.22
USE_REALLOC 1.29
#include <stdio.h>
#include <stdlib.h>
#if defined(USE_FGETC)
long long sum_bytes(FILE *in)
{
long long sum = 0;
int c;
while ((c = fgetc(in)) != EOF)
sum += c;
return sum;
}
#else
char *read_file(FILE *, size_t *);
long long sum_bytes(FILE *in)
{
size_t size;
long long sum = 0;
char *contents = read_file(in, &size);
while (size--)
sum += *contents++;
return sum;
free(contents);
}
#endif
#if defined(USE_SIZE)
char *read_file(FILE *in, size_t *fsize)
{
long long sz;
if (fseek(in, 0, SEEK_END) == 0 && (sz = ftell(in)) >= 0) {
char *contents = malloc((size_t)sz + 1);
if (contents) {
rewind(in);
if (fread(contents, (size_t)sz, 1, in) == 1) {
contents[sz] = 0;
if (fsize) *fsize = (size_t)sz;
return contents;
}
free(contents);
}
}
if (fsize) *fsize = 0;
return 0;
}
#elif defined(USE_REALLOC)
char *read_file(FILE *in, size_t *fsize)
{
size_t nr, size = 0, space = 1024;
char *contents = malloc(space), *bp = contents;
while (contents && (nr = fread(bp, 1, space, in)) == space) {
size += nr;
size_t new_sz = 2 * size;
char *cp = realloc(contents, new_sz);
if (cp) {
bp = cp + size;
space = new_sz - size;
}
else free(contents);
contents = cp;
}
if (fsize)
*fsize = contents ? size + nr : 0;
return contents;
}
#elif !defined(USE_FGETC)
#error One of USE_FGETC, USE_SIZE or USE_REALLOC must be defined.
#endif
int main(int argc, char **argv)
{
FILE *fp = argc > 1 ? fopen(argv[1], "rb") : stdin;
if (fp)
printf("%lld\n", sum_bytes(fp));
else fprintf(stderr, "Unable to open the input.\n");
if (fp && fp != stdin) fclose(fp);
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-10-06 03:47 +0000 |
| Message-ID | <nIcEZxNuOsug9OQ7L8qu2ayCLM3tv@bongo-ra.co> |
| In reply to | #136319 |
On Sat, 06 Oct 2018 03:24:34 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Just how slow is fgetc? In the days when I wrote C library code, it was
> a trivial function that advanced a pointer. Every now and then, a block
> read was done. That's many decades ago, and I know things have got more
> complicated, but the OS should not be hobbling C programmers like you
> describe.
These days on POSIX systems it does extra stuff to make fgetc() thread-safe.
[...]
> Here's a program you can compile with either -DUSE_FGETC, -DUSE_SIZE or
> -DUSE_REALLOC to get three versions that sum the bytes in a file. The
> fgetc version just loops calling fegtc. The other two read the whole
> file into memory, but one makes use of the size and the other grows a
> buffer.
>
> With a 1G file (it's alternating copies of the complete works
> of Mark Twain and of Shakespeare) the realloc version is fractionally
> slower. The fgetc version is definitely slower and ties up the CPU.
>
> With gcc -O2 the times, averaged over five runs, were:
>
> USE_FGETC 3.14
> USE_SIZE 1.22
> USE_REALLOC 1.29
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #if defined(USE_FGETC)
>
> long long sum_bytes(FILE *in)
> {
> long long sum = 0;
> int c;
> while ((c = fgetc(in)) != EOF)
> sum += c;
> return sum;
> }
What do you get if you replace fgetc() with getc_unlocked() (not in standard
C) ?
[...]
> #endif
>
> int main(int argc, char **argv)
> {
> FILE *fp = argc > 1 ? fopen(argv[1], "rb") : stdin;
> if (fp)
> printf("%lld\n", sum_bytes(fp));
> else fprintf(stderr, "Unable to open the input.\n");
> if (fp && fp != stdin) fclose(fp);
> }
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 14:41 +0100 |
| Message-ID | <875zyfjiq6.fsf@bsb.me.uk> |
| In reply to | #136323 |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Sat, 06 Oct 2018 03:24:34 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Just how slow is fgetc? In the days when I wrote C library code, it was
>> a trivial function that advanced a pointer. Every now and then, a block
>> read was done. That's many decades ago, and I know things have got more
>> complicated, but the OS should not be hobbling C programmers like you
>> describe.
>
> These days on POSIX systems it does extra stuff to make fgetc()
> thread-safe.
Indeed. Mind you (as I say below) I thought that was sidestepped in
simple programs like this, but apparently not.
> [...]
>
>> Here's a program you can compile with either -DUSE_FGETC, -DUSE_SIZE or
>> -DUSE_REALLOC to get three versions that sum the bytes in a file. The
>> fgetc version just loops calling fegtc. The other two read the whole
>> file into memory, but one makes use of the size and the other grows a
>> buffer.
>>
>> With a 1G file (it's alternating copies of the complete works
>> of Mark Twain and of Shakespeare) the realloc version is fractionally
>> slower. The fgetc version is definitely slower and ties up the CPU.
>>
>> With gcc -O2 the times, averaged over five runs, were:
>>
>> USE_FGETC 3.14
>> USE_SIZE 1.22
>> USE_REALLOC 1.29
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #if defined(USE_FGETC)
>>
>> long long sum_bytes(FILE *in)
>> {
>> long long sum = 0;
>> int c;
>> while ((c = fgetc(in)) != EOF)
>> sum += c;
>> return sum;
>> }
>
> What do you get if you replace fgetc() with getc_unlocked() (not in standard
> C) ?
Excellent idea. I should have thought of that!
With getc_unlocked the getc version is the fastest of the lot at 0.86s:
USE_GETC 3.29
USE_GETC_UNLOCKED 0.86
USE_SIZE 1.17
USE_REALLOC 1.16
Maybe something similar is hampering Window's fgetc/getc? Some search
results seem to suggest Microsoft's VC has it's own names for these:
_fgetc_nolock? It could be what Bart is seeing is slow lock functions,
not slow IO functions.
I had thought (and now I don't know why) that modern Linux linkers were
able to pick the unlocked version of getc by detecting that the program
is single-threaded. It's a shame that you can't write ISO C and get the
best safe performance.
For reference, here's the latest version of the program. I've switched
to getc in both the normal and _unclocked versions. That change itself
had no effect on the times, it's just that fgetc_unlocked is not a POSIX
function -- only getc_unlocked is.
#include <stdio.h>
#include <stdlib.h>
#if defined(USE_GETC) || defined(USE_GETC_UNLOCKED)
#ifdef USE_GETC_UNLOCKED
#define GETC getc_unlocked
#else
#define GETC getc
#endif
long long sum_bytes(FILE *in)
{
long long sum = 0;
int c;
while ((c = GETC(in)) != EOF)
sum += c;
return sum;
}
#else
char *read_file(FILE *, size_t *);
long long sum_bytes(FILE *in)
{
size_t size;
long long sum = 0;
char *contents = read_file(in, &size);
while (size--)
sum += *contents++;
return sum;
free(contents);
}
#endif
#if defined(USE_SIZE)
char *read_file(FILE *in, size_t *fsize)
{
long long sz;
if (fseek(in, 0, SEEK_END) == 0 && (sz = ftell(in)) >= 0) {
char *contents = malloc((size_t)sz + 1);
if (contents) {
rewind(in);
if (fread(contents, (size_t)sz, 1, in) == 1) {
contents[sz] = 0;
if (fsize) *fsize = (size_t)sz;
return contents;
}
free(contents);
}
}
if (fsize) *fsize = 0;
return 0;
}
#elif defined(USE_REALLOC)
char *read_file(FILE *in, size_t *fsize)
{
size_t nr, size = 0, space = 1024;
char *contents = malloc(space), *bp = contents;
while (contents && (nr = fread(bp, 1, space, in)) == space) {
size += nr;
size_t new_sz = 2 * size;
char *cp = realloc(contents, new_sz);
if (cp) {
bp = cp + size;
space = new_sz - size;
}
else free(contents);
contents = cp;
}
if (fsize)
*fsize = contents ? size + nr : 0;
return contents;
}
#elif !defined(GETC)
#error One of USE_GETC, USE_GETC_UNLOCKED, USE_SIZE or USE_REALLOC\
must be defined.
#endif
int main(int argc, char **argv)
{
FILE *fp = argc > 1 ? fopen(argv[1], "rb") : stdin;
if (fp)
printf("%lld\n", sum_bytes(fp));
else fprintf(stderr, "Unable to open the input.\n");
if (fp && fp != stdin) fclose(fp);
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2018-10-06 15:05 +0000 |
| Message-ID | <PyCwKFw20zKAp94VycnuVgXbU8eFJ@bongo-ra.co> |
| In reply to | #136341 |
On Sat, 06 Oct 2018 14:41:05 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> I had thought (and now I don't know why) that modern Linux linkers were
> able to pick the unlocked version of getc by detecting that the program
> is single-threaded.
How could the linker detect that ? The most the linker can do is examine the
executable. Even if the executable does not have any functions for creating
threads , it could happen that the application loads dynamically during
runtime such functions , creates threads and then calls the getc() which
existed in the source. If the linker linked the unlocked version of getc()
then the application wouldn't work correctly.
> It's a shame that you can't write ISO C and get the
> best safe performance.
There is a theoretically unlimited number of ways an implementation can offer
to get increased performance with some variation of getc() .For example an
implementation may have a special_getc() which will offer increased
performance if used with a file opened which exists in some specific device
but won't work correctly if one uses it with a file not on such a device. ISO
C couldn't cover all possibilities.
The best one can do is have code like
#if defined(implementation_A)
#define fast_getc special_getc_for_implementation_A
#elif defined(implementation_B)
#define fast_getc special_getc_for_implementation_B
#elif
.
.
.
#else
#define fast_getc getc
#endif
Which made me wonder if there is a macro which tests whether you're compiling
for a POSIX implementation. Annoyingly I couldn't find anything. The closest
I came was that gcc predefines
#define __unix__ 1
#define __unix 1
#define unix 1
which isn't exactly what you'd want.
> For reference, here's the latest version of the program. I've switched
> to getc in both the normal and _unclocked versions. That change itself
> had no effect on the times, it's just that fgetc_unlocked is not a POSIX
> function -- only getc_unlocked is.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> #if defined(USE_GETC) || defined(USE_GETC_UNLOCKED)
>
> #ifdef USE_GETC_UNLOCKED
> #define GETC getc_unlocked
> #else
> #define GETC getc
> #endif
>
> long long sum_bytes(FILE *in)
> {
> long long sum = 0;
> int c;
> while ((c = GETC(in)) != EOF)
> sum += c;
> return sum;
> }
>
> #else
>
> char *read_file(FILE *, size_t *);
>
> long long sum_bytes(FILE *in)
> {
> size_t size;
> long long sum = 0;
> char *contents = read_file(in, &size);
> while (size--)
> sum += *contents++;
> return sum;
> free(contents);
> }
>
> #endif
>
> #if defined(USE_SIZE)
>
> char *read_file(FILE *in, size_t *fsize)
> {
> long long sz;
> if (fseek(in, 0, SEEK_END) == 0 && (sz = ftell(in)) >= 0) {
> char *contents = malloc((size_t)sz + 1);
> if (contents) {
> rewind(in);
> if (fread(contents, (size_t)sz, 1, in) == 1) {
> contents[sz] = 0;
> if (fsize) *fsize = (size_t)sz;
> return contents;
> }
> free(contents);
> }
> }
> if (fsize) *fsize = 0;
> return 0;
> }
>
> #elif defined(USE_REALLOC)
>
> char *read_file(FILE *in, size_t *fsize)
> {
> size_t nr, size = 0, space = 1024;
> char *contents = malloc(space), *bp = contents;
> while (contents && (nr = fread(bp, 1, space, in)) == space) {
> size += nr;
> size_t new_sz = 2 * size;
> char *cp = realloc(contents, new_sz);
> if (cp) {
> bp = cp + size;
> space = new_sz - size;
> }
> else free(contents);
> contents = cp;
> }
> if (fsize)
> *fsize = contents ? size + nr : 0;
> return contents;
> }
>
> #elif !defined(GETC)
> #error One of USE_GETC, USE_GETC_UNLOCKED, USE_SIZE or USE_REALLOC\
> must be defined.
> #endif
>
> int main(int argc, char **argv)
> {
> FILE *fp = argc > 1 ? fopen(argv[1], "rb") : stdin;
> if (fp)
> printf("%lld\n", sum_bytes(fp));
> else fprintf(stderr, "Unable to open the input.\n");
> if (fp && fp != stdin) fclose(fp);
> }
--
A group of people dedicated to a process are called scientists. A group of people
dedicated to a conclusion is called a religion or an ideology.
"jlawson"
https://news.ycombinator.com/item?id=18127811
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 20:08 +0100 |
| Message-ID | <87in2ej3ks.fsf@bsb.me.uk> |
| In reply to | #136348 |
Spiros Bousbouras <spibou@gmail.com> writes: > On Sat, 06 Oct 2018 14:41:05 +0100 > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> I had thought (and now I don't know why) that modern Linux linkers were >> able to pick the unlocked version of getc by detecting that the program >> is single-threaded. > > How could the linker detect that ? The most the linker can do is examine the > executable. Even if the executable does not have any functions for creating > threads , it could happen that the application loads dynamically during > runtime such functions , creates threads and then calls the getc() which > existed in the source. If the linker linked the unlocked version of getc() > then the application wouldn't work correctly. Sure, but that could have been declared to be undefined. There could be some requirement that a program declare the fact that it may become multi-threaded or else risk undefined behaviour. Would that fly? Maybe it doesn't matter, but a factor of nearly 4 (and over 8 on Windows according to Bart's latest post) is quite a lot! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-06 13:02 +0100 |
| Message-ID | <ov1uD.5528$134.249@fx03.am4> |
| In reply to | #136319 |
On 06/10/2018 03:24, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> I am surprised that you have not yet wanted to have "readstrfile" take
> its date from stdin. That's a common use in a lot of utilities.
No, the usage pattern in a real program is different. I expect there is
only one stdin per program. Functions such as this can be used multiple
time and at ad hoc points in the code. Should they really hijack the
stdin stream which another part of the program might be in the middle of
reading?
Once stdin is finished [EOF detected] can it be used again in the same
run as the program? It's just too undisciplined for me.
If this was a real requirement, I can use (on Windows)
readstrfile("con"). This is not seekable so currently won't work, but it
would be trivial to detect that filename and switch to different
handling code:
if filename="con" then <fgetc loop> else <normal code> fi
So it is not a big deal.
> But there are two interesting technical questions you (or other Windows
> users) can help with.
>
> (A) Is fgetc so slow that it would put someone off using when it's the
> natural way to process some input? To answer that we need to know how
> slow it is.
>
> (B) Is reading a whole file into memory, without knowing the size in
> advance, in some way expensive? Is it so much so that limiting a
> function to reading files whose size can be guessed before reading is
> worth any inconvenience.
>
> Here's a program you can compile with either -DUSE_FGETC, -DUSE_SIZE or
> -DUSE_REALLOC to get three versions that sum the bytes in a file. The
> fgetc version just loops calling fegtc. The other two read the whole
> file into memory, but one makes use of the size and the other grows a
> buffer.
>
> With a 1G file (it's alternating copies of the complete works
> of Mark Twain and of Shakespeare) the realloc version is fractionally
> slower. The fgetc version is definitely slower and ties up the CPU.
>
> With gcc -O2 the times, averaged over five runs, were:
>
> USE_FGETC 3.14
> USE_SIZE 1.22
> USE_REALLOC 1.29
I got these results from a 238MB file (all the files in my 'c' test
directory combined):
bcc gcc-O3 gcc-O3 [Virtual Linux]
GETC 12.9 12.7 2.2 seconds
SIZE 0.9 0.5 0.3
REALLOC 1.1 0.7 0.5
Last column shows same program, same data on Linux running in Virtual
Box (where things usually run slower), on the same machine.
All timings are measured with clock() at start and end of file-read.
File assumed to be cached.
These are also the results, on the same machine, using equivalents in
interpreted code (these exclude summing the bytes, which would add 9
seconds, that would be done in a later pass):
readstrfile 0.38 [SIZE, read as string]
readbinfile 0.26 [SIZE, read as byte-array]
readblockfile 0.23 [SIZE, read into memory block]
new_readstrfile 30.0 [GETC/REALLOC, read as string]
readtextfile 7.0 [SIZE, read as list of strings]
(The REALLOC here refers to the string destination being appended to so
that every so often it needs to be reallocated.)
Anyway it seems that on Windows, byte-at-a-time is slow, because the
library available is slow. (When I tried the interpreted code on Linux,
via optimised C but without ASM speedups, timings ranged from 0.8
seconds to 24 seconds; 30:1 instead of 100:1)
But as I said, it might be possible to use SIZE when the file is
seekable, and GETC otherwise.
(Note that on the C versions, most compilers will give a different
result for the sum of the bytes between GETC and the others. Only bcc
gives the same result. I think it's because of using signed char for
those others (bcc uses unsigned char).
Not significant, but the test is neater if all outputs are equivalent.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 15:51 +0100 |
| Message-ID | <87zhvri0w1.fsf@bsb.me.uk> |
| In reply to | #136333 |
Bart <bc@freeuk.com> writes: > On 06/10/2018 03:24, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >> I am surprised that you have not yet wanted to have "readstrfile" take >> its date from stdin. That's a common use in a lot of utilities. > > No, the usage pattern in a real program is different. What's a real program? I consider awk, perl, sort, grep and so on to be real programs. They can all take input from stdin, even when that is connected via a pipe. Maybe the issue is with the way Windows shells connect tools together. If modern shells still fake pipes using files, then insisting that all inputs be seek-able (or stat-able) will not show up as an issue. Maybe it is virtually impossible to give a Windows program a non-seekable input? This would surprise me, because pipes give one a natural way to use multi-core processors. Note that I'm not saying that the Windows versions of, say awk and perl do anything other than treat their inputs as proper streams. I'm just saying that the tools you write might not show up as being any less capable than these because of the way the shell connects them up. > I expect there is only one stdin per program. Functions such as this > can be used multiple time and at ad hoc points in the code. Should > they really hijack the stdin stream which another part of the program > might be in the middle of reading? I have no idea what you mean here. I am suggesting that C programs can easily be written so that they handle any inputs. If the programmer wants to do that using a "read_whole_stream" function, that can be written so as to be universal at very little extra cost. I don't see why you keep advocating the method of getting the size first since it has very little benefit. > Once stdin is finished [EOF detected] can it be used again in the same > run as the program? It's just too undisciplined for me. I don't know where this comes from. I'm talking about very ordinary programs that read and process stream from start to finish, some of which will need or want the whole input before doing anything with it (like your reverse example). >> But there are two interesting technical questions you (or other Windows >> users) can help with. >> >> (A) Is fgetc so slow that it would put someone off using when it's the >> natural way to process some input? To answer that we need to know how >> slow it is. >> >> (B) Is reading a whole file into memory, without knowing the size in >> advance, in some way expensive? Is it so much so that limiting a >> function to reading files whose size can be guessed before reading is >> worth any inconvenience. >> >> Here's a program you can compile with either -DUSE_FGETC, -DUSE_SIZE or >> -DUSE_REALLOC to get three versions that sum the bytes in a file. The >> fgetc version just loops calling fegtc. The other two read the whole >> file into memory, but one makes use of the size and the other grows a >> buffer. >> >> With a 1G file (it's alternating copies of the complete works >> of Mark Twain and of Shakespeare) the realloc version is fractionally >> slower. The fgetc version is definitely slower and ties up the CPU. >> >> With gcc -O2 the times, averaged over five runs, were: >> >> USE_FGETC 3.14 >> USE_SIZE 1.22 >> USE_REALLOC 1.29 > > > I got these results from a 238MB file (all the files in my 'c' test > directory combined): > > bcc gcc-O3 gcc-O3 [Virtual Linux] > > GETC 12.9 12.7 2.2 seconds > SIZE 0.9 0.5 0.3 > REALLOC 1.1 0.7 0.5 Only the middle column is interesting here since this is an OS+C library question. Can you try the latest version where I was prompted to try the POSIX functions that avoid FILE object locking? The unlocked gets version was, on Linux, even faster that the other which is not unexpected since the others do more work. You may have to poke about a bit to find out what Windows calls these unlocked IO functions is the libc your are using does not provide the POSIX getc_unlocked directly. > All timings are measured with clock() at start and end of > file-read. File assumed to be cached. Doesn't Windows provide a way to time a program without altering it? > Anyway it seems that on Windows, byte-at-a-time is slow, because the > library available is slow. Yes, it's horrendous. I wonder how much (if any) of that is locking the FILE structure. > But as I said, it might be possible to use SIZE when the file is > seekable, and GETC otherwise. But it is possible to use realloc method always, and then you never have to think about it again. I accept that /you/ may not care, but since the cost is minimal you should not encourage others to write limited stream reading functions. > (Note that on the C versions, most compilers will give a different > result for the sum of the bytes between GETC and the others. Yes. I deliberately used a file with nothing but 7-bit characters since I couldn't decide what the correction should be. We could force a signed value in all cases, or force and unsigned one in the buffered cases using either an unsigned char array or a cast. Both seemed like a distraction from the main point. > Not significant, but the test is neater if all outputs are > equivalent.) Agreed. You can just use a 7-bit file though. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-06 17:15 +0100 |
| Message-ID | <Xc5uD.1499$g31.1187@fx17.am4> |
| In reply to | #136346 |
On 06/10/2018 15:51, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> I expect there is only one stdin per program. Functions such as this
>> can be used multiple time and at ad hoc points in the code. Should
>> they really hijack the stdin stream which another part of the program
>> might be in the middle of reading?
>
> I have no idea what you mean here.
There is just one global stdin resource per program? Does that allow
only one EOF event, or can it be restarted? (I think Windows' "con" can
be, because it's treated as an actual file that has to be opened).
If there is just one stdin stream, and especially if it stops working as
soon as EOF is encountered, it's hard to see how it be seriously
considered as a likely general purpose file option.
If there are 10,000 file open/read/close events so far in the
application, how many of those could be stdin; one?
Also, if I wanted to use a function like readstrfile() in a C program,
what filename do I give it to read from stdin?
To me, stdin is what you might use to read interactively from the keyboard.
>> Once stdin is finished [EOF detected] can it be used again in the same
>> run as the program? It's just too undisciplined for me.
>
> I don't know where this comes from. I'm talking about very ordinary
> programs that read and process stream from start to finish, some of
> which will need or want the whole input before doing anything with it
> (like your reverse example).
Yes, simple programs, like simple functions. I'm used (in the past
anyway) to more elaborate applications that run for hours, reading
scripts, commands, data etc from files, writing to files, listing files...
Where would a crude stdin fit into that?
>> I got these results from a 238MB file (all the files in my 'c' test
>> directory combined):
>>
>> bcc gcc-O3 gcc-O3 [Virtual Linux]
>>
>> GETC 12.9 12.7 2.2 seconds
>> SIZE 0.9 0.5 0.3
>> REALLOC 1.1 0.7 0.5
>
> Only the middle column is interesting here since this is an OS+C library
> question.
The first column with no optimisation shows how much might be due to that.
> Can you try the latest version where I was prompted to try the POSIX
> functions that avoid FILE object locking? The unlocked gets version
> was, on Linux, even faster that the other which is not unexpected since
> the others do more work.
>
> You may have to poke about a bit to find out what Windows calls these
> unlocked IO functions is the libc your are using does not provide the
> POSIX getc_unlocked directly.
On Windows there's a function called _getc_nolock(). It's not in
msvcrt.dll, but there is one in msvcr120.dll.
(I had to use my C compiler as I didn't know how to link msvcr120.dll
with gcc. And gcc actually gave me a strange error here when I had to
declare that function:
c.c:5:5: error: expected identifier or '(' before '--' token
int _getc_nolock(FILE*);
)
With _getc_nolock(), my test data was read in 1.5 seconds instead of
(now) 12.5 seconds with getc(). The docs do say that locks are used.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-06 13:22 -0700 |
| Message-ID | <lnva6e25bh.fsf@kst-u.example.com> |
| In reply to | #136349 |
Bart <bc@freeuk.com> writes:
[...]
> To me, stdin is what you might use to read interactively from the keyboard.
Yes, that's one of many possible ways stdin can be used. But if you
seriously think that's the *only* way it's used, I can see why you don't
understand what we're talking about.
Even on Windows, you can run a program with its input redirected from a
file (... < file) or a pipe (program1 | program2). (And again, that's
not "con".)
[...]
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-06 22:27 +0100 |
| Message-ID | <QM9uD.6205$8m2.5547@fx28.am4> |
| In reply to | #136363 |
On 06/10/2018 21:22, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> To me, stdin is what you might use to read interactively from the keyboard. > > Yes, that's one of many possible ways stdin can be used. But if you > seriously think that's the *only* way it's used, I can see why you don't > understand what we're talking about. > > Even on Windows, you can run a program with its input redirected from a > file (... < file) or a pipe (program1 | program2). (And again, that's > not "con".) 'Its' input... I'm using to writing GUI apps don't have such simply defined input. They did have command lines of their own, but if I needed to control them from a script, that would be read from a file. And if a simple console app such as a compiler took input from stdin and wrote it to stdout, I would regard it as an unfinished toy program. But these matters are trivial. I've just taken a simple program that reads from from A, and outputs to file B. I then wrote a wrapper program which gets input from stdin, creates a file from it, runs the other program with that input, then reads the generated file and writes it to stdout. Of course it may go wrong when the file involved is 8GB, which is 300Mloc in a single file. Look, if the application actually required reading from a stream of unknown length, and it needed to do something with it as it went along, them I would write the application accordingly. But 99.99% of my file operations don't require anything like that. It just seems to be a different mindset over there in Linuxland. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-07 11:55 +1300 |
| Message-ID | <g1ssqqFev09U21@mid.individual.net> |
| In reply to | #136366 |
On 07/10/18 10:27, Bart wrote: > On 06/10/2018 21:22, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> To me, stdin is what you might use to read interactively from the keyboard. >> >> Yes, that's one of many possible ways stdin can be used. But if you >> seriously think that's the *only* way it's used, I can see why you don't >> understand what we're talking about. >> >> Even on Windows, you can run a program with its input redirected from a >> file (... < file) or a pipe (program1 | program2). (And again, that's >> not "con".) > > 'Its' input... I'm using to writing GUI apps don't have such simply > defined input. They did have command lines of their own, but if I needed > to control them from a script, that would be read from a file. > > And if a simple console app such as a compiler took input from stdin and > wrote it to stdout, I would regard it as an unfinished toy program. So gcc is an unfinished toy program? -- Ian.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web