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

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

Program to print the longest line

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

Contents

  Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 08:10 -0800
    Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-18 08:49 -0800
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 09:03 -0800
      Re: Program to print the longest line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 09:04 -0800
        Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-18 09:24 -0800
    Re: Program to print the longest line Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 17:42 +0000
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 10:49 -0800
        Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:55 -0500
          Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 11:01 -0800
            Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-18 14:19 -0500
              Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 21:50 -0800
                Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-19 06:39 -0500
                  Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-19 05:07 -0800
                    Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-19 10:12 -0500
                      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-19 07:49 -0800
        Re: Program to print the longest line Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 19:08 +0000
      Re: Program to print the longest line Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-18 14:54 -0500
        Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 23:36 -0800
          Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-19 21:15 -0800
            Re: Program to print the longest line Geoff <geoff@invalid.invalid> - 2015-11-19 21:29 -0800
            Re: Program to print the longest line David Brown <david.brown@hesbynett.no> - 2015-11-20 11:00 +0100
              Re: Program to print the longest line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 15:13 +0000
              Re: Program to print the longest line supercat@casperkitty.com - 2015-11-20 11:29 -0800
              Re: Program to print the longest line Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 12:51 -0800
                Re: Program to print the longest line Philip Lantz <prl@canterey.us> - 2015-11-24 01:59 -0800
                  Re: Program to print the longest line Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 13:34 -0800
    Re: Program to print the longest line John Gordon <gordon@panix.com> - 2015-11-18 18:10 +0000
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 10:53 -0800
        Re: Program to print the longest line Barry Schwarz <schwarzb@dqel.com> - 2015-11-18 13:55 -0800
          Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 23:32 -0800
    Re: Program to print the longest line Barry Schwarz <schwarzb@dqel.com> - 2015-11-18 11:58 -0800

Page 1 of 2  [1] 2  Next page →

#76408 — Program to print the longest line

Hello!

I am doing my best to understand each program presented in the book
I study now. I get surprise after surprise :) I didn't think, though, that
I am at such a low level of knowledge :)

Please, find my questions within the body of the program.
To discern my comments from the ones coming with the program,
I surround my ones with //  //.


// Program to display the longest line

#include <stdio.h>

#define MAXLINE 1000 /* maximum input line size */

int getline (char s[], int lim);

// this is how this line looked before I changed it:
int getline{char line[], int maxline); 

I changed it because the prototype differs from the 
function declaration //

void copy (char to[], char from[]);

/* print longest input line */

int main(void)
{
    int len;     /* current line length */
    int max;     /* maximum length seen so far */
    char line[MAXLINE]; /* current input line */
    char longest[MAXLINE]; /* longest line saved here */
    
    max = 0;
    
    while ( (len = getline(line, MAXLINE)) > 0)
        if (len > max)
        {
            max = len;
            copy (longest, line);
        }
    
    if (max > 0) /* there was a line */
        printf("%s", longest);
 
// Fun begins with the while loop: two arguments are passed into
getline() function: line and MAXLINE. The later is defined above;
but the former, i.e. line, has yet nothing in it. 

Do I understand correctly the following:

1) although the array "line" has yet nothing in it, when the array name 
"line" is passed into getline() function, the function receives an
address to the first character of the array; hence the function "knows" where 
to store its input; therefore,  an empty array is passed to the function, 
or to be more precise, the address of an empty array to be filled in by
the function;

2) if #1 is correct, then getline() stores the input array into line array,
and the next function copy() gets what is newly stored in the array line. //

// my favorite while loop issues:

len is determined to receive a value from getline() function, and it represents
the length of the input line. Does the condition of the while loop mean
that the loop should check if (len > max) while the len is positive? 

If yes, then it's not clear to me. Getline() returns only one i, hence
len is always equal to that i (the condition of no input is never even 
checked), and is always bigger than 0. How does the loop ever terminate? 

And, I don't see any update of the while loop; what is the base for iteration?

Please, see my example below the program. //  

    return 0;
}

/* getline: read a line into s, return length */

