Warnings in lcc-win

[jacob navia]

After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.

1) The buggy warning about
long l;
printf("%li", l * 10L);
is eliminated. This means that when you
write:
long l;
printf("%i", l*10L);
there will be no warning about expecting an
integer given a long. Better less warnings always correct
than more warnings sometimes incorrect. The alternative, i.e.
maintaining the type long internally when both long and int
are identical would be too much changes in the compiler.

2) I maintain two of the three warnings.

Warning tprintf.c: 4 old-style function definition for 'main'
Warning tprintf.c: 4 missing prototype for 'main'

but dropped the "non-ANSI" warning. A warning will be issued
if main differs from its ANSI prototype.

I thank all people that participated in this discussion and
the user that raised this question in the first place.

jacob

[Eric Sosman]

jacob navia wrote On 09/27/07 17:33,:

After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.

1) The buggy warning about
long l;
printf("%li", l * 10L);
is eliminated. This means that when you
write:
long l;
printf("%i", l*10L);
there will be no warning about expecting an
integer given a long. Better less warnings always correct
than more warnings sometimes incorrect. The alternative, i.e.
maintaining the type long internally when both long and int
are identical would be too much changes in the compiler.

Does the compiler really treat `int' and `long' as
identical? If so, what does it do with

int value = 42;
long *ptr = &value;
or with
extern long global;
extern int global;
or with
int func(void);
long func(void) { return 42L; }

? Diagnostics are required for these -- if the compiler
is able to emit them it must be "aware" at some level that
`int' and `long' are different, even though they share a
common representation.

Are other sets of types similarly confounded? For
example, is `char' a full-fledged type of its own, or is
it just an alias for `signed char' or `unsigned char'?
Are `struct f { int i; }' and `struct g { int i; }'
considered identical?

I hope things aren't as tangled as all that -- but
failing to distinguish between `int' and `long' makes
me fear that they might be.

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

[Jack Klein]

On Thu, 27 Sep 2007 23:33:24 +0200, jacob navia
<ja***@jacob.remcomp.frwrote in comp.lang.c:

After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.

1) The buggy warning about
long l;
printf("%li", l * 10L);
is eliminated. This means that when you
write:
long l;
printf("%i", l*10L);

Surely here you meant "%li", again. If you are going to check *printf
format strings and warn about mismatches, "%i" is a mismatch for long,
even on implementations where both have the same size and
implementation.

there will be no warning about expecting an
integer given a long. Better less warnings always correct
than more warnings sometimes incorrect. The alternative, i.e.
maintaining the type long internally when both long and int
are identical would be too much changes in the compiler.

2) I maintain two of the three warnings.

Warning tprintf.c: 4 old-style function definition for 'main'
Warning tprintf.c: 4 missing prototype for 'main'

Let's talk about these.

I agree with the first one completely, assuming that it is not the
default and the user has asked for a higher warning level.

But I do not like the wording for the second one. I think it is
confusing, because the wording is not specific. I will describe what
I mean.

If the warning is given because the function definition:

return_type func() { /* body */ }

....does not provide a prototype, then I think better wording would be:

Warning filename.c: # definition does not provide a prototype for
'func'

This would distinguish it from a different warning:

Warning filename.c: # function defined without prototype in scope

I remember an old version of CodeWarrior that had an option to
generate this warning if it came across the definition of any
non-static function without having seen a prototype.

This was a nice option for limiting unnecessary external visibility.
If a function was only used in the source file where it was defined,
it could be defined before use as static and you did not get this
warning.

If the function truly needed external linkage, because it would be
called from other source files by name, then the defining source file
should be including a header with a prototype for it, the same header
the calling source file(s) would include.

CodeWarrior specifically exempted main() from this check.

I have not seen another compiler that offered this warning, but PC
Lint does.

So be more specific with your warning, I think you mean:

definition does not provide a prototype for func

....and consider adding, if lcc-win32 does not have it already, an
option to warn about the definition of a non-static function without a
prototype already in scope:

function func defined without prototype in scope

....but be sure to special case main() and exempt it if you do.

[posted and mailed]

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Keith Thompson]

Jack Klein <ja*******@spamcop.netwrites:

On Thu, 27 Sep 2007 23:33:24 +0200, jacob navia
<ja***@jacob.remcomp.frwrote in comp.lang.c:

