FILE argument to a function

[fermineutron]

I seem to run into a funny problem,

basially i need to call a funcyon ReadGeometry and the only parameter
that i need to pass to that function is a file pointer, so my funtion
prototype looks like this:

void ReadGeometry(FILE *ff1)

Now, my compiler gives a compile time error stating that "FILE can not
start a parameter declaration"

Probably the easiest way to fix this would be to just pass a constant
char as the first argument, but that just seems wrong to pass to a
function a parameter that i dont need.

Any ideas?

Also is it just my copiler specific problem or is it in C standard that
argument list can not start with FILE type?

[Eric Sosman]

fermineutron wrote:

I seem to run into a funny problem,

basially i need to call a funcyon ReadGeometry and the only parameter
that i need to pass to that function is a file pointer, so my funtion
prototype looks like this:

void ReadGeometry(FILE *ff1)

Now, my compiler gives a compile time error stating that "FILE can not
start a parameter declaration"

You probably forgot to #include <stdio.hbefore
declaring the function.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Jordan Abel]

2006-11-08 <11**********************@b28g2000cwb.googlegroups .com>,
fermineutron wrote:

I seem to run into a funny problem,

basially i need to call a funcyon ReadGeometry and the only parameter
that i need to pass to that function is a file pointer, so my funtion
prototype looks like this:

void ReadGeometry(FILE *ff1)

Now, my compiler gives a compile time error stating that "FILE can not
start a parameter declaration"

Did you include stdio.h?

>
Probably the easiest way to fix this would be to just pass a constant
char as the first argument, but that just seems wrong to pass to a
function a parameter that i dont need.

It wouldn't help. a "parameter declaration" is the declaration of
a single argument - i.e. int x(int y, int z) contains two parameter
declarations.

Any ideas?

Also is it just my copiler specific problem or is it in C standard that
argument list can not start with FILE type?

If you included stdio.h, and you get that error, your compiler is wrong.

[fermineutron]

Eric Sosman wrote:

You probably forgot to #include <stdio.hbefore
declaring the function.

I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in
main.c
ReadGeometry is prototyped in the NTC.h file.

But it generates the compile error i described above. If i do not
include stdio.h a totaly different error is geerated.

Another question about header files,
I think the following is correct, but i'd appreciate is someone
veryfied it:
if i have 2 or more C files and i have a header file which contains all
of the globals and includes, i have to separately #include "MyHeader.h"
into each of my C files. Is this correct?

[Keith Thompson]

"fermineutron" <fr**********@yahoo.comwrites:

Eric Sosman wrote:

> You probably forgot to #include <stdio.hbefore
declaring the function.

I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in
main.c
ReadGeometry is prototyped in the NTC.h file.

But it generates the compile error i described above. If i do not
include stdio.h a totaly different error is geerated.

Show us some actual code that exhibits the errors.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[fermineutron]

I tried compiling using lcc-win32, it worked.

I guess the other compiler i used is too old, Borland C++ 5.02 is the
one which errors.

Ill just use lcc from now on for this project.

Thanks every body.

Sorry for such a meaningless post.

[Keith Thompson]

"fermineutron" <fr**********@yahoo.comwrites:

I tried compiling using lcc-win32, it worked.

I guess the other compiler i used is too old, Borland C++ 5.02 is the
one which errors.

Ill just use lcc from now on for this project.

Thanks every body.

Sorry for such a meaningless post.

For the Nth time, for some very large value of N, *please* show some
context when you post a followup.

Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

Try compiling the following with your Borland compiler:

void func(int x);

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

fermineutron said:

>
I tried compiling using lcc-win32, it worked.

If it didn't work with a C compiler, but did work with lcc-win32, then your
code is not C code but lcc-win32 code, in which case I suggest you ask
future questions about your code in an lcc-win32 newsgroup rather than
here.

I guess the other compiler i used is too old, Borland C++ 5.02 is the
one which errors.

Borland's C compiler - and yes, that specific version, works just fine on
correct parameter declaration, and rightly rejects those that are not
correct in form.

Ill just use lcc from now on for this project.