int getline (char s[], int lim)
{
    int c, i;
    
    for (i = 0; i < lim - 1 && (c = getchar()) != EOF && c != '\n'; i++)
        s[i] = c;

// Here, in fact, a pointer the array's address is passed into the 
function by char s[]. Hence, s[i] = c stores all input characters into
corresponding i-th address. Is this correct? 
The final character will be '\n', thus i is incremented, and the final
i is returned. //

// I am flummoxed by this condition:

i < lim - 1 && (c = getchar()) != EOF && c != '\n'

= until i is less then MAXLINE AND the EOF is not valid AND ENTER has not
been hit. 

Shouldn't || OR be instead of && as in:

i < lim - 1 && c != '\n' || (c = getchar()) != EOF 

//
    if (c == '\n')
    {
        s[i] = c;
        i++;
    }
    s[i] = '\0';
    
    return i;
}

/* copy 'from' into 'to' */

void copy (char to[], char from [])
{
    int i;
    i = 0;
    
    while ((to[i] = from[i]) != '\0')
        i++;
}

For example:

I enter the following:

Programming in C is fun.\n
Train as much as you can.\n

The function getline() returns i = 24 (including dot and, later, '\n
excluding '\0'). 

Programmin g     i  n     C     i  s    f   u  n  .  \n
012345678910 11 12 13 14 15 16 17 18 19 20 21  22 23 24

The second line is never even read.

The main routine calls getline() in the while loop, and the 
condition becomes:

while ( (len = 24) > 0)

And no update for len.

Thank you very much!

[toc] | [next] | [standalone]

#76418

Alla _ <modelling.data@gmail.com> writes:
[...]
> #include <stdio.h>
>
> #define MAXLINE 1000 /* maximum input line size */
>
> int getline (char s[], int lim);
>
> // this is how this line looked before I changed it:
> int getline{char line[], int maxline); 
>
> I changed it because the prototype differs from the 
> function declaration //

Parameter names are not required to match.  In a function declaration
(prototype) that's not part of a definition, parameter names are
ignored.  On the other hand, making the names consistent is good style.

Incidentally, you might have some problems with your "getline" function,
since there are third-party functions with the same name.  I think POSIX
defines a "getline" function.  If you're careful to compile in
conforming mode, it shouldn't be an issue, but you might want to
consider changing the name to avoid confusion.  "get_line" should be ok.

[...]

> // Fun begins with the while loop: two arguments are passed into
> getline() function: line and MAXLINE. The later is defined above;
> but the former, i.e. line, has yet nothing in it. 
>
> Do I understand correctly the following:
>
> 1) although the array "line" has yet nothing in it, when the array
> name "line" is passed into getline() function, the function receives
> an address to the first character of the array; hence the function
> "knows" where to store its input; therefore, an empty array is passed
> to the function, or to be more precise, the address of an empty array
> to be filled in by the function;

That's very close to being correct.

The array is not *empty*.  Each of its elements has a value from the
moment the array is created.  In the absence of any initialization, that
value just happens to be garbage.  A 1000-element array of char always
holds 1000 char values.

And yes, what's passed to the function is not the array, but the address
of its first element (and no information about the array's size unless
you pass it explicitly -- which you do).  This is described in section 6
of the comp.lang.c FAQ, <http://www.c-faq.com/>, but you seem to have a
good handle on it.

[...]

I'll leave the rest for others to answer.

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

#76422

On Wednesday, November 18, 2015 at 8:49:24 PM UTC+4, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
> [...]
> > #include <stdio.h>
> >
> > #define MAXLINE 1000 /* maximum input line size */
> >
> > int getline (char s[], int lim);
> >
> > // this is how this line looked before I changed it:
> > int getline{char line[], int maxline); 
> >
> > I changed it because the prototype differs from the 
> > function declaration //
> 
> Parameter names are not required to match.  In a function declaration
> (prototype) that's not part of a definition, parameter names are
> ignored.  On the other hand, making the names consistent is good style.
> 
> Incidentally, you might have some problems with your "getline" function,
> since there are third-party functions with the same name.  I think POSIX
> defines a "getline" function.  If you're careful to compile in
> conforming mode, it shouldn't be an issue, but you might want to
> consider changing the name to avoid confusion.  "get_line" should be ok.
> 
Yes, thank you. I have figured that out only after I posted this 
message, and have changed the name of the function to precisely get_line()
a bit later. 
> [...]

