Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #99315 > unrolled thread

Line read from csv file with fgets has two characters before the terminating one

Back to article view | Back to comp.lang.c

Contents

  Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-14 00:04 -0800
    Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 11:10 +0000
      Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-14 23:50 -0800
        Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 08:52 +0000
          Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 00:58 -0800
            Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:09 +0000
              Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 04:23 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:50 +0000
                  Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 14:14 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 14:42 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 09:49 -0800
                      Re: Line read from csv file with fgets has two characters before the terminating one gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-15 17:58 +0000
                      Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 18:22 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 11:51 -0800
                          Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 20:35 +0000
                            Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 12:58 -0800
                            Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:11 -0800
                    Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 02:14 +0000
                      Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-16 11:25 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 16:41 +0000
                          Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-16 22:08 +0000
                            Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:48 +0000
                              Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 11:54 +0000
                                Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 15:33 +0000
                              Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-17 08:27 -0800
                                Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 17:25 +0000
                                  Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 09:53 -0800
                                    Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 18:21 +0000
                                  Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-17 10:30 -0800
                                    Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 22:39 +0000
                                      Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 14:51 -0800
                                        Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 23:12 +0000
                                        Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-18 08:37 -0800
                                          Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-18 13:14 -0800
              Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-15 15:03 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 15:29 -0800
                  Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-15 20:48 -0800
                    Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 22:58 -0800
                      OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-16 10:22 +0000
                        Re: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one) Geoff <geoff@invalid.invalid> - 2016-12-16 07:29 -0800
                          Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 10:06 +0000
                            Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) Geoff <geoff@invalid.invalid> - 2016-12-17 12:39 -0800
                              Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-18 13:54 +0000
                                Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) Geoff <geoff@invalid.invalid> - 2016-12-18 17:57 -0800
                      Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-16 07:12 -0800
                        Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-16 12:02 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 23:29 +0000
                Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-16 02:37 -0800
                  Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-16 07:51 -0800
            Re: Line read from csv file with fgets has two characters before the terminating one Manfred <noname@invalid.add> - 2016-12-15 12:22 +0100
              Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 11:29 +0000
                Re: Line read from csv file with fgets has two characters before the terminating one Melzzzzz <Melzzzzz@zzzzz.com> - 2016-12-15 12:40 +0100
                  Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:00 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Melzzzzz <mel@zzzzz.com> - 2016-12-15 13:09 +0100
                      Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:43 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-15 09:18 -0500
                      Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 14:49 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-15 10:34 -0500
                Re: Line read from csv file with fgets has two characters before the terminating one Manfred <noname@invalid.add> - 2016-12-15 16:34 +0100
      Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 00:22 -0800
        Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:04 +0000
    Re: Line read from csv file with fgets has two characters before the terminating one mark.bluemel@gmail.com - 2016-12-14 03:38 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#99315 — Line read from csv file with fgets has two characters before the terminating one

Hello!

This is not truly a C question, but I am working on a C program, and I will be
grateful for your help on this matter.
Please, do me a favor and read my question and explanation to the end, before
answering.

When reading a line from a csv file with fgets function, and then computing
the length of that line, I get two unknown additional characters at the end of 
the line, which are not represented by "vivid" values, and are located right
before the terminating '\0'. 

Here is the line from csv file:
Interest Expense,4,3,3,1,4,

And the length strlen function has returned is 29, while the line has only 28
characters, including '\n', which, as I thought, would be at index 27 (= 28th
position right after the last comma). And then '\0', which is not computed by strlen.
Therefore I expected the length = 28. My assumptions seem to be
incorrect. 
 
Same is for each line from my file. 
When I have converted all required characters into integers, I got two additional
zeros at the end of each line.

Thank you!

[toc] | [next] | [standalone]

#99326

On 14/12/16 08:04, Alla _ wrote:
> Hello!
>
> This is not truly a C question, but I am working on a C program, and I will be
> grateful for your help on this matter.
> Please, do me a favor and read my question and explanation to the end, before
> answering.
>
> When reading a line from a csv file with fgets function, and then computing
> the length of that line, I get two unknown additional characters at the end of
> the line, which are not represented by "vivid" values, and are located right
> before the terminating '\0'.
>
> Here is the line from csv file:
> Interest Expense,4,3,3,1,4,