When even lcc rejects your code, which compiler will you then move to?
Wouldn't it be easier to learn C than to keep moving from compiler to
compiler as each of them in turn discovers gaps in your knowledge?

Thanks every body.

Sorry for such a meaningless post.

That's okay - we're getting used to it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Richard Heathfield]

Keith Thompson said:

<snip>

Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

It is not, it does not, it is not, and it does, in that order. In other
words, the problem here is not with the compiler, but with the source code
being supplied to it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Serve Laurijssen]

"fermineutron" <fr**********@yahoo.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

void ReadGeometry(FILE *ff1)
Now, my compiler gives a compile time error stating that "FILE can not
start a parameter declaration"

only thing I can think of without seeing the real code is you forgot to put
a semicolon after the prototype declaration.
Although that doesnt compile in lccwin32 either and you said it does in that
compiler

Probably the easiest way to fix this would be to just pass a constant
char as the first argument, but that just seems wrong to pass to a
function a parameter that i dont need.

Any ideas?

Also is it just my copiler specific problem or is it in C standard that
argument list can not start with FILE type?

[Jordan Abel]

2006-11-08 <Ss******************************@bt.com>,
Richard Heathfield wrote:

Keith Thompson said:

<snip>

>Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

It is not, it does not, it is not, and it does, in that order.

?

In other words, the problem here is not with the compiler, but with
the source code being supplied to it.

We haven't seen the source code.

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

[Kenny McCormack]

In article <sl******************@rlaptop.random.yi.org>,
Jordan Abel <ra*******@gmail.comwrote:
....

>We haven't seen the source code.

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

For several responses now, you guys have been whining at the OP to
provide code - with nothing to show for it. Obviously, the OP's
situation is complicated and doesn't resolve to something postable.

So, what you should do is post an example that disproves his basic
assertion, and let him work out why your example works and his doesn't.

Something like (untested, and no doubt nit-pickable for any of a
thousand reasons, but so it goes - have a ball and all that):

#include <stdio.h>
void myfun(FILE *foo) { fprintf(foo,"hello, world\n"); }

int main(void) { myfun(stdout);return 0; }

[Richard Heathfield]

Jordan Abel said:

2006-11-08 <Ss******************************@bt.com>,
Richard Heathfield wrote:

>Keith Thompson said:

<snip>

>>Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

It is not, it does not, it is not, and it does, in that order.

?

Borland C++ 5.02 (in C mode) is not so buggy as to reject such a simple
declaration.

It is not so old that it does not support prototypes.

It does support prototypes.

Therefore, the bug is not in the source code that has been shown, but rather
in the source code that has not been shown.

>In other words, the problem here is not with the compiler, but with
the source code being supplied to it.

We haven't seen the source code.

Very true, and that's why we can't explain to the OP what is wrong with it.

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

Let's wait until we see the full source, shall we?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Jordan Abel]

2006-11-08 <z9******************************@bt.com>,
Richard Heathfield wrote:

Jordan Abel said:

>2006-11-08 <Ss******************************@bt.com>,
Richard Heathfield wrote:

>>Keith Thompson said:

<snip>

Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

It is not, it does not, it is not, and it does, in that order.

?

Borland C++ 5.02 (in C mode) is not so buggy as to reject such a simple
declaration.

It is not so old that it does not support prototypes.

It does support prototypes.

Therefore, the bug is not in the source code that has been shown, but rather
in the source code that has not been shown.

Or there's something wrong with his installation of the compiler.

What confuses me is, what could that error possibly mean, other than it
believes that you cannot pass a FILE * to a function, or that it
believes that you cannot (and that you are trying to) pass a FILE to
a function[1]. But compilers have had more confusing errors before.

To the original poster: Try to make a smaller program that has the same
problem, if you can't or won't post the whole thing, and then post the
source code for that.

[1]I believe the last time we had this discussion, the consensus is that
it's technically legal but not useful, since FILE is, unaccountably,
required to be a complete type.

#include <stdio.h>
FILE s;
int f(FILE x) { return 0; }
int main() { return f(s); }

[Kenneth Brody]

Jordan Abel wrote:

>
2006-11-08 <Ss******************************@bt.com>,
Richard Heathfield wrote:

Keith Thompson said:

<snip>

Here's what you wrote upthread:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I

[...]

We haven't seen the source code.

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

Imagine a C compiler that doesn't support prototypes, nor allow
parameters to be typed within the parens.

In other words, one that requires K&R style:

void ReadGeometry(ffl) FILE *ffl;
{
...function here ...
}

It hits "FILE" as the first token in the parameter list, knows
that FILE is a type, and chokes because it expects a parameter
name only.

Of course, all this is just conjecture, as we don't have any
actual code to look at.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Tobin]

In article <11**********************@b28g2000cwb.googlegroups .com>,
fermineutron <fr**********@yahoo.comwrote:

>Now, my compiler gives a compile time error stating that "FILE can not
start a parameter declaration"

Google for "cannot start a parameter declaration" (with the quotes).
The first result appears to be relevant.

In fact, any time you get an error message you don't understand,
try searching the web for it. Almost certainly someone else has
been in the same situation before.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

Jordan Abel wrote:

>

.... snip ...

>
[1]I believe the last time we had this discussion, the consensus
is that it's technically legal but not useful, since FILE is,
unaccountably, required to be a complete type.

Anyone who takes advantage of that is an idiot. The complete type
is needed to allow macro implementations of getc and putc, which
can have a significant speed advantage.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Jordan Abel]

2006-11-08 <45***************@yahoo.com>,
CBFalconer wrote:

Jordan Abel wrote:

>>

... snip ...

>>
[1]I believe the last time we had this discussion, the consensus
is that it's technically legal but not useful, since FILE is,
unaccountably, required to be a complete type.

Anyone who takes advantage of that is an idiot. The complete type
is needed to allow macro implementations of getc and putc, which
can have a significant speed advantage.

But that is not a reason for the standard to require it to be a complete
type.

The macro getc could be #define getc(f) fgetc(f). Or, for that matter,
it's not required to be a macro.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Jordan Abel wrote:

>>

... snip ...

>>
[1]I believe the last time we had this discussion, the consensus
is that it's technically legal but not useful, since FILE is,
unaccountably, required to be a complete type.

Anyone who takes advantage of that is an idiot.

Agreed. Well, I agree that taking advantage of it in user code is
almost always a bad idea.

The complete type
is needed to allow macro implementations of getc and putc, which
can have a significant speed advantage.

That argues for *allowing* FILE to be a complete type; it doesn't
justify requiring it for all implementations. For that matter, if
FILE were a typedef for void, making FILE* equivalent to void*, the
getc and putc macros could still convert the argument to a pointer to
some implementation-defined type and do the same optimizations.

I think the reason FILE is required to be a complete type is just
historical inertia.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

2006-11-09 <ln************@nuthaus.mib.org>,
Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Jordan Abel wrote:

>>>

... snip ...

>>>
[1]I believe the last time we had this discussion, the consensus
is that it's technically legal but not useful, since FILE is,
unaccountably, required to be a complete type.

Anyone who takes advantage of that is an idiot.

Agreed. Well, I agree that taking advantage of it in user code is
almost always a bad idea.

> The complete type
is needed to allow macro implementations of getc and putc, which
can have a significant speed advantage.

That argues for *allowing* FILE to be a complete type; it doesn't
justify requiring it for all implementations. For that matter, if
FILE were a typedef for void, making FILE* equivalent to void*, the
getc and putc macros could still convert the argument to a pointer to
some implementation-defined type and do the same optimizations.

I think the reason FILE is required to be a complete type is just
historical inertia.

Right. Basically, although the code I posted upthread is valid, the
standard provides no way to legally dereference a FILE * for any purpose
other than that sort of sophistry.

Hmm. Does the standard require that implementations allow you to do
this?

FILE a = *stdout;
fputc('x',&a);

[Richard Heathfield]

Jordan Abel said:

<snip>

Hmm. Does the standard require that implementations allow you to do
this?

FILE a = *stdout;
fputc('x',&a);

No. From 4.9.3 Files:

"The address of the FILE object used to control a stream may be
significant; a copy of a FILE object may not necessarily serve in
place of the original."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[CBFalconer]

Jordan Abel wrote:

CBFalconer wrote:

>Jordan Abel wrote:

>>>

... snip ...

>>>
[1]I believe the last time we had this discussion, the consensus
is that it's technically legal but not useful, since FILE is,
unaccountably, required to be a complete type.

Anyone who takes advantage of that is an idiot. The complete type
is needed to allow macro implementations of getc and putc, which
can have a significant speed advantage.

But that is not a reason for the standard to require it to be a
complete type.

The macro getc could be #define getc(f) fgetc(f). Or, for that
matter, it's not required to be a macro.

Yes it is (a reason, not required) in order for a getc/putc macro
to directly access the file buffers. This can avoid a lot of
overhead.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Bos]

Kenneth Brody <ke******@spamcop.netwrote:

Jordan Abel wrote:

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

Imagine a C compiler that doesn't support prototypes, nor allow
parameters to be typed within the parens.

In other words, one that requires K&R style:

void ReadGeometry(ffl) FILE *ffl;

That wouldn't be called Borland C++, then, wouldn't it? In fact, it
couldn't even be called a conforming implementation, because the notion
of a conforming implementation is part of the Standard, and TTBOMK not
of K&R.

Richard

[goose]

fermineutron wrote:

Eric Sosman wrote:

You probably forgot to #include <stdio.hbefore
declaring the function.

I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in
main.c
ReadGeometry is prototyped in the NTC.h file.

I believe you misunderstood Eric; He did not mean "include
stdio.h in random places in your project". He meant "include
stdio.h in the file where 'FILE' is used, namely ReadGeometry.c".

But it generates the compile error i described above. If i do not
include stdio.h a totaly different error is geerated.

That error is probably being generated in main.c, right?

>
Another question about header files,
I think the following is correct, but i'd appreciate is someone
veryfied it:
if i have 2 or more C files and i have a header file which contains all
of the globals and includes, i have to separately #include "MyHeader.h"
into each of my C files. Is this correct?

Tell me, which C book are you using? I'd recommend
"The C Programming Language" 2nd ed, K&R. In addition,
I suggest you read http://c-faq.com/strangeprob/unclosed.html
and read the linked questions as well (2.18, 10.9, 11.29a).

Lastly, try http://c-faq.com/ for any other seemingly
silly problems - your problems are doubtless not unique
to you and you alone and has probably already been
answered to the satisfaction of expert C programmers
in the FAQ.

Switching to a different compiler just to make your
errors less glaring is an oft-tried and (eventually)
pointless exercise. Your problem will resurface at the
least convenient time.

goose,
does your newsreader not spellcheck?

[Richard Heathfield]

goose said:

fermineutron wrote:

>>
Another question about header files,
I think the following is correct, but i'd appreciate is someone
veryfied it:
if i have 2 or more C files and i have a header file which contains all
of the globals and includes, i have to separately #include "MyHeader.h"
into each of my C files. Is this correct?

Tell me, which C book are you using?

Last I heard, he was a Schildt user.

does your newsreader not spellcheck?

It never occurred to me to ask mine. All my spelling mistake are belong to
me!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Kenneth Brody]

Richard Bos wrote:

>
Kenneth Brody <ke******@spamcop.netwrote:

Jordan Abel wrote:

I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.

Imagine a C compiler that doesn't support prototypes, nor allow
parameters to be typed within the parens.

In other words, one that requires K&R style:

void ReadGeometry(ffl) FILE *ffl;

That wouldn't be called Borland C++, then, wouldn't it? In fact, it
couldn't even be called a conforming implementation, because the notion
of a conforming implementation is part of the Standard, and TTBOMK not
of K&R.

Well, the OP did say it was an old version. I'm not familiar enough
with which Borland was released when. (Even though I did use Borland's
Turbo C years ago.)

However, you are correct that a "conforming implementation," in the
sense of "ANSI C", has to accept such prototypes. I have used many
C compilers over the years which did not accept them. I've even
used one (from HP-UX) that gave an error along the lines of "ANSI
prototypes not supported". It's been several years since I've run
into such a beast, however.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Heathfield]

