Re: Is it standard and practical to use long long types?
From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 04/15/04
- Next message: Dan Pop: "Re: main function address"
- Previous message: Irrwahn Grausewitz: "Re: converting char array to integer"
- In reply to: jacob navia: "Re: Is it standard and practical to use long long types?"
- Next in thread: Ioannis Vranos: "Re: Is it standard and practical to use long long types?"
- Reply: Ioannis Vranos: "Re: Is it standard and practical to use long long types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Apr 2004 12:43:59 GMT
In <c5kgf2$ktc$1@news-reader1.wanadoo.fr> "jacob navia" <jacob@jacob.remcomp.fr> writes:
>lcc-win32 implements most of C99.
>
>There are people here, like you, that are against my work,
>for whatever reasons.
You'd better try to figure out those reasons.
>You are entitled to your opinions of course.
Unfortunately, this is not a matter of opinion. Here are a few hard facts
about your implementation:
1. Inconsistent documentation. MANUAL.DOC says that -ANSI is the
right option for putting the compiler in conforming mode. The online
help says that you need -ansic for this purpose. Only the latter
is actually recognised by the compiler, but the result is not a
conforming compiler.
2. I couldn't find the implementation's document of conformance (maybe
I didn't try hard enough).
An implementation shall be accompanied by a document that defines
^^^^^^^^
all implementation-defined and locale-specific characteristics
^^^^^^^^^^^^^^^^^^^^^^^^^^
and all extensions.
3. Dirty headers. Non-standard functions are declared even when the
compiler is invoked with the extensions disabled, breaking correct
C programs. See the example below.
4. Bogus/idiotic warnings when all warnings are enabled. See the example
below.
5. Badly needed warnings not produced even when all warnings are enabled:
T:\lcc>type test.c
#include <stdio.h>
int fileno;
int main()
{
printf("hello world %d\n", "bar");
}
T:\lcc>lcc -ansic -A test.c
Error test.c: 3 redeclaration of 'fileno' previously declared at h:\lcc\include
\stdio.h 149
Warning test.c: 6 old-style function definition for 'main'
Warning test.c: 6 missing prototype for 'main'
Warning test.c: 6 'int main()' is a non-ANSI definition
1 errors, 3 warnings
Let's look at each diagnostic:
Error test.c: 3 redeclaration of 'fileno' previously declared at h:\lcc\include\stdio.h 149
stdio.h has no business to declare an identifier "fileno" when the
compiler is invoked in conforming mode. Chapter and verse available.
Warning test.c: 6 old-style function definition for 'main'
This one is OK. Except for the fact that the line number is wrong: main
id defined on line 5.
Warning test.c: 6 missing prototype for 'main'
I can't see any call to main() in my program, so why should I provide
a prototype for it? And I've been already chastised for using an
old-style definition for it, right?
Warning test.c: 6 'int main()' is a non-ANSI definition
That's BULLSHIT, Jacob. 'int main()' *is* an ANSI definition. It's even
a C99-conforming definition for the main function. If you don't
believe me, ask in comp.std.c.
Now, for the missing warnings:
1. The printf call is obviously wrong, yet the compiler has no objection.
2. main() is defined as returning int, but it doesn't return anything at
all. Methinks a warning is badly needed.
Imagine that YOU were discovering all these things when evaluating someone
else's work. What would you think?
For reference, this what I get from gcc, when invoked in conforming mode
and with additional warnings enabled:
fangorn:/tmp/lcc 387> gcc -ansi -pedantic -Wall test.c
test.c: In function `main':
test.c:7: warning: int format, pointer arg (arg 2)
test.c:8: warning: control reaches end of non-void function
No bullshit and only the really objectionable "features" of my program
are reported. Do you understand now why your compiler looks like a bad
joke in the eyes of a competent professional, who expects high quality
tools and not toys, even when they are free?
>I am not as orthodox as you would like,
>and I dare to believe that C is not a dead
>language and can be improved.
Improve it all you want, as long as you don't break the compiler in
conforming mode.
>No institution has supported lcc-win32. It is
>a user supported project. There is no GNU,
>nor Stallman, nor Microsoft.
This is a lame excuse for not doing the right thing. It doesn't take more
effort to get things right, you just have to think more seriously about
what you're doing. I refuse to believe that fixing all the issues I've
mentioned above takes herculean efforts.
>Not even a simple sentence like
>"lcc-win32 supports long long" will go unnoticed.
You have a very strange attitude toward bug reports. Yes, it was meant
as a bug report, because it is not done the right way: -ansic should put
the compiler in the only conforming mode it can current support (C89)
and the C99 support should be available *only* when the compiler is
invoked with extensions enabled. You can also add an additional switch,
say -c99, that enables all the C99 features currently supported and
disables other extensions. Again, you can use gcc as an example of
how to get it right: gcc -std=c89 vs gcc -std=c99. Don't be afraid to
look at what other people working on similar projects are doing.
>Go ahead. I do not fear discussions. lcc-win32 has
>a download rate of approx 5000/month. There are
>thousands of users that are using the software I built.
>
>True, there are bugs, and problems. I try to solve them
>as they arise.
On the contrary, you're adopting a paranoid attitude when people report
them to you, as proved by this very subthread...
People are often asking here about a free compiler to use under Windows.
I had a look at yours precisely because I was intending to recommend it
as an option (I'm not a Windows programmer myself). In its current state,
I'm afraid I can only recommend them NOT to use it and to consider one of
the gcc ports instead. Too bad...
Dan
-- Dan Pop DESY Zeuthen, RZ group Email: Dan.Pop@ifh.de
- Next message: Dan Pop: "Re: main function address"
- Previous message: Irrwahn Grausewitz: "Re: converting char array to integer"
- In reply to: jacob navia: "Re: Is it standard and practical to use long long types?"
- Next in thread: Ioannis Vranos: "Re: Is it standard and practical to use long long types?"
- Reply: Ioannis Vranos: "Re: Is it standard and practical to use long long types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