> And yes, what's passed to the function is not the array, but the address
> of its first element (and no information about the array's size unless
> you pass it explicitly -- which you do).  This is described in section 6
> of the comp.lang.c FAQ, <http://www.c-faq.com/>, but you seem to have a
> good handle on it.
> 
Thank you. To my shame, I have not yet visited the FAQ part. 

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

#76423

On Wednesday, November 18, 2015 at 4:49:24 PM UTC, Keith Thompson wrote:
> 
> > 1) although the array "line" has yet nothing in it, when the array
> > name "line" is passed into getline() function, the function receives
> > an address to the first character of the array; hence the function
> > "knows" where to store its input; therefore, an empty array is passed
> > to the function, or to be more precise, the address of an empty array
> > to be filled in by the function;
> 
> That's very close to being correct.
> 
> The array is not *empty*.  Each of its elements has a value from the
> moment the array is created.  In the absence of any initialization, that
> value just happens to be garbage.  A 1000-element array of char always
> holds 1000 char values.
> 
C programmers misuse the term "array".

In a normal programming context, and array is an array of data. Imagine the
data as soliders, on a parade ground, arranged so that each one occupies
exactly the same amount of ground. The point is, the soldier are the array,
you can't have an infantry square of no soldiers, and if it's a true square,
you must necessarily have 1, 4, 9, 16 ... etc soldiers.

But in C we don't make much of a distinction between memory with garbage
in it and memory with data. So int square[10][10]; creates 100 integers,
initialised to garbage values. It actually an error to try to read them, but few
compilers enforce that.
If you set the values to 1 .. 100 then of course you have an array. Now the values
mean something.

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

#76429

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, November 18, 2015 at 4:49:24 PM UTC, Keith Thompson wrote:
[...]
>> That's very close to being correct.
>> 
>> The array is not *empty*.  Each of its elements has a value from the
>> moment the array is created.  In the absence of any initialization, that
>> value just happens to be garbage.  A 1000-element array of char always
>> holds 1000 char values.
>> 
> C programmers misuse the term "array".

No, most of us don't, but you do.

[...]

> But in C we don't make much of a distinction between memory with garbage
> in it and memory with data.

Correct.  For example,

    int n;

defines an object `n` of type int.  It is an int object whether a value
has been stored in it or not.  Exactly the same thing applies to objects
of array type.

>                             So int square[10][10]; creates 100
> integers, initialised to garbage values. It actually an error to try
> to read them, but few compilers enforce that.

To be precise, it's undefined behavior.

> If you set the values to 1 .. 100 then of course you have an
> array. Now the values mean something.

You are introducing needless confusion.  If you want to talk about
initialized array objects vs. uninitialized array objects, either use
those terms (preferable) or invent your own.  Pretending that an
uninitialized array object is not an "array" is not useful, and I
suggest you stop spouting such nonsense in the presence of novice C
programmers.

(If you can cite a reliable source that says an array object isn't an
"array" until it's been initialized, I'd be interested in seeing it --
but it still wouldn't affect the correct terminology used when
discussing C.)

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

#76431

On 18/11/15 16:10, Alla _ wrote:
> Hello!
>
> I am doing my best to understand each program presented in the book
> I study now. I get surprise after surprise :) I didn't think, though, that
> I am at such a low level of knowledge :)
>
> Please, find my questions within the body of the program.
> To discern my comments from the ones coming with the program,
> I surround my ones with //  //.
>
>
> // Program to display the longest line
>
> #include <stdio.h>
>
> #define MAXLINE 1000 /* maximum input line size */
>
> int getline (char s[], int lim);
>
> // this is how this line looked before I changed it:
> int getline{char line[], int maxline);

