That line tells us that you are using a C89 compiler. A C99 compiler would not have compiled that line because C99 does not the recognize implicit int return type. Every C99 function must define -some- return type, even if that return type is given as 'void' (which would not be a good idea for the 'main' routine.)
> int NP; /* no. people */ > fscanf(in, "%d", &NP); > struct friend f[NP];
But those lines tell us that you are using C99. C89 array lengths must be defined at compile time. C99 allows variable length arrays (VLA) in some circumstances.
You need to pick a compiler standard and stick with it. If you mix-and-match features between compiler versions, we cannot tell you what the program means. -- "There are some ideas so wrong that only a very intelligent person could believe in them." -- George Orwell
> That line tells us that you are using a C89 compiler. A C99 compiler > would not have compiled that line because C99 does not the recognize > implicit int return type. Every C99 function must define -some- return > type, even if that return type is given as 'void' (which would > not be a good idea for the 'main' routine.)
> > int NP; /* no. people */ > > fscanf(in, "%d", &NP); > > struct friend f[NP];
> But those lines tell us that you are using C99. C89 array lengths > must be defined at compile time. C99 allows variable length arrays > (VLA) in some circumstances.
> You need to pick a compiler standard and stick with it. > If you mix-and-match features between compiler versions, we > cannot tell you what the program means. > -- > "There are some ideas so wrong that only a very intelligent person > could believe in them." -- George Orwell
OK - I've been referring to K&R 2nd Edition. main() becomes int main()
Can you now tell me what's wrong with the rest of the program?
Bert <albert.xtheunkno...@gmail.com> writes: > On Jul 6, 11:07 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) <snip> >> You need to pick a compiler standard and stick with it. >> If you mix-and-match features between compiler versions, we >> cannot tell you what the program means. >> -- >> "There are some ideas so wrong that only a very intelligent person >> could believe in them." -- George >> Orwell
Best not to quote sig blocks.
> OK - I've been referring to K&R 2nd Edition. > main() > becomes int main()
> Can you now tell me what's wrong with the rest of the program?
The main things are (in no particular order):
(1) No error checking on things that can fail like fopen and fscanf. (2) No decomposition into functions. (3) Dangerous unbounded %s input formats. (4) Misunderstanding how fscanf reads strings. Read FAQ 12.18a [1] (4) Comparing strings by using == on pointers to them. FAQ 8.2.
Because it doesn't compile under either C90 or C99.
[1] c:\c\junk>cc junk.c junk.c: In function `main': junk.c:17: warning: ISO C89 forbids variable-size array `f' junk.c:17: warning: ISO C89 forbids mixed declarations and code junk.c:31: warning: ISO C89 forbids mixed declarations and code junk.c:37: warning: format argument is not a pointer (arg 3) junk.c:37: warning: format argument is not a pointer (arg 4) junk.c:42: warning: ISO C89 forbids mixed declarations and code junk.c:49: warning: ISO C89 forbids mixed declarations and code junk.c:64: warning: implicit declaration of function `exit' junk.c:35: warning: `init' might be used uninitialized in this function
[1] c:\c\junk>gcc -std=c99 -pedantic -W -Wall -Wwrite-strings junk.c junk.c: In function `main': junk.c:37: warning: format argument is not a pointer (arg 3) junk.c:37: warning: format argument is not a pointer (arg 4) junk.c:64: warning: implicit declaration of function `exit'
> FILE* in = fopen("gift1.in" , "r"); > FILE* out = fopen("gift1.out", "w");
> fscanf(in, "%d", &NP);
> struct friend f[NP];
So your compiler has extensions that allow variable length arrays and definitions to follow executable statements. Many of us don't which limits the number of people who can help you.
> int i = 0;
> for (; i < NP; i++) > { > fscanf(in, "%s", f[i].name);
If you gave us a sample of your input it would also help.
> }
> /* Until input tells us how much each friend has (later in this >prog), they're all broke */ > i = 0;
> for (; i < NP; i++) > { > f[i].money = 0;
Is there some reason you chose not to do this in the previous loop?
> }
> char temp[MAXNAMELEN];
> for (i = 0; i < NP; i++) > { > fscanf(in, "%s", temp);
Don't you think this should be in front of the loop?
> if (f[i].name == temp)
This is guaranteed to always be false. If you want to compare strings, you need to use strcmp et al. Read the faq (www.c-faq.com), section 8.2. Then read the rest of the faq also.
> { > int init; /* initial amount of money */
> fscanf(in, "%d %d", init, f[i].ngifts);
> f[i].money = init * -1; /* init is given to people */
Is there some reason -init does not provide the value you want?
>> FILE* in = fopen("gift1.in" , "r"); >> FILE* out = fopen("gift1.out", "w");
>> fscanf(in, "%d", &NP); >> struct friend f[NP];
> So your compiler has extensions that allow variable length arrays and > definitions to follow executable statements. Many of us don't which > limits the number of people who can help you.
Not to mention the use of undefined functions (exit) and implicit int (main).
> Barry Schwarz wrote: >> Bert <albert.xtheunkno...@gmail.com> wrote:
>>> Why doesn't this work?
>> Would you care to describe "doesn't work" so we have a fighting chance >> to help.
> .... snip ...
>>> #include <stdio.h>
<snip>
> Not to mention the use of undefined functions (exit) and implicit > int (main).
ITYM "undeclared functions". Either the presence of a standard C library function in the library supplied with the implementation counts as a definition or it doesn't. If it does, then exit() is defined. And if it doesn't, the mere addition of a declaration (via #include <stdlib.h>) will not provide a definition.