If this is the CSV file I sent you, here is a hex dump of that part of 
the file (offsets removed because of line length considerations):

70 65 72 61 74 69 6e 67  20 50 72 6f 66 69 74 2c  |perating Profit,|
31 32 39 2c 31 33 36 2c  31 37 36 2c 32 33 38 2c  |129,136,176,238,|
33 37 34 0a 49 6e 74 65  72 65 73 74 20 45 78 70  |374.Interest Exp|
65 6e 73 65 2c 34 2c 33  2c 33 2c 31 2c 34 0a 4f  |ense,4,3,3,1,4.O|
74 68 65 72 20 47 61 69  6e 73 20 61 6e 64 20 4c  |ther Gains and L|

As you can see, there's nothing weird going on in the file. So there 
must be something weird going on in the code.

> And the length strlen function has returned is 29, while the line has only 28
> characters, including '\n', which, as I thought, would be at index 27 (= 28th
> position right after the last comma). And then '\0', which is not computed by strlen.
> Therefore I expected the length = 28. My assumptions seem to be
> incorrect.

Let's see the code.

> Same is for each line from my file.
> When I have converted all required characters into integers, I got two additional
> zeros at the end of each line.

Let's see the code.

Please make sure that the code you post is the code of the program that 
is exhibiting the problem. Please make sure you don't ask any other 
questions about that code. Just post the exact code that is showing this 
exact problem. Only.


-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99451

On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
> On 14/12/16 08:04, Alla _ wrote:
> > Hello!
> >
> > This is not truly a C question, but I am working on a C program, and I will be
> > grateful for your help on this matter.
> > Please, do me a favor and read my question and explanation to the end, before
> > answering.
> >
> > When reading a line from a csv file with fgets function, and then computing
> > the length of that line, I get two unknown additional characters at the end of
> > the line, which are not represented by "vivid" values, and are located right
> > before the terminating '\0'.
> >
> > Here is the line from csv file:
> > Interest Expense,4,3,3,1,4,
> 
> If this is the CSV file I sent you, here is a hex dump of that part of 
> the file (offsets removed because of line length considerations):
> 
> 70 65 72 61 74 69 6e 67  20 50 72 6f 66 69 74 2c  |perating Profit,|
> 31 32 39 2c 31 33 36 2c  31 37 36 2c 32 33 38 2c  |129,136,176,238,|
> 33 37 34 0a 49 6e 74 65  72 65 73 74 20 45 78 70  |374.Interest Exp|
> 65 6e 73 65 2c 34 2c 33  2c 33 2c 31 2c 34 0a 4f  |ense,4,3,3,1,4.O|
> 74 68 65 72 20 47 61 69  6e 73 20 61 6e 64 20 4c  |ther Gains and L|
> 
> As you can see, there's nothing weird going on in the file. So there 
> must be something weird going on in the code.
> 
> > And the length strlen function has returned is 29, while the line has only 28
> > characters, including '\n', which, as I thought, would be at index 27 (= 28th
> > position right after the last comma). And then '\0', which is not computed by strlen.
> > Therefore I expected the length = 28. My assumptions seem to be
> > incorrect.
> 
> Let's see the code.
> 
> > Same is for each line from my file.
> > When I have converted all required characters into integers, I got two additional
> > zeros at the end of each line.
> 
> Let's see the code.
> 
> Please make sure that the code you post is the code of the program that 
> is exhibiting the problem. Please make sure you don't ask any other 
> questions about that code. Just post the exact code that is showing this 
> exact problem. Only.
I have hoped to get away without posting the code yet ) I shud posting it
yet because I still want to reach to some point of completeness before 
posting it. I want to get the result to discuss. Otherwise I will again get
lots of ideas and comments, which are  always extremely helpful but are
often controversial and sometimes even distract me from continuing the
process. 
Maybe I will do horrible things now in the code: knowing that for this 
exact file I have these weird things in the end of each line, I will physically
get rid of them in the code (horrific thing to do, I know, so please don't 
even say how horrible it is), and then we can discuss my mistakes, which
have led to this horrific manual intervention. All right? I truly want to 
finish this little piece by myself based on the tremendous help I have already 
gotten. I hope you understand it - only by doing, including by doing mistakes,
I can learn. 