Kenneth Brody said:

Richard Bos wrote:

>>
That wouldn't be called Borland C++, then, wouldn't it? In fact, it
couldn't even be called a conforming implementation, because the notion
of a conforming implementation is part of the Standard, and TTBOMK not
of K&R.

Well, the OP did say it was an old version.

Yeah, but it's not /that/ old. Mid-1990s, I think. It certainly supports
prototypes.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[mark]

Keith Thompson wrote:

"fermineutron" <fr**********@yahoo.comwrites:

| void ReadGeometry(FILE *ff1)
|
| Now, my compiler gives a compile time error stating that "FILE can not
| start a parameter declaration"

and you later said that you did have the required "#include
<stdio.h>". I don't believe that Borland C++ 5.02 (being used, I
presume, as a C compiler) would be so buggy as to reject such a simple
declaration. The only possibility I can think of is that it's so old
that it doesn't support prototypes.

To be precise, he later wrote this:

>I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in main.c
ReadGeometry is prototyped in the NTC.h file.

ie, he included stdio.h from main.c (via NTC.h), but the error occurs
when compiling ReadGeometry.c, which doesnt include it (as far as he
has told us).

I would guess that the reason it works with lcc-win is because it has
some kind of precompiled header option which is on by default.

Mark Williams

[Keith Thompson]

"mark" <ma*****@gmail.comwrites:
[...]

To be precise, he later wrote this:

>>I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in main.c
ReadGeometry is prototyped in the NTC.h file.

ie, he included stdio.h from main.c (via NTC.h), but the error occurs
when compiling ReadGeometry.c, which doesnt include it (as far as he
has told us).

I would guess that the reason it works with lcc-win is because it has
some kind of precompiled header option which is on by default.

If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

But since the OP hasn't shown us his actual code, it's hard to tell.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

"mark" <ma*****@gmail.comwrites:
[...]

>To be precise, he later wrote this:

>>>I did include it. I have a main function in main.c, i have readGeometry
function in ReadGeometry.c and i have stdio and other includes in NTC.h
file. All 3 files are a part of a project and NTC.h is included in
main.c ReadGeometry is prototyped in the NTC.h file.

ie, he included stdio.h from main.c (via NTC.h), but the error occurs
when compiling ReadGeometry.c, which doesnt include it (as far as he
has told us).

I would guess that the reason it works with lcc-win is because it has
some kind of precompiled header option which is on by default.

If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it likes
with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared in
any of the headers are reserved, whether or not the associated header is
included."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Eric Sosman]

Richard Heathfield wrote On 11/09/06 17:55,:

Keith Thompson said:

>>
If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it likes
with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared in
any of the headers are reserved, whether or not the associated header is
included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

--
Er*********@sun.com

[Jordan Abel]

2006-11-09 <1163113932.218297@news1nwk>,
Eric Sosman wrote:

>

Richard Heathfield wrote On 11/09/06 17:55,:

>Keith Thompson said:

>>>
If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it likes
with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared in
any of the headers are reserved, whether or not the associated header is
included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Is a program that uses a type name that is not in scope strictly
conforming?

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

[...]

>If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it likes
with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared in
any of the headers are reserved, whether or not the associated header is
included."

Odd, I can't find that wording in my copy of the C90 standard. I
presume it would be 7.1.2 in the ISO C90 standard, title "Standard
headers". Are you looking at a draft?

C90 7.1.3 and C99 7.1.3, "Reserved identifiers", are identical or
nearly so. The relevant part is:

Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved
for use as a macro name and as an identifier with file scope in
the same name space if any of its associated headers is included.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Eric Sosman said:

Richard Heathfield wrote On 11/09/06 17:55,:

>Keith Thompson said:

>>>
If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.

Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it
likes with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
[in
any of the headers are reserved, whether or not the associated header is
included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <in*****@invalid.invalidwrites:

>>
"All external identifiers declared in any of the headers are reserved,
whether or not the associated header is included."

Odd, I can't find that wording in my copy of the C90 standard.

They changed the spec on me? The cads!

Thanks for the correction.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Jordan Abel]

