Problem 77: Greedy Gift Givers

Bert wrote:

>
Problem is documented at http://ace.delos.com/usacoprob2?a=deAhyErCKsK&S=gift1

Why doesn't this work?

.... snip ...

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'

This is line 37 as I have compressed it:

fscanf(in, "%d %d", init, f[i].ngifts);

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 6 '08 #4

Bert

Why doesn't it do the problem correctly now?

/*
ID: albert.4
LANG: C
TASK: gift1
*/

#include <stdio.h>

#define MAXNAMELEN 14

main()
{
struct friend {
int money, ngifts; /* no. gifts */

char name[MAXNAMELEN];
};

int NP; /* no. people */

FILE* in = fopen("gift1.in" , "r");
FILE* out = fopen("gift1.out", "w");

fscanf(in, "%d", &NP);

struct friend f[NP];

int i = 0;

for (; i < NP; i++)
{
fscanf(in, "%s", f[i].name);
}

/* 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;
}

char temp[MAXNAMELEN];

for (i = 0; i < NP; i++)
{
fscanf(in, "%s", temp);

if (strcmp(f[i].name, temp) == 0)
{
int init; /* initial amount of money */

fscanf(in, "%d %d", &init, &f[i].ngifts);

f[i].money = init * -1; /* init is given to people */

if (f[i].ngifts != 0)
{
f[i].money += init % f[i].ngifts;
}

int amteachpersongets = 0;

if (f[i].ngifts != 0)
{
int amteachpersongets = init / f[i].ngifts;
}

int j = 0;

char temp2[MAXNAMELEN];

for (; j < f[i].ngifts; j++)
{
fscanf(in, "%s", temp2);

int k = 0;

for (; k < NP; k++)
{
if (strcmp(f[k].name, temp2) == 0)
{
f[k].money += amteachpersongets;
break;
}
}
}
}
}

for (i = 0; i < NP; i++)
{
fprintf(out, "%s %d\n", f[i].name, f[i].money);
}

exit(0);
}

Jul 6 '08 #5

Barry Schwarz

On Sat, 5 Jul 2008 17:31:31 -0700 (PDT), Bert
<al*****************@gmail.comwrote:

>Problem is documented at http://ace.delos.com/usacoprob2?a=deAhyErCKsK&S=gift1

Why doesn't this work?

Would you care to describe "doesn't work" so we have a fighting chance
to help.

>
/*
ID: albert.4
LANG: C
TASK: gift1
*/

#include <stdio.h>

#define MAXNAMELEN 14

main()
{
struct friend {
int money, ngifts; /* no. gifts */

char name[MAXNAMELEN];
};

int NP; /* no. people */

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?

f[i].money += init % f[i].ngifts;

What is this quantity supposed to represent?

>
int amteachpersongets = init / f[i].ngifts;

int j = 0;

char temp2[MAXNAMELEN];

for (; j < f[i].ngifts; j++)
{
fscanf(in, "%s", temp2);

int k = 0;

for (; k < NP; k++)
{
if (f[k].name == temp2)
{
f[k].money += amteachpersongets;
break;
}
}
}
}
}

for (i = 0; i < NP; i++)
{
fprintf(out, "%s %d\n", f[i].name, f[i].money);
}

exit(0);
}

Remove del for email

Jul 6 '08 #6

santosh

Bert wrote:

Problem is documented at
http://ace.delos.com/usacoprob2?a=deAhyErCKsK&S=gift1

Do you realise that the link leads to a page that asks for
authentication?

<snip>

Jul 6 '08 #7

Barry Schwarz wrote:

Bert <al*****************@gmail.comwrote:

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

#define MAXNAMELEN 14

main()
{
struct friend {
int money, ngifts; /* no. gifts */
char name[MAXNAMELEN];
};

int NP; /* no. people */

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 6 '08 #8

CBFalconer said:

Barry Schwarz wrote:
>Bert <al*****************@gmail.comwrote:

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 6 '08 #9

Willem

Richard Heathfield wrote:
) 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.

Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)

(On systems where a process returns 0 to the shell for failure).
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Jul 6 '08 #10

santosh

Willem wrote:

