What is wrong with this. (files)

[noridotjabi]

Okay. I'm quite embarased to be asking this but I cannot seem to get
files to work. I don't know what the problem is. Is there something
wrong with this: (file related)

#include <stdio.h>
main() {
FILE *pfsin;
pfsin = fopen("msm.pfs" , "r");
char mystr[100];

fscanf(pfsin, "%s", mystr);
fclose(pfsin);
}

Thanks in advanced, but I have seen several examples of code that looks
EXACLTY like this, and for some reason my compiler is giving me
rediculus errors.
Nori

[Richard Heathfield]

jacob navia said:

pete a écrit :

no*********@gma il.com wrote:

Okay. I'm quite embarased to be asking this but I cannot seem to get
files to work. I don't know what the problem is. Is there something
wrong with this: (file related)

#include <stdio.h>
main() {
FILE *pfsin;

pfsin = fopen("msm.pfs" , "r");
char mystr[100];

The above two lines of code are out of order for C89.

You are living in the past Pete.

No, he's living in the present reality where almost nobody has a conforming
C99 compiler.
We are 2006 and the C standard is 7 years old. The above likes are
standard C.

Standard, yes. Portable, no. The explanation pete gave of the OP's problem
is entirely plausible.

Just because a few guys on a committee somewhere say "hey, let's change the
language definition", that does not automatically upgrade every compiler
installation in the world to meet the new definition.

Based on your past performance, I do not expect you to understand this.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

jacob navia wrote:

pete a écrit :

no*********@gma il.com wrote:

Okay. I'm quite embarased to be asking this but I cannot seem to get
files to work. I don't know what the problem is. Is there something
wrong with this: (file related)

#include <stdio.h>
main() {
FILE *pfsin;

pfsin = fopen("msm.pfs" , "r");
char mystr[100];

The above two lines of code are out of order for C89.

You are living in the past Pete. We are 2006 and the C standard is 7
years old. The above likes are standard C.

Well, the program can't have been C99 since it used implicit int for
main. Also, seeing as very few compilers are C99 compliant (something
you are well aware of) it is reasonable to guess that the OPs compiler
is not C99 compliant and therefore point this out as a possible error.

Once MS VC++ and gcc are both C99 compliant (neither is currently and MS
has made no attempt at it) you might have a little (but not much since
there are lots of compilers for embedded systems as well) cause for
complaint when people point out that things are not valid C89.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[pete]

Flash Gordon wrote:

jacob navia wrote:

pete a écrit :

no*********@gma il.com wrote:

Okay.
I'm quite embarased to be asking this but I cannot seem to get
files to work. I don't know what the problem is.
Is there something
wrong with this: (file related)

#include <stdio.h>
main() {
FILE *pfsin;

pfsin = fopen("msm.pfs" , "r");
char mystr[100];
The above two lines of code are out of order for C89.

You are living in the past Pete. We are 2006 and the C standard is 7
years old. The above likes are standard C.

Well, the program can't have been C99 since it used implicit int for
main.

So, there! Ha!

OP just gave a response as stupid as jacob navia's,
elsewhere on this thread, to which Eric Sosman replied.

--
pete

[Luca Benini]

on cl version 14.00.50727.42
i've:

test.c(4) : warning C4996: 'fopen' was declared deprecated
C:\Programmi\Mi crosoft Visual Studio 8\VC\INCLUDE\st dio.h(234)
: see dec
laration of 'fopen'
Message: 'This function or variable may be unsafe. Consider
using fopen_
s instead. To disable deprecation, use _CRT_SECURE_NO_ DEPRECATE. See
online help
for details.'
test.c(5) : error C2143: syntax error : missing ';' before 'type'
test.c(9) : error C2065: 'mystr' : undeclared identifier
the problem is related to mixing declaration with expression.
switching
pfsin = fopen("msm.pfs" , "r");
char mystr[100];
it's compile.

[Richard Heathfield]

Luca Benini said:

on cl version 14.00.50727.42
i've:

test.c(4) : warning C4996: 'fopen' was declared deprecated
Never heard such nonsense.
C:\Programmi\Mi crosoft Visual Studio 8\VC\INCLUDE\st dio.h(234)
: see dec
laration of 'fopen'
Message: 'This function or variable may be unsafe. Consider
using fopen_
s instead.
Ridiculous. If their fopen is unsafe, they should fix it.
test.c(5) : error C2143: syntax error : missing ';' before 'type'
test.c(9) : error C2065: 'mystr' : undeclared identifier
the problem is related to mixing declaration with expression.
switching
pfsin = fopen("msm.pfs" , "r");
char mystr[100];
it's compile.

Declarations first, code afterwards. That's how C does it.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[pete]

Richard Heathfield wrote:

Declarations first, code afterwards. That's how C does it.

I think you mean "statements " instead of "code".
That's how C89 does it in a block, but it's not required by C99.
Declarations are code, sometimes with side effects.

FILE *pfsin;
pfsin = fopen("msm.pfs" , "r");
char mystr[100];

could also have been fixed for C89 as

FILE *pfsin = fopen("msm.pfs" , "r");
char mystr[100];

--
pete

[pete]

Eric Sosman wrote:

no*********@gma il.com wrote On 05/16/06 10:36,:

wrong with this: (file related)

Oh come the off of it. I know what I am doing.

Then why are you asking for help?

This was simply and
example. Frankly I do not care about C89. I spacificly said FILE
REALTED.
I know that I'm risking this that and the next thing, okay.
I don't care about tactical errors. Its an example not killer-app
source code. Why don't keep your comments about C89 and risks and
tactical errors to your self,
that has nothing to do with my question,
and actually try to help instead of trying to make yourselfs feel
superior.

Your question was about the "rediculous errors" your
compiler generates for your code. Of course, you lacked
the wit to transcribe any of those "rediculous errors" so
someone could actually look at them ...

"Doctor, it hurts!"

"Where does it hurt?"

"Never mind, just hurry up and heal me!"

My diagnosis: You have an error on line 42. True,
there were only nine lines (one of them blank) in the code
you showed, but you've admitted ("This was simply and [sic]
example") that you haven't shown your actual code. Go fix
line 42, and all will be well.

With trouble shooting in general,
be it either automotive or programming,
when somebody tells you that they've got a problem
and that they know what the problem definitely isn't,
then that's the first place I want to start looking.
My experience is that there is about 50% chance
that that's the problem.

--
pete

[Richard Heathfield]

pete said:

Richard Heathfield wrote:

Declarations first, code afterwards. That's how C does it.
I think you mean "statements " instead of "code".

<shrug>
That's how C89 does it in a block, but it's not required by C99.

If the OP had C99, he wouldn't have had the problem. Or if the OP had put
his declarations above his statements, he wouldn't have had the problem.

The first "if" is rather tricky to fix, but the second is trivial.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jab3]

pete wrote:

Eric Sosman wrote:

no*********@gma il.com wrote On 05/16/06 10:36,:

>>wrong with this: (file related)
>
>
> Oh come the off of it. I know what I am doing.

Then why are you asking for help?

> This was simply and
> example. Frankly I do not care about C89. I spacificly said FILE
> REALTED.
> I know that I'm risking this that and the next thing, okay.
> I don't care about tactical errors. Its an example not killer-app
> source code. Why don't keep your comments about C89 and risks and
> tactical errors to your self,
> that has nothing to do with my question,
> and actually try to help instead of trying to make yourselfs feel
> superior.

Your question was about the "rediculous errors" your
compiler generates for your code. Of course, you lacked
the wit to transcribe any of those "rediculous errors" so
someone could actually look at them ...

"Doctor, it hurts!"

"Where does it hurt?"

"Never mind, just hurry up and heal me!"

My diagnosis: You have an error on line 42. True,
there were only nine lines (one of them blank) in the code
you showed, but you've admitted ("This was simply and [sic]
example") that you haven't shown your actual code. Go fix
line 42, and all will be well.

With trouble shooting in general,
be it either automotive or programming,
when somebody tells you that they've got a problem
and that they know what the problem definitely isn't,
then that's the first place I want to start looking.
My experience is that there is about 50% chance
that that's the problem.

Since any given statement either is or is not a problem, any given statement
has a 50% chance of being the problem.

[Richard Heathfield]

jab3 said:

pete wrote:

With trouble shooting in general,
be it either automotive or programming,
when somebody tells you that they've got a problem
and that they know what the problem definitely isn't,
then that's the first place I want to start looking.
My experience is that there is about 50% chance
that that's the problem.

pete - that jibes pretty well with my experience, too, although I'd have put
the probability somewhat higher.
Since any given statement either is or is not a problem, any given
statement has a 50% chance of being the problem.

If you truly believe that two mutually exclusive possibilities are
necessarily of equal probability, I offer you the following bet:

Given suitable precautions to prevent cheating, you will put down $5000 and
I will put down $10000 - so there's $15000 on the table - and then a
trusted third party will put a hundred fair coins (one side heads, the
other side tails) into a sack, shake 'em around a bit, and then spill them
onto a tabletop. Either they will all come out heads, or they won't, so
that's 50-50, right? So - if they all come down heads, you get to keep the
$15000, despite only a $5000 stake. That's good odds for you. If the other
50% chance happens, though, I get the $15000 instead.

Deal?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)