Hi folks. Can you help with some questions?
I gather that some types supported by g++ are nonstandard but have been
proposed as standards.
Are the long long and unsigned long long types still under consideration
for the ANSI C and C++ standards? Are they likely to be accepted into
the standards?
Which compilers support those types, and which do not?
In a general practical sense, is portability impaired for programs that
use those types?
Is there any good literature on standard techniques related to word size
and portability?
________________________
keywords: gnu gcc g++ borland turbo visual microsoft intel ISO ANSI
compiler long long C C++ language standard
Nov 14 '05
93  2542 
Dan Pop wrote: "jacob navia" <ja***@jacob.remcomp.fr> writes:
lcc-win32 supports long long.
Unfortunately, it does it at the expense of not being conforming
to any C standard. long long is a syntax error in C89 and
lcc-win32 is NOT a conforming C99 implementation, either. So, I
have yet to figure out what -ansic means to the lc and lcc commands.
Then again, this is only one droplet in the ocean of lcc-win32
conformance problems...
This is the sort of thing that might be controlled by the public
availability of a conformance checking suite, which could be
available in conjunction with the actual standard. Pascal had
such a thing in the early standardization days, but unfortunately
put it under the commercial control of a single firm, which
effectively wiped it out.
comp.lang.c++ dropped, comp.std.c added.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
"PlasmaDragon" <Pl**********@lycos.co.uk> wrote in message
news:15**************************@posting.google.c om... "Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:<c5**********@ulysses.noc.ntua.gr>... There is no long long in C++98 standard. I also hope that there will not
be one in C++0x.
Regards,
Ioannis Vranos
Why not?
When we will need an 128 bit type in the future we will have long long
long? At first i think long would be sufficient enough to be of 64 bits in
32-bit systems in case we need it. In 64-bit systems i feel it natural int
to be of 64 bits. In .NET that i am currently studying int and long are of
32 bit and we get __int64 for 64-bit integral type. On the other hand "long"
of C# is 64-bits.
Anyway i think that the already provided range of built in types were enough
to cover our needs and we needed to define explicitly what type we needed,
we could be provided only with typedefs in the standard library like in the
style int8, int16, int32, int64, int128 etc with the notice "where
available". That would be open for future extensions. Meanwhile the already
provided built in types would be spreaded to cover the new space, e.g. in a
max 64 bit scenario, short could be 16 bit, int 32, long 64.
Ioannis Vranos
In <c5***********@ulysses.noc.ntua.gr> "Ioannis Vranos" <iv*@guesswh.at.emails.ru> writes: When we will need an 128 bit type in the future we will have long long
long?
For the time being, there is little evidence that we're going to need an
128-bit integer type.
At first i think long would be sufficient enough to be of 64 bits in
32-bit systems in case we need it.
Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.
In 64-bit systems i feel it natural int to be of 64 bits.
Leave your feelings alone and engage your brain. If int is 64-bit, we're
left with char and short (two types) for *three* very common and popular
integer sizes: 8, 16 and 32-bit. Which of them should be dropped by the
implementor, so that int can be a 64-bit, according to your feelings?
long long is an ugly name, but it was existing practice at the time when
the C committee decided to add a new integer type that is at least 64-bit
wide. Like it or not, you'll have to live with it and I bet that the next
C++ standard will adopt it.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c5**********@sunnews.cern.ch... In <c5***********@ulysses.noc.ntua.gr> "Ioannis Vranos"
<iv*@guesswh.at.emails.ru> writes:When we will need an 128 bit type in the future we will have long long
long?
For the time being, there is little evidence that we're going to need an
128-bit integer type.
At first i think long would be sufficient enough to be of 64 bits in
32-bit systems in case we need it.
Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.
I do not know if dmr suggested that. If he did, i can have my own opinion
right? And i did not discuss popularity.
In 64-bit systems i feel it natural int to be of 64 bits.
Leave your feelings alone and engage your brain. If int is 64-bit, we're
left with char and short (two types) for *three* very common and popular
integer sizes: 8, 16 and 32-bit. Which of them should be dropped by the
implementor, so that int can be a 64-bit, according to your feelings?
Byte is 8 bit in all 64-bit systems? My last info about Itanium when it was
being designed was that it would have 16 bit bytes (which is not prohibited
as you know). Even in your case, long could have been 64 bit until 128 bit
systems become popular.
long long is an ugly name, but it was existing practice at the time when
the C committee decided to add a new integer type that is at least 64-bit
wide. Like it or not, you'll have to live with it and I bet that the next
C++ standard will adopt it.
Yes me too. I also bet that we will face a "fragmentation problem" in the
future, that is not all language features will be implemented in most
(popular) implementations as is the case of C99 now. Who can really rely
that C99 code can be really portable? And 5 years have already passed...
Ioannis Vranos
Ioannis Vranos wrote: "PlasmaDragon" <Pl**********@lycos.co.uk> wrote in message
When we will need an 128 bit type in the future we will have long long long?
No, we'll use "really long long".
When we need 256 bit ints, we'll use "jumbo long"
red floyd wrote: When we will need an 128 bit type in the future we will have long long
long?
No, we'll use "really long long".
No, adding a new keyword is more difficult to be accepted.
--
Salu2
In <c5**********@ulysses.noc.ntua.gr> "Ioannis Vranos" <iv*@guesswh.at.emails.ru> writes: "Dan Pop" <Da*****@cern.ch> wrote in message
news:c5**********@sunnews.cern.ch... In <c5***********@ulysses.noc.ntua.gr> "Ioannis Vranos"<iv*@guesswh.at.emails.ru> writes: >When we will need an 128 bit type in the future we will have long long
>long?
For the time being, there is little evidence that we're going to need an
128-bit integer type.
>At first i think long would be sufficient enough to be of 64 bits in
>32-bit systems in case we need it.
Unfortunately, the guy who invented the C language thought otherwise. And
his ideas seem to be far more popular than yours.
I do not know if dmr suggested that.
His own compiler used 32-bit longs on 32-bit hardware...
If he did, i can have my own opinion right?
Did anyone dispute your right to your own opinion? However, you expressed
it in terms of "we", so you should tell us who exactly is included in this
"we".
And i did not discuss popularity.
Yet, popularity does matter when the implementor has to decide the sizes
of the types. He could make int's 1024 bits and long's 16384 bits, but
chances are that few people will want to use his implementation...
>In 64-bit systems i feel it natural int to be of 64 bits.
Leave your feelings alone and engage your brain. If int is 64-bit, we're
left with char and short (two types) for *three* very common and popular
integer sizes: 8, 16 and 32-bit. Which of them should be dropped by the
implementor, so that int can be a 64-bit, according to your feelings?
Byte is 8 bit in all 64-bit systems?
I have yet to hear about one using another byte size. Even the
implementation for the original Cray processors had 8-bit bytes, despite
the lack of hardware support for them (the processor only supported 64-bit
word addressing).
My last info about Itanium when it was
being designed was that it would have 16 bit bytes (which is not prohibited
as you know).
Your last information about Itanium is pure bullshit. I was programming
on the Itanium back when it was called Merced and it only existed in
software emulation, so I should know. Its instruction set makes
implementations with 8, 16, 32 or 64-bit bytes perfectly possible, but
its architecture is based on 8-bit byte addressing.
If you want a processor with 16-bit bytes, have a look at the TMS-320C25,
but don't expect to find any hosted implementation for it.
Even in your case, long could have been 64 bit until 128 bit
systems become popular.
I never said it *couldn't*, I was merely talking about the current
situation, where people needed 64-bit support on 32-bit implementations
that *already* had 32-bit long's. The people maintaining these
implementations would not consider changing the size of long as an
acceptable solution (far too much existing code relied on long as a 32-bit
type), so the *only* acceptable solution was introducing a new type.
I entirely agree that, if C were invented today, long would be the right
type for 64-bit integers. But C was invented over 30 years ago and its
history does influence its current definition. long long is an ugly name, but it was existing practice at the time when
the C committee decided to add a new integer type that is at least 64-bit
wide. Like it or not, you'll have to live with it and I bet that the next
C++ standard will adopt it.
Yes me too. I also bet that we will face a "fragmentation problem" in the
future, that is not all language features will be implemented in most
(popular) implementations as is the case of C99 now. Who can really rely
that C99 code can be really portable? And 5 years have already passed...
C99 is far from being an industry standard and it is not yet clear whether
it will ever become one. Yet, it does exist and it does influence other
standards (the last Unix specification is based on it) and the C++
standardisation process seems to be moving toward adopting its new
features. Whether you (or I) like it or not.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Julián Albo <JU********@terra.es> writes: red floyd wrote:
When we will need an 128 bit type in the future we will have long long
long?
No, we'll use "really long long".
No, adding a new keyword is more difficult to be accepted.
That's no guarantee: C99 added "inline" and "restrict", which
were previously available to the user.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Julián Albo wrote: red floyd wrote:
When we will need an 128 bit type in the future we will have long long
long?
No, we'll use "really long long".
No, adding a new keyword is more difficult to be accepted.
In the future, [HUMOR] tags will be added to aid the humor-impaired in
compliance with the Americans with Disabilities Act.
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in
news:c5***********@ulysses.noc.ntua.gr: In .NET that i am currently studying int and long are of 32 bit and we
get __int64 for 64-bit integral type. On the other hand "long" of C#
is 64-bits.
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
In article <c5**********@ulysses.noc.ntua.gr>,
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote: Byte is 8 bit in all 64-bit systems? My last info about Itanium when it was
being designed was that it would have 16 bit bytes (which is not prohibited
as you know). Even in your case, long could have been 64 bit until 128 bit
systems become 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.
In article <m1******************@newssvr27.news.prodigy.com >,
red floyd <no*****@here.dude> wrote: Ioannis Vranos wrote: "PlasmaDragon" <Pl**********@lycos.co.uk> wrote in message
When we will need an 128 bit type in the future we will have long long
long?
No, we'll use "really long long".
When we need 256 bit ints, we'll use "jumbo long"
More likely int128_t and int256_t.
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c5**********@sunnews.cern.ch...
C99 is far from being an industry standard and it is not yet clear whether
it will ever become one. Yet, it does exist and it does influence other
standards (the last Unix specification is based on it) and the C++
standardisation process seems to be moving toward adopting its new
features. Whether you (or I) like it or not.
Yes i agree. Well, one thing is for sure. Whatever happens, we will keep
coding. :-)
Regards,
Ioannis Vranos
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
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader1.wanadoo.fr...
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.
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
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> writes:
[...] When we will need an 128 bit type in the future we will have long long
long?
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.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
jacob navia wrote: lcc-win32 implements most of C99.
There are people here, like you, that are against my work,
for whatever reasons.
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.
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.
Post your suggestions to comp.std.c, where discussions of changing the
standard belong.
jacob navia wrote:
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.
.... snip ...
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.
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.
--
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses. - James Rhodes. Da*****@cern.ch (Dan Pop) writes: In <c5**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:
lcc-win32 supports long long.
Unfortunately, it does it at the expense of not being conforming to any
C standard. long long is a syntax error in C89 and lcc-win32 is NOT a
conforming C99 implementation, either. So, I have yet to figure out
what -ansic means to the lc and lcc commands.
Then again, this is only one droplet in the ocean of lcc-win32 conformance
problems...
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
[cross-post to c.l.c++ stripped]
"jacob navia" <ja***@jacob.remcomp.fr> wrote: 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.
<snip>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.
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.
Not even a simple sentence like
"lcc-win32 supports long long" will go unnoticed.
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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
In <87************@blp.benpfaff.org> Ben Pfaff <bl*@cs.stanford.edu> writes: Julián Albo <JU********@terra.es> writes:
red floyd wrote:
When we will need an 128 bit type in the future we will have long long
long?
No, we'll use "really long long".
No, adding a new keyword is more difficult to be accepted.
That's no guarantee: C99 added "inline" and "restrict", which
were previously available to the user.
Along with a ton of new function names in the standard library, that are
almost as bad as keywords.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <87************@fbigm.here> Friedrich Dominicus <fr***@q-software-solutions.com> writes: Da*****@cern.ch (Dan Pop) writes:
In <c5**********@news-reader2.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes:
lcc-win32 supports long long.
Unfortunately, it does it at the expense of not being conforming to any
C standard. long long is a syntax error in C89 and lcc-win32 is NOT a
conforming C99 implementation, either. So, I have yet to figure out
what -ansic means to the lc and lcc commands.
Then again, this is only one droplet in the ocean of lcc-win32 conformance
problems...
Are you a bit paranoid?
Nope. YOU are!
Just name one conforming C99 implementation
and then you can flame around as you like.
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.
Of course there is a
migration path from C89 to C99 if you can't see that, well that's you
problem
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <c5**********@news-reader1.wanadoo.fr> "jacob navia" <ja***@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: Da*****@ifh.de
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c5**********@sunnews.cern.ch...
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.
The above two are personally unimportant to me.
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.
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.
Now, for the missing warnings:
1. The printf call is obviously wrong, yet the compiler has no objection.
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.
2. main() is defined as returning int, but it doesn't return anything at
all. Methinks a warning is badly needed.
Nope. Valid C99 behaviour.
Imagine that YOU were discovering all these things when evaluating someone
else's work. What would you think?
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!
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
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>
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?
Behaviour is *very important* if someone does not want to live alone in
another planet.
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.
Again nice effort in the wrong way.
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.
GCC does not fully support C99, yet ansi invokes it's C99 spirit.
On the contrary, you're adopting a paranoid attitude when people report
them to you, as proved by this very subthread...
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
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...
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)
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
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote: "Dan Pop" <Da*****@cern.ch> wrote in message
news:c5**********@sunnews.cern.ch...
<snip> 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.
The above two are personally unimportant to me.
Sorry, but to me it seems extremely unlikely that you are not
interested in _any_ implementation defined behaviour. :^>
<snip> 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.
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.
That's Dan. Attempts to make him improve his diplomatic skills turned
out to be futile.
<snip> 2. main() is defined as returning int, but it doesn't return anything at
all. Methinks a warning is badly needed.
Nope. Valid C99 behaviour.
But not in C89, the standard in question.
<snip>
Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:u9********************************@4ax.com...
That's Dan. Attempts to make him improve his diplomatic skills turned
out to be futile.
Still, we live with other people in this world.
Regards,
Ioannis Vranos
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr... "Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:u9********************************@4ax.com...
That's Dan. Attempts to make him improve his diplomatic skills turned
out to be futile.
Still, we live with other people in this world.
And it's not diplomatic skills, it's interaction skills.
Anyway.
Ioannis Vranos
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:n5********************************@4ax.com...
Actually, the Popism "resident idiot", when used in c.l.c, usually
refers to poor chap Marc McIntyre, but simple replacement might lead
to mildly tautological statements like "Marc McIntyre is our Marc
McIntyre."; "respected fellow poster" might fit better, then.
I dropped tonight some lines of code. The dictionary file goes like this:
// DP Dictionary file
//
// Syntax: DP term=Human term
engage your brain=think
idiot=careless
idiotic=erroneus
bullshit=wrong
-----------
And the main engine so far (at the very beginning):
Available under the GNU GPL
// The main engine of DP written in ISO C++ 98
#include <fstream>
#include <string>
#include <cctype>
class DictionaryFileException
{
};
class dictionaryFile
{
std::ifstream dicFile;
std::string dicFileName;
public:
dictionaryFile(const std::string &filePath) throw (DictionaryFileException)
{
dicFileName=filePath;
dicFile.open(filePath.c_str());
if(dicFile.fail())
throw DictionaryFileException();
FileValidation();
}
void FileValidation() throw (DictionaryFileException)
{
using namespace std;
char input[2];
do
{
dicFile.get(input,2);
if(isspace(input[0]) or (input[0]=='\\' and input[1]=='\\'))
continue;
else if(!isalpha(input[0]) and !isdigit(input[0]))
throw DictionaryFileException();
}while(!dicFile.eof());
}
};
Ioannis Vranos
Ioannis Vranos wrote:
.... snip ...
If you write a compiler (and not only) you must have the document
of the standard. Don't you have the standard?
In C99 if you do not return a value from main(), it is the same as
if you wrote return 0; . But if your compilers cis in ANSI C90
compliance mode, and not C99 then you have to issue a warning.
No you don't. It's a QOI matter, not a standards matter.
FUPs set.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote:
<snip> I dropped tonight some lines of code. The dictionary file goes like this:
// DP Dictionary file
//
// Syntax: DP term=Human term
<snip>
And the main engine so far (at the very beginning):
Available under the GNU GPL
// The main engine of DP written in ISO C++ 98
<snip>
Sigh. Seems I have to learn C++ _seriously_ in the end, then;
somehow managed to get away without doing it, up until now. ;-)
Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
In <c5**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: "Dan Pop" <Da*****@cern.ch> a écrit dans le message de
news:c5**********@sunnews.cern.ch... In <c5**********@news-reader1.wanadoo.fr> "jacob navia"
<ja***@jacob.remcomp.fr> writes:
2. main() is defined as returning int, but it doesn't return anything at
all. Methinks a warning is badly needed.
I HAD this warning, but in a discussion in this SAME GROUP in which YOU
also participated I was pointed to the C99 standard that defines main as
Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <c5**********@news-reader5.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: Error test.c: 3 redeclaration of 'fileno' previously declared ath:\lcc\include \stdio.h 149
fileno returns the integer value (the file number) of a FILE structure.
I know. I also know that it is not a standard C library feature.
I didn't put this particular identifier in my test program by pure
chance ;-)
If I had a team of people working in lcc-win32 (as gcc has)
and a huge budget (as MSVC has) I would fix this and other
warnings, looking at each function to see which is declared
in the standard and which not.
This is, of course, bullshit: identifying the nonstandard identifiers
in a standard header is a piece of cake for any serious implementor
(use grep, when in doubt) and grouping them together under the
protection of an #ifdef is even easier. Note that this is only needed
for identifiers from the program name space, you can leave the ones
in the implementation name space unprotected and no one will have
any business to complain.
Make your project open source and I'm sure you'll find people willing to
help improving it.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
----- Original Message -----
From: "Dan Pop" <Da*****@cern.ch>
Newsgroups: comp.lang.c,comp.lang.c++
Sent: Friday, April 16, 2004 1:59 PM
Subject: Re: Is it standard and practical to use long long types? In <c5**********@news-reader3.wanadoo.fr> "jacob navia"
<ja***@jacob.remcomp.fr> writes:
Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?
Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.
But I have to follow the standard.
As you, I do *not* agree with this stuff for main, but I should
do as specified anyway.
I have tried to keep all extensions compatible with the
standard and make C99 the base of the language lcc-win32
supports.
jacob
I've removed comp.lang.c++ from the newsgroups header.
"jacob navia" <ja***@jacob.remcomp.fr> writes: From: "Dan Pop" <Da*****@cern.ch>
[...] Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?
Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.
But I have to follow the standard.
But the standard doesn't say you can't issue a warning.
The standard requires diagnostics for syntax errors and constraint
violations, but an implementation is absolutely free to produce as
many additional diagnostics as it likes. (Most warning messages, as
oppposed to error messages, are like this.) If the main function
falls off the end without executing a return statement, a
C99-conforming compiler must generate code that causes it to return a
successful status, but the compiler is free to issue a warning.
As a quality-of-implementation issue, I'd suggest changing the wording
for the special case of main(), making it clear that it's allowed by
C99 but is nevertheless a bad idea. (That's a matter of opinion, of
course, but it's your compiler, and you can have it express whatever
opinion you like.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
----- Original Message -----
From: "Keith Thompson" <ks***@mib.org>
Newsgroups: comp.lang.c
Sent: Saturday, April 17, 2004 1:59 AM
Subject: Re: Is it standard and practical to use long long types? I've removed comp.lang.c++ from the newsgroups header.
"jacob navia" <ja***@jacob.remcomp.fr> writes: From: "Dan Pop" <Da*****@cern.ch>
[...] Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to
ignore my advice and now you're making ME responsible for that?!?
Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.
But I have to follow the standard.
But the standard doesn't say you can't issue a warning.
The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway :-)
How can I issue a warning about something that is
*explicitely* allowed? I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced. A better way would be
to change the standard, what looks like a minor change to
C99.
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:c5**********@news-reader3.wanadoo.fr... But the standard doesn't say you can't issue a warning.
The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway :-)
Since you *have* the standard why don't you check what it is written? I do
not consider myself capable of writing a compiler yet, but why don't you
begin implementing the standard from the first page towards the last?
How can I issue a warning about something that is
*explicitely* allowed?
If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main(). Dan Pop was saying that since you have not
implemented all C99 features (and supposedly you have implemented all the
C90 ones), you must work in C90 till you finish your C99 work.
Ioannis Vranos
>"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:c5**********@news-reader3.wanadoo.fr... How can I issue a warning about something that is
*explicitely* allowed?
In article <news:c5***********@ulysses.noc.ntua.gr>
Ioannis Vranos <iv*@guesswh.at.emails.ru> writes:If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main().
This is quite wrong.
Compilers are free to emit completely bogus warnings at any time.
For instance, given a program like:
int main(void) { return 0; }
the C standards allow the following:
% strangecc prog.c
prog.c, line 3: warning: there is no line 3
prog.c: warning: this program has no errors
prog.c: warning: your shoe laces are untied
prog.c: warning: these warnings are annoying
%
The *only* thing the C standard requires, in terms of diagnostics,
is that a translation unit that violates a "shall" in a "constraints"
section produce "at least one diagnostic".
Whether a warning constitutes such a "diagnostic" is something you
-- the compiler writer -- can put in your implementation document.
You might also note that you emit non-required warnings, how to
enable additional warnings, and so on.
To be successfully adopted, a compiler-writer should strive to
produce *useful* warnings, rather than the deliberately annoying
ones above. But the C standard makes no such requirements.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Jacob, if you're going to post a followup on the newsgroup, please
don't send it to me by e-mail as well. If you must send me a copy by
e-mail, please say so in the message so I don't waste my time replying
twice. (I saw your e-mail before the same message showed up the
newsgroup.)
For the benefit of others, here's my reply again.
On Sat, Apr 17, 2004 at 03:28:20AM +0200, jacob navia wrote:
[...] The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway :-)
Depending on how the warning is phrased, the user is probably wrong.
Nothing in the standard forbids issuing whatever warnings you like.
If you're going to be flamed anyway, you might as well do what you like.
How can I issue a warning about something that is
*explicitely* allowed?
Um, by issuing a warning about something that is explicitly allowed.
(Presumably a diagnostic about something that's not allowed would be an
error message, not a warning.)
I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced. A better way would be
to change the standard, what looks like a minor change to
C99.
The change in C99 was deliberate. A lot of us agree that it was a bad
idea, but it wasn't an accidental bug. Now that it's in the standard,
changing it would break existing valid code, so that's just not going
to happen.
Most compilers distinguish between error messages (which cause the
compilation to fail) and warnings (which don't). Some provide more
levels of diagnostics, such as informational messages. Most compilers
that provide more than one level of diagnostic provide options to
disable the lower levels (disable warnings, or show warnings but disable
informational messages). Some, including gcc, provide some options that
disable certain specific warnings.
You should almost certainly issue a warning if control can reach the
end of a non-void function other than main(), even though this isn't
strictly an error. It causes undefined behavior only if the caller uses
the result, and there's no requirement to warn about undefined behavior,
but it's almost certainly something that the programmer should fix.
If you want to warn about reaching the end of main(), I suggest using
a different message, acknowledging that it's well-defined in C99 but
invalid in C90.
There are a number of things you can do. You can issue a warning message
for a program that falls off the end of main(). You can issue something
weaker than a warning, perhaps an informational or style message.
You can provide, or not provide, an option to disable the diagnostic,
either individually or in combination with other diagnostics. You can
allow the user to control the option by means of a formatted comment
in the source, similar to what lint does, or in a config file in the
user's home directory. If you provide such an option, you can either
enable or disable the diagnostic by default.
If you want to follow the spirit of C99, it's clear that falling off
the end of main() is intended by the standard to be perfectly valid;
this argues for disabling the diagnostic by default, but it's entirely
up to you.
The only things you *can't* do are:
1. In C99 mode, reject an otherwise correct program that falls off
the end of main() (issuing a diagnostic is permitted).
2. Claim that the C99 standard doesn't allow you to issue the diagnostic
(it clearly does).
You *can* worry as much as you like about being flamed for whichever
decision you make, but I don't recommend it.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
"Chris Torek" <no****@torek.net> wrote in message
news:c5*********@news4.newsguy.com...
In article <news:c5***********@ulysses.noc.ntua.gr>
Ioannis Vranos <iv*@guesswh.at.emails.ru> writes:If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main().
This is quite wrong.
Compilers are free to emit completely bogus warnings at any time.
c.l.c. will make me insane.
In any case, bogus warnings must not exist in a decent compiler, so my
suggestion still applies.
Ioannis Vranos
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> writes: "Chris Torek" <no****@torek.net> wrote in message
news:c5*********@news4.newsguy.com... In article <news:c5***********@ulysses.noc.ntua.gr>
Ioannis Vranos <iv*@guesswh.at.emails.ru> writes:If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main().
This is quite wrong.
Compilers are free to emit completely bogus warnings at any time.
c.l.c. will make me insane.
In any case, bogus warnings must not exist in a decent compiler, so my
suggestion still applies.
The C standard doesn't distinguish between error messages and
warnings. In typical compilers, error messages are issued for syntax
errors and constraint violations, and usually result in the source
program being rejected. Warnings are issued for things that aren't
actually errors, and rarely correspond to diagnostics required by the
standard. (That's for compilers operating in a standard-compliant
mode; in non-compliant mode, it's not uncommon for compilers to issue
mere warnings for some constraint violations.) In the strictest
sense, all warnings are bogus.
Given that the C99 standard explicitly allows control to fall off the
end of main(), and defines the semantics of doing so, it does seem a
little odd for a C99-compliant compiler to warn about it. On the
other hand, omitting the return or exit() is bad style (in my
opinion), and it's invalid in C90.
If it were my compiler, I'd certainly issue a warning, or at least an
informational message, for falling off the end of any non-void
function, but I'd phrase the warning differently for the special case
of main(). I think the change in C99 was a bad idea, though I
understand that it can't now be changed back without breaking existing
code. I'd probably inhibit the warning by default in strict
C99-conforming mode, enable it by default otherwise, and provide some
kind of user option to control it.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Given that the C99 standard explicitly allows control to fall off the
end of main(), and defines the semantics of doing so, it does seem a
little odd for a C99-compliant compiler to warn about it. On the
other hand, omitting the return or exit() is bad style (in my
opinion), and it's invalid in C90.
If it were my compiler, I'd certainly issue a warning, or at least an
informational message, for falling off the end of any non-void
function, but I'd phrase the warning differently for the special case
of main().
For standard compliant code there should be no warning, as it is the case
for all C compilers i know (and C++98 compilers i know since main() is the
same there too).
I think the change in C99 was a bad idea,
I think it was ok but i believe the explicit int return type declaration of
main() should not be enforced, that is things tobecome as they were used in
K&R 2.
Ioannis Vranos
"Ioannis Vranos" <iv*@guesswh.at.emails.ru> writes: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Given that the C99 standard explicitly allows control to fall off the
end of main(), and defines the semantics of doing so, it does seem a
little odd for a C99-compliant compiler to warn about it. On the
other hand, omitting the return or exit() is bad style (in my
opinion), and it's invalid in C90.
If it were my compiler, I'd certainly issue a warning, or at least an
informational message, for falling off the end of any non-void
function, but I'd phrase the warning differently for the special case
of main().
For standard compliant code there should be no warning, as it is the case
for all C compilers i know (and C++98 compilers i know since main() is the
same there too).
You snipped the part where I said the warning should probably be
inhibited by default in C99 compliant mode. In any case, it's up to
the implementor to decide what to do about this; the standard is
silent. I think the change in C99 was a bad idea,
I think it was ok but i believe the explicit int return type declaration of
main() should not be enforced, that is things tobecome as they were used in
K&R 2.
Ok, so we disagree.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
In <c5**********@news-reader3.wanadoo.fr> "jacob navia" <ja***@jacob.remcomp.fr> writes: ----- Original Message -----
From: "Keith Thompson" <ks***@mib.org>
Newsgroups: comp.lang.c
Sent: Saturday, April 17, 2004 1:59 AM
Subject: Re: Is it standard and practical to use long long types?
I've removed comp.lang.c++ from the newsgroups header.
"jacob navia" <ja***@jacob.remcomp.fr> writes: > From: "Dan Pop" <Da*****@cern.ch> [...] > > Do you remember MY contribution to that discussion? I was strongly
> > arguing that your compiler was doing the RIGHT thing. You chose toignore > > my advice and now you're making ME responsible for that?!?
>
> Wait Dan, I saw that sentence in the standard, and I wrote
> in this group that you were right.
>
> But I have to follow the standard.
But the standard doesn't say you can't issue a warning.
The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway :-)
So, you should have worded it differently, so that it doesn't contradict
the standard. Something like gcc's:
warning: control reaches end of non-void function
is certainly not contradicting *any* C standard.
How can I issue a warning about something that is
*explicitely* allowed?
That's the very point about warnings. If it weren't allowed, they would
be errors and not warnings. ALL warnings *should* be about things that
are allowed, but probably not a good idea, for one reason or another.
Again, an example from gcc:
fangorn:~/tmp 477> cat test.c
int main()
{
unsigned char c = 0;
if (c < 0) ;
return 0;
}
fangorn:~/tmp 478> gcc test.c
test.c: In function `main':
test.c:4: warning: comparison is always false due to limited range of data type
My program is as strictly conforming as you can get, yet gcc emits a
warning that proved to be extremely useful when porting real world
programs.
It is most unfortunate that many compilers emit diagnostics *required* by
the standard as warnings, simply because the compiler can proceed
processing the input file(s), despite the incorrect code. The most
frequent example is:
int foo;
char *p = &foo;
It is trivial to provide the missing cast, but, by using a warning, the
unsuspecting programmer may decide that the code is correct and the
compiler writer is excessively picky.
I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced.
The standard explicitly allows
int main() { return 0; }
yet you have no qualms issuing no less than *three* diagnostics for this
correct program. Misplaced warnings, heh?!?
A better way would be
to change the standard, what looks like a minor change to C99.
It won't (realistically) happen, as this is a new C99 feature. The best
way of expressing your disapproval is by producing the warning shown
above (BTW, the standard allows *any* function defined as returning
something not to return anything).
And I have already asked you NOT to send me copies of your replies by
private email, unless you want to move the discussion to private email.
Yet, you keep ignoring this request... Is common netiquette a concept
beyong your grasp?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: hostmaster |
last post by:
Hi,
I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid....
|
by: Matt |
last post by:
Hi folks. Can you help with some questions?
I gather that some types supported by g++ are nonstandard but have been
proposed as standards.
Are the long long and unsigned long long types still...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
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: 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,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| |
