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

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

Issues with setting variables to true or false: how does the compiler understands it

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

Contents

  Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 02:17 -0700
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 03:29 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 03:38 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 04:30 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-24 12:04 +0000
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 04:59 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 14:28 +0100
        Re: Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 07:26 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:06 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it James Kuyper <jameskuyper@verizon.net> - 2015-10-24 11:56 -0400
      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:02 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 15:45 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 16:28 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 16:44 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:34 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:30 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 20:33 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 11:16 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-28 15:12 -0400
                Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 12:18 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:51 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:38 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 05:34 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-28 14:08 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 06:14 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:50 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 15:08 -0700
                  Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 22:47 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 18:35 -0500
                      Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:12 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-29 01:35 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 21:12 -0500
                          Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 19:52 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:01 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 03:47 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-24 09:54 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:13 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:50 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 04:04 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-25 08:32 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:19 +0000
        Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 11:30 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:56 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 20:59 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-25 21:49 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 08:10 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-26 16:05 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 00:34 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:04 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 18:16 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:33 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:08 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 11:22 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 11:35 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:00 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:59 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 07:55 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:06 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-26 10:56 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:14 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 17:09 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-26 23:39 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 12:31 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 12:45 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:41 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 19:43 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 19:47 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 13:20 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:28 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:54 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 07:51 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 16:46 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 10:52 -0700
                          Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 18:51 +0000
                            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 12:17 -0700
                              Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 19:34 +0000
                                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:10 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 13:41 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 23:11 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 19:02 -0700
                                      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-28 07:09 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 11:27 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 12:27 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:18 -0700

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#73907

Keith Thompson <kst-u@mib.org> wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
(snip)

>> Write a program that displays only the first n lines of its input.

>> Write a program that displays only the /last/ n lines of its input. 
>> (Harder.)

(snip)

> A number of these programs provide opportunities to think about corner
> cases.  For example, if a program is asked to display the first or last
> 10 lines of its input, what should it do if there are only 5 lines?
> What if there are *no* lines?
 
> In such cases, I suggest that part of the exercise should be to define
> the behavior unambiguously.  Sometime the answer may seem obvious but
> it's still worth writing down.

In general, these are good ideas.

I have seen problems that specifically exclude some corner cases.

Consider an exam problem where the student time is limited.
So as not to distract them from the actual question, certain cases
that might be useful to test are excluded.

On the other hand, some might be specifically included, so read
carefully.

--------

If you want to have fun writing Java programs, that are actual
homework or exam problems, see:

http://practiceit.cs.washington.edu/

The system actually runs the programs for you, and compares your
output against the expected output.

It would be interesting to have a similar system for C, but I
don't know of one.

I suspect that doing many of these problems would make one a better C
programmer, though not all of them.

-- glen

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

#73922

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
> (snip)
>
>>> Write a program that displays only the first n lines of its input.
>
>>> Write a program that displays only the /last/ n lines of its input. 
>>> (Harder.)
>
> (snip)
>
>> A number of these programs provide opportunities to think about corner
>> cases.  For example, if a program is asked to display the first or last
>> 10 lines of its input, what should it do if there are only 5 lines?
>> What if there are *no* lines?
>  
>> In such cases, I suggest that part of the exercise should be to define
>> the behavior unambiguously.  Sometime the answer may seem obvious but
>> it's still worth writing down.
>
> In general, these are good ideas.
>
> I have seen problems that specifically exclude some corner cases.
>
> Consider an exam problem where the student time is limited.
> So as not to distract them from the actual question, certain cases
> that might be useful to test are excluded.

Right.  As a first step, it's ok just to enumerate the corner cases and
document the fact that they're not (yet) being handled.

[...]

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

#73921

On 25/10/2015 18:56, Richard Heathfield wrote:

> Write a program that displays only the first n lines of its input.
>
> Write a program that displays only the /last/ n lines of its input.
> (Harder.)

Very hard I would have thought. What do you mean by 'its input'?

If that's interactive input, then it can go on for ever.

Also, clearly your exercises only make sense where the 'input' is 
actually a true line-oriented file where all lines are of 'reasonable' 
length, and where 'n' is also a 'reasonable' value. But I suspect too 
much of the code would be preoccupied with dealing with unreasonable input.

Actually, I think too much would still be tied up with low-level details 
as doing input in C is fiddly. Perhaps a more useful set of exercises 
(but more advanced) is creating a mini library that would then render 
the rest of the input exercises child's play in comparison.

(So the next 3 are just variations on string slicing, provided each line 
is allowed to reside in memory, and given some line-reading routine.)

> Write a program that displays only the leftmost n characters of each
> input line.
>
> Write a program that displays only the rightmost n characters of each
> input line. (Harder!)
>
> Write a program that displays only characters in columns x to y of each
> input line.

