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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 05:26 -0700 |
| Message-ID | <024643c6-4563-48a8-a363-23f212aabc7f@googlegroups.com> |
| In reply to | #136092 |
On Wednesday, October 3, 2018 at 8:13:52 AM UTC-4, Anton Shepelev wrote:
> Rick C. Hodgin to Anton Shepelev:
> >Nope. I have had a few developers I've worked with who
> >have felt the same way, but nothing I've seen published
> >online.
>
> Was a common style enforced on you all, or did each follow
> his own convicion with regard to declaration and
> initialisation?
Personal conviction. We all realized independently that it
worked the best, looked the best, tasted the best, smelled
the best, and was the best all around.
I use it everywhere in all of my code in all of the languages
I write where declarations like that are possible before use.
I typically have a format to my functions:
// function definition
// local variable declaration
// Make sure the environment is sane
// global initialization
// process / iterate as needed
// clean up as needed
// report errors as needed
// return result
And even in C, I still use structured programming wherever
possible. It's sometimes inconvenient, which is why I added
flow { } blocks to CAlive, to make some forms of unstructured
programming actually be structured.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-03 02:59 +0100 |
| Message-ID | <87o9cbu6xm.fsf@bsb.me.uk> |
| In reply to | #136032 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Unix has the "wc" utility to count the lines of a file. It is a pity
> that under linux that program is unusable to count lines in a
> hierarchy of several directories. It requires ZERO terminated file
> names, and the "find" utility produces \n terminated file names, so it
> is unusable for that.
Linux tools are generally designed to work together and so Linux find
has -print0 so that it can work safely with programs like xargs and wc.
> So, I decided to rewrite "wc" as "lc" (for Line Count")
>
> It took me a few hours, and I wanted to post the result here, since it
> is (maybe) a useful program, and the way I wrote it explain some
> opinions I have about software design.
Can you say more? I'm not sure what these opinions are.
> Here it is:
> -----------------------------------------------cut here
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
> #include <string.h>
> /* Go through all file names and find out the longest one.
> This allows to align results.
> */
> static int FindMaxFileNameLength(char *argv[])
> {
> int i,len;
> int Maxlen=-1;
> for (i=1; argv[i];i++) {
As a reader of the code, I am immediately puzzled about why element 0 is
not being looked at. Why is that?
I see below that you start filling the array at element 1, but that is
never explained. Even if starting at 1 is crucial to some other part of
the program, a general function like this one should not import that
assumption.
I'd pass in the number of array elements rather then relying on a NULL
sentinel because it would make this a more general function. As it
happens, there's also a bug here in the the passed array does not always
have a NULL sentinel.
> len = strlen(argv[i]);
> if (len > Maxlen)
> Maxlen = len;
> }
> return Maxlen;
> }
>
> /* Copy the file name into the first n chars, starting at the leftmost */
> static void PadName(char *buf, char *name,int maxlen)
> {
> memset(buf,' ',maxlen);
> memcpy(buf,name,strlen(name));
> buf[maxlen]=0;
> }
I don't see the value of this function. At first glance, it seens you
can get the same effect just with a printf field width. Have I missed
something?
> #define CHUNKSIZE 4096
> static char ** ReadFromStdin(int *pargc)
> {
> // Assumption: No file name exceeds 4K +
> // space for the terminating zero
> char inbuf[4096+1];
You need to add another to allow a full-size 4K file name because of the
newline. The read of a 4K name will work, but you will then see an
erroneous empty line in the next fgets.
> // An array holding the file names that will grow by chunks
> char **fileNameArray = calloc(CHUNKSIZE,sizeof(char *));
> int fileCount = 0; // Counts how many files allocated in this chunk
> int totalFileCount=1; //Index into the array. Note: starts at 1!
You ask the read to note the fact, but as far as a I can see you don't
explain it.
> char *p; // Used to eliminate the '\n'
>
> while (fgets(inbuf,sizeof(inbuf),stdin)) {
> fileNameArray[totalFileCount] = malloc(strlen(inbuf)+1);
I'd allocate the space once you know the length -- in most cases, you
are going to need one fewer characters. It's not a big point, but it
seems odd to allocate first and then remove the newline.
More importantly this line will write outside the allocated array space
because of an off-by-one error in the reallocation logic below.
> if (fileNameArray[totalFileCount] == NULL)
> return NULL;
> // Eliminate the '\n'.
> // If we do not do this, fopen will fail
> p = strchr(inbuf,'\n');
> if (p) *p=0;
> strcpy(fileNameArray[totalFileCount],inbuf);
> fileCount++;
> totalFileCount++;
> if (fileCount >= CHUNKSIZE) {
You have an off-by one bug here. It appears to be caused by the mystery
"starts at 1" initialisation of totalFileCount but since I don't know
the purpose of that, I'm reluctant to offer a fix.
> char **tmp = realloc(fileNameArray,
> (totalFileCount+CHUNKSIZE) * sizeof(char *));
> // If reallocation failed return NULL leaking
> // all the memory allocated
> // so far, assuming main will exit and OS will
> // reclaim memory
> if (tmp == NULL)
> return NULL;
> fileNameArray = tmp;
Now you have an array of pointers that does not necessarily have a
sentinel NULL pointer. The original allocation was with calloc, and I
suspect you were relying on that to give you a NULL to terminate the
file name array.
In fact, even without the realloc, I can't see how the code ensures
there is always a NULL pointer at the end of the file name array. The
other bug (where the array can be overfilled) is probably related to
this one. Did you intend to initialise fileCount to 1 rather than
totalFileCount?
> fileCount = 0;
> }
> }
> *pargc = totalFileCount;
> return fileNameArray;
> }
>
> int main(int argc,char *argv[])
> {
> int fileCount=0;
> int c;
> int titleHasBeenWritten = 0;
> int maxlen;
> int32_t lines=0;
> int64_t bytes=0;
> int64_t totalLines=0;
> int64_t totalBytes=0;
> char *PaddedFileName;
>
> // If called with no arguments print a usage message and exit */
> if (argc < 2) {
> fprintf(stderr,"Usage: lc <files>\n or\nlc -\n");
> return EXIT_FAILURE;
> }
>
> /* If there is only one argument, and it is just a dash - ,
> it means that the file names should be read from standard
> input */
> if (argc == 2 && !strcmp(argv[1],"-")) {
> argv = ReadFromStdin(&argc);
> if (argv == NULL) {
> nomem:
> fprintf(stderr,"No more memory\n");
> exit(EXIT_FAILURE);
> }
> }
> maxlen = FindMaxFileNameLength(argv);
> // If we want to write the totals we should reserve at
> // least 5 chars to write
> // the word "Total" (5 characters)
> if (maxlen < 5) maxlen = 5;
> PaddedFileName = calloc(1,maxlen+1);
> if (PaddedFileName == NULL) {
> goto nomem;
> }
> PadName(PaddedFileName,"File",maxlen);
>
> for (fileCount=1; argv[fileCount]; fileCount++) {
> FILE *infile = fopen(argv[fileCount],"rb");
> if (infile == NULL) {
> fprintf(stderr,
> "Impossible to open %s\n",argv[fileCount]);
> continue;
> }
> c = fgetc(infile);
> while (c != EOF) {
> bytes++;
> if (c == '\n')
> lines++;
> c = fgetc(infile);
> }
I prefer the while ((c = fgetc(infile)) != EOF) form but that's just a
style detail.
> totalBytes += bytes;
> totalLines += lines;
> if (!titleHasBeenWritten) {
> printf("%s %9s | %8s\n",
> PaddedFileName," Bytes","Lines");
> titleHasBeenWritten = 1;
> }
You always know if the header is going to be written since you have a
total file name count so I'd just move this code out of the loop.
> PadName(PaddedFileName,argv[fileCount],maxlen);
> printf("%s:%9d | %8d \n",PaddedFileName,bytes,lines);
The format mismatch has already been mentioned.
> bytes = lines = 0;
> fclose(infile);
> }
> if (fileCount > 2) {
> PadName(PaddedFileName,"Total",maxlen);
> printf("%s %9d | %8d\n",
> PaddedFileName,totalBytes,totalLines);
> }
> return EXIT_SUCCESS;
It's debatable whether it's correct to signal success when one or more
of the files might not have been read. Sure, there will be a message on
stderr, but return codes are so very useful in scripts that I try to
make sure they are as informative as possible.
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 08:57 +0200 |
| Message-ID | <pp1p98$muk$1@dont-email.me> |
| In reply to | #136070 |
Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : > I see below that you start filling the array at element 1, but that is > never explained. argv[0] contains the name of the program (in this case 'lc') This was explained to me in the first days I started using Unix, so I thought it was common knowledge
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 08:59 +0200 |
| Message-ID | <pp1pce$muk$2@dont-email.me> |
| In reply to | #136070 |
Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : > I don't see the value of this function. At first glance, it seens you > can get the same effect just with a printf field width. Have I missed > something? Then I would have to use a %n directive to introduce it dynamically. That is being phased out for security reasons. And I would have to find out the length of the longest one anyway...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-03 21:54 +0100 |
| Message-ID | <87a7nuu4xt.fsf@bsb.me.uk> |
| In reply to | #136073 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : >> I don't see the value of this function. At first glance, it seens you >> can get the same effect just with a printf field width. Have I missed >> something? > > Then I would have to use a %n directive to introduce it > dynamically. That is being phased out for security reasons. And I > would have to find out the length of the longest one anyway... No, you've lost me completely. And you've cut all the context so no one else will know what we are talking about. I'm talking about padding the file name with spaces before printing. You don't need to do that with a buffer are a pad function, do you? And can you explain what you mean by %n (a scanf directive) being phased out for security reasons? Who is phasing it out and what are the security reasons? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 23:26 +0200 |
| Message-ID | <pp3c62$311$1@dont-email.me> |
| In reply to | #136137 |
Le 03/10/2018 à 22:54, Ben Bacarisse a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : >>> I don't see the value of this function. At first glance, it seens you >>> can get the same effect just with a printf field width. Have I missed >>> something? >> >> Then I would have to use a %n directive to introduce it >> dynamically. That is being phased out for security reasons. And I >> would have to find out the length of the longest one anyway... > > No, you've lost me completely. And you've cut all the context so no one > else will know what we are talking about. I'm talking about padding the > file name with spaces before printing. You don't need to do that with a > buffer are a pad function, do you? > Yes, I do need that since I do not know beforehand what is the longest file name that I will get. Since I want columns neatly aligned to easy reading the results, I want to know which file name is the longest and size the first column to that width you see? I can't do that statically in my program > And can you explain what you mean by %n (a scanf directive) being phased > out for security reasons? Who is phasing it out and what are the > security reasons? > The %n (if I remember correctly) makes sprintf read an integer from the arguments and introduce it as a parameter for a format string. Several overflow problems could occur, so that is considered a "nono"...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-03 22:41 +0100 |
| Message-ID | <9IatD.714807$iK2.669160@fx08.am4> |
| In reply to | #136142 |
On 03/10/2018 22:26, jacobnavia wrote:
> Le 03/10/2018 à 22:54, Ben Bacarisse a écrit :
>> No, you've lost me completely. And you've cut all the context so no one
>> else will know what we are talking about. I'm talking about padding the
>> file name with spaces before printing. You don't need to do that with a
>> buffer are a pad function, do you?
>>
>
> Yes, I do need that since I do not know beforehand what is the longest
> file name that I will get. Since I want columns neatly aligned to easy
> reading the results, I want to know which file name is the longest and
> size the first column to that width you see?
>
> I can't do that statically in my program
It can be done like this:
#include <stdio.h>
#include <string.h>
int main(void) {
char *files[6] = {"one","two","three","four",
"seventy-six","five"};
int width=0;
for (int i=0; i<6; ++i) {
if (strlen(files[i])>width) width=strlen(files[i]);
}
for (int i=0; i<6; ++i) {
printf("|%-*s|\n",width,files[i]);
}
}
It doesn't require storing a padded version of each filename. But it
does require two passes.
(I would also impose a maximum width in case there are any crazily long
filenames. In which case, the last characters of over-long names can be
replaced by "..." to show overflow.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 02:23 +0100 |
| Message-ID | <87a7nusdw8.fsf@bsb.me.uk> |
| In reply to | #136142 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 03/10/2018 à 22:54, Ben Bacarisse a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> >>> Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : >>>> I don't see the value of this function. At first glance, it seens you >>>> can get the same effect just with a printf field width. Have I missed >>>> something? >>> >>> Then I would have to use a %n directive to introduce it >>> dynamically. That is being phased out for security reasons. And I >>> would have to find out the length of the longest one anyway... >> >> No, you've lost me completely. And you've cut all the context so no one >> else will know what we are talking about. I'm talking about padding the >> file name with spaces before printing. You don't need to do that with a >> buffer are a pad function, do you? >> > > Yes, I do need that since I do not know beforehand what is the longest > file name that I will get. Since I want columns neatly aligned to easy > reading the results, I want to know which file name is the longest and > size the first column to that width you see? Yes, I know that. You don't need the padding function to format the output. > I can't do that statically in my program > >> And can you explain what you mean by %n (a scanf directive) being phased >> out for security reasons? Who is phasing it out and what are the >> security reasons? >> > > The %n (if I remember correctly) makes sprintf read an integer from > the arguments and introduce it as a parameter for a format > string. Several overflow problems could occur, so that is considered a > "nono"... No, that's no what it does. Mind you I thought you were talking about using %n in and input routine to get the string lengths. Anyway, you don't need %n or the padding function. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-03 14:59 -0700 |
| Message-ID | <lntvm24rpc.fsf@kst-u.example.com> |
| In reply to | #136137 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> And can you explain what you mean by %n (a scanf directive) being phased
> out for security reasons? Who is phasing it out and what are the
> security reasons?
%n is also a printf directive. For example, this:
printf("hello%n, world\n", &count);
sets count to 5 (the number of characters printed so far).
At least one C runtime library I use (on Android) does not support "%n",
supposedly for security reasons. But it is not in any way deprecated or
marked as obsolescent by the ISO C standard (or by POSIX).
I *think* the rationale has something to do with user-defined format
strings.
For Android, "%n" support was dropped in response to bug #14492135,
but I haven't found the bug report itself.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 03:04 +0100 |
| Message-ID | <87y3beqxfv.fsf@bsb.me.uk> |
| In reply to | #136147 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> And can you explain what you mean by %n (a scanf directive) being phased
>> out for security reasons? Who is phasing it out and what are the
>> security reasons?
>
> %n is also a printf directive.
I'd forgotten that.
> For example, this:
>
> printf("hello%n, world\n", &count);
>
> sets count to 5 (the number of characters printed so far).
>
> At least one C runtime library I use (on Android) does not support "%n",
> supposedly for security reasons. But it is not in any way deprecated or
> marked as obsolescent by the ISO C standard (or by POSIX).
>
> I *think* the rationale has something to do with user-defined format
> strings.
I can see how that could be the reason, but un-checked user-defined
formats are a hazard, even without %n.
> For Android, "%n" support was dropped in response to bug #14492135,
> but I haven't found the bug report itself.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 09:01 +0200 |
| Message-ID | <pp1pfp$muk$3@dont-email.me> |
| In reply to | #136070 |
Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : > I'd allocate the space once you know the length -- in most cases, you > are going to need one fewer characters. It's not a big point, but it > seems odd to allocate first and then remove the newline. Yes, that's true. It should be > fileNameArray[totalFileCount] = malloc(strlen(inbuf)); and then replace the '\n' by zero Good point
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-03 22:01 +0100 |
| Message-ID | <874le2u4mf.fsf@bsb.me.uk> |
| In reply to | #136074 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 03/10/2018 à 03:59, Ben Bacarisse a écrit : >> I'd allocate the space once you know the length -- in most cases, you >> are going to need one fewer characters. It's not a big point, but it >> seems odd to allocate first and then remove the newline. > > Yes, that's true. > > It should be > >> fileNameArray[totalFileCount] = malloc(strlen(inbuf)); (Note that I did not write that line despite the quoting seeming to say that I did.) > and then replace the '\n' by zero > > Good point But that introduces another bug if there is no newline (again, impossible to see because there is no context). I was not suggesting you make the change you have indicated. I was suggesting re-ordering the code without removing the +1. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 21:44 +0200 |
| Message-ID | <pp3678$nru$1@dont-email.me> |
| In reply to | #136032 |
Le 03/10/2018 à 21:13, Stefan Ram a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: >> Unix has the "wc" utility to count the lines of a file. It is a pity > > Recently, I read something in (IIRC) a book (or maybe it was > a post here?), but can't remember which book. > > It was the section on counting lines of files. > > First, the text asked how to /define/ the number of lines. > > How many lines are in ""? > How many lines are in "A"? > How many lines are in "\n"? > How many lines are in "A\n"? > How many lines are in "A\nB"? > How many lines are in "A\rB"? > How many lines are in "A\nB\n"? > How many lines are in "A\r\nB"? > How many lines are in "A\n\rB"? > How many lines are in "A\r\n\r"? > How many lines are in "A\r\n\n"? > How many lines are in "A\rB"? > ... > > In the end, IIRC, the text concluded that it is much more > well-defined to just say you count the number of »\n« in > the file. > > Of course, I liked the text as this is also my approach: > First, define precisely what you actually want to do! > A line is a sequence of zero or more characters ending in \n. So, I count the number of \n and the number of bytes and print that.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-03 15:48 -0400 |
| Message-ID | <pp36ed$prp$1@dont-email.me> |
| In reply to | #136128 |
On 10/3/2018 3:44 PM, jacobnavia wrote:
> A line is a sequence of zero or more characters ending in \n.
> So, I count the number of \n and the number of bytes and print that.
I think you'll need to alter that definition to allow 0-length
files to have an implied first line (which means auto-adding /
counting the trailing line-ending sequence).
It should also be extended to allow files like this:
"First line\nSecond line\nThird line\n"
Technically there are four lines there. The first one exists
regardless of whether or not there's a trailing line-ending
sequence. And when you enter that fourth blank line, it is
similar to the 0-length case, in that you have to assume there
is a line there because it's in the file that way.
My $0.02.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2018-10-03 23:15 +0300 |
| Message-ID | <20181003231515.15cfcdd587b8ddd60691ef87@gmail.com> |
| In reply to | #136032 |
TCC's implementations of getc and fgetc seem to collapse
\r\n into \n, and its fputc to expand \n in \r\n. Does
anybody else observe this behavior with TCC (Bart?)?
fputc("\n", file) writes two bytes. Is it normal?
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-03 13:35 -0700 |
| Message-ID | <lny3be4vlc.fsf@kst-u.example.com> |
| In reply to | #136132 |
Anton Shepelev <anton.txt@gmail.com> writes:
> TCC's implementations of getc and fgetc seem to collapse
> \r\n into \n, and its fputc to expand \n in \r\n. Does
> anybody else observe this behavior with TCC (Bart?)?
> fputc("\n", file) writes two bytes. Is it normal?
TCC using what library?
On my Ubuntu system, the tcc compiler uses the same standard library
used by gcc and clang.
Collapsing \r\n into \n on input, and expanding \n to \r\n on output,
is standard behavior for text streams on Windows.
Text processing programs only need to worry about it if they're dealing
with text files in "foreign" formats. Most programs on Unix-like
systems just assume '\n' is the line terminator, and a line containing
"\r\n" is just a line of text whose last character before the terminator
happens to be '\r'.
Usually you'd want to translate text files when transferring them
between Windows and Unix systems. If that's not feasible, there
are programs such as dos2unix and unix2dos to do the translation
for you on the Unix side. (Unfortunately these particular programs
don't act like most Unix text filter programs, so it's difficult
to use them in pipes.)
--
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 | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2018-10-04 00:14 +0300 |
| Message-ID | <20181004001454.fb127e8ccf20f38926dea5f0@gmail.com> |
| In reply to | #136135 |
Keith Thompson: > Collapsing \r\n into \n on input, and expanding \n to \r\n > on output, is standard behavior for text streams on > Windows. Well, it prevented me from easy testing of my line-counting code. How does one distinguish a binary stream from text one while reading from stdin, for some programs, such as the majority of NetPbm utilites expect binary stdin and provide binary stdout? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-03 23:15 +0100 |
| Message-ID | <9cbtD.582387$0v.63982@fx07.am4> |
| In reply to | #136140 |
On 03/10/2018 22:14, Anton Shepelev wrote:
> Keith Thompson:
>
>> Collapsing \r\n into \n on input, and expanding \n to \r\n
>> on output, is standard behavior for text streams on
>> Windows.
>
> Well, it prevented me from easy testing of my line-counting
> code. How does one distinguish a binary stream from text
> one while reading from stdin, for some programs, such as the
> majority of NetPbm utilites expect binary stdin and provide
> binary stdout?
>
I used to set stdin/out to binary, but I've lost the code. Try this
which seems to work:
#include <io.h>
#include <fcntl.h>
....
setmode(0, O_BINARY);
This sets stdin to binary. Use setmode(1, O_BINARY) for stdout.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2018-10-04 23:28 +0300 |
| Message-ID | <20181004232815.0dc473dae3ab26fd558e75e9@gmail.com> |
| In reply to | #136148 |
Bart:
> How does one distinguish a binary stream from text one
> while reading from stdin, for some programs, such as the
> majority of NetPbm utilites expect binary stdin and
> provide binary stdout?
Thank you, Bart and James. Here is my function that counts
the number of newline character sequences in stdin:
static int countlines(void)
{ const int NONE = 256;
int c, lc, skip;
skip = NONE;
lc = 0;
while( 1 )
{ c = getchar();
if( c == EOF ) break;
if( c == skip ) skip = NONE;
else
switch( c )
{ case '\r': skip = '\n'; lc++; break;
case '\n': skip = '\r'; lc++; break;
default : skip = NONE;
}
}
return lc;
}
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2018-10-03 19:39 -0400 |
| Message-ID | <pp3jv6$ckn$1@dont-email.me> |
| In reply to | #136140 |
On 10/03/2018 05:14 PM, Anton Shepelev wrote: > Keith Thompson: > >> Collapsing \r\n into \n on input, and expanding \n to \r\n >> on output, is standard behavior for text streams on >> Windows. > > Well, it prevented me from easy testing of my line-counting > code. How does one distinguish a binary stream from text > one while reading from stdin, for some programs, such as the > majority of NetPbm utilites expect binary stdin and provide > binary stdout? stdin, stdout, and stderr are opened for you prior to the start of your program in text mode. (7.21.3p7). They can be changed to binary mode using freopen(), which is presumably what those utilities do.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web