Pesky Error

[albert_reade]

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[u] = 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[u][v]-flow[u][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[i][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[u]>=0; u=pred[u]) {
increment = min(increment,capacity[pred[u]][u]-flow[pred[u]][u]);
}
// Now increment the flow.
for (u=n-1; pred[u]>=0; u=pred[u]) {
flow[pred[u]][u] += increment;
flow[u][pred[u]] -= 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[i][j] = 0;
}
}
// read edge capacities
for (i=0; i<e; i++) {
fscanf(input,"%d %d %d",&a,&b,&c);
capacity[a][b] = c;
}
fclose(input);
}

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

Again thanks for the help.

[Vladimir S. Oka]

al**********@yahoo.com 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

[Robert Gamble]

[e-mail] 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

[Skarmander]

Robert Gamble wrote:

[e-mail] 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.

[John F]

"Vladimir S. Oka" wrote:

al**********@yahoo.com 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

[Jack Klein]

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

"Vladimir S. Oka" wrote:

al**********@yahoo.com 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/~a...FAQ-acllc.html

[Jordan Abel]

On 2006-03-20, Jack Klein <ja*******@spamcop.net> 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.

[Jack Klein]

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

On 2006-03-20, Jack Klein <ja*******@spamcop.net> 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/~a...FAQ-acllc.html

[Harald van Dijk]

Jack Klein wrote:

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

On 2006-03-20, Jack Klein <ja*******@spamcop.net> 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.

[Vladimir S. Oka]

Jack Klein opined:

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

"Vladimir S. Oka" wrote:

> al**********@yahoo.com 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.

[Eric Sosman]

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
es*****@acm-dot-org.invalid

[John F]

"Jack Klein" wrote:

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

"Vladimir S. Oka" wrote:

> al**********@yahoo.com 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

[Vladimir S. Oka]

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

[Jordan Abel]

On 2006-03-20, Eric Sosman <es*****@acm-dot-org.invalid> 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.