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

[pete]

no*********@gmail.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.
There's other problems too,
but let's see if we can get you compiling first.
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.

--
pete

[Roberto Waltman]

On 16 May 2006 05:13:58 -0700, "no*********@gmail.com"
<no*********@gmail.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];

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

Most likely the errors are not "rediculus" (sic). A quick glance at
your code brings up the following:

(a) Wrong declaration for main().
(b) C89 does not allow mixing declarations with other statements.
(c) No check for fopen() return status.
(d) Use of "magic number" 100.
(e) Risk of buffer overflow in call to fscanf().
(f) Missing return statement.

[CBFalconer]

"no*********@gmail.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];

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.

Yes, there is something wrong with that. Reading the crimson
colored iculus error messages may give you a clue. I can see at
least three glaring errors, and at least two more tactical errors.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[jacob navia]

pete a écrit :

no*********@gmail.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.

[noridotjabi]

> wrong with this: (file related)

Oh come the off of it. I know what I am doing. 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.
NORI

no*********@gmail.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];

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

[Eric Sosman]

no*********@gmail.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.

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

[Bill Pursell]

no*********@gmail.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];

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

Other than warnings, it compiles just fine for me. As pointed out
elsethread, it would be convenient if you list the errors you are
getting.

[Vladimir Oka]

no*********@gmail.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];

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.

Well, as has already been pointed out, there's nothing (seriously)
wrong with your code, assuming C99, and that it's really your compiler
that gives out error messages. Rewritten thus:

#include <stdio.h>

int main(void) {
FILE *pfsin;
char mystr[100];

pfsin = fopen("msm.pfs", "r");
fscanf(pfsin, "%s", mystr);
fclose(pfsin);

return 0;
}

it even compiles cleanly for "gcc -pedantic -W -Wall -Wextra -ansi".

So, unless you provide more specific information about the errors
you're seeing, I'm afraid nobody here can help. (Another look that
pesky line 42 sounds tempting, though.)

Alternatively, your compiler may be broken.

[Ben C]

On 2006-05-16, no*********@gmail.com <no*********@gmail.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];

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.

What are the errors?

I tried it on gcc and got a few warnings but it compiles OK.

The statement before a declaration is a parse error on some compilers,
so it seems most likely to be that. Try swapping the char mystr line
with the one above it.

Either that or you've got some dodgy macros somewhere (someone the other
day redefined FILE...)

[Richard Heathfield]

jacob navia said:

pete a écrit :

no*********@gmail.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*********@gmail.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*********@gmail.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\Microsoft Visual Studio 8\VC\INCLUDE\stdio.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\Microsoft Visual Studio 8\VC\INCLUDE\stdio.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*********@gmail.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*********@gmail.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)

[jab3]

Richard Heathfield wrote:

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?

Well, I don't think my statement works given real probability analysis. (It
was late and the 50% chance comment just struck me as funny) However, I
also don't think your bet is strictly analogous to what I said. I didn't
say the whole program is either all right or all wrong. I said any given
line theoretically has a 50% chance of being right or wrong. Your bet, were
it analogous, would be that any given coin has a 50% chance of being either
heads or tails. But I would imagine the actual probability of any given
line of code being right or wrong is based on the person doing the coding,
the language, the complexity of the program, the emotional state of the
person, etc.

[pete]

jab3 wrote:

Richard Heathfield wrote:

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.

the 50% chance comment just struck me as funny

http://www.google.com/

Results 1 - 10 of about 76,500 for "it's funny because it's true".

--
pete

[Richard Heathfield]

jab3 said:

Well, I don't think my statement works given real probability analysis.
No, it doesn't.
(It
was late and the 50% chance comment just struck me as funny) However, I
also don't think your bet is strictly analogous to what I said. I didn't
say the whole program is either all right or all wrong. I said any given
line theoretically has a 50% chance of being right or wrong.

But in fact, if we know there is one bug in an N-line program, then (if
that's all the information we have to go on) each line has a 1/N
probability of containing that bug. 1/N is only 50% if it's a two-line
program.

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