what does this warning mean ?
#include <stdio.h>
int main()
{
long l = 100;
printf("l is %li\n", l * 10L);
return 0;
}
when i compile this program with lcc-win32 it prints
lcc -A -ansic -O long.c -o long.obj
Warning c:\tmp\long.c: 4 old-style function definition for 'main'
Warning c:\tmp\long.c: 4 missing prototype for 'main'
Warning c:\tmp\long.c: 4 'int main()' is a non-ANSI definition
Warning c:\tmp\long.c: 7 printf argument mismatch for format i.
Expected long int got int
0 errors, 4 warnings
warning 1-3: how to give prototype for main ?
warning 4: i gave it long int but it says it got int . even
'(long)l * 10L' gives same warning . how to cast this properly ?
is it safe to ignore ???
gcc prints no warnings .
--
mfg, heinrich :)
Sep 27 '07
92  6094 
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
Then, the warning I am issuing is justified!
Which one?
For context, here are the three warnings issued for 'int main() { ... }':
Warning c:\tmp\long.c: 4 old-style function definition for 'main'
Warning c:\tmp\long.c: 4 missing prototype for 'main'
Warning c:\tmp\long.c: 4 'int main()' is a non-ANSI definition
The first warning is, IMHO, quite correct and reasonable. Note that
using parentheses for a function that takes no arguments is an easier
mistake to make than using a K&R-style definition with one or more
parameters. I suggest recognizing that special case and suggesting
changing '()' to '(void)'.
The second one is ok. A prototype is indeed missing, but the language
doesn't require a prototype. But if the compiler is invoked in a mode
that specifically requires prototypes, it's a valid warning.
The third one is simply incorrect. It says nothing that the first
warning didn't already tell you, and it's factually incorrect since
the ANSI^H^H^H^H ISO standard specifically allows old-style
declarations.
And *why* does the messsage refer to ANSI rather than ISO?
--
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"
Ben Bacarisse <be********@bsb.me.ukwrites:
Fr************@googlemail.com writes:
[...]
>The seemingly ambiguous case is int main() { ... }. This could either
be regarded as main with an empty parameter-type-list, or main with a
non-supplied optional identifier-list. Which is it?
The syntax makes it quite clear, I think. See below...
>>Well, 6.5.4.3
comes to the rescue again and clears this up for us: for a function
DEFINITION, an empty list of parameters is interpreted in the first
way, specifying that the function has no parameters.
Yes but that section does not tell us how to disambiguate the () in
the function definition -- it tell us what it *means* but not what is
*is*. In fact it is not ambiguous if you look at the syntax. A
parameter type list may not be empty whereas an identifier list can
be. (Check for yourself, readers, because the syntax is complex and I
may well have got that wrong, though I have checked as carefully as I
can.)
I am open to persuasion (that int foo() { ... } acts as a prototype)
but you will have to persuade the gcc people as well! -- OK you need
to ask for -Wstrict-prototypes, but at least you can.
Yes, the grammar is in 6.7.5:
parameter-type-list:
parameter-list
parameter-list , ...
parameter-list:
parameter-declaration
parameter-list , parameter-declaration
A parameter-type-list cannot be empty.
--
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"
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>Then, the warning I am issuing is justified!
Which one?
The second one. The discussion is about the supposed difference
between () in a function declaration, where it means "indeterminate
number of parameters" and a function definition, where some people
here say the space between the () would be "overloaded" to mean
"void".
That interpretation is not correct IMHO.
For context, here are the three warnings issued for 'int main() { ... }':
Warning c:\tmp\long.c: 4 old-style function definition for 'main'
Warning c:\tmp\long.c: 4 missing prototype for 'main'
Warning c:\tmp\long.c: 4 'int main()' is a non-ANSI definition
The first warning is, IMHO, quite correct and reasonable. Note that
using parentheses for a function that takes no arguments is an easier
mistake to make than using a K&R-style definition with one or more
parameters. I suggest recognizing that special case and suggesting
changing '()' to '(void)'.
The second one is ok. A prototype is indeed missing, but the language
doesn't require a prototype. But if the compiler is invoked in a mode
that specifically requires prototypes, it's a valid warning.
The third one is simply incorrect. It says nothing that the first
warning didn't already tell you, and it's factually incorrect since
the ANSI^H^H^H^H ISO standard specifically allows old-style
declarations.
And *why* does the messsage refer to ANSI rather than ISO?
OK, will replace ANSI by ISO. I issue that third warning always
when I find a declaration of main that doesn't *exactly*
fit into int main(void) or int main(int argc,char *argv[])
At maximum warning level that is justified.
Keith Thompson wrote:
Ben Bacarisse <be********@bsb.me.ukwrites:
>Fr************@googlemail.com writes:
[...]
>>The seemingly ambiguous case is int main() { ... }. This could either
be regarded as main with an empty parameter-type-list, or main with a
non-supplied optional identifier-list. Which is it?
The syntax makes it quite clear, I think. See below...
>>Well, 6.5.4.3
comes to the rescue again and clears this up for us: for a function
DEFINITION, an empty list of parameters is interpreted in the first
way, specifying that the function has no parameters.
Yes but that section does not tell us how to disambiguate the () in
the function definition -- it tell us what it *means* but not what is
*is*. In fact it is not ambiguous if you look at the syntax. A
parameter type list may not be empty whereas an identifier list can
be. (Check for yourself, readers, because the syntax is complex and I
may well have got that wrong, though I have checked as carefully as I
can.)
I am open to persuasion (that int foo() { ... } acts as a prototype)
but you will have to persuade the gcc people as well! -- OK you need
to ask for -Wstrict-prototypes, but at least you can.
Yes, the grammar is in 6.7.5:
parameter-type-list:
parameter-list
parameter-list , ...
parameter-list:
parameter-declaration
parameter-list , parameter-declaration
A parameter-type-list cannot be empty.
That is confirmed in DR #317 as Harald van Dijk
told me in comp.std.c
jacob navia wrote On 09/27/07 13:42,:
Keith Thompson wrote:
>>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>>>Then, the warning I am issuing is justified!
Which one?
The second one. The discussion is about the supposed difference
between () in a function declaration, where it means "indeterminate
number of parameters" and a function definition, where some people
here say the space between the () would be "overloaded" to mean
"void".
That interpretation is not correct IMHO.
Unless there are some other postings that haven't
reached my news server yet, yours is the first in this
thread to use the word "overloaded." No post that I
have seen has stated or implied that () and (void) are
equivalent, so I'm not sure who these "some people" are.
What I have claimed is that a function definition
like `int main()' defines a function with no parameters.
Others have claimed the same thing, and some have gone
so far as to quote the Standard's statement to that
effect. The quoted language is sufficiently direct that
there is little if any room for "interpretation."
-- Er*********@sun.com
Eric Sosman wrote:
jacob navia wrote On 09/27/07 13:42,:
>Keith Thompson wrote:
>>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
Then, the warning I am issuing is justified!
Which one?
The second one. The discussion is about the supposed difference
between () in a function declaration, where it means "indeterminate
number of parameters" and a function definition, where some people
here say the space between the () would be "overloaded" to mean
"void".
That interpretation is not correct IMHO.
Unless there are some other postings that haven't
reached my news server yet, yours is the first in this
thread to use the word "overloaded." No post that I
have seen has stated or implied that () and (void) are
equivalent, so I'm not sure who these "some people" are.
What I have claimed is that a function definition
like `int main()' defines a function with no parameters.
My warning was
"missing prototype for main()\n"
Others have claimed the same thing, and some have gone
so far as to quote the Standard's statement to that
effect. The quoted language is sufficiently direct that
there is little if any room for "interpretation."
No, the language is ambiguous and needed DR 317 to
clarify things. I am correct. There is NO prototype
for a function with () in the parameter list.
On Thu, 27 Sep 2007 21:10:33 +0200, jacob navia wrote:
No, the language is ambiguous and needed DR 317 to clarify things.
No, the standard is unambiguous on () in function definitions, which is
why no changes were made as a result of the DR.
Harald van Dijk wrote:
On Thu, 27 Sep 2007 21:10:33 +0200, jacob navia wrote:
>No, the language is ambiguous and needed DR 317 to clarify things.
No, the standard is unambiguous on () in function definitions, which is
why no changes were made as a result of the DR.
Well, if that DR was needed it means that to be certain of the
unambiguous wording it was better to ask the question isn't it?
We have discussed here that at length with some citing this
and another citing that, and we could not get to a solution. OK,
after you say the answer of the committee, yes I believe it,
the wording is unambiguous ... :-)
On Thu, 27 Sep 2007 21:19:17 +0200, jacob navia wrote:
Harald van Dijk wrote:
>On Thu, 27 Sep 2007 21:10:33 +0200, jacob navia wrote:
>>No, the language is ambiguous and needed DR 317 to clarify things.
No, the standard is unambiguous on () in function definitions, which is
why no changes were made as a result of the DR.
Well, if that DR was needed it means that to be certain of the
unambiguous wording it was better to ask the question isn't it?
Yes, it means the standard is not as clear as it could (and possibly
should) be, but not more than that.
jacob navia wrote On 09/27/07 15:10,:
Eric Sosman wrote:
>>jacob navia wrote On 09/27/07 13:42,:
>>>Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>Then, the warning I am issuing is justified!
Which one?
The second one. The discussion is about the supposed difference
between () in a function declaration, where it means "indeterminate
number of parameters" and a function definition, where some people
here say the space between the () would be "overloaded" to mean
"void".
That interpretation is not correct IMHO.
Unless there are some other postings that haven't
reached my news server yet, yours is the first in this
thread to use the word "overloaded." No post that I
have seen has stated or implied that () and (void) are
equivalent, so I'm not sure who these "some people" are.
What I have claimed is that a function definition
like `int main()' defines a function with no parameters.
My warning was
"missing prototype for main()\n"
That was one of them. Another was
'int main()' is a non-ANSI definition
.... and the claim it makes is non-factual.
>>Others have claimed the same thing, and some have gone
so far as to quote the Standard's statement to that
effect. The quoted language is sufficiently direct that
there is little if any room for "interpretation."
No, the language is ambiguous and needed DR 317 to
clarify things.
There is no ambiguity. The committee reviewed the
report of the defect, responded that there was none (and
explained their reasoning), and closed the DR.
The fact that a defect report is filed does not prove
that a defect actually exists. Observe how strenuously
you yourself are denying any defect in lcc-win32 despite
the defect report that originated this very thread!
I am correct. There is NO prototype
for a function with () in the parameter list.
Nobody says there is. Furthermore, most posters agree
that *that* warning (issued twice, really) is reasonable.
It's the one about "non-ANSI" that's wrong. There is nothing
"non-ANSI" about `int main(){...}'. The ANSI Standard and
all its successors to date have all defined this construct,
have all agreed on its meaning, and have all agreed that it
is a valid definition of the `main' function for a hosted
environment.
The compiler may, of course, issue all the warnings
it wants. This particular warning is not "incorrect" in
the sense of contravening the language standard, but is
"incorrect" in the sense that it diminishes QoI. I urge
you to fix it in a future release (but I don't think it's
worth issuing a Mattel-style recall over it).
-- Er*********@sun.com Fr************@googlemail.com writes:
[...]
I don't have the energy to figure it out, but I'll take your word for
it... especially since, re-reading 6.5.4.3 in context, it does seem
that "empty list" refers to an empty identifier list.
So that's really ugly :(
int main() { ... } and int main(void) { ... } do indeed have very
subtly different semantics, which is dumb: after seeing either of them
the compiler knows exactly the signature of main, but only in one case
is it allowed to use this knowledge if it encounters main later in the
same translation unit. Yuck!
Yes, but it's a necessary ugliness. See my explanation in comp.std.c.
--
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"
On Sep 27, 8:10 pm, Philip Potter <p...@see.sig.invalidwrote:
>
int main() is ugly and obsolescent.
It is not ugly to me. The function takes no arguments so
there is nothing inside the parentheses. That's how it is
in almost every other programming language that has
functions.
Requiring text to indicate lack of parameters is ugly.
Old Wolf <ol*****@inspire.net.nzwrites:
On Sep 27, 8:10 pm, Philip Potter <p...@see.sig.invalidwrote:
>int main() is ugly and obsolescent.
It is not ugly to me. The function takes no arguments so
there is nothing inside the parentheses. That's how it is
in almost every other programming language that has
functions.
Requiring text to indicate lack of parameters is ugly.
And necessary given the need for backward compatibility with pre-ANSI
C.
--
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"
[crossposted to comp.compilers.lcc]
In comp.lang.c, Heinrich Pumpernickel wrote:
what does this warning mean ?
#include <stdio.h>
int main()
{
long l = 100;
printf("l is %li\n", l * 10L);
return 0;
}
when i compile this program with lcc-win32 it prints
lcc -A -ansic -O long.c -o long.obj
Warning c:\tmp\long.c: 4 old-style function definition for 'main'
Warning c:\tmp\long.c: 4 missing prototype for 'main'
Warning c:\tmp\long.c: 4 'int main()' is a non-ANSI definition
Warning c:\tmp\long.c: 7 printf argument mismatch for format i.
Expected long int got int
0 errors, 4 warnings
[snip]
<OT group="c.l.c">
One thing I observed a long time ago is that lcc-win32 sometimes
produces warnings for operations on signed types but not for the
same operations on unsigned types.
*long -*int ==diagnostic
*unsigned long -*unsigned int ==no diagnostic
The same seems to be true for printf() arguments as well,
long l; unsigned long ul;
printf("%li\n", l * 10); ==diagnostic
printf("%lu\n", lu * 10); ==no diagnostic
/*** begin lcctest.c ***/
#include <stdio.h>
volatile void *foo;
int main(void)
{
long l = 100;
unsigned long ul = 100;
int *pi = &l; /* line 12: produces diagnostic */
unsigned int *pui = &ul; /* line 13: no diagnostic */
/* prevent prev. two statements from being optimized away */
foo = pi; foo = pui;
printf(" l * 10: %li\n", l * 10);
printf(" ul * 10: %lu\n", ul * 10);
return 0;
}
/*** end lcctest.c ***/
$ wine lcc -ansic -A -O lcctest.c
Warning z:\src\clc\lcctest.c: 12 assignment of pointer to long int to
pointer to int
Warning z:\src\clc\lcctest.c: 18 printf argument mismatch for format i.
Expected long int got int
0 errors, 2 warnings
</OT>
"somenath" <so*********@gmail.comwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...
But If I change the code as mentioned bellow
#include<stdio.h>
int f();
int g(void);
int main(void)
{
return 0;
}
int h(void) {
return f() + g();
}
I get the linker error as
gcc -Wall x.c
/tmp/cc6rowkR.o(.text+0x1f): In function `h':
: undefined reference to `f'
/tmp/cc6rowkR.o(.text+0x26): In function `h':
: undefined reference to `g'
collect2: ld returned 1 exit status
could you please let me know why it is throwing such errors ?
You declared the functions, but you did not define them, i.e. there is no
body to your functions available. If you had enabled optimization, gcc
might have removed f(), g(), and h() entirely since they're never called
from main().
<OT>
"undefined reference to 'foo'" is almost always ld telling you that you
forgot to define the named function or link in a required library that
contains said function. If you only want to check for compilation errors
without trying to link, add "-c" to the gcc command line.
</OT>
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com
Chris Hills <ch***@phaedsys.orgwrote:
In article <_b******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
Joachim Schmitz said:
And believe it or nor, the UK is part of Europe, it is not a continent of
it's own and is even a member in the EU (still)
I'm glad you think so. Just so long as Europe stays on its side of the
water, you can think what you like. :-)
The sooner we get the Euro and fully integrated with Europe the better.
One one condition: that you get out of the United States of America.
Richard
Old Wolf wrote:
On Sep 27, 8:10 pm, Philip Potter <p...@see.sig.invalidwrote:
>int main() is ugly and obsolescent.
It is not ugly to me. The function takes no arguments so
there is nothing inside the parentheses. That's how it is
in almost every other programming language that has
functions.
Yes, and in C++ 'int main()' is definitely nicer than int main(void). But given
the C standard as we have it, writing int main() is ugly because of the mismatch
between the meaning of empty parameter lists in (non-definining) declarations
and definitions.
Requiring text to indicate lack of parameters is ugly.
I agree.
--
Philip Potter pgp <atdoc.ic.ac.uk
U wrote:
[followup set to c.l.c]
[crossposted to comp.compilers.lcc]
In comp.lang.c, Heinrich Pumpernickel wrote:
>what does this warning mean ?
#include <stdio.h>
int main()
{
long l = 100;
printf("l is %li\n", l * 10L);
return 0;
}
when i compile this program with lcc-win32 it prints
lcc -A -ansic -O long.c -o long.obj
Warning c:\tmp\long.c: 4 old-style function definition for 'main'
Warning c:\tmp\long.c: 4 missing prototype for 'main'
Warning c:\tmp\long.c: 4 'int main()' is a non-ANSI definition
Warning c:\tmp\long.c: 7 printf argument mismatch for format i.
Expected long int got int
0 errors, 4 warnings
[snip]
<OT group="c.l.c">
One thing I observed a long time ago is that lcc-win32 sometimes
produces warnings for operations on signed types but not for the
same operations on unsigned types.
*long -*int ==diagnostic
*unsigned long -*unsigned int ==no diagnostic
The same seems to be true for printf() arguments as well,
long l; unsigned long ul;
printf("%li\n", l * 10); ==diagnostic
printf("%lu\n", lu * 10); ==no diagnostic
/*** begin lcctest.c ***/
#include <stdio.h>
volatile void *foo;
int main(void)
{
long l = 100;
unsigned long ul = 100;
int *pi = &l; /* line 12: produces diagnostic */
unsigned int *pui = &ul; /* line 13: no diagnostic */
/* prevent prev. two statements from being optimized away */
foo = pi; foo = pui;
printf(" l * 10: %li\n", l * 10);
printf(" ul * 10: %lu\n", ul * 10);
return 0;
}
/*** end lcctest.c ***/
$ wine lcc -ansic -A -O lcctest.c
Warning z:\src\clc\lcctest.c: 12 assignment of pointer to long int to
pointer to int
Warning z:\src\clc\lcctest.c: 18 printf argument mismatch for format i.
Expected long int got int
0 errors, 2 warnings
</OT>
Um... wouldn't line 13 be a constraint violation and every
conforming compiler is *required* to issue a diagnostic even
when not at the highest warning level? (even warning about
line 12 is not issued without "-A".)
I have extended your test with some suspicious pointer
assignments involving 'char' and no diagnostic is issued for
those either, even at the highest warning level.
Gcc warns about lines 12, 13, 14, and 15.
Which of those are really required by the standard?
Modified test and compiler output follows.
/*** begin lcctest.c (modified by jss) ***/
#include <stdio.h>
volatile void *foo;
int main(void)
{
long l = 100;
unsigned long ul = 100;
char c = 1;
int *pi = &l; /* line 12 */
unsigned int *pui = &ul; /* line 13 */
signed char *psc = &c; /* line 14 */
unsigned char *puc = &c; /* line 15 */
/* prevent prev. two statements from being optimized away */
foo = pi; foo = pui; foo = psc; foo = puc;
printf(" l * 10: %li\n", l * 10);
printf(" ul * 10: %lu\n", ul * 10);
return 0;
}
/*** end lcctest.c ***/
lcc output:
$ wine lcc -ansic -A -O lcctest.c
Warning z:\home\jss\src\clc\lcctest.c: 14 assignment of pointer to long int
to pointer to int
Warning z:\home\jss\src\clc\lcctest.c: 22 printf argument mismatch for
format i. Expected long int got int
0 errors, 2 warnings
gcc output:
$ gcc-4.2 -Wall -W -ansi -pedantic -O2 -c lcctest.c
lcctest.c: In function 'main':
lcctest.c:13: warning: initialization from incompatible pointer type
lcctest.c:14: warning: initialization from incompatible pointer type
lcctest.c:15: warning: pointer targets in initialization differ in
signedness
lcctest.c:16: warning: pointer targets in initialization differ in
signedness
--
John J. Smith
(Just Curious)
John J. Smith wrote:
>
gcc output:
$ gcc-4.2 -Wall -W -ansi -pedantic -O2 -c lcctest.c
lcctest.c: In function 'main':
lcctest.c:13: warning: initialization from incompatible pointer type
lcctest.c:14: warning: initialization from incompatible pointer type
lcctest.c:15: warning: pointer targets in initialization differ in
signedness
lcctest.c:16: warning: pointer targets in initialization differ in
signedness
MSVC++ says:
------------------------------------------------
twarn1.c(11) : warning C4057: 'initializing' : 'int *' differs in
indirection to slightly
different base types from 'long *'
twarn1.c(12) : warning C4057: 'initializing' : 'unsigned int *' differs
in indirection to
slightly different base types from 'unsigned long *'
twarn1.c(14) : warning C4057: 'initializing' : 'unsigned char *' differs
in indirection to
slightly different base types from 'char *'
-----------------------------------------------
only at the highest warning level (-W4)
At the default level absolutely NO warnings are issued.
I am ready to change the compiler if any contradiction
to the standard is detected. I do not see here why a
warning is mandatory however.
jacob
In article <46****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>Chris Hills <ch***@phaedsys.orgwrote:
>In article <_b******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>Joachim Schmitz said:
And believe it or nor, the UK is part of Europe, it is not a continent of
it's own and is even a member in the EU (still)
I'm glad you think so. Just so long as Europe stays on its side of the
water, you can think what you like. :-)
The sooner we get the Euro and fully integrated with Europe the better.
One one condition: that you get out of the United States of America.
Absolutely!.... I couldn't agree more . Though the US can keep Blair
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Eric Sosman wrote:
[...]
There is no ambiguity. The committee reviewed the
report of the defect, responded that there was none (and
explained their reasoning), and closed the DR.
The fact that a defect report is filed does not prove
that a defect actually exists. Observe how strenuously
you yourself are denying any defect in lcc-win32 despite
the defect report that originated this very thread!
[...]
I would expect most software developers to know the difference between
a "defect report" and a "defect". The general populace, on the other
hand...
The company I work for used to keep a list of "bug reports" and their
status publicly available on the website. This stopped when TPTB at
the company that bought the company objected, stating that they were
getting complaints along the line of "why would be buy a software
package with 600 bugs?"
The fact that this list included all reports, including real bugs
that were fixed long ago, as well as non-bugs[1], seemed to elude
some people. Adding a disclaimer to that effect wasn't enough for
TPTB, and the list was removed from the publicly accessible part of
the site.
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", or "on a DT-100 terminal, the
vertical lines don't connect", or things that were simply
pure user error. These were all included in the list.
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Chris Hills <ch***@phaedsys.orgwrites:
In article <46****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites
>>Chris Hills <ch***@phaedsys.orgwrote:
>>In article <_b******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
Joachim Schmitz said:
And believe it or nor, the UK is part of Europe, it is not a
continent of it's own and is even a member in the EU (still)
I'm glad you think so. Just so long as Europe stays on its side of the
water, you can think what you like. :-)
The sooner we get the Euro and fully integrated with Europe the better.
One one condition: that you get out of the United States of America.
Absolutely!.... I couldn't agree more . Though the US can keep Blair
<SARCASM>
Yes, an international political debate is *exactly* what this
newsgroup needs.
</SARCASM>
Followups redirected.
--
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"
Keith Thompson wrote:
>
<SARCASM>
Yes, an international political debate is *exactly* what this
newsgroup needs.
</SARCASM>
Yes, Let's go back to what they were discussing before... What was it?
Ahhh yes!
Why jacob is a "Frog".
Very on topic!
On Thu, 27 Sep 2007 10:49:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Fr************@googlemail.com wrote:
>>
But that wasn't what was in the original code. The original code went:
int main()
>
This is the definition of a function with an unspecified
number of arguments.
No. This is the definition of a function with _no_ arguments.
>So the warning is indeed bogus and incorrect. :)
I do not think so. But I am not a language lawyer.
Well you bloody well should be, if you intend to claim you have
written a C compiler. Good grief.
>This means that main has no prototype since you did NOT
provide a prototype and main *IS* always called!
Note that
a) main is not required to have a prototype; and
b) a function definition _is_ a prototype, if no previous prototype
has been provided, and provided it has parameters - see 6.9.1 .
In my view, whatever else is the case, since main is not required to
have a prototype, it is simply misleading to generate errors
suggesting otherwise.
--
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
Kenneth Brody wrote:
[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]
The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".
--
Eric Sosman es*****@ieee-dot-org.invalid
jacob navia wrote:
Keith Thompson wrote:
>>
<SARCASM>
Yes, an international political debate is *exactly* what this
newsgroup needs.
</SARCASM>
Yes, Let's go back to what they were discussing before... What was it?
Ahhh yes!
Why jacob is a "Frog".
Very on topic!
"It's not that easy bein' green." -- K
--
Eric Sosman es*****@ieee-dot-org.invalid
Mark McIntyre wrote:
On Thu, 27 Sep 2007 10:49:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Fr************@googlemail.com wrote:
>>But that wasn't what was in the original code. The original code went:
int main()
>This is the definition of a function with an unspecified
number of arguments.
No. This is the definition of a function with _no_ arguments.
If I write
int foo() { return 5; }
int main() { foo(10); }
neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???
Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()
So you are just WRONG.
>>So the warning is indeed bogus and incorrect. :)
I do not think so. But I am not a language lawyer.
Well you bloody well should be, if you intend to claim you have
written a C compiler. Good grief.
I am correct according to DR 317.
And I am still not a lawyer.
On Sat, 29 Sep 2007 09:45:28 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre wrote:
>No. This is the definition of a function with _no_ arguments.
....the function definition of foo DOES NOT GIVE A PROTOTYPE
>So you are just WRONG.
Apparently as well as being not a language lawyer, you also can't
read.
I did not say it was a prototype.
>I am correct according to DR 317.
DR 317 relates to whether or not the definition void f() {} is a
prototype. Its not. I have not said otherwise. I've said it defines a
function with no arguments.
--
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
Mark McIntyre wrote:
On Sat, 29 Sep 2007 09:45:28 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre wrote:
>>No. This is the definition of a function with _no_ arguments.
....the function definition of foo DOES NOT GIVE A PROTOTYPE
>So you are just WRONG.
Apparently as well as being not a language lawyer, you also can't
read.
I did not say it was a prototype.
>I am correct according to DR 317.
DR 317 relates to whether or not the definition void f() {} is a
prototype. Its not. I have not said otherwise. I've said it defines a
function with no arguments.
Yes a function with no arguments and no prototype.
THAT IS WHY MY WARNING IS:
missing prototype for "foo".
On Sat, 29 Sep 2007 14:23:38 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>THAT IS WHY MY WARNING IS:
missing prototype for "foo".
However I was commenting on your statement that foo() {} defined a
function with an unspecified number of arguments.
If you want to retract the statement, this is probably a good time.
--
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
jacob navia <ja***@jacob.remcomp.frwrites:
Mark McIntyre wrote:
>On Thu, 27 Sep 2007 10:49:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Fr************@googlemail.com wrote:
But that wasn't what was in the original code. The original code went:
int main()
>>This is the definition of a function with an unspecified
number of arguments.
No. This is the definition of a function with _no_ arguments.
If I write
int foo() { return 5; }
int main() { foo(10); }
neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???
Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()
So you are just WRONG.
[snip]
jacob, *please* calm down. Your habit of (figuratively) jumping up
and down and shouting whenever you think you're right and somebody
else is wrong comes across as being quite childish. We all make
mistakes here. I often correct other people's mistakes, and other
people often correct my mistakes. Most of the time, it's done calmly
and politely, and I'm grateful when someone points out that I've
gotten something wrong. You're acting as if your being right is a
rare event, a cause for celebration; I really don't think that's the
impression you want to convey.
Now I suggest you re-read the above very carefully. Part of the
context was snipped; the orginal example was:
int main()
{
...
}
You said that this is the definition of a function with an unspecified
number of arguments. You were mistaken. Mark said that it's the
definition of a function with no arguments. Apart from the use of the
word "arguments" rather than "parameters", he was right. It defines a
function with no parameters. If you don't believe me, try writing
some code to replace the '..." that refers to a parameter of main.
It's true that the above definition does not provide a prototype for
main (but Mark never said that it does). It's true that, since there
is no prototype, compilers typically do not diagnose calls that
attempt to pass extra arguments (but Mark never said that they do).
The above definition *defines* main as a function with no parameters,
but it *declares* main as a function with an unspecified number and
type of parameters. I presume I don't have to explain to you the
difference between a declaration and a definition.
Mark was right. You were right in some of the things you wrote, but
you were wrong in asserting that Mark was wrong; you refuted things
that he never said.
--
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"
Keith Thompson wrote:
>
jacob navia <ja***@jacob.remcomp.frwrites:
Mark McIntyre wrote:
On Thu, 27 Sep 2007 10:49:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
Fr************@googlemail.com wrote:
But that wasn't what was in the original code. The original code went:
int main()
This is the definition of a function with an unspecified
number of arguments.
No. This is the definition of a function with _no_ arguments.
If I write
int foo() { return 5; }
int main() { foo(10); }
neither MSVC nor gcc will complain even at the HIGHEST
warning level (Wall -W4 respectively) ???
Because the function definition of foo DOES NOT GIVE A PROTOTYPE
as specified in the Defect Report 317 where the question was
explicitly posed to the standard committee that clearly answered:
NO, there is NO prototype produced by
int foo()
So you are just WRONG.
[snip]
jacob, *please* calm down. Your habit of (figuratively) jumping up
and down and shouting whenever you think you're right and somebody
else is wrong comes across as being quite childish. We all make
mistakes here. I often correct other people's mistakes, and other
people often correct my mistakes. Most of the time, it's done calmly
and politely, and I'm grateful when someone points out that I've
gotten something wrong. You're acting as if your being right is a
rare event, a cause for celebration; I really don't think that's the
impression you want to convey.
Now I suggest you re-read the above very carefully. Part of the
context was snipped; the orginal example was:
int main()
{
...
}
You said that this is the definition of a function with an unspecified
number of arguments. You were mistaken. Mark said that it's the
definition of a function with no arguments. Apart from the use of the
word "arguments" rather than "parameters", he was right. It defines a
function with no parameters. If you don't believe me, try writing
some code to replace the '..." that refers to a parameter of main.
It's true that the above definition does not provide a prototype for
main (but Mark never said that it does). It's true that, since there
is no prototype, compilers typically do not diagnose calls that
attempt to pass extra arguments (but Mark never said that they do).
The above definition *defines* main as a function with no parameters,
but it *declares* main as a function with an unspecified number and
type of parameters. I presume I don't have to explain to you the
difference between a declaration and a definition.
You might have to.
Mark was right. You were right in some of the things you wrote, but
you were wrong in asserting that Mark was wrong; you refuted things
that he never said.
Mark was righter than that.
jacob navia even quoted Mark's
explanation of the point of confusion,
and then disagreed with it,
and then followed the diagreement with something
that almost looks like an apology:
"You're right that in a DECLARATION, they are different:
>
int main(); /* main takes an unspecified number of parameters */
int main(void); /* main takes no parameters */
So the warning is indeed bogus and incorrect. :)
I do not think so. But I am not a language lawyer.
"
--
pete
On Sat, 29 Sep 2007 12:56:09 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?
MS define a whole slew of types in ALL CAPS, including LONG. .
--
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
On Fri, 28 Sep 2007 23:08:08 -0400, Eric Sosman wrote:
Kenneth Brody wrote:
>[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]
The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".
It suggests that leap seconds are due to the small inaccuracy of
the Gregorian calendar, whereas in fact they are due to the fact
that the Earth's rotation is slowing down. The proposed correction
to Gregorian calendar is to make years multiple of 4000 non-leap
(though actually the Gregorian calendar falls by about one day
in 8000 years, so accepting that proposal only for multiples of
8000 would make more sense; but anyway, the increment of the
duration of the day (the one for which leap seconds are for) will
cause the duration of the year measured in days to decrease, and
the precise rate of that is unpredictable (for example, in the
early 2000s Earth's rotation sped up, so in those years we didn't
have any leap seconds for 7 years) and therefore deciding now
changes which will apply 1993 or 5993 years from now is pointless).
--
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.
"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
[...]
>Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?
As was already mentioned elsethread, MS typedefs a truckload of all caps
types such as BYTE, WORD, LONG and DWORD intrinsically hard-wired for widths
of 8, 16 and 32 bits. After 20 years of brainwashing, it was impossible to
change the width of LONG or long for the WIN64 architecture.
[...]
But long and LONG are the same size, right? Right???
--
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"
On Sun, 30 Sep 2007 11:06:15 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>
But long and LONG are the same size, right? Right???
You would think so, wouldn't you?
--
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
Eric Sosman wrote:
>
Kenneth Brody wrote:
[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]
The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".
I've seen that before, many years ago.
However, our response at the time was basically "Not a bug -- the
year 2000 _is_ a leap year."
I also found a link to the actual text of the Act which changed the
British empire (including the U.S.A-to-be) to the Gregorian calendar.
I don't recall which URL it was at that time, but here is one that
works today: http://webexhibits.org/calendars/year-text-British.html
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
"Kenneth Brody" <ke******@spamcop.netschrieb im Newsbeitrag
news:47***************@spamcop.net...
Eric Sosman wrote:
>>
Kenneth Brody wrote:
[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]
The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".
I've seen that before, many years ago.
However, our response at the time was basically "Not a bug -- the
year 2000 _is_ a leap year."
While this is short, correct and to the point, the other is certainly more
fun to read 8-)
Bye, Jojo
"Keith Thompson" <ks***@mib.orga écrit dans le message de news: ln************@nuthaus.mib.org...
"Charlie Gordon" <ne**@chqrlie.orgwrites:
>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
[...]
>>Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?
As was already mentioned elsethread, MS typedefs a truckload of all caps
types such as BYTE, WORD, LONG and DWORD intrinsically hard-wired for
widths
of 8, 16 and 32 bits. After 20 years of brainwashing, it was impossible
to
change the width of LONG or long for the WIN64 architecture.
[...]
But long and LONG are the same size, right? Right???
They are and shall remain 32 bits in width for seculae seculorum, amen.
--
Chqrlie.
Joachim Schmitz wrote:
>
"Kenneth Brody" <ke******@spamcop.netschrieb im Newsbeitrag
news:47***************@spamcop.net...
Eric Sosman wrote:
>
Kenneth Brody wrote:
[...]
[1] We would get "bug reports" on things like "isleap() says that
the year 2000 is a leap year", [...]
The response to that one was a classic. It circulated
widely on the Net even before there was a Web, and can still
be found: Google "11-60903".
I've seen that before, many years ago.
However, our response at the time was basically "Not a bug -- the
year 2000 _is_ a leap year."
While this is short, correct and to the point, the other is certainly more
fun to read 8-)
True. But, at the time, Windows 95 was still called Chicago, the
search engines weren't as all-encompassing as they are now, and I
probably didn't know about that link at the time.
On the other hand, I did like replying to the occasional "but my
$MS_APPLICATION says that 2000 isn't a leap year" with something
along the lines of "well, then Microsoft got it wrong, and you
should send them a bug report". (Somehow that was more satisfying
than correcting those who simply said that "century years aren't
leap years".)
[Begin lame attempt to bring this back to clc.]
So, did K&R get it right in their first library?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
John J. Smith wrote, On 01/10/07 01:45:
jacob navia wrote:
<snip>
>>> long l;
unsigned long ul;
int *pi = &l; /* line 12: produces diagnostic */
unsigned int *pui = &ul; /* line 13: no diagnostic */
>>> printf(" l * 10: %li\n", l * 10); /* printf argument mismatch...*/
printf(" ul * 10: %lu\n", ul * 10); /* no warning */
I can confirm that lcc-win32 (version 3.8) issues a warning for
the statement marked 'line 12:' but not for the statement marked
'line 13:'. (MSVC warns in both cases)
Is lcc-win32's behaviour really intentional?
If it does not produce a diagnostic in standard conforming mode then it
is a bug since the standard requires a diagnostic.
--
Flash Gordon
Keith Thompson <ks***@mib.orgwrote:
"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
[...]
Does MS really define a type LONG, distinct from long, or did you put
LONG in all-caps for emphasis?
As was already mentioned elsethread, MS typedefs a truckload of all caps
types such as BYTE, WORD, LONG and DWORD intrinsically hard-wired for widths
of 8, 16 and 32 bits. After 20 years of brainwashing, it was impossible to
change the width of LONG or long for the WIN64 architecture.
But long and LONG are the same size, right? Right???
*Sigh* We can only hope. But I would never bet money on it remaining
that way. For instance, did you know that INT is typically not
typedef'ed in the same header as LONG and CHAR, but in the one which
also typedefs FLOAT and WORD? The way M$ design their systems never
ceases to amaze me, and the liberties they take with C are stunning.
Richard
On Sat, 29 Sep 2007 00:03:18 +0100, Mark McIntyre
<ma**********@spamcop.netwrote:
On Thu, 27 Sep 2007 10:49:18 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
<snip: int main (/*empty*/) { ...}>
Note that
a) main is not required to have a prototype; and
Not required by the standard. M Navia is apparently helping to enforce
a coding style that requires prototypes, which is probably a good idea
(at least when optional as he has said this is) and certainly legal.
b) a function definition _is_ a prototype, if no previous prototype
has been provided, and provided it has parameters - see 6.9.1 .
It is a prototype if it uses the (new) parameter-type-list syntax,
whether or not that declares any parameters. It is not if it has
parameters declared in the old (K&R1) style with identifier-list and
separate following declaration-list.
If there was a previous prototype (which must have been a declaration
because there can't be two definitions) then a prototype(d) definition
is still a prototype, and must be compatible with the previous
declaration(s) (else CV), but is redundant in the sense that it gives
the compiler no new information to use in compiling calls.
It is also a reasonable coding style to require a prototype
_declaration_ for all functions, or at least all with external
linkage, even if they have prototype definitions. If you follow the
convention that the declaration is in the header file and that (same)
header file is #included in both the implementation and all callers,
this checks that all callers are compatible with the callee even if
you change the interface. (Well, assuming you recompile everything
needed as with make or similar, or just recompile everything period;
AND that both/all sites actually get the same header file not some
variant or conflictingly-named one; AND nothing (important) in that
header file is affected by things e.g. typedefs or macros that are
different in the different #include'r environments. Bleah.)
In my view, whatever else is the case, since main is not required to
have a prototype, it is simply misleading to generate errors
suggesting otherwise.
See above.
- formerly david.thompson1 || achar(64) || worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ranjeet.gupta |
last post by:
warning C4013: 'localData' undefined; assuming extern returning int
What the above warning exactly mean ?
|
by: tjb |
last post by:
I often see code like this:
/// <summary>
/// Removes a node.
/// </summary>
/// <param name="node">The node to remove.</param>
public void RemoveNode(Node node) {
<...>
}
|
by: Aditya |
last post by:
Hi
I am using a line of as
char recvedValues = {'\0'};
in my code. I get a warning as near initialization for
recvedValues.
I am using gcc 3.4
Can anybody please explain the meaning.
Thanks...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