> Write a program that displays every other character of its input (either
> the 1st, 3rd, 5th, 7th etc or the 2nd, 4th, 6th, 8th etc at the user's
> discretion).

This suggests there is some actual interactive input, something else 
that can be tricky. Typical code I've seen in C is not line oriented: if 
three numbers are asked for, and only two are on this line, then it will 
wait for a subsequent line until all the inputs are satisfied. This is 
not very user friendly.

Line oriented user input will just return 0 or "" when it hits end-of-line.

-- 
Bartc

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

#73947

On Mon, 2015-10-26, Bartc wrote:
> On 25/10/2015 18:56, Richard Heathfield wrote:
>
>> Write a program that displays only the first n lines of its input.
>>
>> Write a program that displays only the /last/ n lines of its input.
>> (Harder.)
>
> Very hard I would have thought. What do you mean by 'its input'?
>
> If that's interactive input, then it can go on for ever.

Then it would simply not output anything.
This is basically the Unix tail(1) command, and how it works.

> Also, clearly your exercises only make sense where the 'input' is 
> actually a true line-oriented file where all lines are of 'reasonable' 
> length, and where 'n' is also a 'reasonable' value. But I suspect too 
> much of the code would be preoccupied with dealing with unreasonable input.

Just be a little careful with the word "unreasonable": if I were to
give this as an exercise, I'd state that it was ok for the program to
abort on lines over 100 characters (or something) but if I used a tail
utility and it didn't cope with thousands of characters, I'd be
disappointed: that wouldn't be "reasonable" in that context.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#73948

On 27/10/15 12:31, Jorgen Grahn wrote:
> On Mon, 2015-10-26, Bartc wrote:
>> On 25/10/2015 18:56, Richard Heathfield wrote:
>>
>>> Write a program that displays only the first n lines of its input.
>>>
>>> Write a program that displays only the /last/ n lines of its input.
>>> (Harder.)
>>
>> Very hard I would have thought. What do you mean by 'its input'?
>>
>> If that's interactive input, then it can go on for ever.
>
> Then it would simply not output anything.
> This is basically the Unix tail(1) command, and how it works.
>
>> Also, clearly your exercises only make sense where the 'input' is
>> actually a true line-oriented file where all lines are of 'reasonable'
>> length, and where 'n' is also a 'reasonable' value. But I suspect too
>> much of the code would be preoccupied with dealing with unreasonable input.
>
> Just be a little careful with the word "unreasonable": if I were to
> give this as an exercise, I'd state that it was ok for the program to
> abort on lines over 100 characters (or something)

I'd go further than that, and say that it was okay for the programmer to 
*assume* that lines would be no longer than a certain length, and that n 
(the number of lines to print) would be no higher than a certain 
number... BUT I would also suggest that the programmer should test the 
program to see what happens when those limits are exceeded, and to give 
some thought to the issue (WITHOUT making him or her write more robust 
code, not at this stage). That would make a good exercise for later on.


> but if I used a tail
> utility and it didn't cope with thousands of characters, I'd be
> disappointed: that wouldn't be "reasonable" in that context.

Yep. The key point is that a fundamental distinction must be made 
between throwaway academic exercises and robust software tools.

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

#73951

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 27/10/15 12:31, Jorgen Grahn wrote:
>> On Mon, 2015-10-26, Bartc wrote:
>>> On 25/10/2015 18:56, Richard Heathfield wrote:
<snip>
>>>> Write a program that displays only the /last/ n lines of its input.
>>>> (Harder.)
>>>
>>> Very hard I would have thought. What do you mean by 'its input'?
>>>
>>> If that's interactive input, then it can go on for ever.
>>
>> Then it would simply not output anything.
>> This is basically the Unix tail(1) command, and how it works.
>>
>>> Also, clearly your exercises only make sense where the 'input' is
>>> actually a true line-oriented file where all lines are of 'reasonable'
>>> length, and where 'n' is also a 'reasonable' value. But I suspect too
>>> much of the code would be preoccupied with dealing with unreasonable input.
>>
>> Just be a little careful with the word "unreasonable": if I were to
>> give this as an exercise, I'd state that it was ok for the program to
>> abort on lines over 100 characters (or something)
>
> I'd go further than that, and say that it was okay for the programmer
> to *assume* that lines would be no longer than a certain length, and
> that n (the number of lines to print) would be no higher than a
> certain number...

I think that's a little odd.  That might be the Pascal way (I don't
recall) but it seems an odd design to force on someone learning C.  Line
oriented input is a pain in C and using it adds another failure mode to
the program.

