can someone help me how to compile this program??

[Keith Thompson]

#include <stdio.h>


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


for( i = 0; arr; ++i)
{
printf("%c", arr);
}

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.

 

[Nick Keighley]

Anarki wrote:

{
char arr[10] = "Qualifiers"

char * restrict p = arr;
int i = 0;
for(; i < 10; ++i)
printf("%c", arr);
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]

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]

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]

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]

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


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]

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]

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 <[email protected]>
wrote:

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]

I found that and thought "implementation defined"


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.)