[toc] | [prev] | [next] | [standalone]

#99460

On 15/12/16 07:50, Alla _ wrote:
> On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
>> On 14/12/16 08:04, Alla _ wrote:
>>> Hello!
>>>
>>> This is not truly a C question, but I am working on a C program, and I will be
>>> grateful for your help on this matter.
>>> Please, do me a favor and read my question and explanation to the end, before
>>> answering.
>>>
>>> When reading a line from a csv file with fgets function, and then computing
>>> the length of that line, I get two unknown additional characters at the end of
>>> the line, which are not represented by "vivid" values, and are located right
>>> before the terminating '\0'.
>>>
>>> Here is the line from csv file:
>>> Interest Expense,4,3,3,1,4,
>>
>> If this is the CSV file I sent you, here is a hex dump of that part of
>> the file (offsets removed because of line length considerations):
>>
>> 70 65 72 61 74 69 6e 67  20 50 72 6f 66 69 74 2c  |perating Profit,|
>> 31 32 39 2c 31 33 36 2c  31 37 36 2c 32 33 38 2c  |129,136,176,238,|
>> 33 37 34 0a 49 6e 74 65  72 65 73 74 20 45 78 70  |374.Interest Exp|
>> 65 6e 73 65 2c 34 2c 33  2c 33 2c 31 2c 34 0a 4f  |ense,4,3,3,1,4.O|
>> 74 68 65 72 20 47 61 69  6e 73 20 61 6e 64 20 4c  |ther Gains and L|
>>
>> As you can see, there's nothing weird going on in the file. So there
>> must be something weird going on in the code.
>>
>>> And the length strlen function has returned is 29, while the line has only 28
>>> characters, including '\n', which, as I thought, would be at index 27 (= 28th
>>> position right after the last comma). And then '\0', which is not computed by strlen.
>>> Therefore I expected the length = 28. My assumptions seem to be
>>> incorrect.
>>
>> Let's see the code.
>>
>>> Same is for each line from my file.
>>> When I have converted all required characters into integers, I got two additional
>>> zeros at the end of each line.
>>
>> Let's see the code.
>>
>> Please make sure that the code you post is the code of the program that
>> is exhibiting the problem. Please make sure you don't ask any other
>> questions about that code. Just post the exact code that is showing this
>> exact problem. Only.
> I have hoped to get away without posting the code yet ) I shud posting it
> yet because I still want to reach to some point of completeness before
> posting it.

Fair enough, but if you won't show the code, we can't help you fix it.

The only thing that occurred to me was this:

You *might* get the symptoms you suggest *if* you created the CSV file 
on Windows (giving you \r\n line endings), and then either tried to open 
it as a binary stream rather than a text stream, or perhaps FTPd it to a 
Unix-like system (Linux or MacOS, say) in BINary mode (no line-end 
translation), and then opened it on that system.

That might do it. I can't think of anything else that would, except 
screwy code.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99462

On Thursday, December 15, 2016 at 11:53:06 AM UTC+3, Richard Heathfield wrote:
> On 15/12/16 07:50, Alla _ wrote:
> > On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
> >> On 14/12/16 08:04, Alla _ wrote:
><snip>
> The only thing that occurred to me was this:
> 
> You *might* get the symptoms you suggest *if* you created the CSV file 
> on Windows (giving you \r\n line endings), and then either tried to open 
> it as a binary stream rather than a text stream, or perhaps FTPd it to a 
> Unix-like system (Linux or MacOS, say) in BINary mode (no line-end 
> translation), and then opened it on that system.
> 
No, I work on Mac as usual. I think there are some issues with my Excel 
parameteres, or something of this sort because, as we have discussed 
earlier, including in my conversation with Keith, I get strange results 
upon saving xlsx files to csv. 
I will post the code shortly, but with lots of caveats )))) 
> That might do it. I can't think of anything else that would, except 
> screwy code.
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99464