>After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.

1) The buggy warning about
long l;
printf("%li", l * 10L);
is eliminated. This means that when you
write:
long l;
printf("%i", l*10L);

Surely here you meant "%li", again. If you are going to check *printf
format strings and warn about mismatches, "%i" is a mismatch for long,
even on implementations where both have the same size and
implementation.

[...]

No, I'm fairly sure he meant what he wrote. Apparently lcc-win32
internally treats int and long as the same type, at least in some
ways. Given that fact, he has a choice; he can warn about both
printf("%li", long_value); /* correct */
and
printf("%i, long_value); /* incorrect */
or he can warn about neither. Of the two options, I agree that
warning about neither is better.

Of course, warning about the second and not about the first would be
ideal, but apparently that's going to take some more work.

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

[CBFalconer]

Jack Klein wrote:

>

.... snip ...

>
I agree with the first one completely, assuming that it is not
the default and the user has asked for a higher warning level.

But I do not like the wording for the second one. I think it is
confusing, because the wording is not specific. I will describe
what I mean.

If the warning is given because the function definition:

return_type func() { /* body */ }

...does not provide a prototype, then I think better wording would be:

That deserves no warning whatsoever. However, calling the function
earlier in the source, without having a prototype, is an error (not
a warning).

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

jacob navia wrote:

After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.

1) The buggy warning about
long l;
printf("%li", l * 10L);
is eliminated. This means that when you
write:
long l;
printf("%i", l*10L);
there will be no warning about expecting an
integer given a long. Better less warnings always correct
than more warnings sometimes incorrect. The alternative, i.e.
maintaining the type long internally when both long and int
are identical would be too much changes in the compiler.

If you treat them as the same internally, you'll be buggered when
porting to any LP64 64 bit system. That is any 64 bit Linux/Unix platform.

--
Ian Collins.

[Jack Klein]

On Fri, 28 Sep 2007 00:34:45 -0400, CBFalconer <cb********@yahoo.com>
wrote in comp.lang.c:

Jack Klein wrote:

... snip ...

I agree with the first one completely, assuming that it is not
the default and the user has asked for a higher warning level.

But I do not like the wording for the second one. I think it is
confusing, because the wording is not specific. I will describe
what I mean.

If the warning is given because the function definition:

return_type func() { /* body */ }

...does not provide a prototype, then I think better wording would be:

That deserves no warning whatsoever. However, calling the function
earlier in the source, without having a prototype, is an error (not
a warning).

I disagree, I would not mind having such a warning as an _option_. I
consider it an "error" in new code (note C does not define this term),
and would turn the option off for legacy code if necessary.

As for making it an "error", presumably refusing to generate an
executable, could render the compiler non-conforming in some
situations.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[jacob navia]

Eric Sosman wrote:

Does the compiler really treat `int' and `long' as
identical? If so, what does it do with

int value = 42;
long *ptr = &value;
or with
extern long global;
extern int global;
or with
int func(void);
long func(void) { return 42L; }

? Diagnostics are required for these -- if the compiler
is able to emit them it must be "aware" at some level that
`int' and `long' are different, even though they share a
common representation.

I wrote this test program:
extern long global;
extern int global;
int func(void);
int fn(void) {
int value = 42;
long *ptr = &value;
}

long func(void) { return 42; }

At default diagnostic level lcc-win produces:

d:\lcc\test>lcc twarn.c
Error twarn.c: 2 redefinition of 'global'
Error twarn.c: 1 Previous definition of 'global' here
Warning twarn.c: 7 missing return value
Error twarn.c: 9 redefinition of 'func'
Error twarn.c: 3 Previous definition of 'func' here
4 errors, 1 warning

With extended diagnostics turned ON:
d:\lcc\mc68\test>lcc -A twarn.c
Error twarn.c: 2 redefinition of 'global'
Error twarn.c: 1 Previous definition of 'global' here
Warning twarn.c: 6 assignment of pointer to int to pointer to long int
Warning twarn.c: 6 ptr is assigned a value that is never used
Warning twarn.c: 7 missing return value
Error twarn.c: 9 redefinition of 'func'
Error twarn.c: 3 Previous definition of 'func' here
4 errors, 3 warnings