Richard Heathfield wrote:
) 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.

Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)

(On systems where a process returns 0 to the shell for failure).

As far as I can see, exit could be implemented as a macro too, though a
function must also be provided.

Jul 6 '08 #11

santosh wrote:

Willem wrote:

.... snip ...

>
>Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)

(On systems where a process returns 0 to the shell for failure).

As far as I can see, exit could be implemented as a macro too,
though a function must also be provided.

If it is a macro, that macro is defined by #include <stdlib.h>.
However, since it is a non-returning function, it appears awkward
to provide a macro for it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 6 '08 #12

Willem <wi****@stack.nlwrites:

Richard Heathfield wrote:
) 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.

Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

[...]

Like any other library function, it must be provided as a function.
The implementation may optionally implement it as a macro as well.

In particular, assuming you have a "#include <stdlib.h>", this:

(exit)(0);

or this:

#undef exit
exit(0);

must bypass any macro definition and call the actual function.
Similarly, you can assign the address of the exit function to a
pointer object.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 6 '08 #13

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

santosh wrote:
>Willem wrote:
... snip ...
>>
>>Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)

(On systems where a process returns 0 to the shell for failure).

As far as I can see, exit could be implemented as a macro too,
though a function must also be provided.

If it is a macro, that macro is defined by #include <stdlib.h>.
However, since it is a non-returning function, it appears awkward
to provide a macro for it.

I see nothing awkward about it. Willem even provided a plausible
example.

Except that I'd put parentheses around the whole definition:

#define exit(x) (_exitprocess((x) == EXIT_SUCCESS ? 1 : 0))

It's easier to add the parentheses than to figure out whether they're
really necessary.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 6 '08 #14

Peter Nilsson

Keith Thompson wrote:

...
Like any other library function, it must be provided as a function.

Well... it's unspecified whether setjmp is an identifier declared
with external linkage, which gives it scope to be a library function
that needn't be provided as a function! :-)

--
Peter

Jul 6 '08 #15

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
>santosh wrote:
>>Willem wrote:
... snip ...
>>>
Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:

#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)

(On systems where a process returns 0 to the shell for failure).

As far as I can see, exit could be implemented as a macro too,
though a function must also be provided.

If it is a macro, that macro is defined by #include <stdlib.h>.
However, since it is a non-returning function, it appears awkward
to provide a macro for it.

I see nothing awkward about it. Willem even provided a plausible
example.

Since the operation has to go somewhere and do something, it has to
transfer control. There must be code to which to transfer control
to. Since the code must exist and must be used, any macro is a
useless exercize. At least as I see it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 7 '08 #16

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

Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>santosh wrote:
Willem wrote:
... snip ...

Is exit() required to be a library function by the standard ?
Can't it be a macro ? For example:
>
#define exit(x) _exitprocess((x) == EXIT_SUCCESS ? 1 : 0)
>
(On systems where a process returns 0 to the shell for failure).

As far as I can see, exit could be implemented as a macro too,
though a function must also be provided.

If it is a macro, that macro is defined by #include <stdlib.h>.
However, since it is a non-returning function, it appears awkward
to provide a macro for it.

I see nothing awkward about it. Willem even provided a plausible
example.

Since the operation has to go somewhere and do something, it has to
transfer control. There must be code to which to transfer control
to. Since the code must exist and must be used, any macro is a
useless exercize. At least as I see it.

Read Willem's example again. The transfer of control is performed by
the _exitprocess() function. The macro serves to perform a simple
transformation on the argument.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 7 '08 #17

Peter Nilsson <ai***@acay.com.auwrites:

Keith Thompson wrote:
>...
Like any other library function, it must be provided as a function.

Well... it's unspecified whether setjmp is an identifier declared
with external linkage, which gives it scope to be a library function
that needn't be provided as a function! :-)

Well, the standard refers to it as "the setjmp macro", even though it
apparently doesn't require it to be a macro.

In any case, setjmp would simply be the exception that proves the
rule, if exceptions proved rules, which of course they don't, so I
was, er, um, wrong.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 7 '08 #18

Willem

Bert wrote:
) Why doesn't it do the problem correctly now?