On 15/12/16 08:58, Alla _ wrote:
> On Thursday, December 15, 2016 at 11:53:06 AM UTC+3, Richard Heathfield wrote:
>> On 15/12/16 07:50, Alla _ wrote:
>>> On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
>>>> On 14/12/16 08:04, Alla _ wrote:
>> <snip>
>> The only thing that occurred to me was this:
>>
>> You *might* get the symptoms you suggest *if* you created the CSV file
>> on Windows (giving you \r\n line endings), and then either tried to open
>> it as a binary stream rather than a text stream, or perhaps FTPd it to a
>> Unix-like system (Linux or MacOS, say) in BINary mode (no line-end
>> translation), and then opened it on that system.
>>
> No, I work on Mac as usual. I think there are some issues with my Excel
> parameteres, or something of this sort because, as we have discussed
> earlier, including in my conversation with Keith, I get strange results
> upon saving xlsx files to csv.

Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
endings for text files. You don't think Excel might write a screwy text 
file even on MacOS, just out of sheer habit?

Show us the hex dump of the file. Then we'll know for sure.

Or, if you don't know how to do a hex dump, send to me via email the 
file that you think is broken, and I'll hex dump it for you (and teach 
you how to hex-dump).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99487

On Thursday, December 15, 2016 at 12:09:27 PM UTC+3, Richard Heathfield wrote:
> On 15/12/16 08:58, Alla _ wrote:
> > On Thursday, December 15, 2016 at 11:53:06 AM UTC+3, Richard Heathfield wrote:
> >> On 15/12/16 07:50, Alla _ wrote:
> >>> On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
> >>>> On 14/12/16 08:04, Alla _ wrote:
> >> <snip>
> >> The only thing that occurred to me was this:
> >>
> >> You *might* get the symptoms you suggest *if* you created the CSV file
> >> on Windows (giving you \r\n line endings), and then either tried to open
> >> it as a binary stream rather than a text stream, or perhaps FTPd it to a
> >> Unix-like system (Linux or MacOS, say) in BINary mode (no line-end
> >> translation), and then opened it on that system.
> >>
> > No, I work on Mac as usual. I think there are some issues with my Excel
> > parameteres, or something of this sort because, as we have discussed
> > earlier, including in my conversation with Keith, I get strange results
> > upon saving xlsx files to csv.
> 
> Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
> endings for text files. You don't think Excel might write a screwy text 
> file even on MacOS, just out of sheer habit?
> 
> Show us the hex dump of the file. Then we'll know for sure.
> 
> Or, if you don't know how to do a hex dump, send to me via email the 
> file that you think is broken, and I'll hex dump it for you (and teach 
> you how to hex-dump).

Well, I certainly still don't know how to do that, albeit a few days ago
Ben has advised me to have a program that is able to show me the 
hex version of my file; I have not yet done that, postponing things 
that require additional knowledge from me - whenever I start doing
something new, it turns into an endless loop, or rather a data tree, 
where each even tiny unknown item produces a trail of numerous 
things to learn. I have to concentrate and make choices, so sometimes
I have to opt out from making some necessary steps. 
Now I see that this hex thing has to be among my handy tools. I will
do my best to figure out how to do that. Thank you very much for your 
suggestion to help me out again and to convert the file into hex yourself;
it's very tempting but I can't allow myself to tax your kindness all the 
time. 

[toc] | [prev] | [next] | [standalone]

#99490