Stop right there. The program is from page 29 of K&R2 (that is, the 
second edition of Kernighan and Ritchie's "The C Programming Language"), 
and the code on that page *correctly* gives

int getline(char line[], int maxline);

I am tempted to deduce that you don't have the book, but a hacked, 
optically-scanned, rip-off copy that is almost certainly in breach of 
copyright law.

The book is not expensive.

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

#76436

On Wednesday, November 18, 2015 at 9:42:26 PM UTC+4, Richard Heathfield wrote:
> On 18/11/15 16:10, Alla _ wrote:
> > Hello!
> >
> > I am doing my best to understand each program presented in the book
> > I study now. I get surprise after surprise :) I didn't think, though, that
> > I am at such a low level of knowledge :)
> >
> > Please, find my questions within the body of the program.
> > To discern my comments from the ones coming with the program,
> > I surround my ones with //  //.
> >
> >
> > // Program to display the longest line
> >
> > #include <stdio.h>
> >
> > #define MAXLINE 1000 /* maximum input line size */
> >
> > int getline (char s[], int lim);
> >
> > // this is how this line looked before I changed it:
> > int getline{char line[], int maxline);
> 
> Stop right there. The program is from page 29 of K&R2 (that is, the 
> second edition of Kernighan and Ritchie's "The C Programming Language"), 
> and the code on that page *correctly* gives
> 
> int getline(char line[], int maxline);
> 
Richard, this is exactly what I wrote - I quoted the line from
the book, the exact one you did, but I have changed it to the line
you see in the program because I've been "taught" (before Keith 
addressed this issue above, so now I know I was wrong) that both
prototype and declaration should have the same names of variables;
and, honestly, it did sound logical. 
this is my line: int getline (char s[], int lim);
this is the one from the book with my comment: 
// this is how this line looked before I changed it:
> > int getline{char line[], int maxline);

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

#76438

On 11/18/2015 01:49 PM, Alla _ wrote:
> On Wednesday, November 18, 2015 at 9:42:26 PM UTC+4, Richard Heathfield wrote:
>> On 18/11/15 16:10, Alla _ wrote:
...
>>> // this is how this line looked before I changed it:
>>> int getline{char line[], int maxline);
>>
>> Stop right there. The program is from page 29 of K&R2 (that is, the 
>> second edition of Kernighan and Ritchie's "The C Programming Language"), 
>> and the code on that page *correctly* gives
>>
>> int getline(char line[], int maxline);

> this is the one from the book with my comment: 
> // this is how this line looked before I changed it:
>>> int getline{char line[], int maxline);

This message contains three lines containing the identifier "getline".
According to you, all three should be identical, but Richard's line is
different from either of yours. Look at them carefully, character by
character, until you figure out the difference.

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

#76442

On Wednesday, November 18, 2015 at 10:55:17 PM UTC+4, James Kuyper wrote:
> On 11/18/2015 01:49 PM, Alla _ wrote:
> > On Wednesday, November 18, 2015 at 9:42:26 PM UTC+4, Richard Heathfield wrote:
> >> On 18/11/15 16:10, Alla _ wrote:
> ...
> >>> // this is how this line looked before I changed it:
> >>> int getline{char line[], int maxline);
> >>
> >> Stop right there. The program is from page 29 of K&R2 (that is, the 
> >> second edition of Kernighan and Ritchie's "The C Programming Language"), 
> >> and the code on that page *correctly* gives
> >>
> >> int getline(char line[], int maxline);
> 
> > this is the one from the book with my comment: 
> > // this is how this line looked before I changed it:
> >>> int getline{char line[], int maxline);
> 
> This message contains three lines containing the identifier "getline".
> According to you, all three should be identical, but Richard's line is
> different from either of yours. Look at them carefully, character by
> character, until you figure out the difference.

Yes, as John has pointed out, and I have replied to that, I did
make the same typo (last time by simply copying what had been written
by me previously) several times. 

I wonder if I am the only person in the world who makes typos in 
comments: I am being constantly chastised for them, though I am
trying to be careful, even when typing messages :))) Believe me, 
no one's better in chastising me than myself ) 

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

#76447

On 11/18/2015 02:01 PM, Alla _ wrote:
...
> Yes, as John has pointed out, and I have replied to that, I did
> make the same typo (last time by simply copying what had been written
> by me previously) several times. 
> 
> I wonder if I am the only person in the world who makes typos in 
> comments: I am being constantly chastised for them, though I am
> trying to be careful, even when typing messages :))) Believe me, 
> no one's better in chastising me than myself ) 

I create lots of typos every day. For example, the word typo at the
beginning of this sentence was typed as
    't' 'y' 'p' 'e' ' ' backspace backspace 'o' ' '
and that was just the first of a dozen different typing errors I
committed while typing this paragraph (I probably committed more than
usual because I was counting my errors while committing them).

