Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Reading lines from a file, eliminating CR and LF
Date: Sat, 07 Jan 2017 21:51:17 +0000
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <87shouo7xm.fsf@bsb.me.uk>
References: <o3rf6j$qcs$1@gioia.aioe.org> <87pok9ilpd.fsf@bsb.me.uk> <ac8ed4be-a856-4569-a9ae-1b1053661f49@googlegroups.com> <o4eaht$2b4$1@dont-email.me> <6466708f-c0ee-457d-b1e8-e7817949c410@googlegroups.com> <87wpecidvw.fsf@bsb.me.uk> <0ffc9b05-76c6-47ef-8508-44d70383c2aa@googlegroups.com> <87ful0i5rq.fsf@bsb.me.uk> <fed629b4-0b6c-423e-86ea-6f18eeffb3d4@googlegroups.com> <87lgurfqmt.fsf@bsb.me.uk> <6921a3c5-02af-47ee-837c-9d72e2ba8890@googlegroups.com> <87k2abm2wf.fsf@bsb.me.uk> <5e5ee268-ad6a-4aea-a38d-749f5f73d024@googlegroups.com> <87mvf5k31l.fsf@bsb.me.uk> <a07a23cb-f4ee-420c-9810-f19ec1d929a4@googlegroups.com> <878tqpi8x1.fsf@bsb.me.uk> <dd1c283c-79ef-4722-8f1e-5916cbdb2744@googlegroups.com> <87o9zlggg7.fsf@bsb.me.uk> <401c510b-cfe5-4c91-a348-c2f290d96a91@googlegroups.com> <87eg0ggnbu.fsf@bsb.me.uk> <1ba04525-7641-4dd0-9a7b-f23977ab7345@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="4900b6f12aae15f9895b22f3d05581d9"; logging-data="27265"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+VgUUlMgaOeCUHEaK6un5Kh0qoZU9knWo="
Cancel-Lock: sha1:KgfSlphrImuM4JdLGPQgNtfuk8Q= sha1:/M+5DBrO6rpdTS/6SW+kgfGCvLI=
X-BSB-Auth: 1.d25a69805ac5f7ff7853.20170107215117GMT.87shouo7xm.fsf@bsb.me.uk
Xref: csiph.com comp.lang.c:101257

Alla _ <modelling.data@gmail.com> writes:

> On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>> 
>> > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> > <snip> 
>> ><snip>
>> <snip>
>> 
>> This time, since you are moving faster now, I'm going to comment on
>> things that don't really pertain to the exercise, but which bother me a
>> bit.  Please don't worry about the large number of them.
>> 
> I have been sort of moving faster because I had a great chance
> to be in a much better atmosphere and even had enough 
> sleep for the last three days - an exception case during the last
> almost 3 years. Today I am back into a largely stressful
> atmosphere, but anyway I do hope that what we have reached 
> thus far will only get better, independently of outer circumstances.
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> > #include <ctype.h>
>> > #include <string.h>
>> > #include <stdbool.h>
>> > #include <errno.h>
>> >
>> > #define BUFFER_SIZE 100
>> > #define TEXT "../files/ex_1.csv"
>> 
>> I'd try to think of a better name.
>> 
> Are you referring to the TEXT? If so,

Yes, I usually put comments after the text I'm commenting on.

> then I'd suggest INPUT.

But it is not the INPUT to the program.  It is not even the name of the
input to the program.  I would call it DEFAULT_INPUT_FILE_NAME (or maybe
DEFAULT_FILE_NAME since the program is all about input).

<snip>
>> > bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
>> > char *valid_input(char *buffer);
>> >
>> > int main(int argc, char *argv[])
>> > {
>> >     //Check for correct number of arguments
>> >     if(argc > 2)
>> >     {
>> >         fputs("Sorry, the program processes only one file.\n", stderr);
>> >         return EXIT_FAILURE;
>> >     }
>> >     //Determine a file to use
>> >     const char *data_file = (argc == 2)? argv[1] : TEXT;
>> >     errno = 0;
>> >     FILE *fp = fopen(data_file, "r");
>> >     //Couldn't open the file
>> 
>> This should either be a question ("Couldn't open the file?") of the
>> comment belongs in the block below the if.
>> 
>> >     if ( !fp )
>> 
>> In other places you test for not NULL using != NULL but here you just
>> write !fp.  Personally, I have no problem with the sort form but, as you
>> might have seen in a recent thread, there are a wide range of opinions
>> about this.  Whatever you do, pick one and stick with it, at in any one
>> program.  It's fine to try out different styles in different programs.
> I prefer this shortcut version. In this program there are only 2 places
> where  I use !=NULL and those are the ones I wanted to highlight

OK, I agree that, there are sometimes reasons to emphasise the test.  I
don't really get why that's the case here, but I don't want to make a
big issue of it.

> also with this longer form because these places have to be corrected,
> as you have confirmed. Also !ptr doesn't work. Anyway, this has to 
> be done differently.

I don't understand this bit but since all the tests have gone in the new
version, it's probably not worth pursuing.

<snip>
>> I like a blank line (or two even) between functions.
> Yes yes, I do too, but people here often complain when
> too much of vertical space is occupied, so sometimes
> I delete additional blanks, which I would normally have.

I don't think anyone has objected to blank lines between functions.  I
think there is a problem when a function's body takes up too many lines
but that's another matter altogether and the biggest culprit there is
putting {s on a line by themselves!  (I do that at the opening of a
function but not elsewhere.)

<snip>
>> Now for my hint.  Don't look down if you don't want to see it yet...
> I have not yet looked at your hint (oh, and I have not yet deciphered
> your previous ROT 13 one, as well :) ), but I have changed something
> and now I think the result is much better. What do you think?

Yes, that (as you have subsequently found out) was exactly what I was
suggesting.

<snip>
-- 
Ben.