On 15/12/16 12:23, Alla _ wrote:
> On Thursday, December 15, 2016 at 12:09:27 PM UTC+3, Richard Heathfield wrote:
>> On 15/12/16 08:58, Alla _ wrote:
>>> On Thursday, December 15, 2016 at 11:53:06 AM UTC+3, Richard Heathfield wrote:
>>>> On 15/12/16 07:50, Alla _ wrote:
>>>>> On Wednesday, December 14, 2016 at 2:10:52 PM UTC+3, Richard Heathfield wrote:
>>>>>> On 14/12/16 08:04, Alla _ wrote:
>>>> <snip>
>>>> The only thing that occurred to me was this:
>>>>
>>>> You *might* get the symptoms you suggest *if* you created the CSV file
>>>> on Windows (giving you \r\n line endings), and then either tried to open
>>>> it as a binary stream rather than a text stream, or perhaps FTPd it to a
>>>> Unix-like system (Linux or MacOS, say) in BINary mode (no line-end
>>>> translation), and then opened it on that system.
>>>>
>>> No, I work on Mac as usual. I think there are some issues with my Excel
>>> parameteres, or something of this sort because, as we have discussed
>>> earlier, including in my conversation with Keith, I get strange results
>>> upon saving xlsx files to csv.
>>
>> Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line
>> endings for text files. You don't think Excel might write a screwy text
>> file even on MacOS, just out of sheer habit?
>>
>> Show us the hex dump of the file. Then we'll know for sure.
>>
>> Or, if you don't know how to do a hex dump, send to me via email the
>> file that you think is broken, and I'll hex dump it for you (and teach
>> you how to hex-dump).
>
> Well, I certainly still don't know how to do that, albeit a few days ago
> Ben has advised me to have a program that is able to show me the
> hex version of my file; I have not yet done that, postponing things
> that require additional knowledge from me - whenever I start doing
> something new, it turns into an endless loop, or rather a data tree,
> where each even tiny unknown item produces a trail of numerous
> things to learn. I have to concentrate and make choices, so sometimes
> I have to opt out from making some necessary steps.
> Now I see that this hex thing has to be among my handy tools. I will
> do my best to figure out how to do that. Thank you very much for your
> suggestion to help me out again and to convert the file into hex yourself;
> it's very tempting but I can't allow myself to tax your kindness all the
> time.

hexdump -C clients.csv

If you don't have it, here's a primitive hex dump program that you could 
use. It doesn't show character interpretations of the hex values (adding 
them is a simple exercise), but for your purposes you don't need to know 
any more than whether there are any 0D characters in the file, and you 
can find that out using this program and piping the output through grep 0D

#include <stdio.h>

int main(int argc, char **argv)
{
   if(argc > 1)
   {
     FILE *fp = fopen(argv[1], "rb");
     if(fp != NULL)
     {
       int ch;
       int i = 0;
       while((ch = getc(fp)) != EOF)
       {
         printf("%02X", ch);
         if(++i == 16)
         {
           putchar('\n');
           i = 0;
         }
         else
         {
           putchar(' ');
         }
       }
       if(i != 0)
       {
         putchar('\n');
       }
       if(ferror(fp))
       {
         fprintf(stderr, "Input error on %s\n", argv[1]);
       }
       fclose(fp);
     }
     else
     {
       fprintf(stderr, "Can't open %s for reading.\n", argv[1]);
     }
   }
   else
   {
     fprintf(stderr, "No input file.\n");
   }
   return 0;
}

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99497

On 15/12/2016 12:50, Richard Heathfield wrote:

> If you don't have it, here's a primitive hex dump program that you could
> use. It doesn't show character interpretations of the hex values (adding
> them is a simple exercise),

Here's a slightly better version:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main (int nparams, char** params) {
#define blocksize 512
int	bb,offset,ns,sprinted,nblock,quit,c;
char  str[50];
char* file;
FILE* f;

     if (nparams!=2) {
         printf("Usage: dump filename");
         exit(0);
     }
     file = params[1];

     printf("File Dump of %s\n",file);

     f = fopen(file,"rb");
     if (!f) {
         printf("Can't open %s\n",file);
         exit(1);
     }

     sprinted=1;
     offset = 0;
     ns = 0;
     nblock=0;

     while ((bb = fgetc(f)) != EOF) {
         if ((offset & 15) == 0) {
             printf("%04X: ",offset);
             ns = 0;
         }
         ++nblock;
         printf("%02X ",bb);
         if (bb >= 32 && bb <= 127) {
             str[ns++] = bb;
         }
         else {
             str[ns++] = '.';
         }
         str[ns] = 0;
         sprinted = 0;
         if ((offset & 15) == 15) {
             printf("  %s\n",str);
             sprinted = 1;
         }
         ++offset;
         if (nblock >= blocksize) {
             nblock=0;
             printf("\n%s\n","Press Enter to continue, Q Enter to"
                             " quit...");
             quit = 0;
             while ((c = getchar())!='\n') {
               if (c=='Q' || c=='q')
                   quit = 1;
             }
             if (quit) break;
         }
     }
     fclose(f);

     if (!sprinted) {
         printf("  %s\n",str);
     }
     else {
         puts("");
     }
}


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#99500