However, there's a simple precaution that you should use with any
program text: write the code the a file, and try to compile it. If that
compilation fails, and if it's the failure that you're reporting, then
you're ready to report it. If the compilation succeeds, but the program
itself fails, you'll have to do a test run of the program before
reporting it. However, either way, the compiler would have caught the
misplaced '{'.
But how about when you copy the program to your e-mail message? Doesn't
that provide a fresh opportunity to type the wrong character? Yes, if
you copy it in manually - which is why you should NEVER copy it in
manually. Always cut-and-paste from the actual source code that you
compiled.

Any time you post a message with manually copied source code, you are
likely to waste your time and ours tracking down problems caused by
typos created during that copy, rather than the actual problem you had a
question about.

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

#76485

On Wednesday, November 18, 2015 at 11:19:34 PM UTC+4, James Kuyper wrote:
> On 11/18/2015 02:01 PM, Alla _ wrote:
> ...
> > Yes, as John has pointed out, and I have replied to that, I did
> > make the same typo (last time by simply copying what had been written
> > by me previously) several times. 
> > 
> > I wonder if I am the only person in the world who makes typos in 
> > comments: I am being constantly chastised for them, though I am
> > trying to be careful, even when typing messages :))) Believe me, 
> > no one's better in chastising me than myself ) 
> 
> I create lots of typos every day. For example, the word typo at the
> beginning of this sentence was typed as
>     't' 'y' 'p' 'e' ' ' backspace backspace 'o' ' '
> and that was just the first of a dozen different typing errors I
> committed while typing this paragraph (I probably committed more than
> usual because I was counting my errors while committing them).
> 
> However, there's a simple precaution that you should use with any
> program text: write the code the a file, and try to compile it. If that
> compilation fails, and if it's the failure that you're reporting, then
> you're ready to report it. If the compilation succeeds, but the program
> itself fails, you'll have to do a test run of the program before
> reporting it. However, either way, the compiler would have caught the
> misplaced '{'.
> But how about when you copy the program to your e-mail message? Doesn't
> that provide a fresh opportunity to type the wrong character? Yes, if
> you copy it in manually - which is why you should NEVER copy it in
> manually. Always cut-and-paste from the actual source code that you
> compiled.
> 
> Any time you post a message with manually copied source code, you are
> likely to waste your time and ours tracking down problems caused by
> typos created during that copy, rather than the actual problem you had a
> question about.

Thank you ) I agree 100%, and that is exactly what I do. In this case this
tiny typo occurred when I typed in a comment within this program, and
I don't have this comment in my original Xcode file, and, even if I had it,
the compiler would not utter a word about it, because it is within a 
comment ) Anyway, I guess it's too much attention to this typo ) 

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

#76507

On 11/19/2015 12:50 AM, Alla _ wrote:
...
> Thank you ) I agree 100%, and that is exactly what I do. In this case this
> tiny typo occurred when I typed in a comment within this program, and
> I don't have this comment in my original Xcode file, and, even if I had it,
> the compiler would not utter a word about it, because it is within a 
> comment ) Anyway, I guess it's too much attention to this typo ) 

The comment started out as an actual line of code, then became a comment
because you thought the parameter names needed correcting. If you had
tried to compile it before performing that "correction", you would have
a) found the '{' problem, and b) discovered that the parameter names
didn't need to be corrected.
-- 
James Kuyper

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

#76510

On Thursday, November 19, 2015 at 3:39:15 PM UTC+4, James Kuyper wrote:
> On 11/19/2015 12:50 AM, Alla _ wrote:
> ...
> > Thank you ) I agree 100%, and that is exactly what I do. In this case this
> > tiny typo occurred when I typed in a comment within this program, and
> > I don't have this comment in my original Xcode file, and, even if I had it,
> > the compiler would not utter a word about it, because it is within a 
> > comment ) Anyway, I guess it's too much attention to this typo ) 
> 
> The comment started out as an actual line of code, then became a comment
> because you thought the parameter names needed correcting. 