What is the incorrect output then, and what should the correct output be ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Jul 7 '08 #19

Nick Keighley

On 6 Jul, 02:07, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

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.

well *you* might not be able to...

The semantice of C89 and C90 arn't *that*
different
--
Nick Keighley

Jul 7 '08 #20

Nick Keighley <ni******************@hotmail.comwrites:

On 6 Jul, 02:07, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
>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.

well *you* might not be able to...

The semantice of C89 and C90 arn't *that*
different

The semantics of C89 and C90 are identical. I presume you meant C90
vs. C99.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 7 '08 #21

vippstar

On Jul 6, 6:07 am, CBFalconer <cbfalco...@yahoo.comwrote:

Bert wrote:

Problem is documented at http://ace.delos.com/usacoprob2?a=deAhyErCKsK&S=gift1

Why doesn't this work?

... snip ...

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'

<snip more warnings>

Note that 'cc' in your particular example is not a C compiler invoked
in C89/C90 conformance mode.

Jul 8 '08 #22

vi******@gmail.com wrote:

CBFalconer <cbfalco...@yahoo.comwrote:

.... snip ...

>
>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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 8 '08 #23

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

vi******@gmail.com wrote:
>CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...
>>
>>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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.

Does that alias pass the extra arguments needed to invoke C90
conforming mode? If so, you might have said so.

The warning message was characteristic of gcc. On many systems, the
"cc" command is identical to the "gcc" command (typically
"/usr/bin/cc" is a symbolic link to "/usr/bin/gcc"). The DOS-style
prompt does indicate that something else is going on, but vippstar's
assumption was not an entirely unreasonable one.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 8 '08 #24

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
>vi******@gmail.com wrote:
>>CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...
>>>
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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.

Does that alias pass the extra arguments needed to invoke C90
conforming mode? If so, you might have said so.

However, the point of the message was to point out that the source
didn't compile under either C90 or C99, by displaying the two sets
of error messages. All the rest is needless.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 8 '08 #25

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
>vi******@gmail.com wrote:
>>CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...
>>>
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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.

Does that alias pass the extra arguments needed to invoke C90
conforming mode? If so, you might have said so.

Jul 8 '08 #26

vippstar

On Jul 8, 11:19 am, CBFalconer <cbfalco...@yahoo.comwrote:

vipps...@gmail.com wrote:
CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...

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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.

The code is not valid in C89/C90, there was a constraint violation,
but no error was diagnosed.
Maybe I'm wrong and it is not a constraint violation! gcc in C90 mode
only warns for this code:

int main(void) { int i = 10; char foo[i]; return 0; }

I would find out myself but I don't have the C90 standard. Can anyone
help?

Jul 9 '08 #27

vi******@gmail.com said:

<snip>

Maybe I'm wrong and it is not a constraint violation!

It is.

gcc in C90 mode
only warns for this code:

int main(void) { int i = 10; char foo[i]; return 0; }