On 15/12/16 14:14, BartC wrote:
> On 15/12/2016 12:50, Richard Heathfield wrote:
>
>> If you don't have it, here's a primitive hex dump program that you could
>> use. It doesn't show character interpretations of the hex values (adding
>> them is a simple exercise),
>
> Here's a slightly better version:

As I said, the addition of character interpretations is simple.

I tested your code on itself. The last few lines came out like this:

0570: 6E 74 66 28 22 20 20 25 73 5C 6E 22 2C 73 74 72   ntf("  %s\n",str
0580: 29 3B 0A 20 20 20 20 7D 0A 20 20 20 20 65 6C 73   );.    }.    els
0590: 65 20 7B 0A 20 20 20 20 20 20 20 20 70 75 74 73   e {.        puts
05A0: 28 22 22 29 3B 0A 20 20 20 20 7D 0A 7D 0A 0A   ("");.    }.}..

so you have a column alignment problem on the last line.

As for the code, well, I was going to give you a detailed analysis, but 
I kept finding myself saying "yes, okay, you /can/ do it like that, but 
I just /wouldn't/!" And I found myself wanting to rewrite the whole 
thing from scratch. So to save you some grief and myself some grey 
hairs, I chose not to do the analysis after all. But I'm glad I don't 
have to maintain your code (and no doubt you're glad you don't have to 
maintain mine!).

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99540

BartC <bc@freeuk.com> writes:
> On 15/12/2016 12:50, Richard Heathfield wrote:
>> If you don't have it, here's a primitive hex dump program that you could
>> use. It doesn't show character interpretations of the hex values (adding
>> them is a simple exercise),
>
> Here's a slightly better version:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
>
> int main (int nparams, char** params) {
[snip]

I'll restrict myself to just one question.

Why did you decide to call the parameters to main "nparams" and
"params", rather than the universally conventional "argc" and "argv"?

-- 
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]

#99542