Sorry, I miss your point here. Or is it a clairvoyance from your side? )
If so, it's wrong )
I have typed the program from the book into my prog1-5-4.c file, in
which I initially changed the prototype, not even typing in the one from
the book. And, as I said elsewhere, this comments exists only in this 
thread, and it is not part of my file where I have my version of prototype.
I have added the line to show you that I have changed it and explain my 
reason. 
With all my respect and enormous thankfulness to you and everyone here,
I should say I am sorry, but I am not getting back to this topic, and would be
grateful if the discussion is jinked towards points which deserve attention. 

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

#76523

On 11/19/2015 08:07 AM, Alla _ wrote:
> On Thursday, November 19, 2015 at 3:39:15 PM UTC+4, James Kuyper wrote:
>> On 11/19/2015 12:50 AM, Alla _ wrote:
>> ...
>>> Thank you ) I agree 100%, and that is exactly what I do. In this case this
>>> tiny typo occurred when I typed in a comment within this program, and
>>> I don't have this comment in my original Xcode file, and, even if I had it,
>>> the compiler would not utter a word about it, because it is within a 
>>> comment ) Anyway, I guess it's too much attention to this typo ) 
>>
>> The comment started out as an actual line of code, then became a comment
>> because you thought the parameter names needed correcting. 
> 
> Sorry, I miss your point here. Or is it a clairvoyance from your side? )
> If so, it's wrong )
> I have typed the program from the book into my prog1-5-4.c file, in
> which I initially changed the prototype, not even typing in the one from
> the book. And, as I said elsewhere, this comments exists only in this 
> thread, and it is not part of my file where I have my version of prototype.
> I have added the line to show you that I have changed it and explain my 
> reason. 

OK - sorry, I made some assumptions that turned out to be incorrect. Let
me restated those assumptions as the first part of a recommendation:
when working with code provided from some external source, before
modifying it in any way, you should first confirm that you typed it in
correctly by attempting to compile and run it.  If the compilation
produces no error messages and the program produces the expected results
when given the appropriate inputs, then and only then should you start
modifying it in any way other than correcting typos.
-- 
James Kuyper

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

#76529

<snip>
> OK - sorry, I made some assumptions that turned out to be incorrect. Let
> me restated those assumptions as the first part of a recommendation:
> when working with code provided from some external source, before
> modifying it in any way, you should first confirm that you typed it in
> correctly by attempting to compile and run it.  If the compilation
> produces no error messages and the program produces the expected results
> when given the appropriate inputs, then and only then should you start
> modifying it in any way other than correcting typos.
> -- 
Thank you. I understand it, and will follow this recommendation. Still
a lot to learn )

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

#76445