Note that lcc-win is much more strict than MSVC that
issues no errors, just warnings:

twarn.c(2) : warning C4142: benign redefinition of type
twarn.c(9) : warning C4142: benign redefinition of type
d:\lcc\test\twarn.c(7) : warning C4716: 'fn' : must return a value

-------------------------------------------------------------
In all this "easy" cases, the diagnostics are issued before
the evaluation and transformation of types is done. In the
case of printf however, the tests are done just before
the function call, well after they have been prepared to
be put in the stack, hence the problems. Of course I should
test before, but that is quite a lot of work.

[Keith Thompson]

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

Jack Klein wrote:

>>

... snip ...

>>
I agree with the first one completely, assuming that it is not
the default and the user has asked for a higher warning level.

But I do not like the wording for the second one. I think it is
confusing, because the wording is not specific. I will describe
what I mean.

If the warning is given because the function definition:

return_type func() { /* body */ }

...does not provide a prototype, then I think better wording would be:

That deserves no warning whatsoever. However, calling the function
earlier in the source, without having a prototype, is an error (not
a warning).

That definition does not provide a prototype.

More concretely:

void foo()
{
}

int main(void)
{
foo(42);
return 0;
}

The definition of 'foo' does not provide a prototype. The incorrect
call 'foo(42)' is not a constraint violation, though it does invoke
undefined behavior.

On the other hand, if the definition of foo were:

void foo(void)
{
}

then the call would be a constraint violation.

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

[jacob navia]

Pietro Cerutti wrote:

>
What prevents long to be^H^H^H^H^H from being a type by itself?

I was speaking about lccc-win. In C long *is* a type by itself.

[Army1987]

On Thu, 27 Sep 2007 18:18:38 -0400, Eric Sosman wrote:

[about lcc-win32]

Are other sets of types similarly confounded? For
example, is `char' a full-fledged type of its own, or is
it just an alias for `signed char' or `unsigned char'?

Considering int8_t is a typedef for char...
(Note that char is by definition neither a signed type nor an
unsigned type, even though it is required to behave either
identically to signed char or to unsigned char. So to be pedantic
int8_t should be a typedef for signed char, though it is
impossible that that breaks any program.)
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Eric Sosman]

jacob navia wrote:

[...]
In all this "easy" cases, the diagnostics are issued before
the evaluation and transformation of types is done. In the
case of printf however, the tests are done just before
the function call, well after they have been prepared to
be put in the stack, hence the problems. Of course I should
test before, but that is quite a lot of work.

Well, it's a relief to hear that the compiler *does* know
the difference between `int' and `long', and doesn't rely on
some internal `#define long int' or `typedef int long;' magic!

It seems to me (though I am ignorant of the internal
organization of the compiler) that the format-string validation
might be easier and would certainly be more accurate if it were
done while more information about types is still available. Or
equivalently, if the type information were carried along further
before being turned into undecorated representational data. How
big a job that would be isn't for me to say, but it would improve
the diagnostic power of the compiler if it could be done.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Eric Sosman]

CBFalconer wrote:

[...]
However, calling the function
earlier in the source, without having a prototype, is an error (not
a warning).

Chapter and verse?

(Hypothesis: You may have meant to write "declaration"
rather than "prototype.")

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Default User]

Richard Heathfield wrote:

Ian Collins said:

I thought he has a Linux port?

For the benefit of the folks from Missouri, would you care to back
that statement with a URL?

Actually, I'm not all that interested. There may be some other MO
people that are though.


Brian

[Richard Heathfield]

Default User said:

Richard Heathfield wrote:

>Ian Collins said:

I thought he has a Linux port?

For the benefit of the folks from Missouri, would you care to back
that statement with a URL?

Actually, I'm not all that interested. There may be some other MO
people that are though.

Ah well, so much for the "Show Me!" state. :-)

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

[jacob navia]

Jack Klein wrote:
[snip]

>
If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.
At the highest warning level it says:

Warning twarn2.c: 7 assignment of pointer to long int to pointer to int

jacob

[Army1987]

jacob navia wrote:

>In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?
--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[Joachim Schmitz]

"Army1987" <ar******@NOSPAM.itschrieb im Newsbeitrag
news:pa****************************@NOSPAM.it...

>jacob navia wrote:

>>In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