In article <lninqlm6aa.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>BartC <bc@freeuk.com> writes:
>> On 15/12/2016 12:50, Richard Heathfield wrote:
>>> If you don't have it, here's a primitive hex dump program that you could
>>> use. It doesn't show character interpretations of the hex values (adding
>>> them is a simple exercise),
>>
>> Here's a slightly better version:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <stdint.h>
>>
>> int main (int nparams, char** params) {
>[snip]
>
>I'll restrict myself to just one question.
>
>Why did you decide to call the parameters to main "nparams" and
>"params", rather than the universally conventional "argc" and "argv"?

Because the standard allows it and there's no reason not to.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/BestCLCPostEver

[toc] | [prev] | [next] | [standalone]

#99545

On 15/12/2016 17:49, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> int main (int nparams, char** params) {

> I'll restrict myself to just one question.
>
> Why did you decide to call the parameters to main "nparams" and
> "params", rather than the universally conventional "argc" and "argv"?
>

I keep getting them mixed up, when I can remember them.

Also, from 5.1.2.2.1p1: "...referred to here as argc and argv, though 
any names may be used, as they are local to the function in which they 
are declared..."

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99554

BartC <bc@freeuk.com> writes:
> On 15/12/2016 17:49, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> int main (int nparams, char** params) {
>> I'll restrict myself to just one question.
>>
>> Why did you decide to call the parameters to main "nparams" and
>> "params", rather than the universally conventional "argc" and "argv"?
>
> I keep getting them mixed up, when I can remember them.

argc is "argument count".  argv is "argument vector".

> Also, from 5.1.2.2.1p1: "...referred to here as argc and argv, though 
> any names may be used, as they are local to the function in which they 
> are declared..."

Yes, you *can* use any names you like.  I recommend sticking to the
convention that all C programmers will recognize.

-- 
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]

#99565

On 15/12/2016 19:51, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 15/12/2016 17:49, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>>> int main (int nparams, char** params) {
>>> I'll restrict myself to just one question.
>>>
>>> Why did you decide to call the parameters to main "nparams" and
>>> "params", rather than the universally conventional "argc" and "argv"?
>>
>> I keep getting them mixed up, when I can remember them.
>
> argc is "argument count".  argv is "argument vector".

I wouldn't have guessed that last one.

But, is it that big a deal? Sometimes I have to delve into C code 
amounting to tens or hundreds of thousands of lines of code. The exact 
parameter names used by just one of thousands of functions - and one 
discussed here ad nauseam - is the least of the problems!

I'm sure it wouldn't faze any of the experts.

(And actually, on Windows, I normally use a plain main(void) entry 
point, choosing to do my own parameter parsing via GetCommandLine().)

> Yes, you *can* use any names you like.  I recommend sticking to the
> convention that all C programmers will recognize.

(And you probably won't like that I relegate main() to a library most of 
the time and prefer start() as my visible entry point! But I have to 
drag it again out when I post code fragments here.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99569

BartC <bc@freeuk.com> writes:
> On 15/12/2016 19:51, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 15/12/2016 17:49, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>> int main (int nparams, char** params) {
>>>> I'll restrict myself to just one question.
>>>>
>>>> Why did you decide to call the parameters to main "nparams" and
>>>> "params", rather than the universally conventional "argc" and "argv"?
>>>
>>> I keep getting them mixed up, when I can remember them.
>>
>> argc is "argument count".  argv is "argument vector".
>
> I wouldn't have guessed that last one.

And now you don't have to guess.

> But, is it that big a deal? Sometimes I have to delve into C code 
> amounting to tens or hundreds of thousands of lines of code. The exact 
> parameter names used by just one of thousands of functions - and one 
> discussed here ad nauseam - is the least of the problems!

It's not a very big deal, just the first thing I happened to notice.
It's a small problem, but still a problem.  It obfuscates the code for
not good reason.

> I'm sure it wouldn't faze any of the experts.

It fazed me.  I know exactly what it means, of course, but if I
encountered this in a real-world program I'd waste some small amount of
time wondering why unconventional names were used, and whether there
might be some actual significance.

[...]

-- 
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]

#99570

On Thursday, December 15, 2016 at 8:36:08 PM UTC, Bart wrote:
>
> (And you probably won't like that I relegate main() to a library most of 
> the time and prefer start() as my visible entry point! But I have to 
> drag it again out when I post code fragments here.)
> 
Baby X doesn't define main.

If it did, it would fail to work with anything else that did define
main. It does however have a main loop.
Initially user could run the tick function by hand, but I found I
never had a need to do this in any test program.

[toc] | [prev] | [next] | [standalone]

#99596

BartC <bc@freeuk.com> writes:

> On 15/12/2016 12:50, Richard Heathfield wrote:
>
>> If you don't have it, here's a primitive hex dump program that you could
>> use. It doesn't show character interpretations of the hex values (adding
>> them is a simple exercise),
>
> Here's a slightly better version:

There's rarely a total ordering called "better" amongst programs that
solve some problem.  Here you prevent the program from being used as a
filter which matters to me.  (I see from another reply that it
matters much less to you.)

<snip>
>     while ((bb = fgetc(f)) != EOF) {

Why is this loop not clearer and/or more intuitive (in your mind) using
your extra eof() function?  Genuine question.  I know it may sound like
a facetious question, but I really am asking.  I don't see why the
arguments you advanced in the other thread do not apply here.

<snip>
>             printf("\n%s\n","Press Enter to continue, Q Enter to"
>                             " quit...");
>             quit = 0;
>             while ((c = getchar())!='\n') {

Here I'd also end the loop on EOF.  This is another of my reasoning
issues.  For every loop I see I try to prove that it will always
terminate.

If you do add the EOF check, it's a good idea to guard the whole
prompting part with

  if (!feof(stdin) && !ferror(stdin)) ...

(I'd remove it all, but presumably you need this on a system with no
simple way of paging output.)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99636

On 16/12/2016 02:14, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>>     while ((bb = fgetc(f)) != EOF) {
>
> Why is this loop not clearer and/or more intuitive (in your mind) using
> your extra eof() function?  Genuine question.  I know it may sound like
> a facetious question, but I really am asking.  I don't see why the
> arguments you advanced in the other thread do not apply here.

Special rules apply to posting code to comp.lang.c. Code must be 
self-contained for a start.

So using an eof() function, which actually makes little difference in 
this case as the first line of the loop would be fgetc anyway, would 
require me to have added the eof() function, which would have been 
pounced on as making the program far too long etc.

(Instead, the way I declared main() was pounced on!)

The original code actually worked from a byte-size of the file, needing 
a 'getfilesize' function, which would have have been controversial too 
from past experience.

> <snip>
>>             printf("\n%s\n","Press Enter to continue, Q Enter to"
>>                             " quit...");
>>             quit = 0;
>>             while ((c = getchar())!='\n') {
>
> Here I'd also end the loop on EOF.  This is another of my reasoning
> issues.  For every loop I see I try to prove that it will always
> terminate.

You're trying to merge interactive and file input again. I tried to use 
code that was portable. The original code waited for a single key, but 
that needed a library function that was not portable, or would have 
required me adding a hefty bit of conditional code that worked on either 
kind of OS.

> If you do add the EOF check, it's a good idea to guard the whole
> prompting part with
>
>   if (!feof(stdin) && !ferror(stdin)) ...
>
> (I'd remove it all, but presumably you need this on a system with no
> simple way of paging output.)

A better way would have been to send the whole formatted outputted to a 
file, then the user could have used an editor of their choice to page 
forwards and backwards at their leisure (perhaps with a scrollbar!). But 
they might be able to spot how to do that themselves.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99661

BartC <bc@freeuk.com> writes:

> On 16/12/2016 02:14, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>>     while ((bb = fgetc(f)) != EOF) {
>>
>> Why is this loop not clearer and/or more intuitive (in your mind) using
>> your extra eof() function?  Genuine question.  I know it may sound like
>> a facetious question, but I really am asking.  I don't see why the
>> arguments you advanced in the other thread do not apply here.
>
> Special rules apply to posting code to comp.lang.c.

Ah, OK.  That makes sense and it's appreciated.

<snip>
>>>             printf("\n%s\n","Press Enter to continue, Q Enter to"
>>>                             " quit...");
>>>             quit = 0;
>>>             while ((c = getchar())!='\n') {
>>
>> Here I'd also end the loop on EOF.  This is another of my reasoning
>> issues.  For every loop I see I try to prove that it will always
>> terminate.
>
> You're trying to merge interactive and file input again.

No, I was just suggesting you avoid an infinite loop.

But doesn't writing the prompt to stdout merge the interactive IO with
the file IO?  I prefer the output to be separated from the prompts.

> I tried to
> use code that was portable.

It's more portable to test for EOF as you can't be sure the system won't
have a way for the user to accidentally close the input.  Anyway, it was
only a suggestion.

<snip>
>> (I'd remove it all, but presumably you need this on a system with no
>> simple way of paging output.)
>
> A better way would have been to send the whole formatted outputted to
> a file, then the user could have used an editor of their choice to
> page forwards and backwards at their leisure (perhaps with a
> scrollbar!).

A good pager does that (though I prefer a mouse wheel to a scroll bar)
but having one available doesn't preclude using a file.  I nicely
written tool can work either way.

> But they might be able to spot how to do that themselves.

How would you suggest?  I know how to on my Linux system, but it's not
obvious to beginners, and at least one obvious attempt will provoke the
infinite loop you don't want to avoid.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web