The code violates the constraint in 3.5.4.2 that "The expression that
specifies the size of an array shall be an integral constant expression
that has a value greater than zero" because i is not an integral constant
expression. (And no, making it const won't help.)

The gcc implementation, in issuing a diagnostic message, fulfils its
conformance obligations to you. Whether it calls the message a warning or
an error is irrelevant, as long as it issues the message.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 9 '08 #28

santosh

vi******@gmail.com wrote:

On Jul 8, 11:19 am, CBFalconer <cbfalco...@yahoo.comwrote:
>vipps...@gmail.com wrote:
CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...

>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'
<snip more warnings>

Note that 'cc' in your particular example is not a C compiler
invoked in C89/C90 conformance mode.

You don't know that. As a matter of fact it is, being simply gcc
called via an alias.
The code is not valid in C89/C90, there was a constraint violation,
but no error was diagnosed.

Maybe I'm wrong, but I believe that a constraint violation only requires
a diagnostic (commonly a warning). The further behaviour of the
translation is undefined by the standard and the implementation can do
anything including compiling the code anyway, refusing translation,
deleting all your files etc.

I believe that the only construct that must absolutely stop compilation
is an active #error directive. All syntax errors and constraint
violations require a diagnostic but translation need not necessarily
halt, though they commonly do so for syntax errors.

Maybe I'm wrong and it is not a constraint violation! gcc in C90 mode
only warns for this code:

int main(void) { int i = 10; char foo[i]; return 0; }

I would find out myself but I don't have the C90 standard. Can anyone
help?

The clc Wiki has a draft of the old ANSI standard. Maybe that can help
you?

Jul 9 '08 #29

santosh said:

<snip>

Maybe I'm wrong, but I believe that a constraint violation only requires
a diagnostic (commonly a warning).

(Here I refer to C89.) The term used by the Standard is "diagnostic
message". If a program contains at least one constraint violation or at
least one syntax error, the translator must issue a diagnostic message.
The message "Your program contains at least one constraint violation or
syntax error" would be conforming, albeit rather unhelpful. Diagnostic
messages are implementation-defined, so they must be documented.

The Standard doesn't mention the word "warning" even once in normative
text. It does mention the phrase "error message" four times in normative
text (three of which are in relation to perror and one in relation to
strerror), but in each case it's talking about runtime behaviour, not what
happens during translation.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 9 '08 #30

vippstar

On Jul 9, 12:22 pm, santosh <santosh....@gmail.comwrote:

vipps...@gmail.com wrote:

<snip>

I would find out myself but I don't have the C90 standard. Can anyone
help?

The clc Wiki has a draft of the old ANSI standard. Maybe that can help
you?

Thanks! This will help a lot.

Jul 9 '08 #31

vippstar

On Jul 9, 11:26 am, Richard Heathfield <r...@see.sig.invalidwrote:

vipps...@gmail.com said:

<snip>

Maybe I'm wrong and it is not a constraint violation!

It is.

gcc in C90 mode
only warns for this code:

int main(void) { int i = 10; char foo[i]; return 0; }

The code violates the constraint in 3.5.4.2 that "The expression that
specifies the size of an array shall be an integral constant expression
that has a value greater than zero" because i is not an integral constant
expression. (And no, making it const won't help.)

The gcc implementation, in issuing a diagnostic message, fulfils its
conformance obligations to you. Whether it calls the message a warning or
an error is irrelevant, as long as it issues the message.

Great, thanks. I always thought there are "error messages" and
"warning messages", such as that the compiler has to print at least
one of the former if a constraint violation/syntax error happends, and
that the compiler is free to print any number of the latter.
I have a question though, if warning messages (ie warning: text) are
allowed by the standard to be printed for constraint violations, how
can the programmer differentiate between a successfully compiled
program and one which had a syntax error or a constraint violation?
This is purely academic, of course all compilers will attempt to have
meaningful error/warning messages such that the programmer will
_receive_ information from them instead of confusion.

Jul 9 '08 #32

vi******@gmail.com said:

<snip>

I have a question though, if warning messages (ie warning: text) are
allowed by the standard to be printed for constraint violations,

The Standard requires the implementation to produce a diagnostic message if
the program contains any syntax errors or constraint violations. The
Standard does not require the implementation to give these diagnostic
messages a badge of "warning" or "error", but you can call them warning
messages if you like.

how
can the programmer differentiate between a successfully compiled
program and one which had a syntax error or a constraint violation?

I'm afraid the answer is that a program for which the translator emits at
least one diagnostic message may (or may not) contain at least one syntax
error or constraint violation. That is - if the translator is a conforming
implementation and NO messages are produced, you know that the program
didn't contain any syntax errors or constraint violations. (It might still
contain mistakes of logic or instances of undefined behaviour, of course.)

This is purely academic, of course all compilers will attempt to have
meaningful error/warning messages such that the programmer will
_receive_ information from them instead of confusion.

That was never the impression I got when I was first learning C. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 9 '08 #33

Bert

Well, this compiles on the compiler somewhere else wherever I sent
this to. Could you guys please point out which parts could be improved
oh and I just realised you're all professionals...um...could you
please INDICATE the points where I need to do all the error checking
like the try..catch kinda things for all kinds of exceptions (only C
doesn't have this cool stuff) like for adverse inputs? Thanks

/*
ID: albert.4
LANG: C
TASK: gift1
*/

#include <stdio.h>

#define MAXNAMELEN 20

main()
{
/*************************************************/
struct friend {
int money, ngifts;

char name[MAXNAMELEN];
};

int NP;

FILE* in = fopen("gift1.in" , "r");
FILE* out = fopen("gift1.out", "w");

fscanf(in, "%d", &NP);
struct friend f[NP];

int i = 0;

for (; i < NP; i++)
{
fscanf(in, "%s", f[i].name);
f[i].money = 0;
}
/*************************************************/

/*************************************************/
int m = 0;
for (; m < NP; m++)
{
struct friend* currf;
char temp[MAXNAMELEN];

fscanf(in, "%s", temp);

i = 0;
for (; i < NP; i++)
{
if ( strcmp(temp, f[i].name) == 0 )
{
currf = &f[i];
/* printf("Current friend%s\n", f[i].name); */
break;
}
}
/*************************************************/

/*************************************************/
int init;
fscanf(in, "%d %d", &init, &currf->ngifts);
currf->money += -1 * init;
if (currf->ngifts != 0)
{
currf->money += init % currf->ngifts;
}
/* printf("%d %d\n", init, currf->ngifts); */
/*************************************************/

char receivers[currf->ngifts][MAXNAMELEN];
int j = 0;
int l;
for (; j < currf->ngifts; j++)
{
fscanf(in, "%s", receivers[j]);
/* printf("%s\n", receivers[j]); */

l = 0;
for (; l < NP; l++)
{
if ( strcmp(receivers[j], f[l].name) == 0 )
{
/* printf("%s\n", f[l].name); */
f[l].money += init / currf->ngifts;
/* printf("%d\n", f[l].money); */
}
}
}
}

/*************************************************/
for (i = 0; i < NP; i++)
{
fprintf(out, "%s %d\n", f[i].name, f[i].money);
}
/************************************************/

exit(0);
}

Jul 10 '08 #34

santosh

Bert wrote:

Well, this compiles on the compiler somewhere else wherever I sent
this to. Could you guys please point out which parts could be improved
oh and I just realised you're all professionals...um...could you
please INDICATE the points where I need to do all the error checking
like the try..catch kinda things for all kinds of exceptions (only C
doesn't have this cool stuff) like for adverse inputs? Thanks

/*
ID: albert.4
LANG: C
TASK: gift1
*/

#include <stdio.h>

You need in addition stdlib.h and string.h.

<snip code>

Jul 10 '08 #35

Bert said:

#include <stdio.h>

santosh has already pointed out that you're missing a couple of headers.

#define MAXNAMELEN 20

main()
{
/*************************************************/
struct friend {
int money, ngifts;

char name[MAXNAMELEN];
};

int NP;

Minor problem.

>
FILE* in = fopen("gift1.in" , "r");

Problem.

FILE* out = fopen("gift1.out", "w");

Problem.

>
fscanf(in, "%d", &NP);

Problem.

>

struct friend f[NP];

Your compiler *must* either diagnose the lack of an explicit return type
for main (C99) or the mixture of code and declarations (C90), so we know
you're posting code that doesn't compile cleanly. Why bother? First, fix
the stuff that can be diagnosed automatically.

int i = 0;

for (; i < NP; i++)
{
fscanf(in, "%s", f[i].name);

Two problems.

That'll do to be going on with. When you've got a clean compile and are at
least curious about the problems I've outlined above...

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 10 '08 #36

santosh

Bert wrote:

Well, this compiles on the compiler somewhere else wherever I sent
this to. Could you guys please point out which parts could be improved
oh and I just realised you're all professionals...um...could you
please INDICATE the points where I need to do all the error checking
like the try..catch kinda things for all kinds of exceptions (only C
doesn't have this cool stuff) like for adverse inputs? Thanks

C does not have support for exceptions so you need to check that each
library function you call has in fact succeeded. Each function has it's
own way of documenting failures; some return null pointers, others EOF,
still others return a count and so on. You should consult the
documentation for your Standard library and write in checks as
appropriate. A good on-line reference for the Standard library is
<http://www.dinkumware.com/manuals/>.

What you do when a function has failed will obviously be highly
dependant on the exact situation, but for small test programs (like
yours) you might want to print a useful message printing what went
wrong and where (function and source line number) and probably, exit.
Recovery strategies (even if they are possible) may be too advanced at
this point.

An example:

if (fscanf(file, "%d", &i) != 1) {
fprintf(stderr, "%s (%d): fscanf() failed.\n",
__FILE__, __LINE__);
exit(EXIT_FAILURE);
}

With C99 you can also use the predefined identifier __func__ to extract
the name of the current function (as a string).

For checking the internal consistency of the program you can use the
macro assert in assert.h. If the expression passed to assert evaluates
to zero (logically false), assert will print a message and abort the
program. You can define the macro NDEBUG *prior* to including assert.h
to turn off all assertions.

Many library functions also set the object 'errno' to some integer value
upon failure. To use this mechanism you need to include the header
errno.h and set errno to zero before the function in question is
called. Immediately after you need to check errno for the presence of
documented error values (like ERANGE, EDOM, EILSEQ and other
implementation defined values), and if so, take appropriate action. You
can translate the error codes in errno to implementation specific
messages using the strerror or perror.

In addition to all this C99 has added considerable diagnostic facilities
for floating point and maths functions; consult the Standard for
details.

Draft of C1x <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

<snip>

Jul 10 '08 #37

Bert

On Jul 10, 4:30 pm, Richard Heathfield <r...@see.sig.invalidwrote:
When you've got a clean compile and are at

least curious about the problems I've outlined above...

You're wrong!!!
LMFAO
http://albert.xtheunknown0.googlepages.com/home

Jul 10 '08 #38

santosh

Bert wrote:

On Jul 10, 4:30 pm, Richard Heathfield <r...@see.sig.invalidwrote:
When you've got a clean compile and are at
>least curious about the problems I've outlined above...

You're wrong!!!
LMFAO

*plonk*

<snip>

Jul 10 '08 #39

Bert said:

On Jul 10, 4:30 pm, Richard Heathfield <r...@see.sig.invalidwrote:
When you've got a clean compile and are at
>least curious about the problems I've outlined above...

You're wrong!!!

Nope. Here's a favourite Chris Torek quote:

"Someone once told me it's illegal to carry the ball around
the court in basketball [i.e., to walk or run without bouncing
the ball on the ground -- `dribbling']. Well, I tried it
last night, and it worked fine. I did not get arrested.
Whoever told me that must be an idiot!"

LMFAO
http://albert.xtheunknown0.googlepages.com/home

If you're getting a clean compile, your compiler is non-conforming. A
compiler that conforms to C90 must at the very least diagnose the mixed
code and declarations, and a compiler that conforms to C99 must at the
very least diagnose the lack of an explicit return type for main. A
compiler that diagnoses neither fails to conform to either C90 or C99, and
therefore cannot reasonably claim to be a modern C compiler.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 10 '08 #40

Bert

On Jul 10, 6:59 pm, Richard Heathfield <r...@see.sig.invalidwrote:

Bert said:

On Jul 10, 4:30 pm, Richard Heathfield <r...@see.sig.invalidwrote:
When you've got a clean compile and are at
least curious about the problems I've outlined above...

You're wrong!!!

Nope. Here's a favourite Chris Torek quote:

"Someone once told me it's illegal to carry the ball around
the court in basketball [i.e., to walk or run without bouncing
the ball on the ground -- `dribbling']. Well, I tried it
last night, and it worked fine. I did not get arrested.
Whoever told me that must be an idiot!"

LMFAO
http://albert.xtheunknown0.googlepages.com/home

If you're getting a clean compile, your compiler is non-conforming. A
compiler that conforms to C90 must at the very least diagnose the mixed
code and declarations, and a compiler that conforms to C99 must at the
very least diagnose the lack of an explicit return type for main. A
compiler that diagnoses neither fails to conform to either C90 or C99, and
therefore cannot reasonably claim to be a modern C compiler.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Try telling that to the competition organisers and let us know how you
go. Doing the stuff I do that ain't that great makes it sorta more
similar to C# which is a lot more fun btw, though slower. Do you
wanna tell me what to do about the problems cos it ain't in k&r, I've
never had anyone say what you said to me.
Oh, and you should get used to some programming comps.

Jul 10 '08 #41

Bert said:

On Jul 10, 6:59 pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>

>If you're getting a clean compile, your compiler is non-conforming. A
compiler that conforms to C90 must at the very least diagnose the mixed
code and declarations, and a compiler that conforms to C99 must at the
very least diagnose the lack of an explicit return type for main. A
compiler that diagnoses neither fails to conform to either C90 or C99,
and therefore cannot reasonably claim to be a modern C compiler.

Try telling that to the competition organisers and let us know how you
go.

What is your goal? To learn C, or to win a broken competition hosted by
people who don't understand the language? If it's the former, you should
start paying more attention to what you're told. If it's the latter, which
seems to be the case at the moment, I don't understand why you continue to
post in comp.lang.c.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 10 '08 #42

Bert

On Jul 10, 7:35 pm, Richard Heathfield <r...@see.sig.invalidwrote:

Bert said:

On Jul 10, 6:59 pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>

If you're getting a clean compile, your compiler is non-conforming. A
compiler that conforms to C90 must at the very least diagnose the mixed
code and declarations, and a compiler that conforms to C99 must at the
very least diagnose the lack of an explicit return type for main. A
compiler that diagnoses neither fails to conform to either C90 or C99,
and therefore cannot reasonably claim to be a modern C compiler.

Try telling that to the competition organisers and let us know how you
go.

What is your goal? To learn C, or to win a broken competition hosted by
people who don't understand the language? If it's the former, you should
start paying more attention to what you're told. If it's the latter, which
seems to be the case at the moment, I don't understand why you continue to
post in comp.lang.c.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Well there's no other resource for help with these programming
competitions. Like there's ONE book on amazon.com that is specifically
for programming comps and I haven't got it yet, I don't know any
websites that help, I don't know people who've won programming comps,
I'm by myself, I'm apparently talking to a person who doesn't really
like me who won't tell me or even try suggest me to me where to go for
other help, like the comp has really completely broken my attention to
the 'standard' form of coding in C, but as a teen I'm really bored,
there's nothing else good to do in IT while I'm still in high school
other than to learn a million apps, print hello world onto a console,
so I've found it necessary to do programming comps. Like no one else
at school does it, it sounds pretty fun. Like if I had to fix all the
problems you mentioned I'd have to buy some c texts and find that 1%
of it is currently what I need, another 1% from an algorithm book for
use in programming comps, and I can't buy a dozen expensive texts just
to get so little of it just because I don't do this for a living (NOT
YET). Like programming in C at my level ain't what a normal teenager
does but I like it so that renders what I said moot. Like I don't live
next door to any of youse, I can't go on MSN to talk about this, I
can't email you pplz, I have to wait an hour for a response from
someone (mode value). Like you guys don't credit what I write and I
understand why you don't and you have reasons that are far superior to
mine but I'm now no longer a total noob to C programming, not
professional yet either and it's kinda hard being in between. Maybe
you can recommend to me what I should do now assuming I continue
practicing for the programming comps.

Jul 10 '08 #43

Bert said:

On Jul 10, 7:35 pm, Richard Heathfield <r...@see.sig.invalidwrote:

<snip>

>What is your goal? To learn C, or to win a broken competition hosted by
people who don't understand the language? If it's the former, you should
start paying more attention to what you're told. If it's the latter,
which seems to be the case at the moment, I don't understand why you
continue to post in comp.lang.c.

Well there's no other resource for help with these programming
competitions.

This newsgroup is a resource for discussing the C language.

<snip>

I'm apparently talking to a person who doesn't really
like me

If you mean me, you are mistaken in thinking that I don't like you,
although I will acknowledge that I'm a little concerned at your apparent
unwillingness to accept the help that is offered.

who won't tell me or even try suggest me to me where to go for
other help,

You *are* getting help here. You just don't seem to be able to recognise
the fact.

<snip>

Like if I had to fix all the
problems you mentioned I'd have to buy some c texts

Not really (although that wouldn't hurt you, if you bought good C
textbooks, which is harder than it sounds); you could make a great start
just by applying the fixes we tell you about, and learn why they matter -
before long, it becomes second nature.

[...] I don't do this for a living (NOT YET).

If you want to program for a living, at some point you will need to learn
the difference between hack-n-slash coding and robust professional
programming.

[...] Like you guys don't credit what I write

Give us a reason to credit it, by taking and applying the advice that we
offer.

<snip>

Maybe
you can recommend to me what I should do now assuming I continue
practicing for the programming comps.

Yes, I can do that. I recommend that you start paying attention to what
we're saying, and applying those lessons to your code. Before long, you'll
find that you are writing better *and* faster C programs.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Jul 10 '08 #44

vi******@gmail.com writes:

On Jul 9, 11:26 am, Richard Heathfield <r...@see.sig.invalidwrote:
>vipps...@gmail.com said:

<snip>

Maybe I'm wrong and it is not a constraint violation!

It is.

gcc in C90 mode
only warns for this code:

int main(void) { int i = 10; char foo[i]; return 0; }

The code violates the constraint in 3.5.4.2 that "The expression that
specifies the size of an array shall be an integral constant expression
that has a value greater than zero" because i is not an integral constant
expression. (And no, making it const won't help.)

The gcc implementation, in issuing a diagnostic message, fulfils its
conformance obligations to you. Whether it calls the message a warning or
an error is irrelevant, as long as it issues the message.

Great, thanks. I always thought there are "error messages" and
"warning messages", such as that the compiler has to print at least
one of the former if a constraint violation/syntax error happends, and
that the compiler is free to print any number of the latter.
I have a question though, if warning messages (ie warning: text) are
allowed by the standard to be printed for constraint violations, how
can the programmer differentiate between a successfully compiled
program and one which had a syntax error or a constraint violation?
This is purely academic, of course all compilers will attempt to have
meaningful error/warning messages such that the programmer will
_receive_ information from them instead of confusion.

Typically, compilers do distinguish between error messages and warning
messages. The distinction is that (a) warning messages typically
begin with the word "warning", and (b) a warning doesn't cause
compilation to fail, but an error does.

I've seen even more distinctions than that. For example, a "fatal
error" might cause the compiler to immediately stop processing the
input file, an ordinary "error" might set an internal flag that will
cause compilation to fail, but the compiler continues to attempt to
process the rest of the source file (in an attempt to diagnose more
errors), a "warning" indicates a probable problem but doesn't cause
the compilation to fail, and an "informational message" is something
the compiler thinks you should know that isn't necessarily a problem
(these are often disabled by default).

The standard makes no such distinctions. It requires a "diagnostic
message" for any translation unit containing a constraint violation or
syntax error. The definition of "diagnostic message" is left entirely
up to the implementation. Additional diagnostics may be issued for
things that are not constraint violations or syntax errors; the
implementation needn't distinguish these. Once a required diagnostic
message has been issued, the compiler may or may not successfully
translate the source file; if it does so, the behavior of the
resulting program is undefined.

A compiler must fail to compile a source file containing a #error
directive (if it's not skipped by #if or #ifdef); that's the only case
where such a failure is required. A compiler must successfully
compile a source file that doesn't contain a #error directive, a
constraint violation, a syntax error, or anything that exceeds some
capacity limit.

There's a whole lot of wiggle room in between.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Jul 14 '08 #45

Chris Torek

In article <b5******************************@bt.com>
Richard Heathfield <rj*@see.sig.invalidwrote:

>Here's a favourite Chris Torek quote:

"Someone once told me it's illegal to carry the ball around
the court in basketball [i.e., to walk or run without bouncing
the ball on the ground -- `dribbling']. Well, I tried it
last night, and it worked fine. I did not get arrested.
Whoever told me that must be an idiot!"

Actually, that was my paraphrase of Steve Summit quoting yet another
person (Steve told me who but I have forgotten again).

It does illustrate, in an interesting way, what it means for code
to be "against the Standard". Code that violates various rules
may work just fine, as long as you do not get caught. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html

Jul 24 '08 #46