Great. If I do

long long foo(void);
int main(void) { return foo; }

here you'd most probably get an error like 'return value type does not match
the function type'
If you change it to
main(void) { return foo(); }
I'd expect a warning 'implicit conversion from "long long" to "int":
rounding, sign extension, or loss of accuracy may result'

long foo(void) { return 0L; }

whether or not you get an error 'declaration is incompatible with "long long
foo(void)" (declared at line 1)' is I guess the one you're interested in?

what diagnostics do I get?

Bye, Jojo

[Richard Heathfield]

Army1987 said:

>jacob navia wrote:

>>In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

Well? What diagnostics /do/ you get?

(Translation: I can't find any evidence that a Linux implementation of
lcc-win32 exists.)

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

[Flash Gordon]

jacob navia wrote, On 29/09/07 08:34:

Jack Klein wrote:
[snip]

>>
If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

At the highest warning level it says:

Warning twarn2.c: 7 assignment of pointer to long int to pointer to int

In my opinion it should warn (or better yet error) on the default
warning level. It certainly has to produce a diagnostic in whatever mode
it claims to conform to any version of the C standard.
--
Flash Gordon

[jacob navia]

Army1987 wrote:

>jacob navia wrote:

>>In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

root@ubuntu:/tmp# lcc twarn.c
Error /tmp/twarn.c: twarn.c: 2 illegal return type; found 'pointer to
long long function(void)' expected 'int'
Error /tmp/twarn.c: twarn.c: 3 redefinition of 'foo'
Error /tmp/twarn.c: twarn.c: 1 Previous definition of 'foo' here
3 errors, 0 warnings

This is in 32 Bit linux. Under 64 bit linux will do that
when I reconstruct my 64 bit linux since debian refuses to run
in my machine (screen 1900x1200 not recognized, X windows doesn't
work, etc)

[jacob navia]

Richard Heathfield wrote:

Army1987 said:

>>jacob navia wrote:
In 64 bit linux I have hacked the lexer!

When I see a "long" keyword, I return "long long". Internally
"long" is still never used. This works quite OK.

Great. If I do

long long foo(void);
int main(void) { return foo; }
long foo(void) { return 0L; }

what diagnostics do I get?

Well? What diagnostics /do/ you get?

(Translation: I can't find any evidence that a Linux implementation of
lcc-win32 exists.)

For all people (except heathfield) I can mail a version of lcc-win under
linux in a tar.gz file. There will be a public URL for the 32 bit
version tomorrow where everybody will be able to download it.

[Chris Hills]

In article <pb************@news.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.ukwrites

>jacob navia wrote, On 29/09/07 08:34:

>Jack Klein wrote:
[snip]

>>>
If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?

At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

Which C standard? Virtually no compiler fully conforms to ISO9899:1999
+ TC1+TC2+TC3

Lcc-win is not different to any other in that respect.

Having just discussed standards adherence with most of the main stream
embedded compiler writes world wide*. Standards adherence is not a
priority for them Lcc is not different to any other in this respect.
Some of the more popular compilers are not the most standards compliant

* Any compiler (or other C tool) company who wants an input to or
updates about MISRA-C:2010 please email me
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Sat, 29 Sep 2007 12:09:12 +0100, in comp.lang.c , Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>jacob navia wrote, On 29/09/07 08:34:

>At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

But thats ok - hardly any compilers warn properly at the default
level.

>In my opinion it should warn (or better yet error) on the default
warning level.

Sure - but you might want to mention this to all the other compiler
writers too...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

Chris Hills wrote, On 29/09/07 13:34:

In article <pb************@news.flash-gordon.me.uk>, Flash Gordon
<sp**@flash-gordon.me.ukwrites

>jacob navia wrote, On 29/09/07 08:34:

>>Jack Klein wrote:
[snip]

If I have a prototype (in 32-bit code):

int func(int *);

...and a snippet like this:

void other_func(void)
{
long l = 42L;
func(&l);
}

...do your versions of lcc accept this without a diagnostic?
At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

Which C standard? Virtually no compiler fully conforms to ISO9899:1999
+ TC1+TC2+TC3

All of them. You failed to quote the part where I stated that my comment
applied to all versions.

Lcc-win is not different to any other in that respect.

