Pesky Error

Discussion in 'C Programming' started by albert_reade@yahoo.com, Mar 19, 2006.

  1. Guest

    Could someone help me figure out why this error keeps occuring thanks
    for the help.

    error:
    cc FordFulkerson.c
    FordFulkerson.c:117:2: warning: no newline at end of file

    Code:
    #include <stdio.h>
    #define WHITE 0
    #define GRAY 1
    #define BLACK 2
    #define MAX_NODES 1000
    #define oo 1000000000

    //Declarations
    int n; // number of nodes
    int e; // number of edges
    int capacity[MAX_NODES][MAX_NODES]; // capacity matrix
    int flow[MAX_NODES][MAX_NODES]; // flow matrix
    int color[MAX_NODES]; // needed for breadth-first search
    int pred[MAX_NODES]; // array to store augmenting path

    int min (int x, int y) {
    return x<y ? x : y; // returns minimum of x and y
    }

    //A Queue for Breadth-First Search
    int head,tail;
    int q[MAX_NODES+2];

    void enqueue (int x) {
    q[tail] = x;
    tail++;
    color[x] = GRAY;
    }

    int dequeue () {
    int x = q[head];
    head++;
    color[x] = BLACK;
    return x;
    }

    //Breadth-First Search for an augmenting path
    int bfs (int start, int target) {
    int u,v;
    for (u=0; u<n; u++) {
    color = WHITE;
    }
    head = tail = 0;
    enqueue(start);
    pred[start] = -1;
    while (head!=tail) {
    u = dequeue();
    // Search all adjacent white nodes v. If the capacity
    // from u to v in the residual network is positive,
    // enqueue v.
    for (v=0; v<n; v++) {
    if (color[v]==WHITE && capacity[v]-flow[v]>0) {
    enqueue(v);
    pred[v] = u;
    }
    }
    }
    // If the color of the target node is black now,
    // it means that we reached it.
    return color[target]==BLACK;
    }

    //Ford-Fulkerson Algorithm
    int max_flow (int source, int sink) {
    int i,j,u;
    // Initialize empty flow.
    int max_flow = 0;
    for (i=0; i<n; i++) {
    for (j=0; j<n; j++) {
    flow[j] = 0;
    }
    }
    // While there exists an augmenting path,
    // increment the flow along this path.
    while (bfs(source,sink)) {
    // Determine the amount by which we can increment the flow.
    int increment = oo;
    for (u=n-1; pred>=0; u=pred) {
    increment = min(increment,capacity[pred]-flow[pred]);
    }
    // Now increment the flow.
    for (u=n-1; pred>=0; u=pred) {
    flow[pred] += increment;
    flow[pred] -= increment;
    }
    max_flow += increment;
    }
    // No augmenting path anymore. We are done.
    return max_flow;
    }

    //Reading the input file and the main program
    void read_input_file() {
    int a,b,c,i,j;
    FILE* input = fopen("mf.in","r");
    // read number of nodes and edges
    fscanf(input,"%d %d",&n,&e);
    // initialize empty capacity matrix
    for (i=0; i<n; i++) {
    for (j=0; j<n; j++) {
    capacity[j] = 0;
    }
    }
    // read edge capacities
    for (i=0; i<e; i++) {
    fscanf(input,"%d %d %d",&a,&b,&c);
    capacity[a] = c;
    }
    fclose(input);
    }

    int main () {
    read_input_file();
    printf("%d\n",max_flow(0,n-1));
    return 0;
    }

    Again thanks for the help.
     
    , Mar 19, 2006
    #1
    1. Advertising

  2. opined:

    > Could someone help me figure out why this error keeps occuring thanks
    > for the help.
    >
    > error:
    > cc FordFulkerson.c
    > FordFulkerson.c:117:2: warning: no newline at end of file


    For exactly the reason given in the error text.

    The compiler expects a newline as the very last thing in the source
    file. Just go to the very end of the file, hit <ENTER>, and it
    disappears.

    I don't the rational for this requirement. I also tend to see a lot of
    this when copy/pasting code from Usenet articles. :-(

    <snip lots of code with no newline at the very end>

    --
    BR, Vladimir

    We should have a Vollyballocracy. We elect a six-pack of presidents.
    Each one serves until they screw up, at which point they rotate.
    -- Dennis Miller
     
    Vladimir S. Oka, Mar 19, 2006
    #2
    1. Advertising

  3. wrote:
    > Could someone help me figure out why this error keeps occuring thanks
    > for the help.
    >
    > error:
    > cc FordFulkerson.c
    > FordFulkerson.c:117:2: warning: no newline at end of file


    [snip over 100 lines of code]

    You are missing the required newline at the end of your source file,
    but I see how you might be confused from the overly cryptic error
    message...

    Robert Gamble
     
    Robert Gamble, Mar 19, 2006
    #3
  4. Skarmander Guest

    Robert Gamble wrote:
    > wrote:
    >> Could someone help me figure out why this error keeps occuring thanks
    >> for the help.
    >>
    >> error:
    >> cc FordFulkerson.c
    >> FordFulkerson.c:117:2: warning: no newline at end of file

    >
    > [snip over 100 lines of code]
    >
    > You are missing the required newline at the end of your source file,
    > but I see how you might be confused from the overly cryptic error
    > message...
    >

    Well, for starters, what's a "newline", eh? Is it the same as a "new line"?
    I don't actually see a new line when I add a newline, mind you. And, of
    course, when you move your source files across platforms, you may have to
    use new newlines.

    And don't get me started about "end of file"...

    S.
     
    Skarmander, Mar 19, 2006
    #4
  5. John F Guest

    "Vladimir S. Oka" wrote:
    > opined:
    >
    >> Could someone help me figure out why this error keeps occuring
    >> thanks
    >> for the help.
    >>
    >> error:
    >> cc FordFulkerson.c
    >> FordFulkerson.c:117:2: warning: no newline at end of file

    >
    > For exactly the reason given in the error text.
    >
    > The compiler expects a newline as the very last thing in the source
    > file. Just go to the very end of the file, hit <ENTER>, and it
    > disappears.
    >
    > I don't the rational for this requirement. I also tend to see a lot
    > of
    > this when copy/pasting code from Usenet articles. :-(
    >
    > <snip lots of code with no newline at the very end>



    I suppose the standard requires a source file to be a text file (which
    seems to make some sense).

    The only formal definition of what a text file is supposed to look
    like is done by POSIX (AFAIK) and it _requires_ a text file to end
    with a newline character.

    References:
    "IEEE Std 1003.1, 2004 Edition. The Open Group Technical Standard Base
    Specifications, Issue 6." defines:
    "3.392 Text file
    A file that contains characters organised into one or more
    lines.[...]"

    and:

    "3.205 Line
    A sequence of zero or more non- <newline>s plus a terminating
    <newline>."

    thus:
    - minimum of one line.
    - line has to end with a "newline"
    - line without newline is illegal

    follows:
    - a zero byte file can never be a text file.
    - any file with a series of characters without
    a newline at its end is not a text file.
    - the last line in a text file must have a "newline" to be called a
    line and to make it a text file.

    --
    regards
    John
     
    John F, Mar 20, 2006
    #5
  6. Jack Klein Guest

    On Mon, 20 Mar 2006 02:04:26 +0100, "John F" <spam@127.0.0.1> wrote in
    comp.lang.c:

    > "Vladimir S. Oka" wrote:
    > > opined:
    > >
    > >> Could someone help me figure out why this error keeps occuring
    > >> thanks
    > >> for the help.
    > >>
    > >> error:
    > >> cc FordFulkerson.c
    > >> FordFulkerson.c:117:2: warning: no newline at end of file

    > >
    > > For exactly the reason given in the error text.
    > >
    > > The compiler expects a newline as the very last thing in the source
    > > file. Just go to the very end of the file, hit <ENTER>, and it
    > > disappears.
    > >
    > > I don't the rational for this requirement. I also tend to see a lot
    > > of
    > > this when copy/pasting code from Usenet articles. :-(
    > >
    > > <snip lots of code with no newline at the very end>

    >
    >
    > I suppose the standard requires a source file to be a text file (which
    > seems to make some sense).
    >
    > The only formal definition of what a text file is supposed to look
    > like is done by POSIX (AFAIK) and it _requires_ a text file to end
    > with a newline character.
    >
    > References:
    > "IEEE Std 1003.1, 2004 Edition. The Open Group Technical Standard Base
    > Specifications, Issue 6." defines:
    > "3.392 Text file
    > A file that contains characters organised into one or more
    > lines.[...]"
    >
    > and:
    >
    > "3.205 Line
    > A sequence of zero or more non- <newline>s plus a terminating
    > <newline>."
    >
    > thus:
    > - minimum of one line.
    > - line has to end with a "newline"
    > - line without newline is illegal
    >
    > follows:
    > - a zero byte file can never be a text file.
    > - any file with a series of characters without
    > a newline at its end is not a text file.
    > - the last line in a text file must have a "newline" to be called a
    > line and to make it a text file.


    Has nothing at all to do with the POSIX standard, and everything to do
    with the C standard, period:

    "Each instance of a backslash character (\) immediately followed by a
    new-line character is deleted, splicing physical source lines to form
    logical source lines. Only the last backslash on any physical source
    line shall be eligible for being part of such a splice. A source file
    that is not empty shall end in a new-line character, which shall not
    be immediately preceded by a backslash character before any such
    splicing takes place."

    The C standard just plain requires that a source file end in a
    new-line character, except for the degenerate case of an empty file.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Mar 20, 2006
    #6
  7. Jordan Abel Guest

    On 2006-03-20, Jack Klein <> wrote:
    > The C standard just plain requires that a source file end in a
    > new-line character, except for the degenerate case of an empty file.


    "...which it does not admit at all", I suspect you meant to say. I don't
    even think a file ending in a newline but containing no declarations is
    legal.
     
    Jordan Abel, Mar 20, 2006
    #7
  8. Jack Klein Guest

    On 20 Mar 2006 03:41:01 GMT, Jordan Abel <> wrote
    in comp.lang.c:

    > On 2006-03-20, Jack Klein <> wrote:
    > > The C standard just plain requires that a source file end in a
    > > new-line character, except for the degenerate case of an empty file.

    >
    > "...which it does not admit at all", I suspect you meant to say. I don't
    > even think a file ending in a newline but containing no declarations is
    > legal.


    Let me repost the actual quoted text from the standard, which you
    snipped:

    "Each instance of a backslash character (\) immediately followed by a
    new-line character is deleted, splicing physical source lines to form
    logical source lines. Only the last backslash on any physical source
    line shall be eligible for being part of such a splice. A source file
    that is not empty shall end in a new-line character, which shall not
    be immediately preceded by a backslash character before any such
    splicing takes place."

    ....since the standard obviously allows for the existence of an empty
    source file, and allows such a source file to be completely empty,
    exempting it from the final new-line requirement, why do you think it
    is not "admitted"?

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Mar 20, 2006
    #8
  9. Jack Klein opined:

    > On Mon, 20 Mar 2006 02:04:26 +0100, "John F" <spam@127.0.0.1> wrote
    > in comp.lang.c:
    >
    >> "Vladimir S. Oka" wrote:
    >> > opined:
    >> >
    >> >> FordFulkerson.c:117:2: warning: no newline at end of file
    >> >
    >> > I don't the rational for this requirement.

    >>
    >> I suppose the standard requires a source file to be a text file
    >> (which seems to make some sense).
    >>
    >> The only formal definition of what a text file is supposed to look
    >> like is done by POSIX (AFAIK) and it _requires_ a text file to end
    >> with a newline character.

    >
    > Has nothing at all to do with the POSIX standard, and everything to
    > do with the C standard, period:
    >
    > "A source file that is not empty shall end in a new-line character,
    > which shall not be immediately preceded by a backslash character
    > before any such splicing takes place."
    >
    > The C standard just plain requires that a source file end in a
    > new-line character, except for the degenerate case of an empty file.


    Thanks for all the info. However, I already knew it's required in the
    Standard. I was just wandering about the rationale (I admit messing up
    the sentence did not help :-( ). Is it explained in the rationale
    document?

    --
    BR, Vladimir

    UNIX enhancements aren't.
     
    Vladimir S. Oka, Mar 20, 2006
    #9
  10. Jack Klein wrote:
    > On 20 Mar 2006 03:41:01 GMT, Jordan Abel <> wrote
    > in comp.lang.c:
    >
    > > On 2006-03-20, Jack Klein <> wrote:
    > > > The C standard just plain requires that a source file end in a
    > > > new-line character, except for the degenerate case of an empty file.

    > >
    > > "...which it does not admit at all", I suspect you meant to say. I don't
    > > even think a file ending in a newline but containing no declarations is
    > > legal.

    >
    > Let me repost the actual quoted text from the standard, which you
    > snipped:
    >
    > "Each instance of a backslash character (\) immediately followed by a
    > new-line character is deleted, splicing physical source lines to form
    > logical source lines. Only the last backslash on any physical source
    > line shall be eligible for being part of such a splice. A source file
    > that is not empty shall end in a new-line character, which shall not
    > be immediately preceded by a backslash character before any such
    > splicing takes place."
    >
    > ...since the standard obviously allows for the existence of an empty
    > source file, and allows such a source file to be completely empty,
    > exempting it from the final new-line requirement, why do you think it
    > is not "admitted"?


    I think you're talking about different things. The grammar does not
    permit a translation unit to contain no declarations, but a source file
    can legitimately be empty when it is included in another file via
    #include.
     
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=, Mar 20, 2006
    #10
  11. Eric Sosman Guest

    Vladimir S. Oka wrote:
    > Jack Klein opined:
    >>
    >>The C standard just plain requires that a source file end in a
    >>new-line character, except for the degenerate case of an empty file.

    >
    > Thanks for all the info. However, I already knew it's required in the
    > Standard. I was just wandering about the rationale (I admit messing up
    > the sentence did not help :-( ). Is it explained in the rationale
    > document?


    The Rationale doesn't discuss the issue directly,
    although there are some tantalizing near-misses in what
    it says about the line-oriented nature of the preprocessor.
    Perhaps the near-misses are enough to fuel a few guesses.

    Suppose there were no requirement to end each source
    file with a newline, and consider this header file:

    #ifndef H_HEADER
    #define H_HEADER
    typedef int squint;
    #endif

    .... and imagine the #endif line is the last and that it
    doesn't have a newline character. Now let's use it:

    #include "header.h"
    squint main(void) {
    return 0;
    }

    A silly program, of course, but apparently legal -- or
    is it? Remember, there's no newline at the end of the
    header file, so the complete translation unit looks like

    #ifndef H_HEADER
    #define H_HEADER
    typedef int squint;
    #endif squint main(void) {
    return 0;
    }

    .... or maybe even

    #ifndef H_HEADER
    #define H_HEADER
    typedef int squint;
    #endifsquint main(void) {
    return 0;
    }

    .... which are obviously not going to work. I surmise that
    the Committee's distaste for the task of defining reasonable
    behavior when "lines" cross file boundaries prompted them to
    legislate the problem out of existence. (At very little
    inconvenience to the programmer, I might add.)

    See also 5.1.1.2/3 and Question 10.9 in the FAQ for some
    related difficulties in "splicing" files together.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Mar 20, 2006
    #11
  12. John F Guest

    "Jack Klein" wrote:
    > On Mon, 20 Mar 2006 02:04:26 +0100, "John F" <spam@127.0.0.1> wrote
    > in
    > comp.lang.c:
    >
    >> "Vladimir S. Oka" wrote:
    >> > opined:
    >> >
    >> >> Could someone help me figure out why this error keeps occuring
    >> >> thanks
    >> >> for the help.
    >> >>
    >> >> error:
    >> >> cc FordFulkerson.c
    >> >> FordFulkerson.c:117:2: warning: no newline at end of file
    >> >
    >> > For exactly the reason given in the error text.
    >> >
    >> > The compiler expects a newline as the very last thing in the
    >> > source
    >> > file. Just go to the very end of the file, hit <ENTER>, and it
    >> > disappears.
    >> >
    >> > I don't the rational for this requirement. I also tend to see a
    >> > lot
    >> > of
    >> > this when copy/pasting code from Usenet articles. :-(
    >> >
    >> > <snip lots of code with no newline at the very end>

    >>
    >> I suppose the standard requires a source file to be a text file
    >> (which
    >> seems to make some sense).
    >>
    >> The only formal definition of what a text file is supposed to look
    >> like is done by POSIX (AFAIK) and it _requires_ a text file to end
    >> with a newline character.
    >>
    >> References:
    >> "IEEE Std 1003.1, 2004 Edition. The Open Group Technical Standard
    >> Base
    >> Specifications, Issue 6." defines:


    [IEEE definition of text file]

    > Has nothing at all to do with the POSIX standard, and everything to
    > do
    > with the C standard, period:
    >
    > "Each instance of a backslash character (\) immediately followed by
    > a
    > new-line character is deleted, splicing physical source lines to
    > form
    > logical source lines. Only the last backslash on any physical
    > source
    > line shall be eligible for being part of such a splice. A source
    > file
    > that is not empty shall end in a new-line character, which shall not
    > be immediately preceded by a backslash character before any such
    > splicing takes place."


    OK... didn't check translation phases for that :)

    > The C standard just plain requires that a source file end in a
    > new-line character, except for the degenerate case of an empty file.


    To summarize:
    This means that under POSIX constraints a C source file is a text
    file, via compatibility of definition. The only difference is that an
    empty file cannot be a text file.

    That is: any POSIX text file can be a source file but not vice versa.

    --
    regards
    John
     
    John F, Mar 20, 2006
    #12
  13. Eric Sosman wrote:
    > Vladimir S. Oka wrote:
    > > Jack Klein opined:
    > >>
    > >>The C standard just plain requires that a source file end in a
    > >>new-line character, except for the degenerate case of an empty file.

    > >
    > > Thanks for all the info. However, I already knew it's required in the
    > > Standard. I was just wandering about the rationale (I admit messing up
    > > the sentence did not help :-( ). Is it explained in the rationale
    > > document?

    >
    > The Rationale doesn't discuss the issue directly,
    > although there are some tantalizing near-misses in what
    > it says about the line-oriented nature of the preprocessor.
    > Perhaps the near-misses are enough to fuel a few guesses.
    >
    > Suppose there were no requirement to end each source
    > file with a newline, and consider this header file:
    >
    > #ifndef H_HEADER
    > #define H_HEADER
    > typedef int squint;
    > #endif
    >
    > ... and imagine the #endif line is the last and that it
    > doesn't have a newline character. Now let's use it:
    >
    > #include "header.h"
    > squint main(void) {
    > return 0;
    > }
    >
    > A silly program, of course, but apparently legal -- or
    > is it?


    I think it is, as well...

    > Remember, there's no newline at the end of the
    > header file, so the complete translation unit looks like
    >
    > #ifndef H_HEADER
    > #define H_HEADER
    > typedef int squint;
    > #endif squint main(void) {
    > return 0;
    > }
    >
    > ... or maybe even
    >
    > #ifndef H_HEADER
    > #define H_HEADER
    > typedef int squint;
    > #endifsquint main(void) {
    > return 0;
    > }
    >
    > ... which are obviously not going to work. I surmise that
    > the Committee's distaste for the task of defining reasonable
    > behavior when "lines" cross file boundaries prompted them to
    > legislate the problem out of existence. (At very little
    > inconvenience to the programmer, I might add.)
    >
    > See also 5.1.1.2/3 and Question 10.9 in the FAQ for some
    > related difficulties in "splicing" files together.


    Thanks. This does indeed give a good reason for the requirement.

    --
    BR, Vladimir
     
    Vladimir S. Oka, Mar 20, 2006
    #13
  14. Jordan Abel Guest

    On 2006-03-20, Eric Sosman <> wrote:
    > ... or maybe even
    >
    > #ifndef H_HEADER
    > #define H_HEADER
    > typedef int squint;
    > #endifsquint main(void) {
    > return 0;
    > }


    No. an included file does not end in a partial token or partial comment.

    >
    > ... which are obviously not going to work. I surmise that
    > the Committee's distaste for the task of defining reasonable
    > behavior when "lines" cross file boundaries prompted them to
    > legislate the problem out of existence. (At very little
    > inconvenience to the programmer, I might add.)


    Especially since [as acknowledged by the standard] many platforms
    require all text files to end in a newline anyway.

    > See also 5.1.1.2/3 and Question 10.9 in the FAQ for some
    > related difficulties in "splicing" files together.
    >
     
    Jordan Abel, Mar 20, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pesky reverse()

    , Jan 9, 2004, in forum: Python
    Replies:
    3
    Views:
    346
    Elaine Jackson
    Jan 9, 2004
  2. Beauregard T. Shagnasty

    Re: removing pesky spammers

    Beauregard T. Shagnasty, Nov 8, 2009, in forum: HTML
    Replies:
    1
    Views:
    454
    Nik Coughlin
    Nov 8, 2009
  3. DLU
    Replies:
    1
    Views:
    476
    Beauregard T. Shagnasty
    Nov 8, 2009
  4. Jan C. Faerber

    Re: removing pesky spammers

    Jan C. Faerber, Nov 13, 2009, in forum: HTML
    Replies:
    0
    Views:
    509
    Jan C. Faerber
    Nov 13, 2009
  5. Pesky rollover error

    , Oct 16, 2006, in forum: Javascript
    Replies:
    2
    Views:
    88
    Yanick
    Oct 17, 2006
Loading...

Share This Page