float pointers

[ehabaziz2001]

That program does not yield and respond correctly espcially for the
pointers (*f),(*i)
in
print_divide_meter_into(&meter,&yds,&ft,&ins);

/*--------------pnt02own.c------------
---1 inch = 2.51 cm
---1 inch = 2.54/100 Meter
---1 yard = 3 feet
---1 feet = 12 inch
---inches=meter/0.0254
---feets =meter/0.3048 (0.0254 * 12)
---yards =meter/0.9144 (0.0254 * 36)
---meter=1/0.0254=39.3700 INCH
---meter=1/0.3048=3.28084 FEET
---meter=1/0.9144=1.09361 YARDS
----------------------------------------------*/
#include "stdio.h"
/*Module 2 : using pointers in a function to convert Size Entry
in meter to sizes of Yards,feet,inches-----*/


main()
{
float meter;
float yds,ft,ins;
char another();
system("cls");
do {
input_meter(&meter);
divide_meter_into(&meter,&yds,&ft,&ins);
print_divide_meter_into(&meter,&yds,&ft,&ins);
} while (another()=='y');
return 0;
}

input_meter(float *m)
{
printf("\nEnter size in meter :");
scanf("%f",&(*m));
printf("\nYou have Entered % f",*m);
}

divide_meter_into(float *m,float *y,float *f,float *i)
{
float temp_m=0;
temp_m=(*m)*100.0/2.54;
(*y)=(temp_m)/36.0;
(temp_m)=(temp_m)-(*y)*36.0;
(*f)=(temp_m)/12.0;
(*i)=(temp_m)-(*f)*12.0;
printf("\n Meter %f is = %f yards %f feet %f
inches",(*m),(*y),(*f),(*i));
}

print_divide_meter_into(float *m,float *y,float *f,float *i)
{
printf("\n Meter %f is = %f yards %f feet %f
inches",(*m),(*y),(*f),(*i));
}

char another()
{
char answer;
printf("\n do ou want to procees (y/n)");
scanf("\n");
scanf("%c",&answer);
return (answer);
}

 

[Mark McIntyre]

On 10 Jan 2006 13:34:36 -0800, in comp.lang.c , (e-mail address removed)
wrote:

Turn up warninglevels in your compiler, as high as they'll go, and fix
all the errors it now shows you.

main()

int main(). Since 1989, its been considered incorrect to use implicit
int.

{
float meter;
float yds,ft,ins;

FYI, most people advise not to use floats for maths, they're too
imprecise.

char another();

don't declare functions inside other functions - this isn't supported
in C, and serves no useful purpose.

system("cls");

you don't include the header required for system(), so this won't
compile.

do {
input_meter(&meter);

Your compiler must have complained about this line.... You must
declare or prototype the function before you can use it. If you don't
do that, then the arguments are "promoted" according to some rules
that will cause you problems - floats are promoted to doubles, but
input_meter expects floats, so it will get bad data since floats are
not doubles....

divide_meter_into(&meter,&yds,&ft,&ins);
print_divide_meter_into(&meter,&yds,&ft,&ins);

same problem for these two...

} while (another()=='y');
return 0;
}

input_meter(float *m)

again, inplicit int. Don't do that - either return void or return an
int. In this case, void is good.

void input_meter(float * m)

{
printf("\nEnter size in meter :");
scanf("%f",&(*m));

scanf("%f", m);

& and * cancel out. So just "m" will work fine (though if you use
doubles, you'll want %lf).

Mind you, scanf is not a safe function. Try typing in "foo" or just
hitting enter. Read the FAQ for further comments on that.

printf("\nYou have Entered % f",*m);
}

divide_meter_into(float *m,float *y,float *f,float *i)
{
float temp_m=0;
temp_m=(*m)*100.0/2.54;

100.0 is a double, and your compiler will complain about this since
you're converting a double into a float and possibly losing data.
Another reason its easier to use doubles. Also the brackets round *m
are not needed. Use whitespace if you want to make it clearer

(*y)=(temp_m)/36.0;

the brackets....

(temp_m)=(temp_m)-(*y)*36.0;

and more brackets...

Oh, and your logic is wrong here - for any y, temp_m==0, not what you
want. Work it out on paper.

(*f)=(temp_m)/12.0;
brackets...


etc

printf("\n Meter %f is = %f yards %f feet %f inches",(*m),(*y),(*f),(*i));

yet more unneeded brackets....

print_divide_meter_into(float *m,float *y,float *f,float *i)

no need to pass pointers here, you're not modifying what they point
to.

{
printf("\n Meter %f is = %f yards %f feet %f inches",(*m),(*y),(*f),(*i));

again unneccessary brackets

Mark McIntyre

 

[Default User]

That program does not yield and respond correctly espcially for the
pointers (*f),(*i)

What does this mean? What did you expect it to do? What did it actually
do?

We aren't mind readers.



Brian

 

[Michael Mair]

That program does not yield and respond correctly espcially for the
pointers (*f),(*i)
in
print_divide_meter_into(&meter,&yds,&ft,&ins);

Please post code that compiles.
Yours did not.
If I fix that and all warnings:

#include "stdio.h"
/*Module 2 : using pointers in a function to convert Size Entry
in meter to sizes of Yards,feet,inches-----*/

void input_meter(float *m);
void divide_meter_into(float *m,float *y,float *f,float *i);
void print_divide_meter_into(float *m, float *y, float *f, float *i);
char another (void);

int main (void)
{
float meter;
float yds,ft,ins;
char another();

/* system("cls");
*/
do {
input_meter(&meter);
divide_meter_into(&meter,&yds,&ft,&ins);
print_divide_meter_into(&meter,&yds,&ft,&ins);
} while (another() == 'y');

return 0;
}

void input_meter(float *m)
{
printf("\nEnter size in meter :");
scanf("%f",&(*m));
printf("\nYou have Entered % f",*m);
}

void divide_meter_into(float *m,float *y,float *f,float *i)
{
float temp_m=0;

temp_m=(*m)*100.0/2.54;
(*y)=(temp_m)/36.0;
(temp_m)=(temp_m)-(*y)*36.0;
(*f)=(temp_m)/12.0;
(*i)=(temp_m)-(*f)*12.0;
}

void print_divide_meter_into(float *m, float *y, float *f, float *i)
{
printf("\n Meter %f is = %f yards %f feet"
" %f inches",(*m),(*y),(*f),(*i));
}

char another (void)
{
char answer;

printf("\n do ou want to procees (y/n)");
scanf("\n");
scanf("%c",&answer);

return (answer);
}


Back to the original problem:

divide_meter_into(float *m,float *y,float *f,float *i)
{
float temp_m=0;
temp_m=(*m)*100.0/2.54;
(*y)=(temp_m)/36.0;
(temp_m)=(temp_m)-(*y)*36.0;

Here, you try to calculate
temp_m = temp_m - (temp_m/36.0)*36.0;
Guess what.

(*f)=(temp_m)/12.0;
(*i)=(temp_m)-(*f)*12.0;
printf("\n Meter %f is = %f yards %f feet %f
inches",(*m),(*y),(*f),(*i));
}

<snip!>

What are you trying to do?
If you want integer division, use integers, "/" and "%".

The version I think you want:

#include "stdio.h"
#include "ctype.h"
#include "limits.h"


#define METER_PER_INCH 0.0254


typedef struct {
double meter;
struct {
double inch;
long int yard;
unsigned char foot;
} imperial;
} metric_imp;

int input_meter (double *meters);
void cleanup_stdin (void);
void calculate_yfi (metric_imp *in);
void print_metric_imp (metric_imp *in);
int do_another (void);

int main (void)
{
metric_imp input = {0};

do {
if (input_meter(&input.meter)) {
calculate_yfi(&input);
print_metric_imp(&input);
}
cleanup_stdin();
} while (do_another());

return 0;
}

int input_meter(double *m)
{
printf("\nEnter size in meter: ");
fflush(stdout);
if (1 == scanf("%lf", m)) {
return 1;
}
else {
fprintf(stderr, "Input error\n");
return 0;
}
}

void cleanup_stdin (void)
{
int c;

while (EOF != (c=getchar()))
if (c=='\n')
break;
}

void calculate_yfi (metric_imp *in)
{
in->imperial.inch = in->meter / METER_PER_INCH;

if (in->imperial.inch >= 0
&& in->imperial.inch/36 < LONG_MAX)
{
in->imperial.yard = in->imperial.inch/36;
in->imperial.inch -= in->imperial.yard*36.0;
in->imperial.foot = in->imperial.inch/12;
in->imperial.inch -= in->imperial.foot*12.0;
}
else {
in->imperial.yard = in->imperial.foot = 0;
}
}

void print_metric_imp (metric_imp *in)
{
printf("\n Meter %g is = %ld yards %d feet"
" %g inches\n",
in->meter, in->imperial.yard,
(int)in->imperial.foot, in->imperial.inch);
}

int do_another (void)
{
int answer;

printf("\n Do you want to proceed (y/n)? ");
fflush(stdout);
answer = getchar();
cleanup_stdin();

return EOF != answer && 'y' == tolower(answer);
}

 

[Eric Sosman]

Mark McIntyre wrote On 01/10/06 17:34,:

On 10 Jan 2006 13:34:36 -0800, in comp.lang.c , (e-mail address removed)
wrote:

Turn up warninglevels in your compiler, as high as they'll go, and fix
all the errors it now shows you.




int main(). Since 1989, its been considered incorrect to use implicit
int.

s/8/9/ or s/correct/advisable/.

FYI, most people advise not to use floats for maths, they're too
imprecise.

"Most people" don't know what they're talking about.
Besides, precision is clearly not the O.P.'s biggest worry
(contemplate the table of equivalences at the start of
his code, and ponder how NASA lost a Mars probe ...)

don't declare functions inside other functions - this isn't supported
in C, and serves no useful purpose.

It's perfectly legal to declare (not define) one function
inside another, and it serves the useful purpose of providing
a declaration. It's certainly not the best way to do things,
but it is "supported by C."

you don't include the header required for system(), so this won't
compile.

Legal under C89 rules. Not advisable, but legal.

Your compiler must have complained about this line.... You must
declare or prototype the function before you can use it.

That's the C99 rule, but C89 didn't (or "doesn't," in
what I'm guessing about the O.P.'s case) doesn't require it.
It's still a good idea to declare before use, but C89 doesn't
make it mandatory.

If you don't
do that, then the arguments are "promoted" according to some rules
that will cause you problems - floats are promoted to doubles, but
input_meter expects floats, so it will get bad data since floats are
not doubles....

I was just going to let the whole message slide by until
this piece of misleading misinformation caught my eye. Please
note that pointers are not subject to promotion, not ever.
Since `meter' is a float, `&meter' is a float*, and that's
exactly what input_meter() expects to receive. There's no
promotion, no bad data, and no error in this line.

same problem for these two...

Same non-problem for these two.

again, inplicit int. Don't do that - either return void or return an
int. In this case, void is good.

void input_meter(float * m)




scanf("%f", m);

& and * cancel out. So just "m" will work fine (though if you use
doubles, you'll want %lf).

Mind you, scanf is not a safe function. Try typing in "foo" or just
hitting enter. Read the FAQ for further comments on that.




100.0 is a double, and your compiler will complain about this since
you're converting a double into a float and possibly losing data.
Another reason its easier to use doubles. Also the brackets round *m
are not needed. Use whitespace if you want to make it clearer

Some compilers may complain about converting a double
to a float (one even complained about `float f = 0.0;'),
but no complaint is required and the language permits the
conversion.

[remainder snipped]

 

[Old Wolf]

#include "stdio.h"
#include "ctype.h"
#include "limits.h"

typedef struct {
double meter;
struct {
double inch;
long int yard;
unsigned char foot;
} imperial;
} metric_imp;

void calculate_yfi (metric_imp *in);

I can't agree with this design choice. In general, you don't want to
maintain a value in both metric form and imperial form. You have
a value of one or the other, and convert it as need be.

Also using only one byte for foot is perhaps questionable (due to
overflow risk).

I would far prefer:

struct imperial
{
double inch;
int foot;
long yard;
};

void calculate_yfi( double metric, struct imperial *imp );

This also has the advantage that 'metric' cannot be modified
by the function.

In fact I would personally go for:

struct imperial calculate_yfi( double metric)

but I could understand if you don't like passing structures
by value.

while (EOF != (c=getchar()))
if (c=='\n')
break;

Strange that one of the tests is in the while condition and one of
them is in the body -- I'd prefer to see either both in the condition
or both in the body.

return EOF != answer && 'y' == tolower(answer);

tolower(EOF) is defined as returning EOF. So simply:

return 'y' == tolower(answer);

 

[Michael Mair]

Causes UB. Should be <stdio.h> etc.

AFAIK, this is implementation defined at best, as
after not finding things in implementation defined
places, #include "foo" is processed as #include <foo>.

However, you are right; I just took the OP's program
and modified it.

I can't agree with this design choice. In general, you don't want to
maintain a value in both metric form and imperial form. You have
a value of one or the other, and convert it as need be.

You are right. I just typed ahead and changed the OP's programme
as I went without giving appropriate consideration to it.
I just wanted to show the OP a slightly different way.

Also using only one byte for foot is perhaps questionable (due to
overflow risk).

Well, the way I proceed, inch is my base unit and I have
at most 2 ft.

I would far prefer:

struct imperial
{
double inch;
int foot;
long yard;
};

void calculate_yfi( double metric, struct imperial *imp );

This is a much better interface.

This also has the advantage that 'metric' cannot be modified
by the function.

In fact I would personally go for:

struct imperial calculate_yfi( double metric)

but I could understand if you don't like passing structures
by value.

Hmmm, I am a friend of being able to return the error status.

Strange that one of the tests is in the while condition and one of
them is in the body -- I'd prefer to see either both in the condition
or both in the body.

This is a matter of taste, so I won't discuss it

tolower(EOF) is defined as returning EOF. So simply:

return 'y' == tolower(answer);

True; I did not look it up.

Thank you for the corrections!


Cheers
Michael

 

[Mark McIntyre]

Causes UB. Should be <stdio.h> etc.

No, the "" notation causes the compiler to search for headers in an
implementation defined manner, or if the compiler chooses, identically
to <> (6.10.2 p3).
Mark McIntyre

 

[Mark McIntyre]

On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman

(okay, I'll bite)

Mark McIntyre wrote On 01/10/06 17:34,:

s/8/9/ or s/correct/advisable/.

I disagree. Even though C89 allowed implicit int, its been considered
a naughty thing to rely on for decades. Sure, you can do it. You can
also toboggan in the nude.

"Most people" don't know what they're talking about.

I'm sure I've no need to point you at Goldberg. However if the above
is truly your opinion, I can only assume you do very very little
maths. However I'm not here to educate you, you're a big boy.

Besides, precision is clearly not the O.P.'s biggest worry
(contemplate the table of equivalences at the start of
his code, and ponder how NASA lost a Mars probe ...)

Oh, sure, whch is why it was an FYI. I wanted to save him some pain
later on, when he tried some *real* maths.

It's perfectly legal to declare (not define) one function
inside another,

my understanding was that it was a GCC extension, but if you can
provide me a refrence in the standard, I'm happy to be corrected.

But I am also astonished that you encourage the practice by your
remarks below. I thought you a better programmer than that.

and it serves the useful purpose of providing
a declaration. It's certainly not the best way to do things,
but it is "supported by C."

That's the C99 rule, but C89 didn't (or "doesn't," in
what I'm guessing about the O.P.'s case) doesn't require it.
It's still a good idea to declare before use, but C89 doesn't
make it mandatory.

But no C89 compiler will "let it slide" so my point is entirely valid.

this piece of misleading misinformation caught my eye. Please
note that pointers are not subject to promotion, not ever.

Yes, my mistake. Stupid of me.

but no complaint is required and the language permits the
conversion.

But with a potential loss of data. Which is why compilers complain,
no? If you have one that doesn't , I suggest you get your wallet out.
Mark McIntyre

 

[Old Wolf]

No, the "" notation causes the compiler to search for headers in an
implementation defined manner, or if the compiler chooses, identically
to <> (6.10.2 p3).

You're right (as is Michael Mair). In fact, N869 6.10.2 says
that if the "" notation does not find a file, then it MUST be
reprocessed as if it were the <> notation. (Did this change
in the final standard?)

However, I suppose it would be legal for someone to create
their own "stdio.h" somewhere on the "" search path, though..

 

[Mike Wahler]

On 10 Jan 2006 13:34:36 -0800, in comp.lang.c , (e-mail address removed)
wrote:

Turn up warninglevels in your compiler, as high as they'll go, and fix
all the errors it now shows you.


int main(). Since 1989, its been considered incorrect to use implicit
int.


FYI, most people advise not to use floats for maths, they're too
imprecise.


don't declare functions inside other functions - this isn't supported
in C,

It certainly is.

and serves no useful purpose.

It certainly does.

I'll leave it to others to debate whether declaring
a function inside another (vs. at file scope) is a good idea.

-Mike

 

[Keith Thompson]

On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman


I disagree. Even though C89 allowed implicit int, its been considered
a naughty thing to rely on for decades. Sure, you can do it. You can
also toboggan in the nude.

Every conforming C89/C90 implementation is required to support
implicit int. The C90 standard doesn't even list it as an obsolescent
feature in section 6.9, "Future language directions", though it does
say that non-prototype function declarations are obsolescent.

Yes, using implicit int is a bad idea, and nobody is advocating it.
But since it was clearly part of the C90 language, it's more accurate
to say that it's inadvisable than to say that it's "incorrect".

 

[Mark McIntyre]

Every conforming C89/C90 implementation is required to support
implicit int. The C90 standard doesn't even list it as an obsolescent
feature in section 6.9, "Future language directions", though it does
say that non-prototype function declarations are obsolescent.

I agree with this, my point is that in all my experience its been
considered exceptionally bad practice for at least a decade.

Yes, using implicit int is a bad idea, and nobody is advocating it.

I disagree. Eric's post pretty much said "go ahead, thats fine"

But since it was clearly part of the C90 language, it's more accurate
to say that it's inadvisable than to say that it's "incorrect".

YMMV.
Mark McIntyre

 

[Keith Thompson]

I agree with this, my point is that in all my experience its been
considered exceptionally bad practice for at least a decade.


I disagree. Eric's post pretty much said "go ahead, thats fine"

No, I don't think that's what he said at all. Here's the relevant
snippet from his article:

] Mark McIntyre wrote On 01/10/06 17:34,:
] > On 10 Jan 2006 13:34:36 -0800, in comp.lang.c , (e-mail address removed)
] > wrote:
] >
] > Turn up warninglevels in your compiler, as high as they'll go, and fix
] > all the errors it now shows you.
] >
] >
] >>main()
] >
] >
] > int main(). Since 1989, its been considered incorrect to use implicit
] > int.
]
] s/8/9/ or s/correct/advisable/.
]
] >

So with his suggested correction applied, the sentence becomes either

Since 1989, its been considered inadvisable to use implicit int.

or

Since 1999, its been considered incorrect to use implicit int.

Neither of those statements says "go ahead, that's fine". (Did you
misread the correction and think the modified sentence would say
"advisable" rather than "inadvisable"?)

 

[Eric Sosman]

Mark McIntyre wrote On 01/12/06 18:40,:

I agree with this, my point is that in all my experience its been
considered exceptionally bad practice for at least a decade.




I disagree. Eric's post pretty much said "go ahead, thats fine"

Eric's post said it was "inadvisable." Mark's post said
"Since 1989, it's been considered incorrect."

 

[Kenny McCormack]

On Tue, 10 Jan 2006 18:02:31 -0500, in comp.lang.c , Eric Sosman


my understanding was that it was a GCC extension, but if you can
provide me a refrence in the standard, I'm happy to be corrected.

He said "declare", not "define". Big difference. GCC does, indeed, allow
nested definitions (as an extension).

The following is entirely legal (though possibly misguided) (stock) C:

int myfun(void) { char *funofmine(void); char *s = funofmine(); return strlen(s); }
char *funofmine(void) { return "This is a test"; }

But we all know it is better to:
a) Declare/prototype all functions "globally" (at file scope).
b) Do so in header files.

But I am also astonished that you encourage the practice by your
remarks below. I thought you a better programmer than that.

He did not "encourage" it - he just said it was "OK" (as in legal).
See above.

 

[Mark McIntyre]

No, I don't think that's what he said at all. Here's the relevant
snippet from his article:

no, thats not the relevant snippet. This is the relevant snippet:

It's perfectly legal to declare (not define) one function
inside another, and it serves the useful purpose of providing
a declaration.

This seems to me to say "its fine to do this". even if...

It's certainly not the best way to do things, but it is "supported by C."

.... this bit notes that its not the best way.

As I earlier noted, I had the impression that even a declaration was a
gcc extension, but I've no problem about being mistaken.

And now back to something you said:

misread the correction and think the modified sentence would say
"advisable" rather than "inadvisable"?)

I suspect that after a couple of decades of using unix I can read
basic sed. No offense taken though.
Mark McIntyre

 

[Keith Thompson]

no, thats not the relevant snippet. This is the relevant snippet:



This seems to me to say "its fine to do this". even if...


... this bit notes that its not the best way.

As I earlier noted, I had the impression that even a declaration was a
gcc extension, but I've no problem about being mistaken.

[snip]

I'm a little tired of arguing about what was said rather than
discussing the C language, but ...

In context, it was clearly implicit int that was being discussed, not
function declarations inside functions.

Here's what you posted just upthread (see
<http://groups.google.com/group/comp.lang.c/msg/9ebe6ac1b8bb6d8f>):

] On Thu, 12 Jan 2006 01:17:12 GMT, in comp.lang.c , Keith Thompson
]
] >Every conforming C89/C90 implementation is required to support
] >implicit int. The C90 standard doesn't even list it as an obsolescent
] >feature in section 6.9, "Future language directions", though it does
] >say that non-prototype function declarations are obsolescent.
]
] I agree with this, my point is that in all my experience its been
] considered exceptionally bad practice for at least a decade.
]
] >Yes, using implicit int is a bad idea, and nobody is advocating it.
]
] I disagree. Eric's post pretty much said "go ahead, thats fine"
]
] >But since it was clearly part of the C90 language, it's more accurate
] >to say that it's inadvisable than to say that it's "incorrect".
]
] YMMV.
] Mark McIntyre

Whatever you intended to write, what you actually wrote was that Eric
had said "go ahead, thats fine" with respect to implicit int. In
fact, he didn't; he clearly said it's inadvisable.

Function declarations within function bodies are a different subject.
I don't use them myself, but I can imagine that there might be a
perfectly good reason to do so. For example, suppose a source file
contains a number of function definitions. Function foo_assistant()
is used only by function foo(), not by anything else in the file. In
this case, putting a declaration of foo_assistant() inside the body of
foo() could be a way of documenting the fact that only foo() is
intended to use it. (If the language permitted it, it would make
sense to *define* foo_assistent() inside foo(), but of course it
doesn't.)

 

[Mark McIntyre]

I'm a little tired of arguing about what was said rather than
discussing the C language, but ...

Then lets stop.

Eric's post said "this technique can be used and is useful". In my
opinion, posting such comments to obvious newbies is foolish in the
extreme, the impression clearly given was that it was ok to use it,
which again in my opinion it most certainly is not.

And forgive me for being blunt, but I believe you're arguing with me
mostly because you've taken a dislike to my posting style. I'm, sure
that you are of the opinion that you're arguing because I'm factually
wrong. Thats as may be, but I'm coming close to plonking you because
I find it tedious to spend so much time dealing with trivia. Perhaps
you should do the same to me, so that you can avoid being upset.

Both would be a shame for me because I value your C posts, and
appreciate your reasonable corrections or additions to mine. The value
is however close to being outweighed by the constant sniping.
Mark McIntyre

 

[Keith Thompson]

Then lets stop.

Eric's post said "this technique can be used and is useful". In my
opinion, posting such comments to obvious newbies is foolish in the
extreme, the impression clearly given was that it was ok to use it,
which again in my opinion it most certainly is not.

Which technique are you referring to? There were two distinct
techniques under discussion, implicit int and function declarations
within function definitions.

Let's summarize some things I hope we can agree on and move on.

Eric did not say or imply that implicit int is useful. He merely
pointed out that it's legal (but inadvisable) in C89 and illegal in
C99. I agree with him on both points.

Eric did say that function declarations inside function definitions
are perfectly legal and can serve a useful purpose. You obviously
feel strongly that they're a bad idea. They don't particularly bother
me, and I can imagine circumstances in which they *might* be a good
approach. Since they're unquestionably legal, we can agree to
disagree on the style issue -- and I'll avoid using them in any code I
post here. (I'll note that you had previously assumed they were a gcc
extension, which might have colored your opinion of them -- but
regardless of that, your opinion that they're a bad idea is perfectly
valid.)

I believe the impression has been given in this thread that Eric was
endorsing the use of implicit int. Since that would be, IMHO, a
foolish thing for Eric to say, and since Eric in fact didn't say that,
I thought it was important to set the record straight.