You failed to quote the part where I made the point that a diagnostic is
required in whatever mode

Having just discussed standards adherence with most of the main stream
embedded compiler writes world wide*. Standards adherence is not a
priority for them Lcc is not different to any other in this respect.

It is relevant because Jacob has repeatedly stated that his compiler has
a mode in which it conforms to one of the versions of the C standard. If
it does not generate a diagnostic in that mode (which he has not made
clear) then this is a bug in his compiler.

Are you saying that we should not point out to compiler writers where
there compilers have bugs and/or fail to comply to any standard (current
or not) that they claim to meet?

Some of the more popular compilers are not the most standards compliant

I'm talking about a specific compiler which the author claims has a
standard compliant mode, so that is not relevant to the discussion.

No tell me in which version of the standard a diagnostic is NOT required
for the code in question.
--
Flash Gordon

[Flash Gordon]

Mark McIntyre wrote, On 29/09/07 13:46:

On Sat, 29 Sep 2007 12:09:12 +0100, in comp.lang.c , Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>jacob navia wrote, On 29/09/07 08:34:

>>At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

But thats ok - hardly any compilers warn properly at the default
level.

For the code in question I would consider not warning on the default
level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode where it
claims conformance to some version of the standard.

>In my opinion it should warn (or better yet error) on the default
warning level.

Sure - but you might want to mention this to all the other compiler
writers too...

If I am in a discussion with another compiler writer and their compiler
does not do this I will be sure to mention it.
--
Flash Gordon

[CBFalconer]

Flash Gordon wrote:

>

.... snip ...

>
For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest, and is
off-topic, in this newsgroup.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Chris Hills]

In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>Flash Gordon wrote:

>>

... snip ...

>>
For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest,

Maybe to you but is of interest to others.

>and is
off-topic, in this newsgroup.

Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[CBFalconer]

Chris Hills wrote:

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

>Flash Gordon wrote:

>>>

... snip ...

>>>
For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest,

Maybe to you but is of interest to others.

>and is off-topic, in this newsgroup.

Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[santosh]

CBFalconer wrote:

Chris Hills wrote:

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

>>Flash Gordon wrote:

... snip ...

For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest,

Maybe to you but is of interest to others.

>>and is off-topic, in this newsgroup.

Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

You might take a look at Richard Heathcliffs thread [ ... ]

This is the funniest typo(?) I've seen in some time.

[Chris Hills]

In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

>Chris Hills wrote:

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

>>Flash Gordon wrote:

... snip ...

For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest,

Maybe to you but is of interest to others.

>>and is off-topic, in this newsgroup.

Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

It exceeds 2 by quite a way. Every time this gets discussed it is the
same SMALL group of net nannies and a larger and now more vocal group
that are getting fed up with them.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

<snip>

>>
You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

It exceeds 2 by quite a way.

Yes, you're right - it appears to be 3 rather than 2.

Every time this gets discussed it is the
same SMALL group of net nannies and a larger and now more vocal group
that are getting fed up with them.

The group of people posting in that thread who share your views currently
includes Richard Riley, Kenny McCormack, and - nobody else. At least a
dozen people have expressed a contrary view.

I'll compile statistics in a day or two. Unfiltered, of course (which means
I'll have to turn off my killfile for the purpose, but c'est la vie).

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

[Philip Potter]

Richard Heathfield wrote:

Chris Hills said:

>In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites

<snip>

>>You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

It exceeds 2 by quite a way.

Yes, you're right - it appears to be 3 rather than 2.

Don't look at him in that tone of voice.

>Every time this gets discussed it is the
same SMALL group of net nannies and a larger and now more vocal group
that are getting fed up with them.

The group of people posting in that thread who share your views currently
includes Richard Riley, Kenny McCormack, and - nobody else. At least a
dozen people have expressed a contrary view.

In this thread, the phrase being contested is CBFalconer's:

"What it does in _any_ other mode is of no interest, and is
off-topic, in this newsgroup."

This would be contested by anyone in your Moderate group and possibly by
some in your Conservative group. Most people have claimed to be
Conservative in that thread, with some (including Chris Torek) claiming
some leaning towards Moderate.

I wouldn't say that this expresses their position to be for or against
the above statement. I fail to see how you got your "at least a dozen"
figure using only statements from that thread.