2006-11-10 <Wc********************@bt.com>,
Richard Heathfield wrote:

Eric Sosman said:

>Richard Heathfield wrote On 11/09/06 17:55,:

>>[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
[in
any of the headers are reserved, whether or not the associated header is
included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

external.

[Richard Heathfield]

Jordan Abel said:

2006-11-10 <Wc********************@bt.com>,
Richard Heathfield wrote:

>Eric Sosman said:

>>Richard Heathfield wrote On 11/09/06 17:55,:
[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
[in
any of the headers are reserved, whether or not the associated header
is included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

external.

(a) the point is moot, since Keith reckons the spec changed in the final C90
Standard;
(b) I have failed to find any indication in the Standard that FILE is
internal, or rather not external. I expect I haven't looked hard enough.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Max TenEyck Woodbury]

Richard Heathfield wrote:

Jordan Abel said:

>>2006-11-10 <Wc********************@bt.com>,
Richard Heathfield wrote:

>>>Eric Sosman said:
Richard Heathfield wrote On 11/09/06 17:55,:

>[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
>[in
>any of the headers are reserved, whether or not the associated header
>is included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

external.

(a) the point is moot, since Keith reckons the spec changed in the final C90
Standard;
(b) I have failed to find any indication in the Standard that FILE is
internal, or rather not external. I expect I haven't looked hard enough.

FILE is not the name of a storage location. It is neither a named data
area nor a named executable code area. Either of these can be external.
It is a type. Types are not exportable objects in C. They are never
external. (They are not exported in C++ either, but C++ does export
the _names_ of some types when it 'mangles' identifiers, but that is
another subject.)

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Jordan Abel said:

>2006-11-10 <Wc********************@bt.com>,
Richard Heathfield wrote:

>>Eric Sosman said:

Richard Heathfield wrote On 11/09/06 17:55,:
[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
[in
any of the headers are reserved, whether or not the associated header
is included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

external.

(a) the point is moot, since Keith reckons the spec changed in the final C90
Standard;
(b) I have failed to find any indication in the Standard that FILE is
internal, or rather not external. I expect I haven't looked hard enough.

C99 6.9 discusses "external declarations" and "external definitions".
Assuming that the declaration of FILE is something like:

typedef struct { /* ... */ } FILE;

then that's clearly an external declaration (but *not* an external
definition). The standard uses the phrase "external identifier", but
it doesn't seem to define it; I'm not quite sure what it means. (My
own understanding of what an "external identifier" is was apparently
incorrect; I won't add to the confusion by trying to explain what I
thought it meant.)

I'm still bewildered by the apparent difference between the ANSI C89
and ISO C90 specs. I had thought that the only differences were the
addition of some ISO-mandated front matter and the renumbering of
certain sections. Richard, if you're actually using a pre-C89 draft,
that would relieve my confusion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

Richard, if you're actually using a pre-C89 draft,
that would relieve my confusion.

Yes, I am. Sorry, I thought that was obvious (not least from the fact that I
can quote largish chunks from it without getting RSI!).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Richard Bos]

Kenneth Brody <ke******@spamcop.netwrote:

Richard Bos wrote:

Kenneth Brody <ke******@spamcop.netwrote:

Jordan Abel wrote:
>
I can't even imagine a conforming implementation that would be capable
of generating the error string "FILE can not start a parameter
declaration" if stdio.h has been included.
>
Imagine a C compiler that doesn't support prototypes, nor allow
parameters to be typed within the parens.
>
In other words, one that requires K&R style:
>
void ReadGeometry(ffl) FILE *ffl;

That wouldn't be called Borland C++, then, wouldn't it? In fact, it
couldn't even be called a conforming implementation, because the notion
of a conforming implementation is part of the Standard, and TTBOMK not
of K&R.

Well, the OP did say it was an old version. I'm not familiar enough
with which Borland was released when. (Even though I did use Borland's
Turbo C years ago.)

It's still Borland _C++_. ISO C nicked prototypes from C++ in the first
place.

Richard

[Eric Sosman]

Richard Heathfield wrote On 11/09/06 21:25,:

Eric Sosman said:

>>Richard Heathfield wrote On 11/09/06 17:55,:

>>>Keith Thompson said:

If lcc-win32 recognizes the identifier FILE in a translation unit that
doesn't have a "#include <stdio.h>", then that's probably a bug in
lcc-win32.
Not so, methinks, sirrah. Since FILE is reserved, it can't be used by a
strictly conforming program unless <stdio.his included[1]. Since the
program isn't strictly conforming, the implementation can do what it
likes with such a program - including "accidentally" (on purpose) quietly
defining FILE in the background.

[1] See 4.1.2 or the C99 equivalent: "All external identifiers declared
[in
any of the headers are reserved, whether or not the associated header is
included."

... but FILE is not an external identifier: it is a
type name (7.19.1/2).

Which bit do you think it isn't? external, or an identifier?

It's not external: it is an identifier with no linkage.

6.2.2 Linkages of identifiers
[...]
6/ The following identifiers have no linkage: an
identifier declared to be anything other than an
object or function; [...]

--
Er*********@sun.com

[Richard Heathfield]

Eric Sosman said:

Richard Heathfield wrote On 11/09/06 21:25,:

>>
Which bit do you think it isn't? external, or an identifier?

It's not external: it is an identifier with no linkage.

And there was me all set to prove that it's an identifier...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

[Joe Wright]

Richard Heathfield wrote:

Eric Sosman said:

>Richard Heathfield wrote On 11/09/06 21:25,:

>>Which bit do you think it isn't? external, or an identifier?

It's not external: it is an identifier with no linkage.

And there was me all set to prove that it's an identifier...

On my C implementation FILE is a typedef for a structure declared in
stdio.h.

typedef struct {
...
} FILE;

I don't see why FILE would be an identifier, it is a type. Types don't
have linkage.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Joe Wright wrote:

>

.... snip ...

>
I don't see why FILE would be an identifier, it is a type. Types
don't have linkage.

It is an identifier, which happens to label a type.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Joe Wright]

CBFalconer wrote:

Joe Wright wrote:
... snip ...

>I don't see why FILE would be an identifier, it is a type. Types
don't have linkage.

It is an identifier, which happens to label a type.

Really? Is int an identifier which happens to label a type? Are any or
all type names, char, short etc. identifiers? I suppose not.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Jordan Abel]

2006-11-11 <pf******************************@comcast.com>,
Joe Wright wrote:

CBFalconer wrote:

>Joe Wright wrote:
... snip ...

>>I don't see why FILE would be an identifier, it is a type. Types
don't have linkage.

It is an identifier, which happens to label a type.

Really? Is int an identifier which happens to label a type? Are any or
all type names, char, short etc. identifiers? I suppose not.

The reason that FILE is an identifier and not a keyword is because you
can still use it as an identifier in other contexts.

#include <stdio.h>
struct FILE {
...
};

[CBFalconer]

Joe Wright wrote:

CBFalconer wrote:

>Joe Wright wrote:

... snip ...

>>I don't see why FILE would be an identifier, it is a type. Types
don't have linkage.

It is an identifier, which happens to label a type.

Really? Is int an identifier which happens to label a type? Are any
or all type names, char, short etc. identifiers? I suppose not.

Yes, int is an identifier too. It also happens to be a reserved
word, while identifying a particular integral type.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Kenny McCormack]

In article <xu******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:
....

>On my C implementation, ...

Oh, oh. You're not allowed to begin a sentence that way here.
I'm sure you know that.

[Harald van Dijk]

CBFalconer wrote:

Joe Wright wrote:

CBFalconer wrote:

Joe Wright wrote:

... snip ...
I don't see why FILE would be an identifier, it is a type. Types
don't have linkage.

It is an identifier, which happens to label a type.

Really? Is int an identifier which happens to label a type? Are any
or all type names, char, short etc. identifiers? I suppose not.

Yes, int is an identifier too. It also happens to be a reserved
word, while identifying a particular integral type.

int is not an identifier except during preprocessing. The standard
could have been specified differently, so that keywords are
identifiers, but wasn't.