On 18/11/15 18:49, Alla _ wrote:
> On Wednesday, November 18, 2015 at 9:42:26 PM UTC+4, Richard Heathfield wrote:
>> On 18/11/15 16:10, Alla _ wrote:
>>> Hello!
>>>
>>> I am doing my best to understand each program presented in the book
>>> I study now. I get surprise after surprise :) I didn't think, though, that
>>> I am at such a low level of knowledge :)
>>>
>>> Please, find my questions within the body of the program.
>>> To discern my comments from the ones coming with the program,
>>> I surround my ones with //  //.
>>>
>>>
>>> // Program to display the longest line
>>>
>>> #include <stdio.h>
>>>
>>> #define MAXLINE 1000 /* maximum input line size */
>>>
>>> int getline (char s[], int lim);
>>>
>>> // this is how this line looked before I changed it:
>>> int getline{char line[], int maxline);
>>
>> Stop right there. The program is from page 29 of K&R2 (that is, the
>> second edition of Kernighan and Ritchie's "The C Programming Language"),
>> and the code on that page *correctly* gives
>>
>> int getline(char line[], int maxline);
>>
> Richard, this is exactly what I wrote

No, exactly what you wrote is quoted above. I'll repeat it here:

 >>> // this is how this line looked before I changed it:
 >>> int getline{char line[], int maxline);

Now let's look at it side by side with the correct version:

int getline{char line[], int maxline);
int getline(char line[], int maxline);

Spot the difference. Hint: it's a punctuation character.

> this is my line: int getline (char s[], int lim);
> this is the one from the book with my comment:
> // this is how this line looked before I changed it:
>>> int getline{char line[], int maxline);

Same problem. Clearly, if you are reporting it accurately, the "book" is 
wrong, in which case it isn't K&R, because K&R gets this right.

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

#76451

On Wednesday November 18 2015 12:42, in comp.lang.c, "Richard Heathfield"
<rjh@cpax.org.uk> wrote:

> On 18/11/15 16:10, Alla _ wrote:
>> Hello!
>>
>> I am doing my best to understand each program presented in the book
>> I study now. I get surprise after surprise :) I didn't think, though, that
>> I am at such a low level of knowledge :)
>>
>> Please, find my questions within the body of the program.
>> To discern my comments from the ones coming with the program,
>> I surround my ones with //  //.
>>
>>
>> // Program to display the longest line
>>
>> #include <stdio.h>
>>
>> #define MAXLINE 1000 /* maximum input line size */
>>
>> int getline (char s[], int lim);
>>
>> // this is how this line looked before I changed it:
>> int getline{char line[], int maxline);
> 
> Stop right there. The program is from page 29 of K&R2 (that is, the
> second edition of Kernighan and Ritchie's "The C Programming Language"),
> and the code on that page *correctly* gives
> 
> int getline(char line[], int maxline);

FWIW, K&R1 page 26 gives
  getline(s, lim)
  char s[];
  int lim;
  {
   ...

It looks here like _Alla is trying to rewrite K&R2 code to match something the
equivalent K&R1 code.

[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#76493

<snip>
> > 
> > int getline(char line[], int maxline);
> 
> FWIW, K&R1 page 26 gives
>   getline(s, lim)
>   char s[];
>   int lim;
>   {
>    ...
> 
> It looks here like _Alla is trying to rewrite K&R2 code to match something the
> equivalent K&R1 code.
> 
<snip>

No ) I was trying to follow the rules I have learned - prototypes 
and function definitions should have consistent names of variables;
this is the only reason why (and what) I have dared to changed in this
program.
Keith has explained my mistake, and now I know, but will follow the 
"rule" of being consistent; I believe it adds up to readability of any
code, and to beauty of it. 

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

#76599

Alla _ <modelling.data@gmail.com> writes:
> <snip>
>> > 
>> > int getline(char line[], int maxline);
>> 
>> FWIW, K&R1 page 26 gives
>>   getline(s, lim)
>>   char s[];
>>   int lim;
>>   {
>>    ...
>> 
>> It looks here like _Alla is trying to rewrite K&R2 code to match
>> something the equivalent K&R1 code.
>> 
> <snip>
>
> No ) I was trying to follow the rules I have learned - prototypes 
> and function definitions should have consistent names of variables;
> this is the only reason why (and what) I have dared to changed in this
> program.
> Keith has explained my mistake, and now I know, but will follow the 
> "rule" of being consistent; I believe it adds up to readability of any
> code, and to beauty of it. 

I just checked my copy of K&R2.  It does indeed use different parameter
names in the declaration and in the definition.  I have no idea why; I
can't think of any good reason for it -- but as I've said it's perfectly
legal.  (It might have been useful as a way to illustrate that very
point, but there's no explicit mention of it.)

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

#76602

On Thu, 19 Nov 2015 21:15:43 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>>> > 
>>> > int getline(char line[], int maxline);
>>> 
>>> FWIW, K&R1 page 26 gives
>>>   getline(s, lim)
>>>   char s[];
>>>   int lim;
>>>   {
>>>    ...
>>> 
>>> It looks here like _Alla is trying to rewrite K&R2 code to match
>>> something the equivalent K&R1 code.
>>> 
>> <snip>
>>
>> No ) I was trying to follow the rules I have learned - prototypes 
>> and function definitions should have consistent names of variables;
>> this is the only reason why (and what) I have dared to changed in this
>> program.
>> Keith has explained my mistake, and now I know, but will follow the 
>> "rule" of being consistent; I believe it adds up to readability of any
>> code, and to beauty of it. 
>
>I just checked my copy of K&R2.  It does indeed use different parameter
>names in the declaration and in the definition.  I have no idea why; I
>can't think of any good reason for it -- but as I've said it's perfectly
>legal.  (It might have been useful as a way to illustrate that very
>point, but there's no explicit mention of it.)

It's explicitly stated on page 26, in the middle paragraph about their
declaration of the power function.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web