Incedentally, I feel that although CBFalconer was strictly correct about
topicality, he was rude about policing it, and stifling discussion which
might be of interest to people still taking part in that thread.

We discuss the behaviour of gcc and msvc in their default
(nonconforming) modes here, why not lcc-win32?

I'll compile statistics in a day or two. Unfiltered, of course (which means
I'll have to turn off my killfile for the purpose, but c'est la vie).

You have to be very careful when compiling statistics from points of
view. The only meaningful one you can extract is a bar chart with one
bar of height one per person...

--
Philip Potter pgp <atdoc.ic.ac.uk

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

<snip>

>The group of people posting in that thread who share your views
currently includes Richard Riley, Kenny McCormack, and - nobody else. At
least a dozen people have expressed a contrary view.

In this thread, the phrase being contested is CBFalconer's:

"What [a compiler] does in _any_ other mode [other than conforming mode]
is of no interest, and is off-topic, in this newsgroup."

This would be contested by anyone in your Moderate group and possibly by
some in your Conservative group.

Unlikely. After all, in non-conforming mode, a compiler can do anything it
likes - it can, for example, reject or mistranslate correct programs, and
it can accept incorrect programs (without producing a diagnostic message
for any syntax errors or constraint violations such a program may
contain). Without specifying in *which* ways a non-conforming mode does
not conform, a discussion of non-conforming mode is indeed of no interest
to comp.lang.c. A "Moderate" might reasonably take the view that a
/particular/ non-conforming mode could be full of quiet interest, and
indeed it might, but arbitrarily discarding conformance is not the
position of a conservative or even a moderate comp.lang.c subscriber.

Most people have claimed to be
Conservative in that thread, with some (including Chris Torek) claiming
some leaning towards Moderate.

Indeed. In fact, I'm rather more liberal than most of those who have so far
expressed an opinion in that thread (but no more so than Chris, I think).

I wouldn't say that this expresses their position to be for or against
the above statement. I fail to see how you got your "at least a dozen"
figure using only statements from that thread.

I would argue that the behaviour of any compiler invoked in a mode that
discards the rules of the language is not a behaviour that con/mod clc
subscribers would find particularly interesting as far as C is concerned.
(Those same people may, of course, find such a discussion absolutely
fascinating if it were set in a more appropriate context, such as
comp.programming or an implementation-specific group.)

Incedentally, I feel that although CBFalconer was strictly correct about
topicality, he was rude about policing it, and stifling discussion which
might be of interest to people still taking part in that thread.

Yes, I know. Some of the netcops in clc make you glad they're not cops IRL.

We discuss the behaviour of gcc and msvc in their default
(nonconforming) modes here,

Such discussions are not topical, and I for one would prefer them to be
conducted in gnu.gcc.help or microsoft.public.vc

why not lcc-win32?

Why gcc and msvc?

>I'll compile statistics in a day or two. Unfiltered, of course (which
means I'll have to turn off my killfile for the purpose, but c'est la
vie).

You have to be very careful when compiling statistics from points of
view. The only meaningful one you can extract is a bar chart with one
bar of height one per person...

I know. Actually, I don't *have* to be very careful - but I will
nevertheless at least try to be a bit careful.

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

[CBFalconer]

Richard Heathfield wrote:

Chris Hills said:

><cb********@yahoo.comwrites

<snip>

>>

>>You might take a look at Richard Heathcliffs thread on 'broaden
the topicality', and the opinions showing up there. You are in
the small group, which may possibly exceed 2.

It exceeds 2 by quite a way.

Yes, you're right - it appears to be 3 rather than 2.

>Every time this gets discussed it is the same SMALL group of net
nannies and a larger and now more vocal group that are getting
fed up with them.

The group of people posting in that thread who share your views
currently includes Richard Riley, Kenny McCormack, and - nobody
else. At least a dozen people have expressed a contrary view.