I'd suggest the student limit only the number of bytes to buffer since
the purpose of a limit is simply to avoid teaching about growing buffers
too soon.  There's no obvious advantage (unless I'm missing it) to
limiting both line length and the maximum number of lines.

<snip>
>> but if I used a tail
>> utility and it didn't cope with thousands of characters, I'd be
>> disappointed: that wouldn't be "reasonable" in that context.
>
> Yep. The key point is that a fundamental distinction must be made
> between throwaway academic exercises and robust software tools.

I'm worried by that idea, as least in the way it's phrases.  I think the
distinction should be *minimised* wherever possible.  That involves
carefully choosing exercises so that it is not necessary to make too
many unrealistic simplifications, and to teach, wherever possible, "best
practise".  That's hard to define, of course, but I mean, very roughly,
best practice given the fewest simplify assumptions about the program's
overall design.

We are probably not too far apart on this point but the way you phrase
it suggests you might be happy with what, for me, would be unacceptable
designs, because you've put a huge wall between throwaway academic
exercises and properly usable tools.  I believe one should try to make
as little distinction between these as is practical.

-- 
Ben.

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

#73955

On 27/10/15 13:24, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 27/10/15 12:31, Jorgen Grahn wrote:
>>> On Mon, 2015-10-26, Bartc wrote:
>>>> On 25/10/2015 18:56, Richard Heathfield wrote:
> <snip>
>>>>> Write a program that displays only the /last/ n lines of its input.
>>>>> (Harder.)
>>>>
>>>> Very hard I would have thought. What do you mean by 'its input'?
>>>>
>>>> If that's interactive input, then it can go on for ever.
>>>
>>> Then it would simply not output anything.
>>> This is basically the Unix tail(1) command, and how it works.
>>>
>>>> Also, clearly your exercises only make sense where the 'input' is
>>>> actually a true line-oriented file where all lines are of 'reasonable'
>>>> length, and where 'n' is also a 'reasonable' value. But I suspect too
>>>> much of the code would be preoccupied with dealing with unreasonable input.
>>>
>>> Just be a little careful with the word "unreasonable": if I were to
>>> give this as an exercise, I'd state that it was ok for the program to
>>> abort on lines over 100 characters (or something)
>>
>> I'd go further than that, and say that it was okay for the programmer
>> to *assume* that lines would be no longer than a certain length, and
>> that n (the number of lines to print) would be no higher than a
>> certain number...
>
> I think that's a little odd.  That might be the Pascal way (I don't
> recall) but it seems an odd design to force on someone learning C.  Line
> oriented input is a pain in C and using it adds another failure mode to
> the program.

I wasn't planning on forcing that design on anyone. I'm just leaving it 
open. Not quite the same thing.

> I'd suggest the student limit only the number of bytes to buffer since
> the purpose of a limit is simply to avoid teaching about growing buffers
> too soon.  There's no obvious advantage (unless I'm missing it) to
> limiting both line length and the maximum number of lines.

Well, it means you can do this:

#define MAX_LINE_LENGTH 60
#define MAX_HISTORY 10

char history[MAX_HISTORY][MAX_LINE_LENGTH] = {0};

and then the implementation is pretty much obvious from that point on.

>
> <snip>
>>> but if I used a tail
>>> utility and it didn't cope with thousands of characters, I'd be
>>> disappointed: that wouldn't be "reasonable" in that context.
>>
>> Yep. The key point is that a fundamental distinction must be made
>> between throwaway academic exercises and robust software tools.
>
> I'm worried by that idea, as least in the way it's phrases.  I think the
> distinction should be *minimised* wherever possible.

I think that "wherever possible" should not include the very early 
stages of learning to write programs. When a kid builds his or her first 
pramwheels-and-string go-kart, it is unkind to insist that it is fitted 
with air-bags. (Proof by analogy is fraud, of course. This is 
illustration by analogy, quite a different thing.)

> That involves
> carefully choosing exercises so that it is not necessary to make too
> many unrealistic simplifications, and to teach, wherever possible, "best
> practise".  That's hard to define, of course, but I mean, very roughly,
> best practice given the fewest simplify assumptions about the program's
> overall design.

Taking that paragraph purely on its own merits without the surrounding 
context, I think I'd agree. In fact, I think the key phrase is 
"carefully choosing exercises". Looking back on my suggested list, I 
recognise that I wasn't as careful as I should have been!

> We are probably not too far apart on this point but the way you phrase
> it suggests you might be happy with what, for me, would be unacceptable
> designs, because you've put a huge wall between throwaway academic
> exercises and properly usable tools.  I believe one should try to make
> as little distinction between these as is practical.

I think there /is/ a huge wall between early learning and best practice. 
In my view, the purpose of academic exercises is to help the student to 
build a ladder (or stairway) to scale that wall, set at an angle that 
offers a challenge without actually requiring ropes and crampons. That 
is, early exercises should be judged very, very forgivingly, with the 
bar becoming steadily higher as the student gains experience and 
confidence with the language.

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

#74001

On Tue, 2015-10-27, Richard Heathfield wrote:
> On 27/10/15 13:24, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
...
>>> Yep. The key point is that a fundamental distinction must be made
>>> between throwaway academic exercises and robust software tools.
>>
>> I'm worried by that idea, as least in the way it's phrases.  I think the
>> distinction should be *minimised* wherever possible.
...

>> We are probably not too far apart on this point but the way you phrase
>> it suggests you might be happy with what, for me, would be unacceptable
>> designs, because you've put a huge wall between throwaway academic
>> exercises and properly usable tools.  I believe one should try to make
>> as little distinction between these as is practical.
>
> I think there /is/ a huge wall between early learning and best practice. 

And as a side note: I believe there's also another distinction between
"code that does its job well enough" and "best practice".

I wrote above that I would dismiss an implementation of tail(1) with
limitations ... but at the same time we can't teach people that they
must always produce code that is /that/ good.  The original vi text
editor couldn't cope with terminals wider than 132 characters (or
something), but if people had laughed at Bill Joy when he showed his
first version, we wouldn't have any vi today.

And it was only a few weeks ago that I myself last used fgets() with
an artificial line length limit.  I started thinking about fixing that
(and was looking forward to it) but then decided it was not in my
employer's best interest.  That code would not have solved any
real-world problems (input lines were short) and the code would never
be reused.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#74002

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 27/10/15 13:24, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
>>> I'd go further than that, and say that it was okay for the programmer
>>> to *assume* that lines would be no longer than a certain length, and
>>> that n (the number of lines to print) would be no higher than a
>>> certain number...
>>
>> I think that's a little odd.  That might be the Pascal way (I don't
>> recall) but it seems an odd design to force on someone learning C.  Line
>> oriented input is a pain in C and using it adds another failure mode to
>> the program.
>
> I wasn't planning on forcing that design on anyone. I'm just leaving
> it open. Not quite the same thing.

Maybe the force is the wrong word, but if you specify that limited line
length and limited n are permitted, you probably won't get many designs
other than the one you already have in your mind.

>> I'd suggest the student limit only the number of bytes to buffer since
>> the purpose of a limit is simply to avoid teaching about growing buffers
>> too soon.  There's no obvious advantage (unless I'm missing it) to
>> limiting both line length and the maximum number of lines.
>
> Well, it means you can do this:
>
> #define MAX_LINE_LENGTH 60
> #define MAX_HISTORY 10
>
> char history[MAX_HISTORY][MAX_LINE_LENGTH] = {0};
>
> and then the implementation is pretty much obvious from that point on.

Yes, I was not in doubt about that part!  I should probably not comment
further until I've written it both ways, but having only one limitation
looks better to me than having two.  Maybe maintaining a circular buffer
of characters is messier than I'm imagining.  I'll see if I have time
(and inclination) later.

>> <snip>
>>>> but if I used a tail
>>>> utility and it didn't cope with thousands of characters, I'd be
>>>> disappointed: that wouldn't be "reasonable" in that context.
>>>
>>> Yep. The key point is that a fundamental distinction must be made
>>> between throwaway academic exercises and robust software tools.
>>
>> I'm worried by that idea, as least in the way it's phrases.  I think the
>> distinction should be *minimised* wherever possible.
>
> I think that "wherever possible" should not include the very early
> stages of learning to write programs. When a kid builds his or her
> first pramwheels-and-string go-kart, it is unkind to insist that it is
> fitted with air-bags. (Proof by analogy is fraud, of course. This is
> illustration by analogy, quite a different thing.)

It's possible we agree -- I'm not really sure.  We may both simply be
putting it in terms the other can't quite accept.  I say that because:

>> That involves
>> carefully choosing exercises so that it is not necessary to make too
>> many unrealistic simplifications, and to teach, wherever possible, "best
>> practise".  That's hard to define, of course, but I mean, very roughly,
>> best practice given the fewest simplify assumptions about the program's
>> overall design.
>
> Taking that paragraph purely on its own merits without the surrounding
> context, I think I'd agree. In fact, I think the key phrase is
> "carefully choosing exercises". Looking back on my suggested list, I
> recognise that I wasn't as careful as I should have been!

To take the go-kart analogy further, the exercise is not to build a
child-safe racing vehicle -- it's to build something fun to ride, often
with only what you find lying around.  Airbags will never be part of
that.

The hard part is to come up with exercises that are fun, don't use
anything the student does not have "lying round", but that can be done
well without too many compromises.  It's only that last part that's in
dispute because your phrase about a fundamental distinction with
throwaway academic exercises suggests a difference about what
constitutes too many compromises.

>> We are probably not too far apart on this point but the way you phrase
>> it suggests you might be happy with what, for me, would be unacceptable
>> designs, because you've put a huge wall between throwaway academic
>> exercises and properly usable tools.  I believe one should try to make
>> as little distinction between these as is practical.
>
> I think there /is/ a huge wall between early learning and best
> practice.

Take a classic that drives me mad every time I see it: write a program
to convert degrees C to degrees F.  The intended solution is usually a
tedious thing that uses interactive input and does a simple calculation.
I'd prefer to teach the use of command-line arguments and a simple call
to atof or strtod because that's the sort of conversion tool I might
actually use (and it extends well for later more challenging exercises).

Now it's true that there is some noise in using argv, but it does not
need very much more in terms of explanation (and hand waving) than scanf
or fgets, and the result is, trivial though it may be, closer to "best
practice" than the usual "simple" solution.  I say "closer" because I'd
probably leave returning a useful status for later programs.  Best
practise would require one to be returned, of course, so this is simply
closer to best practice than the usual solution.

<snip>
-- 
Ben.

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

#73950

On 27/10/2015 12:31, Jorgen Grahn wrote:
> On Mon, 2015-10-26, Bartc wrote:

>But I suspect too
>> much of the code would be preoccupied with dealing with unreasonable input.
>
> Just be a little careful with the word "unreasonable": if I were to
> give this as an exercise, I'd state that it was ok for the program to
> abort on lines over 100 characters (or something) but if I used a tail
> utility and it didn't cope with thousands of characters, I'd be
> disappointed: that wouldn't be "reasonable" in that context.

Whenever this comes up ('line-oriented' input), solutions are expected 
to work with gigantic (multi-GB) files containing a single multi-GB line 
of text.

That's usually the reason why character-oriented approaches are 
preferred to line-buffered ones.

Line-buffering however makes it easier to construct higher level 
solutions**.

Then there's file-buffering, which is in disfavour because it imposes an 
upper limit on the sizes of files it can cope with, but also it usually 
leads to endless discussions about file sizes and whether or not they 
can be meaningfully derived.

In short, it's one of those subjects in clc where it is impossible to 
merely have a 'reasonable' solution which usually works well enough; it 
needs to be perfect. (Random number generators and, I think, hash 
functions, are a couple of others.)

(**I have a scripting language which can take care of most of these 
file-reading exercises in a handful of lines. Reading an entire file 
into a list of strings is a single function. But buried somewhere in the 
implementation, is a call to fgets(), complete with a fixed-size 
line-buffer!)

-- 
Bartc

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

#73952

On 27/10/15 13:20, Bartc wrote:
> On 27/10/2015 12:31, Jorgen Grahn wrote:
>> On Mon, 2015-10-26, Bartc wrote:
>
>> But I suspect too
>>> much of the code would be preoccupied with dealing with unreasonable
>>> input.
>>
>> Just be a little careful with the word "unreasonable": if I were to
>> give this as an exercise, I'd state that it was ok for the program to
>> abort on lines over 100 characters (or something) but if I used a tail
>> utility and it didn't cope with thousands of characters, I'd be
>> disappointed: that wouldn't be "reasonable" in that context.
>
> Whenever this comes up ('line-oriented' input), solutions are expected
> to work with gigantic (multi-GB) files containing a single multi-GB line
> of text.

The current case is a counter-example. I would not ask someone of Alla's 
experience level to cope with files larger than maybe a hundred or two 
hundred lines, maybe sixty or so characters per line, and perhaps a tail 
of up to ten lines. Just enough for a little light testing.

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

#73958

Bartc <bc@freeuk.com> writes:

> On 27/10/2015 12:31, Jorgen Grahn wrote:
>> On Mon, 2015-10-26, Bartc wrote:
>
>>But I suspect too
>>> much of the code would be preoccupied with dealing with unreasonable input.
>>
>> Just be a little careful with the word "unreasonable": if I were to
>> give this as an exercise, I'd state that it was ok for the program to
>> abort on lines over 100 characters (or something) but if I used a tail
>> utility and it didn't cope with thousands of characters, I'd be
>> disappointed: that wouldn't be "reasonable" in that context.
>
> Whenever this comes up ('line-oriented' input), solutions are expected
> to work with gigantic (multi-GB) files containing a single multi-GB
> line of text.

That's unreasonable for an early student exercise in C.  Until dynamic
allocation has been discussed, a fixed limit is perfectly reasonable.

> That's usually the reason why character-oriented approaches are
> preferred to line-buffered ones.

I prefer them (where they are possible) because they are often simpler
in C.

> Line-buffering however makes it easier to construct higher level
> solutions**.

That's one reason I used to like teaching C++.  You can use relatively
high-level primitives at first (e.g. getline) but then you can explain
how they are implemented (or set that as an exercise) without leaving
the language.  You can switch levels very easily.

You could do the same in C by giving the students a getline function
(not as source!) and later asking for an implementation of it, but my
experience is that students don't like that style.  They often feel ever
so slightly patronised -- after all they are learning C to be "close to
the metal".

> Then there's file-buffering, which is in disfavour because it imposes
> an upper limit on the sizes of files it can cope with, but also it
> usually leads to endless discussions about file sizes and whether or
> not they can be meaningfully derived.

Cutting though the debates, it should be clear that the fundamental
distinction is between algorithms that seek the input and those that
don't; one pass or multi-pass algorithms; stream- or file-oriented
solutions.  That's not a vacuous debate, it matters.

> In short, it's one of those subjects in clc where it is impossible to
> merely have a 'reasonable' solution which usually works well enough;
> it needs to be perfect.

Nonsense!  Even the idea of a perfect solution is your invention to keep
the debate going.  There is not such thing in the vast majority of
cases.  The arguments simply come from people having different
perspectives.  It seems that there are some (like you?) who are happy to
drop the requirement that a tool can process an un-seekable stream long
before others (like me) would be prepared to do.

<snip>
-- 
Ben.

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

#73963

On Tuesday, October 27, 2015 at 8:54:41 AM UTC-5, Ben Bacarisse wrote:
> That's unreasonable for an early student exercise in C.  Until dynamic
> allocation has been discussed, a fixed limit is perfectly reasonable.

I'd suggest a fixed limit within the body of the code should be discouraged;
at minimum, there should be definitions near the top of the file which set
the buffer size.

> > That's usually the reason why character-oriented approaches are
> > preferred to line-buffered ones.
> 
> I prefer them (where they are possible) because they are often simpler
> in C.

For something like "tail", a helpful approach can be to use a "rolling"
buffer of the last N bytes [for some N] and simply read data until one
has the last N bytes, and then count newlines backward; have as a documented
limit that regardless of the requested N the utility will only output lines
that fit entirely within the last __ bytes of a file.  Having the utility
ignore everything until it has found the end of the file will be faster than
having to check the lengths of all incoming lines and adjust buffer sizes
accordingly.

> That's one reason I used to like teaching C++.  You can use relatively
> high-level primitives at first (e.g. getline) but then you can explain
> how they are implemented (or set that as an exercise) without leaving
> the language.  You can switch levels very easily.

I really wish someone would standardize a line input function which would
return either the number of characters received or a one-past pointer for
the received data.  On many platforms, fgets() is faster than anything that
can be synthesized using fgetc(), but having to search for and eliminate
the newline character is a major nuisance; fgets() also has no way of
handling inputs which contain embedded zero bytes.

Incidentally, I am also somewhat puzzled at the refusal of the Committee to
recognize any standard means of requesting raw keyboard input.  I know that
some platforms cannot support raw interactive I/O, but it is a sufficiently
common feature that there should be a standardized means of requesting it
on platforms that can support it (and having those that cannot support it
report that fact).

> Cutting though the debates, it should be clear that the fundamental
> distinction is between algorithms that seek the input and those that
> don't; one pass or multi-pass algorithms; stream- or file-oriented
> solutions.  That's not a vacuous debate, it matters.

Definitely.  If it's possible to seek a file, one could start by guessing
that the last N lines will be somewhere in the last N*80 bytes of the file,
and if that doesn't work, try the last N*160, N*320, etc. bytes until
one finds the last N lines or has read the whole file.  At worst it will
take about twice as long as scanning the whole file once, but in most
cases it will be much faster.

> > In short, it's one of those subjects in clc where it is impossible to
> > merely have a 'reasonable' solution which usually works well enough;
> > it needs to be perfect.
> 
> Nonsense!  Even the idea of a perfect solution is your invention to keep
> the debate going.  There is not such thing in the vast majority of
> cases.  The arguments simply come from people having different
> perspectives.  It seems that there are some (like you?) who are happy to
> drop the requirement that a tool can process an un-seekable stream long
> before others (like me) would be prepared to do.

One thing I've long thought, not just with C but other languages with
enumerable sequences, is that there should be a system-supplied means of
telling a data source "I will need to be able to seek back by a certain
distance" and having the data source do whatever it needs to do to make
that possible.  If the data source is something like a pipe, the OS may
be in a better position to handle such buffering than the application,
especially since the OS will in many cases be including buffering of its
own anyway.

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

#73975

On 27/10/2015 14:51, supercat@casperkitty.com wrote:

> I really wish someone would standardize a line input function which would
> return either the number of characters received or a one-past pointer for
> the received data.  On many platforms, fgets() is faster than anything that
> can be synthesized using fgetc(), but having to search for and eliminate
> the newline character is a major nuisance;

Hint: it's usually at the end. (If not, then the line was probably too 
long and has been split.)

> fgets() also has no way of
> handling inputs which contain embedded zero bytes.

That probably wouldn't be a regarded as a text file then.

> Definitely.  If it's possible to seek a file, one could start by guessing
> that the last N lines will be somewhere in the last N*80 bytes of the file,
> and if that doesn't work, try the last N*160, N*320, etc. bytes until
> one finds the last N lines or has read the whole file.  At worst it will
> take about twice as long as scanning the whole file once, but in most
> cases it will be much faster.

In 99% of cases, loading the entire file into memory is probably the 
fastest and simplest way:

int numberoflines;
char **linelist;

status = load_file_into_memory_as_lines(
     filename, &linelist, &numberoflines);

<check status and do it the hard way if the file is too big>

if (n>numberoflines) n = numberoflines;

for (int i=numberoflines-n; i<numberoflines) puts(linelist[i]);

free_linelist(linelist, numberoflines);

-- 
Bartc

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

#73984

On Tuesday, October 27, 2015 at 11:46:55 AM UTC-5, Bart wrote:
> On 27/10/2015 14:51, supercat wrote:
> 
> > I really wish someone would standardize a line input function which would
> > return either the number of characters received or a one-past pointer for
> > the received data.  On many platforms, fgets() is faster than anything that
> > can be synthesized using fgetc(), but having to search for and eliminate
> > the newline character is a major nuisance;
> 
> Hint: it's usually at the end. (If not, then the line was probably too 
> long and has been split.)

The fgets() knows where the last character is.  The caller is 99% likely
to need that information, if nothing else to eliminate the newline.  It
makes little sense to require the caller to use a semantically-dubious
call to strlen (which may fail to correctly report how much information
was read) to try to re-compute information which fgets() had but
didn't bother to return.  It wouldn't be safe to change fgets() itself,
since it would not only break the handful of programs that actually use
its return value, but more importantly it would create problems if  code
that expects fgets() to return something useful is compiled against a
version of fgets() that doesn't.  Adding a new variation, however, should
be much safer, and would generally save a line of code every time it's
used.

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

#73991

On 27/10/2015 17:52, supercat@casperkitty.com wrote:
> On Tuesday, October 27, 2015 at 11:46:55 AM UTC-5, Bart wrote:
>> On 27/10/2015 14:51, supercat wrote:
>>
>>> I really wish someone would standardize a line input function which would
>>> return either the number of characters received or a one-past pointer for
>>> the received data.  On many platforms, fgets() is faster than anything that
>>> can be synthesized using fgetc(), but having to search for and eliminate
>>> the newline character is a major nuisance;
>>
>> Hint: it's usually at the end. (If not, then the line was probably too
>> long and has been split.)
>
> The fgets() knows where the last character is.  The caller is 99% likely
> to need that information, if nothing else to eliminate the newline.  It
> makes little sense to require the caller to use a semantically-dubious
> call to strlen (which may fail to correctly report how much information
> was read)

What's dubious about it? And why should it report what was read? You can 
work that out with ftell(), but it's slow.

> to try to re-compute information which fgets() had but
> didn't bother to return.

