C
Christian Bau
"Ioannis Vranos said:
unsigned char being anything other than 8 bit will break an awful lot of
code. I know that the C and C++ Standards allow this, but that compiler
will not popular.
unsigned char being anything other than 8 bit will break an awful lot of
code. I know that the C and C++ Standards allow this, but that compiler
will not popular.
C
Christian Bau
red floyd said:
More likely int128_t and int256_t.
J
josh
Microsoft has had __int64 for a while, as well as __int8, __int16, and
__int32. MSVC6 even recognizes __int128, but it doesn't actually let you
use it. (all of these, and their unsigned versions, are distict types from
the standard C++ ones)
Wouldn't a standard "at least 64 bits" type require compilers for 8-bit
processors to support math that spans 16 registers? Ouch.
-josh
I
Ioannis Vranos
Dan Pop said:
Yes i agree. Well, one thing is for sure. Whatever happens, we will keep
coding.
Regards,
Ioannis Vranos
J
jacob navia
lcc-win32 implements most of C99.
There are people here, like you, that are against my work,
for whatever reasons. You are entitled to your
opinions of course.
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.
No institution has supported lcc-win32. It is
a user supported project. There is no GNU,
nor Stallman, nor Microsoft.
Each time I say something in this forum, people like
you, or Mr "Irrwahn Grausewitz" or Mr Falconer
will inevitably say something against my work.
Not even a simple sentence like
"lcc-win32 supports long long" will go unnoticed.
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.
jacob
http://www.cs.virginia.edu/~lcc-win32
There are people here, like you, that are against my work,
for whatever reasons. You are entitled to your
opinions of course.
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.
No institution has supported lcc-win32. It is
a user supported project. There is no GNU,
nor Stallman, nor Microsoft.
Each time I say something in this forum, people like
you, or Mr "Irrwahn Grausewitz" or Mr Falconer
will inevitably say something against my work.
Not even a simple sentence like
"lcc-win32 supports long long" will go unnoticed.
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.
jacob
http://www.cs.virginia.edu/~lcc-win32
I
Ioannis Vranos
jacob navia said:
You are probably refering to clc (this thread is cross posted to clc++ too).
I was using lcc-win32 at the time i was learning C90 along with some other
commercial compiler and it was a really nice piece of work (i think i had
even sent you an email back then asking you about upcoming C99 support).
Well, some in clc are tough people, i don't know why. clc is the harshest
newsgroup i have ever met, they tend to answer angrily. I hear some coming,
i gotta go.
Ioannis Vranos
K
Keith Thompson
Ioannis Vranos said:
Quite possibly (unless someone comes up with a better idea), but it
likely won't matter much. Assuming that 128-bit integers are *ever*
commonly supported, and assuming that any C compilers that support
them are C99 compliant (or higher), you'll be able to refer to the
128-bit signed integer type as int128_t, and to the corresponding
128-bit unsigned type as uint128_t, after a "#include <stdint.h>".
The 128-bit types needn't even be standard types. They might not have
predefined names other than, say, __int128 and __uint128. The
<stdint.h> typedefs can refer to extended integer types.
M
Martin Ambuhl
jacob said:
I haven't noticed that. There are many of us who appreciate your work
and even use your product. What we are against is your gratuitous
flogging your compiler here, presenting its non-standard features as
somehow relevant to this newsgroup.
Post your suggestions to comp.std.c, where discussions of changing the
standard belong.
C
CBFalconer
jacob said:
No, you misunderstand. We criticize things that fail the
standard. You can add extensions as you wish without hurting
anybodies feelings, but they need to be capable of disarming and
the remainder should implement the full standard. All of C99
would be nice, but all of C90 should be a minimum objective.
Extensions should be clearly identified as such. Areas of failure
to implement the standards should also be clearly indicated.
We also try to limit discussion here to things that are specified
via the standards.
F
Friedrich Dominicus
Are you a bit paranoid? Just name one conforming C99 implementation
and then you can flame around as you like. Of course there is a
migration path from C89 to C99 if you can't see that, well that's you
problem
Friedrich
I
Irrwahn Grausewitz
[cross-post to c.l.c++ stripped]
FWIW, I never encountered a message indicating that its poster is
"against your work". I, for one, highly respect people who go
through the hassle to maintain a C compiler for non-profit.
What I, among others, regularly object to is the fact and the way
you try to promote lcc-win32 features as if they were of any
relevance to this forum: they're, by definition, not. Think Kant:
if everybody would start to promote his favourite extension provided
by his favourite compiler on his favourite platform, this group could
no longer work according to its intended purpose, namely providing
a place where people can discuss the "pure" C language as specified
by the relevant international standards. If you can't be bothered
to act accordingly, be prepared for your off-topic contributions
being rejected. If you can't take it, well, leave it, but whining
about the fact that comp.lang.c is not a compiler advocacy group
won't gain you anything but just another rebuttal, or even being
held for a troll and plonked in the extreme case.
And rightfully so, for the reasons given above, and in an impressive
number of posts in the past, according to the archives.
If you want to promote your own work, well, there are _definitely_
better places to put it than the body of a message posted to clc.
For a starter, try to keep it in a proper delimited sig-block or
between <OT></OT> pseudo-tags, and I suspect almost nobody here in
c.l.c will ever object to it.
If you want to propose a new feature, or changes to an existing one,
to be incorporated in a future revision of the C standard, comp.std.c
is the place to go.
Regards
jacob navia said:
FWIW, I never encountered a message indicating that its poster is
"against your work". I, for one, highly respect people who go
through the hassle to maintain a C compiler for non-profit.
What I, among others, regularly object to is the fact and the way
you try to promote lcc-win32 features as if they were of any
relevance to this forum: they're, by definition, not. Think Kant:
if everybody would start to promote his favourite extension provided
by his favourite compiler on his favourite platform, this group could
no longer work according to its intended purpose, namely providing
a place where people can discuss the "pure" C language as specified
by the relevant international standards. If you can't be bothered
to act accordingly, be prepared for your off-topic contributions
being rejected. If you can't take it, well, leave it, but whining
about the fact that comp.lang.c is not a compiler advocacy group
won't gain you anything but just another rebuttal, or even being
held for a troll and plonked in the extreme case.
And rightfully so, for the reasons given above, and in an impressive
number of posts in the past, according to the archives.
If you want to promote your own work, well, there are _definitely_
better places to put it than the body of a message posted to clc.
For a starter, try to keep it in a proper delimited sig-block or
between <OT></OT> pseudo-tags, and I suspect almost nobody here in
c.l.c will ever object to it.
If you want to propose a new feature, or changes to an existing one,
to be incorporated in a future revision of the C standard, comp.std.c
is the place to go.
Regards
D
Dan Pop
In said:
Along with a ton of new function names in the standard library, that are
almost as bad as keywords.
Dan
D
Dan Pop
Nope. YOU are!
Have I ever criticised lcc-win32 for not being C99-conforming? I have
criticised it for not conforming to *any* C standard, which is quite a
bit different.
This migration path need not break C89 conformance. gcc -ansi -pedantic
is still C89 conforming, while gcc -std=c99 -pedantic gives you the
current state of gcc on its migration path towards C99 conformance.
Now, pray tell, how do I put lcc-win32 in C89 conforming mode?
Dan
D
Dan Pop
In said:
You'd better try to figure out those reasons.
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?
Improve it all you want, as long as you don't break the compiler in
conforming mode.
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.
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.
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
I
Ioannis Vranos
Dan Pop said:
The above two are personally unimportant to me.
The above are indeed serious but have you to be insulting? Are you at war or
something? There is no need to hurt our feelings.
Well it could give a warning but i do not think it could be signaled as
error. However your 3,4,5 are indeed serious.
Nope. Valid C99 behaviour.
Thinking is one thing, criticising (and better suggesting) is another thing.
Insulting is a third thing! This guy is trying to create a useful thing for
free, i think he should be encouraged to continue with the right direction.
You also are trying to do a good thing here by making useful suggestions,
but you are doing it in the wrong way!
Yours must be old. Mine:
C:\c>\mingw\bin\gcc -std=c99 -pedantic-errors -O3 -Wall temp.c -o temp
temp.c: In function `main':
temp.c:7: warning: int format, pointer arg (arg 2)
C:\c>
Behaviour is *very important* if someone does not want to live alone in
another planet.
Again nice effort in the wrong way.
GCC does not fully support C99, yet ansi invokes it's C99 spirit.
If someone suggested something to you and at the meantime was calling you
d**khead, wouldn't you get angry? I think that you don't understand that
others get your words more seriously ad you are missing the fact that the
same words from a completely stranger is a heavy insult than when from a
close friend.
Ioannis Vranos
I
Ioannis Vranos
Ioannis Vranos said:
My mistake:
C:\c>\mingw\bin\gcc -ansi -pedantic-errors -O3 -Wall temp.c -o temp
temp.c: In function `main':
temp.c:7: warning: int format, pointer arg (arg 2)
temp.c:8: warning: control reaches end of non-void function
But i do not think the warning about int main() is so important. The others
you mentioned were. But again you must try to be more constructive.
Ioannis Vranos
I
Irrwahn Grausewitz
Ioannis Vranos said:
Sorry, but to me it seems extremely unlikely that you are not
interested in _any_ implementation defined behaviour. :^>
That's Dan. Attempts to make him improve his diplomatic skills turned
out to be futile.
But not in C89, the standard in question.
<snip>
Regards
I
Ioannis Vranos
Irrwahn Grausewitz said:
Still, we live with other people in this world.
Regards,
Ioannis Vranos
I
Ioannis Vranos
Ioannis Vranos said:
And it's not diplomatic skills, it's interaction skills.
Anyway.
Ioannis Vranos
I
Irrwahn Grausewitz
Ioannis Vranos said:
Correct. There are clever ones and dumb ones, nice ones and not
so nice ones, rude experts and kind imbeciles; there are people
feeling the necessity to practise self discipline in human
interaction, and there's Dan Pop. ;-)
If it were not for his expertise, he probably would've been
killfiled by everybody around. However, the art of successfully
communicating with Dan includes the ability to listen to what he
has to say, while blissfully ignoring the way he presents it.
His exaggerations can actually be very amusing, if you avoid to
make the mistake of taking it personally.
If I were to complain about anyone in amusenet, I'd rather object
to people like the resident quote forging troll in c.l.c, or the
ineffable nilgewater dispenser in c.p. But anyway, that's just me.
Regards