I'll compile statistics in a day or two. Unfiltered, of course
(which means I'll have to turn off my killfile for the purpose,
but c'est la vie).

Oh my - McCormack must be rubbing his hands in glee. :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Richard Heathfield wrote:

Philip Potter said:

.... snip ...

>

>Incedentally, I feel that although CBFalconer was strictly
correct about topicality, he was rude about policing it, and
stifling discussion which might be of interest to people still
taking part in that thread.

Yes, I know. Some of the netcops in clc make you glad they're not
cops IRL.

While my answers may be short (or taut), I don't consider them
rude. Why do you? In fact, I tend to avoid rudeness (IMO) at all
times.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

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

Richard Heathfield wrote:

>Philip Potter said:

... snip ...

>>

>>Incedentally, I feel that although CBFalconer was strictly
correct about topicality, he was rude about policing it, and
stifling discussion which might be of interest to people still
taking part in that thread.

Yes, I know. Some of the netcops in clc make you glad they're not
cops IRL.

While my answers may be short (or taut), I don't consider them
rude. Why do you? In fact, I tend to avoid rudeness (IMO) at all
times.

Since you ask ...

When someone posts a program or code snippet that uses some
non-standard feature, you sometimes assert that it doesn't exist (not
that it's non-standard, but that it doesn't exist at all) and/or
suggest that the poster needs to provide an implementation for the
construct in portable standard C.

I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

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

[CBFalconer]

Keith Thompson wrote:

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

>Richard Heathfield wrote:

>>Philip Potter said:

... snip ...

>>>
Incedentally, I feel that although CBFalconer was strictly
correct about topicality, he was rude about policing it, and
stifling discussion which might be of interest to people still
taking part in that thread.

Yes, I know. Some of the netcops in clc make you glad they're not
cops IRL.

While my answers may be short (or taut), I don't consider them
rude. Why do you? In fact, I tend to avoid rudeness (IMO) at all
times.

Since you ask ...

When someone posts a program or code snippet that uses some
non-standard feature, you sometimes assert that it doesn't exist (not
that it's non-standard, but that it doesn't exist at all) and/or
suggest that the poster needs to provide an implementation for the
construct in portable standard C.

I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

OK, thanks. I shall try to bear it in mind.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Old Wolf]

On Sep 28, 6:48 pm, CBFalconer <[e-mail]:

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all
calls to the function pass the correct count and
type of arguments, and receive the return value
correctly.

[Old Wolf]

On Sep 29, 11:09 pm, Flash Gordon <[e-mail]:

jacob navia wrote, On 29/09/07 08:34:

Jack Klein wrote:

int func(int *);

void other_func(void)
{
long l = 42L;
func(&l);
}

At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

gcc does not conform to the C standard at default
warning level either.

I don't think it's a compiler's job to enforce the
writer to write portable code. I'm quite happy with
compilers accepting code that is guaranteed to work
on that particular implementation, in their default
mode of operation. Another example is // comments
in C90 code.

Those programmers who do want portability can invoke
the compiler in the mode that conforms to the C standard.

[CBFalconer]

Old Wolf wrote:

CBFalconer <[e-mail]:

>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement. In:

double foo(double d) {....; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

The definition of foo acts as a declaration and prototype. No
copying needed.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Old Wolf]

On Oct 2, 12:11 pm, CBFalconer <[e-mail]:

Old Wolf wrote:

CBFalconer <[e-mail]:

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

[Keith Thompson]

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

Old Wolf wrote:

>CBFalconer <[e-mail]:

>>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement. In:

double foo(double d) {....; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

The definition of foo acts as a declaration and prototype. No
copying needed.

Replace "No, because" by "Yes, and", and I'll agree with you.

As you say, the definition of foo provides a prototype. The purpose
of doing so is precisely "to ensure that all calls to the function
pass the correct count and type of arguments, and receive the return
value correctly".

The alternative would be:

double foo(d) double d; { ...; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

where the definition of foo *doesn't* provide a prototype, even though
it's defined before it's used.

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

[Flash Gordon]

Old Wolf wrote, On 01/10/07 23:51:

On Sep 29, 11:09 pm, Flash Gordon <[e-mail]:

>jacob navia wrote, On 29/09/07 08:34:

>>Jack Klein wrote:
int func(int *);
void other_func(void)
{
long l = 42L;
func(&l);
}
At the default warning level there are no warnings.

In that case at the default warning level it does not conform to the C
standard.

gcc does not conform to the C standard at default
warning level either.

Agreed. However Jacob was only talking about default level and maximum
warning level. Maximum warning level normally includes lots of
diagnostics which are not required by the standard which, whilst it does
not break conformance, does IMHO make it appropriate to comment on the
conformance of the only other level mentioned. IIRC I also asked about
what it does in standards conforming mode in this post.

I don't think it's a compiler's job to enforce the
writer to write portable code. I'm quite happy with
compilers accepting code that is guaranteed to work
on that particular implementation, in their default
mode of operation. Another example is // comments
in C90 code.

Those programmers who do want portability can invoke
the compiler in the mode that conforms to the C standard.

Agreed. However I still believe (and think I mentioned, but could be
wrong) that a diagnostic for the above code should be provided at
default warning level as a matter of QoI.
--
Flash Grdon

[Charlie Gordon]

"Old Wolf" <ol*****@inspire.net.nza écrit dans le message de news:
11**********************@19g2000hsx.googlegroups.c om...

On Oct 2, 12:11 pm, CBFalconer <[e-mail]:

>Old Wolf wrote:

CBFalconer <[e-mail]:

>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

for the second time in two days, memset arguments are mem, c, count.
the above code invokes undefined behaviour.

--
Chqrlie.

[Mark L Pappin]

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Old Wolf" <ol*****@inspire.net.nza écrit:

>On Oct 2, 12:11 pm, CBFalconer <[e-mail]:

>>Old Wolf wrote:
CBFalconer <[e-mail]:

>>>>Now why would you say that? To my mind, prototypes have just
two purposes: 1. Expose the calling sequence to other files,
and 2. Resolve indirect recursive calls.

>>>Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and
receive the return value correctly.

>>No, because that is handled by the declaration before use
requirement.

>No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

for the second time in two days, memset arguments are mem, c, count.
the above code invokes undefined behaviour.

Old Wolf's point, I think.

The code shown has a declaration of 'memset()' before its use, which
CBF claimed handled the checking the number and type of arguments.

The code shown has no prototype for 'memset()', and thus the compiler
is not required (but may, since that function is defined by the
standard and thus the compiler may have "special" knowledge of it) to
check the number and type of arguments.

ml "reading for comprehension" p

[Eric Sosman]

Keith Thompson wrote On 10/01/07 16:00,:

[...]
I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

Yabbut, if the question concerns fork() in any
essential way, like "Does a successful call to fork()
double the swap space allocation?" or "Does the new
process preempt the old one immediately, or does the
old keep on executing for a while?" then the question
really really really isn't about C. Even if you know
something about fork(), the best answer you can give
is probably "It depends."

Personally, I've no reluctance to answering questions
that involve stat() or open() or whatever, if I perceive
them as being involved "incidentally." If a code snippet
shows input being obtained from recv() and the question
is about how to manage memory allocation for the received
data, I see no reason not to discuss the proper use of
malloc() et al. On the other hand, a question about how
to use recv()'s MSG_PEEK flag is a clear candidate for
"Try another newsgroup; you'll get better answers."

IMHO, fork() is a function for which practically all
serious questions fall into the second category.

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

[CBFalconer]

Old Wolf wrote:

CBFalconer <[e-mail]:

>Old Wolf wrote:

>>CBFalconer <[e-mail]:

>>>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

>>Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main() {
char x[4];
memset(x, sizeof x, 100);
}

Why did you delete the example I gave? That was a proper
definition, with proper definition of parameters etc. And it did
not use the reserved std. library name. You are using an ancient
K&R1 declaration.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Old Wolf]

On Oct 2, 7:34 pm, CBFalconer <[e-mail]:

Old Wolf wrote:

CBFalconer <[e-mail]:

Old Wolf wrote:
CBFalconer <[e-mail]:

>>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

>Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main() {
char x[4];
memset(x, sizeof x, 100);
}

Why did you delete the example I gave?

Because it was not relevant. You made an assertion, and provided
a corroborative example. I provided a counterexample, proving
the assertion false.

That was a proper
definition, with proper definition of parameters etc. And it did
not use the reserved std. library name. You are using an ancient
K&R1 declaration.

That's the whole point.

[Mark McIntyre]

On Mon, 01 Oct 2007 20:11:31 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>Old Wolf wrote:

>CBFalconer <[e-mail]:

>>Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement.

Declaration before use doesn't provide this unless you have
prototypes.

>The definition of foo acts as a declaration and prototype.

NB: declaration is different to definition.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan