can someone help me how to compile this program??

[Anarki]

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()
{
char arr[10] = "Qualifiers"
char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

i am using cygwin in window xp SP2, my gcc version is 3.4.4

how do i compile the above program?

i tried using this

gcc -c -std=c99 restrict.c

but i get an error like this

restrict.c: In function 'main':
restrict.c:6: error: parse error before "char"

can someone help me how to compile this program??

[Ian Collins]

Anarki wrote:

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()
{
char arr[10] = "Qualifiers"

Missing semicolon.

--
Ian Collins.

[MisterE]

char arr[10] = "Qualifiers"

you are missing ;
try:
char arr[10] = "Qualifiers";

[Anarki]

On Oct 1, 1:31*pm, MisterE <[e-mail]:

* *char arr[10] = "Qualifiers"

you are missing ;
try:
char arr[10] = "Qualifiers";

omg! i didnt see tht *** semicolon srry thread closed!

[Anarki]

On Oct 1, 1:31*pm, Ian Collins <[e-mail]:

Anarki wrote:

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()
{
* *char arr[10] = "Qualifiers"

Missing semicolon.

--
Ian Collins.

Thx to Ian Collins and MisterE

[Joachim Schmitz]

Anarki wrote:

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()

Better: int main(void)

{
char arr[10] = "Qualifiers"

Others told you about the missig ; here, but as yet nobody mentioned that
arr[10] is too short to hold the string "Qualifiers". You need arr[11] to
have enough space for the terminating '\0'.
You could automate that by using arr[] = "Qualifiers"; but then may have to
adjust your for loop.

char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

i am using cygwin in window xp SP2, my gcc version is 3.4.4

how do i compile the above program?

i tried using this

gcc -c -std=c99 restrict.c

but i get an error like this

restrict.c: In function 'main':
restrict.c:6: error: parse error before "char"

can someone help me how to compile this program??

Bye, Jojo

[James Kuyper]

Joachim Schmitz wrote:

Anarki wrote:

>The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()

Better: int main(void)

>{
char arr[10] = "Qualifiers"

Others told you about the missig ; here, but as yet nobody mentioned that
arr[10] is too short to hold the string "Qualifiers". You need arr[11] to
have enough space for the terminating '\0'.

It's legal to use a string literal to initialize an array that is not
big enough to hold the terminating '\0' (6.7.8p14). He does not use arr
in any way that requires it, so why should he provide space to store it?

You could automate that by using arr[] = "Qualifiers"; but then may have to
adjust your for loop.

>char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

[Joachim Schmitz]

James Kuyper wrote:

Joachim Schmitz wrote:

>Anarki wrote:

<snip>

>>char arr[10] = "Qualifiers"

Others told you about the missig ; here, but as yet nobody mentioned
that arr[10] is too short to hold the string "Qualifiers". You need
arr[11] to have enough space for the terminating '\0'.

It's legal to use a string literal to initialize an array that is not
big enough to hold the terminating '\0' (6.7.8p14). He does not use
arr in any way that requires it, so why should he provide space to
store it?

It may be legal to do so and he might not use it in this program, but it is
a common enough mistake to forget to allocate space for the terminating '\0'
to make it worthwhile being mentioned, wouldn't you agree?

Bye, Jojo

[James Kuyper]

Joachim Schmitz wrote:

James Kuyper wrote:

>Joachim Schmitz wrote:

>>Anarki wrote:

<snip>

>>>char arr[10] = "Qualifiers"
Others told you about the missig ; here, but as yet nobody mentioned
that arr[10] is too short to hold the string "Qualifiers". You need
arr[11] to have enough space for the terminating '\0'.

It's legal to use a string literal to initialize an array that is not
big enough to hold the terminating '\0' (6.7.8p14). He does not use
arr in any way that requires it, so why should he provide space to
store it?

It may be legal to do so and he might not use it in this program, but it is
a common enough mistake to forget to allocate space for the terminating '\0'
to make it worthwhile being mentioned, wouldn't you agree?

Perhaps, but the mention should have been written in a way that
acknowledges the possibility that the knew precisely what he was doing.
The way you wrote it left the impression that his code was unambiguously
wrong. You said "too short" and "you need", when it was precisely big
enough for everything he was going to do with it, and he therefore did
not need to make the change that you suggested.

[Joachim Schmitz]

James Kuyper wrote:

Joachim Schmitz wrote:

>James Kuyper wrote:

>>Joachim Schmitz wrote:
Anarki wrote:

<snip>

>>>>char arr[10] = "Qualifiers"
Others told you about the missig ; here, but as yet nobody
mentioned that arr[10] is too short to hold the string
"Qualifiers". You need arr[11] to have enough space for the
terminating '\0'.
It's legal to use a string literal to initialize an array that is
not big enough to hold the terminating '\0' (6.7.8p14). He does not
use arr in any way that requires it, so why should he provide space
to store it?

It may be legal to do so and he might not use it in this program,
but it is a common enough mistake to forget to allocate space for
the terminating '\0' to make it worthwhile being mentioned, wouldn't
you agree?

Perhaps, but the mention should have been written in a way that
acknowledges the possibility that the knew precisely what he was
doing. The way you wrote it left the impression that his code was
unambiguously wrong. You said "too short" and "you need", when it was
precisely big enough for everything he was going to do with it, and
he therefore did not need to make the change that you suggested.

OK, point taken.

Bye, Jojo

[August Karlstrom]

Anarki wrote:

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()
{
char arr[10] = "Qualifiers"
char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

i am using cygwin in window xp SP2, my gcc version is 3.4.4

how do i compile the above program?

i tried using this

gcc -c -std=c99 restrict.c

but i get an error like this

restrict.c: In function 'main':
restrict.c:6: error: parse error before "char"

can someone help me how to compile this program??

I would write the program as

#include <stdio.h>

int main(void)
{
char arr[] = "Qualifiers";
int i;

for (i = 0; arr[i] != '\0'; i++) {
printf("%c", arr[i]);
}
printf("\n");

return 0;
}

or simply

#include <stdio.h>

int main(void)
{
puts("Qualifiers");

return 0;
}
August

[Martin Ambuhl]

Anarki wrote:

char arr[10] = "Qualifiers"

^^^
missing ';', creating an error before

char * restrict p = arr;

^^^^
'char'. This is what your diagnostic mesage says:

restrict.c:6: error: parse error before "char"

can someone help me how to compile this program??

Add the semi-colon. No magic invocation of the compiler will make your
errors disappear.

[Martin Ambuhl]

Joachim Schmitz wrote:

Anarki wrote:

>The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()

Better: int main(void)

>{
char arr[10] = "Qualifiers"

Others told you about the missig ; here, but as yet nobody mentioned that
arr[10] is too short to hold the string "Qualifiers".

It is not too short for this initialization. It is true thar arr is an
array of characters and not a string, but the program in no way assumes
a string.

You need arr[11] to
have enough space for the terminating '\0'.

Only if he needs a string, which he does not.

You could automate that by using arr[] = "Qualifiers"; but then may have to
adjust your for loop.

There is nothing in the loop needing adjusting.

>char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character, instead of an
imaginary "problem".

[Joachim Schmitz]

Martin Ambuhl wrote:

Joachim Schmitz wrote:

>Anarki wrote:

>>The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()

Better: int main(void)

>>{
char arr[10] = "Qualifiers"

Others told you about the missig ; here, but as yet nobody mentioned
that arr[10] is too short to hold the string "Qualifiers".

It is not too short for this initialization. It is true thar arr is
an array of characters and not a string, but the program in no way
assumes a string.

>You need arr[11] to
have enough space for the terminating '\0'.

Only if he needs a string, which he does not.

And all that has been said some 4 hours ago, by James Kuyper...

>You could automate that by using arr[] = "Qualifiers"; but then may
have to adjust your for loop.

There is nothing in the loop needing adjusting.

Not in this particular case, but I said 'may', didn't I?

>>char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

If you wanted to pick nits,

I did not, but apparently you do

you should have pointed out the failure to
end the last line of output with an end-of-line character, instead of
an imaginary "problem".

This problem wasn't the OP's, but it certainly isn't imaginary.

Bye, Jojo

[Keith Thompson]

August Karlstrom <fu********@gmail.comwrites:

Anarki wrote:

>The following is the program i am trying to compile
//restrict.c
#include <stdio.h>
int main()
{
char arr[10] = "Qualifiers"
char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}
i am using cygwin in window xp SP2, my gcc version is 3.4.4
how do i compile the above program?
i tried using this
gcc -c -std=c99 restrict.c
but i get an error like this
restrict.c: In function 'main':
restrict.c:6: error: parse error before "char"
can someone help me how to compile this program??

I would write the program as

#include <stdio.h>

int main(void)
{
char arr[] = "Qualifiers";
int i;

for (i = 0; arr[i] != '\0'; i++) {
printf("%c", arr[i]);
}
printf("\n");

return 0;
}

or simply

#include <stdio.h>

int main(void)
{
puts("Qualifiers");

return 0;
}

I wouldn't write a program for that at all; I'd type "echo Qualifiers"
at my shell prompt.

Any program that illustrates some particular point that's been trimmed
down enough to post here can (probably) be transformed into a program
with equivalent behavior that utterly fails to illustrate the original
point. Which misses the point.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Keith Thompson said:

August Karlstrom <fu********@gmail.comwrites:

<snip>

>#include <stdio.h>

int main(void)
{
puts("Qualifiers");

return 0;
}

I wouldn't write a program for that at all; I'd type "echo Qualifiers"
at my shell prompt.

I wouldn't even do that, since there's no point.

Any program that illustrates some particular point that's been trimmed
down enough to post here can (probably) be transformed into a program
with equivalent behavior that utterly fails to illustrate the original
point. Which misses the point.

Right - the *output* of an exercise/illustrative program is rarely the
point of the exercise.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[August Karlstrom]

Keith Thompson wrote:

August Karlstrom <fu********@gmail.comwrites:

[...]

>I would write the program as

#include <stdio.h>

int main(void)
{
char arr[] = "Qualifiers";
int i;

for (i = 0; arr[i] != '\0'; i++) {
printf("%c", arr[i]);
}
printf("\n");

return 0;
}

or simply

#include <stdio.h>

int main(void)
{
puts("Qualifiers");

return 0;
}

I wouldn't write a program for that at all; I'd type "echo Qualifiers"
at my shell prompt.

Of course, the second version was more of a joke. My point was to
illustrate the automatic calculation of the needed array length and the
comparison to the sentinel '\0' in the loop.

Any program that illustrates some particular point that's been trimmed
down enough to post here can (probably) be transformed into a program
with equivalent behavior that utterly fails to illustrate the original
point. Which misses the point.

Not if it's part of a real program that tries to achieve something. Even
when I ask about more theoretical issues I usually try to make examples
"minimal".
August

[Peter Nilsson]

Anarki <[e-mail]:

>
//restrict.c

All this illustrates is a declaration using restrict.
It doesn't show any practical value stemming therefrom.

#include <stdio.h>
int main()
{
* * * * char arr[10] = "Qualifiers"
* * * * char * restrict p = arr;
* * * * int i = 0;
* * * * for(; i < 10; ++i)
* * * * printf("%c", arr[i]);
* * * * return 0;
}

You now know about the missing semicolon, but as an
asside it's worth mentioning that the loop can be
replaced with printf, e.g.

printf("%.*s\n", 10, arr);

--
Peter

[Bartc]

"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:gc**********@registered.motzarella.org...

Anarki wrote:

>char arr[10] = "Qualifiers"

^^^
missing ';', creating an error before

>char * restrict p = arr;

^^^^
'char'. This is what your diagnostic mesage says:

>restrict.c:6: error: parse error before "char"

>can someone help me how to compile this program??

Add the semi-colon. No magic invocation of the compiler will make your
errors disappear.

A mention of 'missing semicolon' from the compiler could help though.

Imagine a few dozen lines of comments and/or conditional code between line 5
and 6.

--
bartc

[arnuld]

On Wed, 01 Oct 2008 21:31:11 +1300, Ian Collins wrote:

>Anarki wrote:
The following is the program i am trying to compile

>//restrict.c
#include <stdio.h>
int main()
{
char arr[10] = "Qualifiers"

Missing semicolon.

I rewrote his program just like "August" wrote:

#include <stdio.h>
int main(void)
{
char arr[] = "Qualifiers";
char* restrict p = arr;
int i;
for( i = 0; arr[i]; ++i)
{
printf("%c", arr[i]);
}

printf("\n");

return 0;
}

================= COMPILE ===================

[arnuld@dune ztest]$ gcc -std=c99 -pedantic -Wall -Wextra restrict.c
restrict.c: In function `main':
restrict.c:7: warning: unused variable `p'
[arnuld@dune ztest]$

[arnuld@dune ztest]$ gcc -ansi -pedantic -Wall -Wextra restrict.c
restrict.c: In function `main':
restrict.c:7: warning: ISO C forbids nested functions
restrict.c:7: error: syntax error before "p"
[arnuld@dune ztest]$

Then I wonder at the compilation warning of -std=c99. Why OP used p at
all?

2nd, -ansi flag emits warning of nested functions. I don't get it.



--
www.lispmachine.wordpress.com
my email is @ the above blog.
Gooogle Groups is Blocked. Reason: Excessive Spamming

[Ian Collins]

arnuld wrote:

>
#include <stdio.h>
int main(void)
{
char arr[] = "Qualifiers";
char* restrict p = arr;
int i;
for( i = 0; arr[i]; ++i)
{
printf("%c", arr[i]);
}

printf("\n");

return 0;
}

================= COMPILE ===================

[arnuld@dune ztest]$ gcc -std=c99 -pedantic -Wall -Wextra restrict.c
restrict.c: In function `main':
restrict.c:7: warning: unused variable `p'
[arnuld@dune ztest]$

[arnuld@dune ztest]$ gcc -ansi -pedantic -Wall -Wextra restrict.c
restrict.c: In function `main':
restrict.c:7: warning: ISO C forbids nested functions
restrict.c:7: error: syntax error before "p"
[arnuld@dune ztest]$

2nd, -ansi flag emits warning of nested functions. I don't get it.

It's probably spitting the dummy over "restrict" which is a C99 keyword.

--
Ian Collins.

[Keith Thompson]

arnuld <su*****@invalid.addresswrites:
[...]

#include <stdio.h>
int main(void)
{
char arr[] = "Qualifiers";
char* restrict p = arr;
int i;
for( i = 0; arr[i]; ++i)
{
printf("%c", arr[i]);
}

printf("\n");

return 0;
}

[...]

>
[arnuld@dune ztest]$ gcc -ansi -pedantic -Wall -Wextra restrict.c
restrict.c: In function `main':
restrict.c:7: warning: ISO C forbids nested functions
restrict.c:7: error: syntax error before "p"
[arnuld@dune ztest]$

[...]

>
2nd, -ansi flag emits warning of nested functions. I don't get it.

"restrict" is not a keyword in C90. gcc interpreted it as an
identifier. Apparently it confused the parser so much that thought it
was seeing a nested function. Any error messages you see after the
first syntax error message should be taken with a grain of salt.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Nick Keighley]

On 1 Oct, 16:13, Martin Ambuhl <[e-mail]:

Joachim Schmitz wrote:

Anarki wrote:

The following is the program i am trying to compile

//restrict.c
#include <stdio.h>
int main()

<snip>

{
char arr[10] = "Qualifiers"

<snip>

char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr[i]);
return 0;
}

If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character,

doesn't the fact that all stream get flushed at program termination
fix this problem?

instead of an imaginary "problem".

--
Nick Keighley

Anybody who still believes in the media must have been in a coma
for the past 30 years."
- Robert Anton Wilson

[Martin Ambuhl]

Nick Keighley wrote:

On 1 Oct, 16:13, Martin Ambuhl <[e-mail]:

>If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character,

doesn't the fact that all stream get flushed at program termination
fix this problem?

No. And we have had to go over this countless times with people who
made such unwarranted, baseless assumptions. The fact that this is
specifically addressed in the standard doesn't seem to bother them at all.

[James Kuyper]

Bartc wrote:

>
"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:gc**********@registered.motzarella.org...

>Anarki wrote:

>>char arr[10] = "Qualifiers"

^^^
missing ';', creating an error before

>>char * restrict p = arr;

^^^^
'char'. This is what your diagnostic mesage says:

>>restrict.c:6: error: parse error before "char"

>>can someone help me how to compile this program??

Add the semi-colon. No magic invocation of the compiler will make
your errors disappear.

A mention of 'missing semicolon' from the compiler could help though.

It would help, but it's usually not easy for the compiler to uniquely
identify what mistake was made. The compiler knows that the grammar does
not permit the keyword 'char' at that location, but it can't know for
sure what the actual mistake was.

If the 'char' token is assumed to be correct, and there's only a single
missing token, then I think that ';' might be the only token it could be
(though I wouldn't be surprised to learn that I'd missed other
possibilities).

However, there also might be an extra token, or an incorrect token, or
any of several more complicated problems, and the problem might have
occurred long before the point where it rendered further parsing
impossible. I can understand why a compiler might not want to put the
effort into trying to identify the single most plausible explanation for
a parsing error.

[Nick Keighley]

On 2 Oct, 09:10, Martin Ambuhl <[e-mail]:

Nick Keighley wrote:

On 1 Oct, 16:13, Martin Ambuhl <[e-mail]:

If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character,

doesn't the fact that all stream get flushed at program termination
fix this problem?

No. And we have had to go over this countless times with people who
made such unwarranted, baseless assumptions.

seemed a pretty reasonable question to me. This is the second
snotty response I've had today is everyone on too much coffee?

The fact that this is
specifically addressed in the standard doesn't seem to bother them at all.

whereabouts in the standard? And, yes, I looked before I asked.
--
Nick Keighley

"...the characters are legible and well-known, but when put
together they do not say anything that leaves an imprint
on the modern mind."

"Like instructions for programming a VCR."
(Neal Stephenson "Snow Crash")

[James Kuyper]

Nick Keighley wrote:

On 2 Oct, 09:10, Martin Ambuhl <[e-mail]:

>Nick Keighley wrote:

>>On 1 Oct, 16:13, Martin Ambuhl <[e-mail]:

>>>If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character,
doesn't the fact that all stream get flushed at program termination
fix this problem?

No. And we have had to go over this countless times with people who
made such unwarranted, baseless assumptions.

seemed a pretty reasonable question to me. This is the second
snotty response I've had today is everyone on too much coffee?

>The fact that this is
specifically addressed in the standard doesn't seem to bother them at all.

whereabouts in the standard? And, yes, I looked before I asked.

7.19.2p2: "Whether the last line requires a terminating new-line
character is implementation-defined."

Note that while the requirement is implementation-defined, the behavior
when the requirement is not met is not described by the standard, and is
therefore implicitly undefined. Whether or not the file was flushed is
irrelevant to that conclusion.

While the condition that makes the behavior undefined was specifically
addressed, the fact that the behavior is undefined is not - it is
implicit, not explicit, and I therefore think that Martin was
overstating his case.

[Nick Keighley]

On 3 Oct, 13:59, James Kuyper <[e-mail]:

Nick Keighley wrote:

On 2 Oct, 09:10, Martin Ambuhl <[e-mail]:

Nick Keighley wrote:
On 1 Oct, 16:13, Martin Ambuhl <[e-mail]:

>>If you wanted to pick nits, you should have pointed out the failure to
end the last line of output with an end-of-line character,

doesn't the fact that all stream get flushed at program termination
fix this problem?

No. *And we have had to go over this countless times with people who
made such unwarranted, baseless assumptions.

seemed a pretty reasonable question to me. This is the second
snotty response I've had today is everyone on too much coffee?

The fact that this is
specifically addressed in the standard doesn't seem to bother them at all.

whereabouts in the standard? And, yes, I looked before I asked.

7.19.2p2: "Whether the last line requires a terminating new-line
character is implementation-defined."

I found that and thought "implementation defined"

Note that while the requirement is implementation-defined, the behavior
when the requirement is not met is not described by the standard, and is
therefore implicitly undefined.

I thought the standard was supposed to list the possible
implementation defined behaviours? Though with a seriously derranged
file system this might not be easy.

Whether or not the file was flushed is
irrelevant to that conclusion.

While the condition that makes the behavior undefined was specifically
addressed, the fact that the behavior is undefined is not - it is
implicit, not explicit, and I therefore think that Martin was
overstating his case

and yet when we see code like this (usual caveats for untested code)

#include <stdio.h>
int main (void)
{
char buffer[32];
printf ("prompt>");
fgets (buffer, 32, stdin);
printf (buffer);
return 0;
}

we all cry (well some do) "fflush(stdout) or you may not see the
prompt!". Which implies fflush() can, in this situation, cause the
ouput
to appear (the standard is more cagey here it says something about
"delivering it to the host environment").

But in this code:

#include <stdio.h>
int main (void)
{
char buffer[32];
printf ("prompt>");
fflush (stdout);
return 0;
}

does the prompt appear? And if so, why does this not cause
the prompt to appear?

#include <stdio.h>
int main (void)
{
char buffer[32];
printf ("prompt>");
return 0;
}

There *is* an implicit fflush() of all output streams here?

Is it that fflush() merely makes it *more likely* the output
will appear? I've used this idiom and had assumed it was
DS 9000 proof.
--
Nick Keighley

"Morality is a spandrel of the game theoretic implications of the
society of symbol users.
We impute moral worth to the non-social world on that basis."

[Kenny McCormack]

In article <6d**********************************@j22g2000hsf. googlegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:
....

>seemed a pretty reasonable question to me. This is the second
snotty response I've had today is everyone on too much coffee?

This is CLC. You've been around long enough to understand what we do here.

[vippstar]

On Oct 3, 5:38 pm, Nick Keighley <[e-mail]>
wrote:
<snip>

>
and yet when we see code like this (usual caveats for untested code)

#include <stdio.h>
int main (void)
{
char buffer[32];
printf ("prompt>");
fgets (buffer, 32, stdin);
printf (buffer);
return 0;

}

we all cry (well some do) "fflush(stdout) or you may not see the
prompt!". Which implies fflush() can, in this situation, cause the
ouput
to appear (the standard is more cagey here it says something about
"delivering it to the host environment").

Not exactly. fflush() just "writes" the buffer to the stream. Like
what fwrite() can do with an unbuffered stream.
Ie, nothing. fflush() can do just nothing other than clear the buffer,
or just return EOF...

fflushing before the fgets is just a guarantee that the writing will
be done before calling fgets.
What writing that is... doesn't matter.

But in this code:

#include <stdio.h>
int main (void)
{
char buffer[32];
printf ("prompt>");
fflush (stdout);
return 0;

}

does the prompt appear? And if so, why does this not cause
the prompt to appear?

I'm also curious for this. If it's still implementation defined
behavior, then the previous code can also be implementation defined
behavior (in case fgets reads an incomplete line, because no newline
will be printed)

[Keith Thompson]

Nick Keighley <ni******************@hotmail.comwrites:

On 3 Oct, 13:59, James Kuyper <[e-mail]:

[...]

>7.19.2p2: "Whether the last line requires a terminating new-line
character is implementation-defined."

I found that and thought "implementation defined"

>Note that while the requirement is implementation-defined, the behavior
when the requirement is not met is not described by the standard, and is
therefore implicitly undefined.

I thought the standard was supposed to list the possible
implementation defined behaviours? Though with a seriously derranged
file system this might not be easy.

It's not the behavior that's implementation-defined, it's the choice
of whether or not the terminating new-line is required. If it's not
required, then the behavior is well-defined; characters written to a
text stream are sent to the stream, whether there's a terminating
new-line or not. If it *is* required, the behavior of a program that
doesn't print the terminating new-line is undefined (simply because
the standard doesn't define it); it could do anything. Plausible
behaviors, among the infinitely many that are allowed:

The last unterminated line doesn't appear in the output file at
all, because writing '\n' is what causes physical output to occur.

The output file could be corrupted and not accessible as a text
file, on a system that distinguishes strongly between text and
binary files.

The output could be written, just as if the new-line weren't
required; the implementers just chose not to guarantee this
behavior.

[...]

Is it that fflush() merely makes it *more likely* the output
will appear? I've used this idiom and had assumed it was
DS 9000 proof.

All output streams with unwritten data are flushed on normal program
termination, so an explicit fflush() just before program termination
doesn't make the output any more likely to appear.

Although if the implementation requires a terminating new-line, and
you haven't written one, then one of the infinitely many possible
behaviors is that fflush() could have some real effect. (On the
DS 9000, it probably *prevents* the output from appearing.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"