Not everyone is interested in the length of the resulting string (maybe 
the same sorts of people who aren't interested in the sizes of files).

But if it's important, I don't think it's a big overhead. I've just 
tested reading a 300,000-line file into memory (assorted source codes, 
averaging 22 characters/line), and it took 220ms using fgets and using 
strlen.

I measured the strlen overhead as around 4ms in total, or about 2%. It 
means the difference between 1.300M lines/second throughput, and 1.326M.

(For extra speed, reading the file in as a single string took 11ms, or 
27M lines/second, using one fread() call.)

> Adding a new variation, however, should
> be much safer, and would generally save a line of code every time it's
> used.

A new version would more than likely just be a combination of old 
fgets() and strlen()!

-- 
Bartc

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

#73994

On Tuesday, October 27, 2015 at 1:51:31 PM UTC-5, Bart wrote:
> What's dubious about it? And why should it report what was read? You can 
> work that out with ftell(), but it's slow.

While text inputs won't usually contain NUL characters, there's nothing
illegal about text inputs doing so.  Sometimes it's helpful to be able to
use text-file tools on files that are 99% text but have a few weird
characters thrown in as well.  Having NUL considered a line ending
or having it be available to code which tracks string lengths rather than
using zero termination might both be reasonable behaviors, but without
a means of knowing how much data was actually read it's hard to avoid
nonsensical behaviors when given files that contain NUL characters.

> Not everyone is interested in the length of the resulting string (maybe 
> the same sorts of people who aren't interested in the sizes of files).

Seldom is the trailing newline wanted by the code that's going to process
the string, but if one doesn't know the length there's no way to strip that
trailing newline.

> But if it's important, I don't think it's a big overhead. I've just 
> tested reading a 300,000-line file into memory (assorted source codes, 
> averaging 22 characters/line), and it took 220ms using fgets and using 
> strlen.

It's not outrageously important, but if the vast majority of calls to
fgets() are immediately followed by calls to strlen() that would suggest
that code could be easier to read and write, as well as more fast to
execute, if there were a function that indicated how much data had been
read.

> > Adding a new variation, however, should
> > be much safer, and would generally save a line of code every time it's
> > used.
> 
> A new version would more than likely just be a combination of old 
> fgets() and strlen()!

Some platforms might possibly implement it that way (though hopefully not
if text files can contain NUL bytes), but more likely the platform would
change the core get-line routine to return the number of bytes read, and
then have fgets chain to the new routine.

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

#73999

On 27/10/2015 19:17, supercat@casperkitty.com wrote:
> On Tuesday, October 27, 2015 at 1:51:31 PM UTC-5, Bart wrote:
>> What's dubious about it? And why should it report what was read? You can
>> work that out with ftell(), but it's slow.
>
> While text inputs won't usually contain NUL characters, there's nothing
> illegal about text inputs doing so.

Then it would be a binary file IMO. You have to draw the line somewhere.

And you don't want to discard the use of a fast strlen call because of 
that very rare possibility.

Remember also that fgets uses a trailing null as the primary method to 
indicate the end of the line. Any program that makes use of that is 
going to screw up when it encounters extra nulls within the line.

(And a file that might have null characters as data, is liable to want 
to use codes 13, 10 and 26 as data too!)

-- 
Bartc

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

#74005

On Tuesday, October 27, 2015 at 2:34:24 PM UTC-5, Bart wrote:
> Then it would be a binary file IMO. You have to draw the line somewhere.

What exactly constitutes a "text" file, and what is the basis for limiting
things to that?

At least in the MS-DOS world it was hardly uncommon to have files which
contain mostly printable characters separated by newlines but also contain
a few printer-setup codes, word-processor formatting codes, etc.  There's
no particular reason something like a "grep" utility shouldn't be usable
with such files.

> And you don't want to discard the use of a fast strlen call because of 
> that very rare possibility.

Having to follow every fgets call with strlen is, at minimum, a nuisance
compared with having a function which simply returns the proper information
directly.

> Remember also that fgets uses a trailing null as the primary method to 
> indicate the end of the line. Any program that makes use of that is 
> going to screw up when it encounters extra nulls within the line.

A lot of programs keep track of string lengths and then use memcpy/memmove
rather than str* functions, and thus would have no reason to care about
any zero bytes that might appear within lines.

> (And a file that might have null characters as data, is liable to want 
> to use codes 13, 10 and 26 as data too!)

If a "grep" utility sees a line break where there isn't really supposed to
be one, that's often less of a problem than having it be blind to anything
on a line that follows a NUL.  Code 1A is a bit of a nuisance, but I've
seen more printer setup strings that use NUL than that use 1A.

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

#74009

supercat@casperkitty.com writes:
> On Tuesday, October 27, 2015 at 2:34:24 PM UTC-5, Bart wrote:
>> Then it would be a binary file IMO. You have to draw the line somewhere.
>
> What exactly constitutes a "text" file, and what is the basis for limiting
> things to that?

I'm not aware of any universal rigorous definition.  The C standard
(N1570 7.21.2p2) makes no guarantees for characters other than printable
characters, '\t', and '\n', or for space characters at the end of a
line.  Of course implementations can and do make further guarantees.

> At least in the MS-DOS world it was hardly uncommon to have files which
> contain mostly printable characters separated by newlines but also contain
> a few printer-setup codes, word-processor formatting codes, etc.  There's
> no particular reason something like a "grep" utility shouldn't be usable
> with such files.

And in fact GNU grep (to pick the example I'm most familiar with)
handles non-printable characters, including null characters, in a
reasonable way.  I'm sure the code that implements this handling is a
bit more complex than a more naive implementation would be.

>> And you don't want to discard the use of a fast strlen call because of 
>> that very rare possibility.
>
> Having to follow every fgets call with strlen is, at minimum, a nuisance
> compared with having a function which simply returns the proper information
> directly.

Every fgets call needs to be followed by a call to strlen *only* if you
always need to find and remove the '\n'.  That's not always necessary.

[...]

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web