Endless loop question

[Tweaxor]

This has been puzzling me all this week. This is actually a homework
assignment
from last semesmter. But the teacher wouldn't tell us why certain
things didn't work, but it didn't just work. My thing was what
actually turn this while loop into an endless loop instead of waiting
for user response it'll would skip right over it. Could someone with
the time explain this to me what would make it behave like this
int pts1, pts2, pts3, wk_exp, p_pay, total_pts, total_pay;
char degree, again;

int main() {
char again = 'Y';

while (again != 'N')
{

printf("\nEnter degree type: (B for Bachelors), (M for Masters), (D
for Doctorate\n");
printf("\t\t\t: ");
scanf("%1c", &degree);
if (degree = 'B') {
pts1 = 3;
}
if (degree = 'M') {
pts1 = 5;
}
if (degree = 'D') {
pts1 =7;
}
printf("\nEnter number of years of work experience: ");
scanf("%2d",&wk_exp);
if (wk_exp <= 3) {
pts2 = 4;
}
if (wk_exp >= 4 && wk_exp <= 6) {
pts2 = 7;
}
if (wk_exp >= 7) {
pts2 = 10;
}

printf("\nEnter current Pay: ");
scanf("%5d",&p_pay);
if (p_pay <= 15000) {
pts3 = 4;
}
if (p_pay >= 15001 && p_pay <= 22500) {
pts3 = 8;
}
if (p_pay > 22500) {
pts3 = 12;
}

total_pts = pts1 + pts2 + pts3;
if (total_pts <= 19) {
total_pay = 25000;
}
if (total_pts >= 20 && total_pts <= 28) {
total_pay = 30000;
}
else if (total_pts >= 29) {
total_pay = 35000;
}

printf("\nThe pay rate is: %d\n",total_pay);

printf("\nWant to do this again? Press N for NO: ");
/*scanf("%1c", &again); */
getchar();
}

return (0) ;
}

[Mark A. Odell]

ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

This has been puzzling me all this week. This is actually a homework
assignment
from last semesmter. But the teacher wouldn't tell us why certain
things didn't work, but it didn't just work. My thing was what
actually turn this while loop into an endless loop instead of waiting
for user response it'll would skip right over it. Could someone with
the time explain this to me what would make it behave like this

None of these seem to need to be defined outside of main().
int pts1, pts2, pts3, wk_exp, p_pay, total_pts, total_pay;
char degree, again;

int main() { Ick ^^^^^^^^

int main(void)
{
char again = 'Y';

while (again != 'N')
{
/*scanf("%1c", &again); */
getchar();
}

return (0) ;

}

Since again is initially == 'Y', explain how again will ever be anything
but 'Y'. Then see why the while loop becomes endless.

--
- Mark ->
--

[S.Tobias]

Mark A. Odell <od*******@hotmail.com> wrote:

ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

int main() {

Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Alan Balmer]

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Mark A. Odell <od*******@hotmail.com> wrote:

ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

> int main() {

Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dave Vandervies]

In article <07********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Mark A. Odell <od*******@hotmail.com> wrote:

ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

> int main() {
Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

In this case, though, the distinction doesn't make any difference; one
form means "Here's the definition of a function called main, returning
int and taking no arguments, without a prototype" and the other form
means "Here's the definition of a function called main, returning int
and taking no arguments, with a prototype".

Unless, of course, you're planning on calling main later on with a
nonempty argument list. But if you really want to lie to the compiler,
a prototype won't stop you either.
dave
((int (*)())main)(argv,argc);

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Shoot. Maybe I should port [GCC] to MMIX to get some [experience]
on my own.
--Ben Pfaff in comp.lang.c

[S.Tobias]

Alan Balmer <al******@att.net> wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

In declarations that are not definitions.

What can be unspecified in function definition?
int f() {}

Grep through n869.txt - there are two examples using "int main()"
(and one "int main(void)") declaration. They wouldn't miss an error
like that, would they?

--
Stan Tobias
sed 's/[A-Z]//g' to email

[187]

Alan Balmer wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Mark A. Odell <od*******@hotmail.com> wrote:

ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

int main() {
Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

but when it coems down to it, I've never seen any difference in actual
behavior between the two. When it comes to normal functions, there is no
difference.

[Flash Gordon]

On Wed, 29 Sep 2004 18:30:11 +0000 (UTC)
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote:

In article <07********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Mark A. Odell <od*******@hotmail.com> wrote:
ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

> int main() {
Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?
They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are
unspecified.

In this case, though, the distinction doesn't make any difference; one
form means "Here's the definition of a function called main, returning
int and taking no arguments, without a prototype" and the other form
means "Here's the definition of a function called main, returning int
and taking no arguments, with a prototype".

So why not give the compiler all the information you have? It's
generally a good habit and if you[1] break it for main you are likely to
break it for other functions.
Unless, of course, you're planning on calling main later on with a
nonempty argument list. But if you really want to lie to the
compiler, a prototype won't stop you either.

Actually, if there is a prototype in scope and you pass an incorrect
number of parameters the compiler is (I believe) *required* to produce a
diagnostic.

[1] The generic you, not the specific you.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Mark A. Odell]

"S.Tobias" <sN*******@amu.edu.pl> wrote in
news:2s*************@uni-berlin.de:

> int main() {

Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

I just said "Ick", it's not wrong, just lazy IMHO.

--
- Mark ->
--

[Alan Balmer]

On 29 Sep 2004 19:00:34 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

>No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

In declarations that are not definitions.

What can be unspecified in function definition?
int f() {}

Grep through n869.txt - there are two examples using "int main()"
(and one "int main(void)") declaration. They wouldn't miss an error
like that, would they?

The examples are not the standard. Your copy of the draft probably
includes section 5.1.2.2.1, paragraph 1, which gives the two allowable
forms, plus allows other *implementation-defined* forms. If the OP's
implementation documents that usage, it's OK. It probably doesn't.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On Wed, 29 Sep 2004 12:34:22 -0700, "187"
<bi******@invalid.rx.eastcoasttfc.com> wrote:

Alan Balmer wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Mark A. Odell <od*******@hotmail.com> wrote:
ph****@yahoo.com (Tweaxor) wrote in
news:1c**************************@posting.google.c om:

> int main() {
Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

but when it coems down to it, I've never seen any difference in actual
behavior between the two. When it comes to normal functions, there is no
difference.

If your compiler is paying attention, you should see a difference. If
you use "void", the compiler should complain when you invoke the
function with a parameter.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dave Vandervies]

In article <ie************@brenda.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:

On Wed, 29 Sep 2004 18:30:11 +0000 (UTC)
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote:

In article <07********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:

>On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:
>
>>Mark A. Odell <od*******@hotmail.com> wrote:
>>> ph****@yahoo.com (Tweaxor) wrote in
>>> news:1c**************************@posting.google.c om:
>>
>>> > int main() {
>>> Ick ^^^^^^^^
>>
>>> int main(void)
>>> {
>>
>>No, why? You can drop `void' in function definition, can't you?
>
>They mean different things. '(void)' tells the compiler there are no
>arguments. '()' tells the compiler that the arguments are
>unspecified.

In this case, though, the distinction doesn't make any difference; one
form means "Here's the definition of a function called main, returning
int and taking no arguments, without a prototype" and the other form
means "Here's the definition of a function called main, returning int
and taking no arguments, with a prototype".

So why not give the compiler all the information you have? It's
generally a good habit and if you[1] break it for main you are likely to
break it for other functions.

Since main is already special in other ways, and since it's quite rare
for a programmer to write code that calls it, I don't see this as being
worth even an "Ick", only a "It's generally considered good form to
write this as..." (if even that).

(I would be entirely unsurprised to find that a large proportion, perhaps
even a majority, of programmers think of "int main()" (or "main()") as
"Define the entry point of this program" rather than "Define a function
called main [which happens to be the entry point of this program]",
so not writing a full prototype definition for main doesn't necessarily
indicate sloppiness that would carry over to writing other functions.)

Unless, of course, you're planning on calling main later on with a
nonempty argument list. But if you really want to lie to the
compiler, a prototype won't stop you either.

Actually, if there is a prototype in scope and you pass an incorrect
number of parameters the compiler is (I believe) *required* to produce a
diagnostic.

....if you call it through the function name given in the prototype and
not, say, cast it to a nonprototyped function pointer type and call
through that.

Like I said, if you really want to lie to the compiler, a prototype
won't stop you.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Shoot. Maybe I should port [GCC] to MMIX to get some [experience]
on my own.
--Ben Pfaff in comp.lang.c

[Flash Gordon]

On Wed, 29 Sep 2004 20:22:20 +0000 (UTC)
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote:

In article <ie************@brenda.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:

On Wed, 29 Sep 2004 18:30:11 +0000 (UTC)
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote:
<snip int main() vs int main(void)

So why not give the compiler all the information you have? It's
generally a good habit and if you[1] break it for main you are likely
to break it for other functions.
Since main is already special in other ways, and since it's quite rare
for a programmer to write code that calls it, I don't see this as
being worth even an "Ick", only a "It's generally considered good form
to write this as..." (if even that).

(I would be entirely unsurprised to find that a large proportion,
perhaps even a majority, of programmers think of "int main()" (or
"main()") as"Define the entry point of this program" rather than
"Define a function called main [which happens to be the entry point of
this program]",

I agree so far.
so not writing a full prototype definition for main
doesn't necessarily indicate sloppiness that would carry over to
writing other functions.)
Unfortunately it seems like a lot of programmers think of () as the
parameter list for no parameters.

Unless, of course, you're planning on calling main later on with a
nonempty argument list. But if you really want to lie to the
compiler, a prototype won't stop you either.

Actually, if there is a prototype in scope and you pass an incorrect
number of parameters the compiler is (I believe) *required* to
produce a diagnostic.

...if you call it through the function name given in the prototype and
not, say, cast it to a nonprototyped function pointer type and call
through that.

Precisely. It means you have to work to do it, whereas not specifying
the parameter list makes calling a function (even main) with incorrect
parameters all too easy.
Like I said, if you really want to lie to the compiler, a prototype
won't stop you.

In that case I suggest you disable all warnings possibly on your
compiler since you can always find a way of achieving the same effect
without invoking the warnings.

In the mean time I will try to make the compiler warn me about all the
problems it can be made to detect (which don't generate spurious
warnings) since it generally improves code quality.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[S.Tobias]

Alan Balmer <al******@att.net> wrote:

On 29 Sep 2004 19:00:34 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote:

On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

>No, why? You can drop `void' in function definition, can't you?

They mean different things. '(void)' tells the compiler there are no
arguments. '()' tells the compiler that the arguments are unspecified.

In declarations that are not definitions.

What can be unspecified in function definition?
int f() {}

Grep through n869.txt - there are two examples using "int main()"
(and one "int main(void)") declaration. They wouldn't miss an error
like that, would they?

The examples are not the standard. Your copy of the draft probably
True. If that's so then faq is also guilty, and K&R2 is
the greatest offender.
includes section 5.1.2.2.1, paragraph 1, which gives the two allowable
forms, plus allows other *implementation-defined* forms.
.... or equivalent, you forgot to add.
implementation documents that usage, it's OK. It probably doesn't.

6.7.5.3

10 The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters.

14 [...] An empty list in a function declarator that is part of a
definition of that function specifies that the function has no
parameters. The empty list in a function declarator that is not part
of a definition of that function specifies that no information about
the number or types of the parameters is supplied.

If
void f() {}
and
void f(void) {}
are not equivalent, then my brain must be seriously in trouble.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Alan Balmer]

On 30 Sep 2004 00:36:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote:

On 29 Sep 2004 19:00:34 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

>Alan Balmer <al******@att.net> wrote:
>> On 29 Sep 2004 18:11:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:
>
>> >No, why? You can drop `void' in function definition, can't you?
>
>> They mean different things. '(void)' tells the compiler there are no
>> arguments. '()' tells the compiler that the arguments are unspecified.
>
>In declarations that are not definitions.
>
>What can be unspecified in function definition?
>int f() {}
>
>Grep through n869.txt - there are two examples using "int main()"
>(and one "int main(void)") declaration. They wouldn't miss an error
>like that, would they?

The examples are not the standard. Your copy of the draft probably

True. If that's so then faq is also guilty, and K&R2 is
the greatest offender.

includes section 5.1.2.2.1, paragraph 1, which gives the two allowable
forms, plus allows other *implementation-defined* forms.

... or equivalent, you forgot to add.

implementation documents that usage, it's OK. It probably doesn't.

6.7.5.3

10 The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters.

14 [...] An empty list in a function declarator that is part of a
definition of that function specifies that the function has no
parameters. The empty list in a function declarator that is not part
of a definition of that function specifies that no information about
the number or types of the parameters is supplied.

If
void f() {}
and
void f(void) {}
are not equivalent, then my brain must be seriously in trouble.

First, this has nothing to do with the standard's specification of the
"main" function. Second, read again what you quoted above, carefully.
It tells you what the difference is and where it applies.

Bottom line: if you have a function which takes no parameters, it is
never wrong to use "void" in its declarator. If you do, the compiler
will check for proper usage. It really takes little extra effort, and
is not worth discussing further.

--
Al Balmer
Balmer Consulting
re************************@att.net

[S.Tobias]

Alan Balmer <al******@att.net> wrote:

On 30 Sep 2004 00:36:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote:

includes section 5.1.2.2.1, paragraph 1, which gives the two allowable
forms, plus allows other *implementation-defined* forms.
... or equivalent, you forgot to add. ^^^^^^^^^^^^^6.7.5.3 [snip]
void f() {}
void f(void) {}

....are equivalent. If not, then why?
First, this has nothing to do with the standard's specification of the
"main" function.
I don't understand you. Of course the quotes didn't directly concern
main() definition. They only determined that the above function
definitions (one with, and one without prototype) were equivalent,
because they specified exactly same thing: no parameters.

5.1.2.2.1 mentions that main() definition may have equivalent form.
Therefore
int main() {...}
is as good as
int main(void) {...}

I don't see why one could not connect those two facts.
Bottom line: if you have a function which takes no parameters, it is
never wrong to use "void" in its declarator.
But I have never said it's wrong. All I have said is that you can
drop `void' from main() (or any other function) *definition*.
If you do, the compiler
will check for proper usage. It really takes little extra effort, and
is not worth discussing further.

Well, it's definitely not a problem for the compiler. But you have
seeded doubt in my mind, and I ask you to convince me I was wrong.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Old Wolf]

"S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote:
"S.Tobias" <sN*******@amu.edu.pl> wrote:

5.1.2.2.1 mentions that main() definition may have equivalent form.
Therefore
int main() {...}
is as good as
int main(void) {...}

They are not equivalent (as I will demonstrate below)

Bottom line: if you have a function which takes no parameters, it is
never wrong to use "void" in its declarator.

But I have never said it's wrong. All I have said is that you can
drop `void' from main() (or any other function) *definition*.

If you do, the compiler
will check for proper usage. It really takes little extra effort, and
is not worth discussing further.

Well, it's definitely not a problem for the compiler. But you have
seeded doubt in my mind, and I ask you to convince me I was wrong.

int main()
{
return 0;
}

void foo()
{
main("muahaha!");
foo(1);
foo(2,3);
}

This compiles without error (and gives undefined behaviour
at runtime). It would give a compile error if you added 'void'
to the definition of main or foo.

[Method Man]

> Since main is already special in other ways, and since it's quite rare

for a programmer to write code that calls it, I don't see this as being
worth even an "Ick", only a "It's generally considered good form to
write this as..."
Agreed.
(if even that).

It's worth mentioning so that a beginner can start writing code with proper
style eventhough he may not understand all the reasons for it at first.

[j0mbolar]

"S.Tobias" <sN*******@amu.edu.pl> wrote in message news:<2s*************@uni-berlin.de>...

Alan Balmer <al******@att.net> wrote:

On 30 Sep 2004 00:36:07 GMT, "S.Tobias" <sN*******@amu.edu.pl> wrote:

Alan Balmer <al******@att.net> wrote: includes section 5.1.2.2.1, paragraph 1, which gives the two allowable
> forms, plus allows other *implementation-defined* forms.

... or equivalent, you forgot to add. ^^^^^^^^^^^^^6.7.5.3 [snip]
void f() {}
void f(void) {}

...are equivalent. If not, then why?

First, this has nothing to do with the standard's specification of the
"main" function.

I don't understand you. Of course the quotes didn't directly concern
main() definition. They only determined that the above function
definitions (one with, and one without prototype) were equivalent,
because they specified exactly same thing: no parameters.

5.1.2.2.1 mentions that main() definition may have equivalent form.
Therefore
int main() {...}
is as good as
int main(void) {...}

I don't see why one could not connect those two facts.

Bottom line: if you have a function which takes no parameters, it is
never wrong to use "void" in its declarator.

But I have never said it's wrong. All I have said is that you can
drop `void' from main() (or any other function) *definition*.

If you do, the compiler
will check for proper usage. It really takes little extra effort, and
is not worth discussing further.

Well, it's definitely not a problem for the compiler. But you have
seeded doubt in my mind, and I ask you to convince me I was wrong.

Well, according to 6.7.5.3#14, I think it makes it
pretty clear that int main() semantically acts the same
as int main(void) but as though there was an explicit void.

As such, the compiler should realize that
int main() accepts no arguments and therefore
whenever used recursively(with arguments),
should produce some error.

However, 6.11.6 considers this usage to be
obsolescent so probably best avoided but
in actuality will more than likely
remain in the language.

Is this analysis correct?

[S.Tobias]

Old Wolf <ol*****@inspire.net.nz> wrote:

"S.Tobias" <sN*******@amu.edu.pl> wrote:

5.1.2.2.1 mentions that main() definition may have equivalent form.
Therefore
int main() {...}
is as good as
int main(void) {...}

They are not equivalent (as I will demonstrate below)

[snip]

Thank you!

They are equivalent as to what they define, but not what they declare
(different types and consequences). Put together: not equivalent.

void f() { f(1); } // UB
void f(void) { f(1); } // diagnostics

OTOH, if the Standard makes so much effort to handle functions
without prototype (I gather this is for pre-ANSI compilers, that
didn't have them back then), I can't imagine why it should make
specifically non-prototype main() definition undefined.

I think I'm going to ask it in c.s.c.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[S.Tobias]

Mark A. Odell <od*******@hotmail.com> wrote:

"S.Tobias" <sN*******@amu.edu.pl> wrote in
news:2s*************@uni-berlin.de:

> int main() {
Ick ^^^^^^^^

int main(void)
{

No, why? You can drop `void' in function definition, can't you?

I withdraw what I have said above, I might have been wrong, I'm sorry.
As a matter of fact, I'm not yet sure on either side, but it seems
very probable that the "Ick" was valid here.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Dave Thompson]

On 29 Sep 2004 10:12:59 -0700, ph****@yahoo.com (Tweaxor) wrote:

This has been puzzling me all this week. This is actually a homework
assignment
from last semesmter. But the teacher wouldn't tell us why certain
things didn't work, but it didn't just work. My thing was what
actually turn this while loop into an endless loop instead of waiting
for user response it'll would skip right over it. Could someone with
the time explain this to me what would make it behave like this <snip> int main() {
char again = 'Y';
Aside from your inconsistent and sometimes odd layout, which makes
your code hard(er) to read, so I suggest you work on that:
while (again != 'N')
{

printf("\nEnter degree type: (B for Bachelors), (M for Masters), (D
for Doctorate\n");
printf("\t\t\t: ");
scanf("%1c", &degree); <snip> printf("\nEnter number of years of work experience: ");
scanf("%2d",&wk_exp); <snip> printf("\nEnter current Pay: ");
scanf("%5d",&p_pay); <snip> printf("\nWant to do this again? Press N for NO: ");
/*scanf("%1c", &again); */
getchar();
This reads a character but doesn't do anything with it, in particular
it doesn't store to 'again', so the loop continues. You probably meant

again = getchar();

But once you do that, or if you do the scanf("%1c",&again) instead --
or it could be just %c, 1 is the default width for that specifier --
you will find that the loop _always_ exits because the character you
read is the newline (or perhaps other garbage character) following the
pay value, because the scanf %d above reads only through the end of
the number leaving any other input, in particular the newline,
buffered for later reads. This is (almost) 12.18 in the FAQ, in the
usual places and at http://www.eskimo.com/~scs/C-faq/top.html .

scanf has other "features" that can be problematical as well, (many)
also detailed in that part of the FAQ. Especially if you fail to check
its return value, as you did.

The way of doing input usually recommended here is to read each line
into a buffer with fgets(), and then pick the desired data value(s)
out of it with sscanf() (note the addtional s -- that's scan formatted
_from string_) or sometimes explicit code and/or other functions like
strto[u]l[l](), strtok(), strchr(), str[c]spn(), etc. Even that isn't
perfect, if you (might) get input lines longer than your fixed-size
buffer, but that gets into complications I suggest you leave aside for
now and come back to later when you are a little more experienced.
}

- David.Thompson1 at worldnet.att.net

[Kevin Bracey]

In message <2d**************************@posting.google.com >
j0******@engineer.com (j0mbolar) wrote:

Well, according to 6.7.5.3#14, I think it makes it
pretty clear that int main() semantically acts the same
as int main(void) but as though there was an explicit void.

We've just had this discussion on comp.std.c throughout September. I suggest
you check the thread "main prototype" on Google. I don't feel like going
through it again.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Old Wolf]

Kevin Bracey <ke**********@tematic.com> wrote:

j0******@engineer.com (j0mbolar) wrote:

Well, according to 6.7.5.3#14, I think it makes it
pretty clear that int main() semantically acts the same
as int main(void) but as though there was an explicit void.

We've just had this discussion on comp.std.c throughout September. I suggest
you check the thread "main prototype" on Google. I don't feel like going
through it again.

That thread didn't explicitly answer the question of whether
int main() { ... violates 5.1.2.2.1 (the bit that says
main must be either int main(void) or int main(int, char **)
or equivalents). In other words, is a compiler allowed to
reject int main().

The majority view seemed to be that int main() and int main(void)
were equivalent as a part of the function definition, but did
not provide an equivalent prototype. So does it constitute
an "equivalent" as worded in 5.1.2.2.1? (And what's the wording
in C90 and does it comply with that?)

[Douglas A. Gwyn]

Old Wolf wrote:

... In other words, is a compiler allowed to
reject int main().

No, conforming compilers accept int main() { whatever }
as a valid function definition. That also qualifies as
one of the two accepted shapes for the main function
invoked to start the program by a hosted implementation.