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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 16:01 +0200 |
| Message-ID | <pp7qrv$5h4$2@dont-email.me> |
| In reply to | #136248 |
On 05/10/18 12:41, jacobnavia wrote: > Le 05/10/2018 à 09:44, David Brown a écrit : >> Your native language is French. Do you think you should be banned from >> calling a filename "Française.txt", just because "ç" is not in the list >> of portable POSIX characters? > > Yes. I never used any special characters in file names, and I write > > francaise.txt > > because I KNOW (by experience) that in a few years, when I move that > file from windows to mac or from mac to linux I will ALWAYS have > problems since they do not use the same code page, or Unicode or WHATEVER! > > It has NEVER WORKED, and all files with special characters become garbled. It works fine, and at my company we have been using filenames with Norwegian letters for a couple of decades at least - with Windows clients and Linux file servers.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-10-22 13:58 +0000 |
| Message-ID | <slrnpsrls3.f78.grahn+nntp@frailea.sa.invalid> |
| In reply to | #136263 |
On Fri, 2018-10-05, David Brown wrote: > On 05/10/18 12:41, jacobnavia wrote: >> Le 05/10/2018 à 09:44, David Brown a écrit : >>> Your native language is French. Do you think you should be banned from >>> calling a filename "Française.txt", just because "ç" is not in the list >>> of portable POSIX characters? >> >> Yes. I never used any special characters in file names, and I write >> >> francaise.txt >> >> because I KNOW (by experience) that in a few years, when I move that >> file from windows to mac or from mac to linux I will ALWAYS have >> problems since they do not use the same code page, or Unicode or WHATEVER! >> >> It has NEVER WORKED, and all files with special characters become garbled. > > It works fine, and at my company we have been using filenames with > Norwegian letters for a couple of decades at least - with Windows > clients Doesn't really work here. Linux with an UTF-8 locale doesn't like files with Latin-1 names. Some popular programs (like the GIMP) and toolkits hardcode themselves to UTF-8 encoding, and won't let you open files or directories with Latin-1 names. Which is fine if you're willing to batch-rename all your files (including those on read-only media, and in archives) and not try to use them on a non-UTF-8 system in the future. > and Linux file servers. I suppose it's easier if you can let a file server transcode the file names. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-22 16:44 +0200 |
| Message-ID | <pqkno0$9l8$1@dont-email.me> |
| In reply to | #137029 |
On 22/10/18 15:58, Jorgen Grahn wrote: > On Fri, 2018-10-05, David Brown wrote: >> On 05/10/18 12:41, jacobnavia wrote: >>> Le 05/10/2018 à 09:44, David Brown a écrit : >>>> Your native language is French. Do you think you should be banned from >>>> calling a filename "Française.txt", just because "ç" is not in the list >>>> of portable POSIX characters? >>> >>> Yes. I never used any special characters in file names, and I write >>> >>> francaise.txt >>> >>> because I KNOW (by experience) that in a few years, when I move that >>> file from windows to mac or from mac to linux I will ALWAYS have >>> problems since they do not use the same code page, or Unicode or WHATEVER! >>> >>> It has NEVER WORKED, and all files with special characters become garbled. >> >> It works fine, and at my company we have been using filenames with >> Norwegian letters for a couple of decades at least - with Windows >> clients > > Doesn't really work here. Linux with an UTF-8 locale doesn't like > files with Latin-1 names. Some popular programs (like the GIMP) and > toolkits hardcode themselves to UTF-8 encoding, and won't let you open > files or directories with Latin-1 names. > > Which is fine if you're willing to batch-rename all your files > (including those on read-only media, and in archives) and not try > to use them on a non-UTF-8 system in the future. > >> and Linux file servers. > > I suppose it's easier if you can let a file server transcode the file > names. > No, the easiest is if the file server, its kernel, its disk filesystem, its network filesystem keep out of the way entirely in regard to character sets and encoding. If the client writes a file called "føø", then it can later read the file by the name "føø". I guess samba needs to know a bit about the naming, to get Windows case-independence to work (at least, to make it work as well as Windows does). But apart from that, a file server's job is to take data and return what it was given. And the most important use-case is for when you have the same clients reading and writing the data. On our Linux samba fileservers, it used to be the case that files written from Windows clients with Norwegian letters gave "funny" letters when viewed from the command line directly on the server. But they were fine for other Windows clients, which is far and away the most important point. To be honest, I don't remember at what point the Norwegian filenames became consistent from the server shell and Windows clients (it may simply have been after we started having UTF-8 locales on the servers), but it simply isn't a problem.
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2018-10-08 09:10 -0700 |
| Message-ID | <2a7bd5dc-47a3-473a-9183-38e8d82661aa@googlegroups.com> |
| In reply to | #136248 |
On Friday, October 5, 2018 at 6:41:30 AM UTC-4, jacobnavia wrote: > Le 05/10/2018 à 09:44, David Brown a écrit : > > Your native language is French. Do you think you should be banned from > > calling a filename "Française.txt", just because "ç" is not in the list > > of portable POSIX characters? > > Yes. I never used any special characters in file names, and I write > > francaise.txt > > because I KNOW (by experience) that in a few years, when I move that > file from windows to mac or from mac to linux I will ALWAYS have > problems since they do not use the same code page, or Unicode or WHATEVER! > > It has NEVER WORKED, and all files with special characters become garbled. I've got to have special characters for music with non-English titles. It's just annoying enough that I can't stand not using the original text if I can help it. On some media players those characters show up funny, but I can control that by what software I use.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-05 13:17 +0100 |
| Message-ID | <871s94lh6k.fsf@bsb.me.uk> |
| In reply to | #136241 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 05/10/2018 à 00:09, Ben Bacarisse a écrit : >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> >>> The POSIX standard POSIX.1-2008 disallows all funny characters from >>> file names. >> >> No it does not. It's clear from the part that you quote that (a) you >> understand how to read the standard, and (b) what the parts you quote >> really mean. I want to find a way to avoid saying that you are lying, >> but I am having a hard time. Maybe you don't know the force of the word >> "disallows" in English? >> > > It says very clearly that the special characters make a file name NOT > PORTABLE and hence not supported by all implementations! Absolutely. I does not, however, say what you claimed in the "headline". POSIX does not "disallow" funny characters in file names, but it includes a specification for maximally portable file names. >> POSIX has this to say about filenames: >> >> Filename >> >> Filenames are sequences of bytes, not sequences of characters. The >> only bytes that this standard says cannot appear in any filename are >> the slash byte and the null byte. >> > > Yes, you can make any unportable file names and if you are lucky they > will be accepted. It's a little more than luck -- it is by design in many cases. Commas in RCS, trailing ~s for "backup" files... these all work because the components involved are designed so that they to work. <snip> >>> Bart is right. >> >> About what? > > About the nonsense of allowing any characters in a file name. That's > the subtopic we are discussing now isn't it? Ah, I was not discussing that. I was correcting your gross misrepresentation what the POSIX standard says. The bigger issue of whether to allow them is old hat (I've been having debates about it since the late 70s) and I didn't intend to get into it yet again. >> Yes it is. That's why I am having trouble taking this post as >> good-faith one expressing a view that is simply erroneous. >> > > Special characters in file names ARE NOT PORTABLE and should be > banned. Could we gree with that? Not without you saying what you mean. In particular, what characters are "special" and what you mean by "banned". For example, I am happy to have a file called "Mouvements Perpétuels", but newlines are banned from my files by me. I'd strongly object any system-imposed banning of commas, tildes and so on. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-10-03 11:34 -0700 |
| Message-ID | <5980d214-b4af-4045-addb-0dd813cab5c8@googlegroups.com> |
| In reply to | #136101 |
On Wednesday, October 3, 2018 at 3:49:11 PM UTC+3, David Brown wrote: > On 03/10/18 13:07, Bart wrote: > > On 03/10/2018 11:48, Queequeg wrote: > >> jacobnavia <jacob@jacob.remcomp.fr> wrote: > >> > >>> In that case it is OK. > >>> I am using Unix since 25 maybe 30 years, I do not remember exactly. And > >>> I have never seen a file with a newline in its name. > >>> > >>> So, my program will work in 99.9999999% of the cases. > >> > >> And malicious attacker will use one of these 10e-8% cases. > >> > >>> I remember a text by Ritchie, where he spoke about the two approaches to > >>> software. > >> > >> Your approach should be: > >> > >> 1. Thank you, I didn't know about newlines, I'll change my program. > >> 2. Thank you, I wasn't aware of -print0, I just learned something. > > > > My approach would be: > > > > 1. Fix the newline problem in Linux > > > > 1. There is no "newline problem" in Linux. > > 2. Newlines can be useful in filenames, from a user's viewpoint. People > sometimes like to have long names with spaces, newlines, and other > things that look nice on their desktop. > > 3. Newlines (and carriage returns) are valid in Windows too, AFAIK. > > 4. The best way to handle these things is to have the minimum possible > assumptions, rather than to make multiple assumptions and hope you stay > ahead of new use-cases and security issues. So assume that filenames > can have any character except a NULL character. (In *nix, they can't > have a / character either.) Get your filenames from the command line or > system calls, pass them out to system calls, and avoid any assumptions > in the middle. > > 5. The entire Linux world, its history and its installed base is not > going to change details of its valid file names to suit /your/ needs. > > > That way you close a loophole so that it becomes impossible to exploit > > it, and your don't require thousands of applications to each code their > > way around it, or to support a 'feature' that few know about, and nobody > > uses. > > > > I think if enough applications took the same attitude as this > > line-counting program, maybe they might have to do something about it. > > > > Just pandering to such things is not going to do it. > > Bart has has David Wheeler (no, not The David Wheeler) on his side: https://dwheeler.com/essays/fixing-unix-linux-filenames.html
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-03 13:14 +0200 |
| Message-ID | <pp28a8$d2l$1@dont-email.me> |
| In reply to | #136085 |
Le 03/10/2018 à 12:48, Queequeg a écrit : >> In that case it is OK. >> I am using Unix since 25 maybe 30 years, I do not remember exactly. And >> I have never seen a file with a newline in its name. >> >> So, my program will work in 99.9999999% of the cases. > And malicious attacker will use one of these 10e-8% cases. > I tried to figure out what a "malicious" attacker could do with my program. It counts the characters '\n' and the number of characters read in a file. It opens all files in read only mode, so it can't change anything. Can you point to a possible security exploit? Because if you can't you are just talking nonsense. jacob
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 00:59 +0100 |
| Message-ID | <87lg7eshsb.fsf@bsb.me.uk> |
| In reply to | #136087 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 03/10/2018 à 12:48, Queequeg a écrit :
>>> In that case it is OK.
>>> I am using Unix since 25 maybe 30 years, I do not remember exactly. And
>>> I have never seen a file with a newline in its name.
>>>
>>> So, my program will work in 99.9999999% of the cases.
>> And malicious attacker will use one of these 10e-8% cases.
>>
>
> I tried to figure out what a "malicious" attacker could do with my
> program. It counts the characters '\n' and the number of characters
> read in a file. It opens all files in read only mode, so it can't
> change anything.
True, but it will read files the user may not have intended to be read
and it may present incorrect data (from the user's point of view)
without an error message.
By the way, I have no problem with "mostly correct" tools. They are, as
you say, simple, and my memory is still good enough that I can remember
when they are not suitable.
> Can you point to a possible security exploit?
Well, you have a buffer overrun in the program and that's the kind of
thing that is often considered to be exploitable.
More to the point, your example illustrates what is really wrong with C.
You have decades of C experience (as do I) and we are both still liable
to make array allocation errors.
Now I flatter myself by thinking I would not have made the particular
slips that you made, but that's only because I've made them so often in
the past that I now check for them. But C is still too widely used (for
all sorts of sociological rather than technical reasons), and so this
sort of error will just keep happening.
Here's a very similar program but in C++. The array allocation issues
just vanish with std::vector:
#include <vector>
#include <algorithm>
#include <numeric>
#include <iostream>
#include <fstream>
#include <iomanip>
int main(int argc, char **argv)
{
std::vector<std::string> file_names;
if (argc == 2 && std::string(argv[1]) == "-") {
std::string name;
while (getline(std::cin, name))
file_names.push_back(name);
}
else for (int a = 1; a < argc; a++)
file_names.push_back(argv[a]);
if (file_names.size() > 0) {
size_t max_len = std::accumulate(
file_names.begin(), file_names.end(), 5,
[](size_t m, const std::string &s){
return std::max(s.length(), m);
});
std::cout << std::left << std::setw(max_len) << "File"
<< " Bytes | Lines\n";
size_t total_lines = 0, total_bytes = 0;
for (auto name: file_names) {
std::ifstream istrm(name, std::ios::binary);
if (istrm) {
size_t lines = 0, bytes = 0;
char c;
while (istrm.get(c)) {
if (c == '\n')
lines += 1;
bytes += 1;
}
total_lines += lines;
total_bytes += bytes;
std::cout << std::left << std::setw(max_len) << name << ": "
<< std::right
<< std::setw(9) << bytes << " | "
<< std::setw(9) << lines << "\n";
}
else std::cerr << "Unable to open '" << name << "'\n";
}
std::cout << std::left << std::setw(max_len) << "Total" << " "
<< std::right
<< std::setw(9) << total_bytes << " | "
<< std::setw(9) << total_lines << "\n";
}
}
>
> Because if you can't you are just talking nonsense.
>
> jacob
>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-04 08:57 +0200 |
| Message-ID | <pp4dln$o5t$1@dont-email.me> |
| In reply to | #136154 |
Le 04/10/2018 à 01:59, Ben Bacarisse a écrit : > More to the point, your example illustrates what is really wrong with C. Yes, C is wrong. I will switch to C++ after committing suicide. C++ has no problems, bugs or misfeatures, it is the paradise; and that is why, after committing suicide, I will go there to rest in peace. My mistake. I shuldn't post here. Trying to discuss C, what a stiupid idea.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-10-04 20:05 +1300 |
| Message-ID | <g1lsd9Fev09U19@mid.individual.net> |
| In reply to | #136169 |
On 04/10/18 19:57, jacobnavia wrote: > Le 04/10/2018 à 01:59, Ben Bacarisse a écrit : >> More to the point, your example illustrates what is really wrong with C. > > Yes, C is wrong. I will switch to C++ after committing suicide. See what happens when you snip too much context? You become overwhelmed with bombast. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 10:58 +0100 |
| Message-ID | <87h8i2qbic.fsf@bsb.me.uk> |
| In reply to | #136169 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 04/10/2018 à 01:59, Ben Bacarisse a écrit : >> More to the point, your example illustrates what is really wrong with C. > > Yes, C is wrong. I will switch to C++ after committing suicide. > > C++ has no problems, bugs or misfeatures, it is the paradise; and that > is why, after committing suicide, I will go there to rest in peace. > > My mistake. I shuldn't post here. Trying to discuss C, what a stiupid > idea. Oh for goodness sake. You posted a C program and you got (at least from me) a technical discussion of it. It had two bugs that would not have occurred in a language that provides even simple dynamic data structures. C's memory management is important aspect of the language we discuss here -- people need to know that great care is needed to avoid this sort of bug. In case it needs to be said, I agree that C++ has many problems and misfeatures. I don't think it is a paradise. Your post was interesting and on-topic. There has not been enough of that lately. Why don't you respond by explaining to readers what's good about the way C does arrays and memory management? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-04 04:06 -0700 |
| Message-ID | <4430acf8-2786-4397-85a6-e0000903c136@googlegroups.com> |
| In reply to | #136172 |
On Thursday, October 4, 2018 at 10:58:28 AM UTC+1, Ben Bacarisse wrote: > jacobnavia <jacob@jacob.remcomp.fr> writes: > > > Le 04/10/2018 à 01:59, Ben Bacarisse a écrit : > >> More to the point, your example illustrates what is really wrong with C. > > > > Yes, C is wrong. I will switch to C++ after committing suicide. > > > > C++ has no problems, bugs or misfeatures, it is the paradise; and that > > is why, after committing suicide, I will go there to rest in peace. > > > > My mistake. I shuldn't post here. Trying to discuss C, what a stiupid > > idea. > > Oh for goodness sake. You posted a C program and you got (at least from > me) a technical discussion of it. It had two bugs that would not have > occurred in a language that provides even simple dynamic data > structures. C's memory management is important aspect of the language > we discuss here -- people need to know that great care is needed to > avoid this sort of bug. > > In case it needs to be said, I agree that C++ has many problems and > misfeatures. I don't think it is a paradise. > > Your post was interesting and on-topic. There has not been enough of > that lately. Why don't you respond by explaining to readers what's good > about the way C does arrays and memory management? > C treats memory allocations as an almost-normal function. I say almost-normal because, firstly, there's a little quirk which means that strictly a my_malloc() cannot guarantee alignment for any purpose, and also because it can't portably query for memory in the machine, it must use a fixed pool. But you can provide your own functions, which is useful in some circumstances, maybe less now than it was due to the loss of medium-sized multi-program computers like the early games consoles, where you didn't have a system malloc() but have enough memory to make a home-rolled one worthwhile.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 15:35 +0100 |
| Message-ID | <87k1mxpyp2.fsf@bsb.me.uk> |
| In reply to | #136177 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, October 4, 2018 at 10:58:28 AM UTC+1, Ben Bacarisse wrote: >> jacobnavia <jacob@jacob.remcomp.fr> writes: >> >> > Le 04/10/2018 à 01:59, Ben Bacarisse a écrit : >> >> More to the point, your example illustrates what is really wrong with C. >> > >> > Yes, C is wrong. I will switch to C++ after committing suicide. >> > >> > C++ has no problems, bugs or misfeatures, it is the paradise; and that >> > is why, after committing suicide, I will go there to rest in peace. >> > >> > My mistake. I shuldn't post here. Trying to discuss C, what a stiupid >> > idea. >> >> Oh for goodness sake. You posted a C program and you got (at least from >> me) a technical discussion of it. It had two bugs that would not have >> occurred in a language that provides even simple dynamic data >> structures. C's memory management is important aspect of the language >> we discuss here -- people need to know that great care is needed to >> avoid this sort of bug. >> >> In case it needs to be said, I agree that C++ has many problems and >> misfeatures. I don't think it is a paradise. >> >> Your post was interesting and on-topic. There has not been enough of >> that lately. Why don't you respond by explaining to readers what's good >> about the way C does arrays and memory management? >> > C treats memory allocations as an almost-normal function. I say almost-normal > because, firstly, there's a little quirk which means that strictly a > my_malloc() cannot guarantee alignment for any purpose, _Alignof (max_align_t) can help with that, can't it? > and also because > it can't portably query for memory in the machine, it must use a fixed > pool. > But you can provide your own functions, which is useful in some > circumstances, You can provide your own in C++ as well. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 11:48 +0100 |
| Message-ID | <aemtD.284114$cw.201301@fx39.am4> |
| In reply to | #136154 |
On 04/10/2018 00:59, Ben Bacarisse wrote:
> Here's a very similar program but in C++. The array allocation issues
> just vanish with std::vector:
>
> #include <vector>
> #include <algorithm>
> #include <numeric>
> #include <iostream>
> #include <fstream>
> #include <iomanip>
>
> int main(int argc, char **argv)
> {
> std::vector<std::string> file_names;
>
> if (argc == 2 && std::string(argv[1]) == "-") {
> std::string name;
<snip>
Some readable C++ for a change.
But why choose to spoil it by plastering "std::" everywhere so that it's
hard to see past it to the actual code?
(I believe it can be eliminated here with 'using namespace std;')
One quibble however, not about the code (which I haven't tried) but
about compiling C++.
I did this on godbolt.org. Compiling this short program, I was able to
count slowly to four or five (or it might have been five or six) until
it reported the result.
When I instead compiled jacob's original C program, which was bigger,
and using the -xc option, it finished compiling before I could start
counting!
(I don't know how representative that is, when I also tried
rextester.com, both took ages.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 15:30 +0100 |
| Message-ID | <87pnwppywf.fsf@bsb.me.uk> |
| In reply to | #136175 |
Bart <bc@freeuk.com> writes:
> On 04/10/2018 00:59, Ben Bacarisse wrote:
>
>> Here's a very similar program but in C++. The array allocation issues
>> just vanish with std::vector:
>>
>> #include <vector>
>> #include <algorithm>
>> #include <numeric>
>> #include <iostream>
>> #include <fstream>
>> #include <iomanip>
>>
>> int main(int argc, char **argv)
>> {
>> std::vector<std::string> file_names;
>>
>> if (argc == 2 && std::string(argv[1]) == "-") {
>> std::string name;
>
>
> <snip>
>
> Some readable C++ for a change.
Thank you. I don't think the maximum string length calculation is
particularly readable, but I wanted to use std::accumulate as an
illustration.
> But why choose to spoil it by plastering "std::" everywhere so that
> it's hard to see past it to the actual code?
Just the way I do it. I don't find it cluttered. I wonder if any IDEs
can hide it? It would a handy option for those that consider it
clutter.
> One quibble however, not about the code (which I haven't tried) but
> about compiling C++.
>
> I did this on godbolt.org. Compiling this short program, I was able to
> count slowly to four or five (or it might have been five or six) until
> it reported the result.
>
> When I instead compiled jacob's original C program, which was bigger,
> and using the -xc option, it finished compiling before I could start
> counting!
On my laptop, gcc -o lc lc.c takes about 0.07s and g++ -o lc lc.cc takes
about 0.55s.
But that's missing the point. lc.c contains two memory allocation bug
that are almost impossible to replicate in C++ code that uses the STL.
Also, I am pretty sure I wrote the C++ faster than I'd have been able to
write the C version. Even ten minutes less coding time is over 1000
compiles.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-10-04 21:35 +0000 |
| Message-ID | <e8407f5e-3648-431d-a89e-829d022d3f53@trust.no1> |
| In reply to | #136087 |
jacobnavia <jacob@jacob.remcomp.fr> wrote: >> And malicious attacker will use one of these 10e-8% cases. > > I tried to figure out what a "malicious" attacker could do with my > program. It counts the characters '\n' and the number of characters read > in a file. It opens all files in read only mode, so it can't change > anything. Attacker could point your program to either a device file (where reading will have a measurable effect) or use it to detect whether a file exists (if your program is run with different privileges than the user calling it, for example a program is used in a root script, but list of files is supplied by the user; or a program is called from a web script). > Can you point to a possible security exploit? > > Because if you can't you are just talking nonsense. I don't have much interest in arguing with you. -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-05 07:35 +0200 |
| Message-ID | <pp6t68$q3o$1@dont-email.me> |
| In reply to | #136231 |
Le 04/10/2018 à 23:35, Queequeg a écrit : > Attacker could point your program to either a device file (where reading > will have a measurable effect) he can do that with any utility that uses a file name... not only my small program... or use it to detect whether a file exists "ls" will do that for you also > (if your program is run with different privileges than the user calling > it, for example a program is used in a root script, but list of files is > supplied by the user; "ls" will also list those files or a program is called from a web script). None of those "security problems" can't be used by a hacker using also OTHER utilities than my small program. But I am not telling you that this small program is absolutely harmless when run by root... Use at your own risk. The point here is that you shouldn't over engineer everything, and not be afraid of writing a small utility program in C that will fill its intended use in a normal situation. If you are writing a utility program that will be run by root for use in a nuclear power plant... do not use this program. But trying to impose draconian security considerations for a line counting program is overkill, in my opinion of course. You finish with: <quote> I don't have much interest in arguing with you. <end quote> If that is the case, then do not do it. Just do not answer to my posts in the future. :-) jacob
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2018-10-06 23:56 +0000 |
| Message-ID | <slrn3mkcpriitk.eoq.ike@sdf.lonestar.org> |
| In reply to | #136051 |
On 2018-10-02, jacobnavia <jacob@jacob.remcomp.fr> wrote: > So, my program will work in 99.9999999% of the cases. Is there any evidence for that percentage? How many cases were examined? In how many of those cases did your program work? Or is it YAPPOOTA (Yet Another Percentage Pulled Out Of Thin Air)?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-07 09:13 +0200 |
| Message-ID | <ppcbni$9s$1@dont-email.me> |
| In reply to | #136372 |
Le 07/10/2018 à 01:56, Ike Naar a écrit : > On 2018-10-02, jacobnavia <jacob@jacob.remcomp.fr> wrote: >> So, my program will work in 99.9999999% of the cases. > > Is there any evidence for that percentage? > How many cases were examined? > In how many of those cases did your program work? > > Or is it YAPPOOTA (Yet Another Percentage Pulled Out Of Thin Air)? > In 25+ years using UNIX I have never seen a file with a newline. Supposing I see only 5 new files each day, working 5 days a week, 22 days a monthI should see around 1320 files a year. Since I am using to issue a "find / -name foo" to search the whole machine for a file I have lost, we could multiply by 3 that figure to take into account files that I "see" indirectly. That makes 3960 files a year, in 25 years makes 99 000 files. So, if I have never seen a file with embedded \n, the frequency of those files should be less than 1 in 99 000. Let's assume that it is 1 in 100 000, i.e. I should happen to see one SOON. So, (in percentage) my little program should work for 99.99999% of the cases. And that is an estimation since NOBODY here (you included) has said that it has SEEN a file with an embedded \n. Since at least 10 people are following this thread, you have to add a 9 to that figure. Q.E.D jacob
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-10-11 22:14 +0000 |
| Message-ID | <slrn3t84prviot.4u7.ike@iceland.freeshell.org> |
| In reply to | #136374 |
On 2018-10-07, jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 07/10/2018 ? 01:56, Ike Naar a ?crit?: >> On 2018-10-02, jacobnavia <jacob@jacob.remcomp.fr> wrote: >>> So, my program will work in 99.9999999% of the cases. >> >> Is there any evidence for that percentage? >> How many cases were examined? >> In how many of those cases did your program work? >> >> Or is it YAPPOOTA (Yet Another Percentage Pulled Out Of Thin Air)? >> > > In 25+ years using UNIX I have never seen a file with a newline. I suppose you mean file *names* with a newline. Files with newlines are abundant. > Supposing I see only 5 new files each day, working 5 days a week, 22 > days a monthI should see around 1320 files a year. Since I am using to > issue a > > "find / -name foo" > > to search the whole machine for a file I have lost, we could multiply by > 3 that figure to take into account files that I "see" indirectly. > > That makes 3960 files a year, in 25 years makes 99 000 files. So, if I > have never seen a file with embedded \n, the frequency of those files > should be less than 1 in 99 000. Let's assume that it is 1 in 100 000, > i.e. I should happen to see one SOON. > > So, (in percentage) my little program should work for 99.99999% of the > cases. > > And that is an estimation since NOBODY here (you included) has said that > it has SEEN a file with an embedded \n. Since at least 10 people are > following this thread, you have to add a 9 to that figure. In your original post you added two nines to that figure. I'll re-quote it here: >>> So, my program will work in 99.9999999% of the cases. > Q.E.D > jacob
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web