Discussion:
Is it standard and practical to use long long types?
(too old to reply)
Matt
2004-04-12 21:11:10 UTC
Permalink
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
Kevin Goodsell
2004-04-12 21:45:18 UTC
Permalink
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.
Post by Matt
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?
long long (along with its variants) was added to C with the 1999 ISO
standard. C++ had not been updated with new features since 1998 (a 2003
update corrected and clarified the existing standard, but added nothing
new), and does not include long long. I don't know the details, but I'm
sure it has been discussed and may still be being discussed for
addition. I'd be surprised if it was not included in the next version of
the C++ standard.
Post by Matt
Which compilers support those types, and which do not?
C99 compilers do. Other C and C++ compilers do not, unless through
extensions.
Post by Matt
In a general practical sense, is portability impaired for programs that
use those types?
I would say so. C99 support is rather narrow at the moment.
Post by Matt
Is there any good literature on standard techniques related to word size
and portability?
I don't understand this question.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Matt
2004-04-13 00:40:20 UTC
Permalink
Post by Kevin Goodsell
Post by Matt
Is there any good literature on standard techniques related to word
size and portability?
I don't understand this question.
-Kevin
Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.
Kevin Goodsell
2004-04-13 01:42:55 UTC
Permalink
Post by Matt
Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.
Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges. So if I need a variable that might exceed 32,767, I don't use an
int. In many cases, additional precision beyond what is needed is not
harmful, so choosing something guaranteed to be "wide enough" works just
fine.

When people have problems with the differences in precision that
different implementations may use, it's usually because they want to do
something that relies on variables using a particular representation and
size. For example, writing a value out to a file as raw bits, and
reading it back in later. The simple answer to this problem is "don't do
that". A file written that way isn't portable anyway. The right thing to
do is to define your file format, and write your program so that it
handles that format (by reading & writing byte-by-byte and
reconstructing/deconstructing values as you go if necessary -- though
differences in the size of a byte could potentially cause problems).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Matt
2004-04-13 03:06:55 UTC
Permalink
Post by Kevin Goodsell
Post by Matt
Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.
Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.
OMG. Is this my punishment for cross posting?
Nils Petter Vaskinn
2004-04-13 18:40:09 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.
Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.
OMG. Is this my punishment for cross posting?
Yes :)

Seriously thogh, you now know that you can't have long long unless you
limit yourself to C99 compilers or C89 compilers with long long as an
extension, or C++ compilers with long long as an extension.
Now is the time for a new post (or two new posts if you want ansers
for both C and C++) where you tell us what you want to achieve and ask
about how to do it.

Something along the lines of

Q: I want to shuffle around data in 64 bit chunks
A: Use an array of bytes

Q: I want to do calculations on integers that require more than 32
bits of storage.
A: Look at bigint libraries, or roll your own.


Seriously these two groups is a great place to ask about how to do
anything in a compiler-independent standards-compliant way, the hard
part is phrasing the question right.
--
NPV

What did that old blonde gal say? -- That is the part you throw away.
Tom Waits - The part you throw away
Matt
2004-04-13 22:02:39 UTC
Permalink
Post by Nils Petter Vaskinn
Now is the time for a new post (or two new posts if you want ansers
for both C and C++) where you tell us what you want to achieve and ask
about how to do it.
Done. See my new post to comp.lang.c++ at 16:19 CST.
Keith Thompson
2004-04-13 06:22:00 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Is there any good literature on standard techniques related to word
size and portability?
I don't understand this question.
-Kevin
Oh. Uh, well, people have to deal with the fact that for a given
numerical type, different compilers have different precisions for the
given type. They want the same code to work the same with all or many
compilers. I am looking for descriptions of standard techniques for
doing that.
I've redirected followups to comp.lang.c.

C99 provides a standard header, <stdint.h>, that provides typedefs for
a variety of exact-width, minimum-width, and "fastest" signed and
unsigned integer types.

If your compiler doesn't support <stdint.h>, it's easy to implement
for any C90 compiler (except that it may or may not support 64-bit
types). See Doug Gwyn's public-domain q8 library, available at
<http://www.lysator.liu.se/c/q8/>.

Many pre-C99 compilers support "long long" and "unsigned long long" as
an extension, though it's not certain that the corresponding printf
formats will be supported by the library.
--
Keith Thompson (The_Other_Keith) kst-***@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"
Matt
2004-04-13 15:31:32 UTC
Permalink
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
Keith Thompson
2004-04-13 17:40:08 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough
that answers for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
Then it probably would have been better to post separately to each
newsgroup, since you're really asking two separate (but indirectly
related) questions.
--
Keith Thompson (The_Other_Keith) kst-***@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"
Matt
2004-04-13 21:39:46 UTC
Permalink
Post by Keith Thompson
Post by Matt
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough
that answers for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
Then it probably would have been better to post separately to each
newsgroup, since you're really asking two separate (but indirectly
related) questions.
Thank you. I see your point.

I often find it useful to understand one language in terms of the other.
Ioannis Vranos
2004-04-13 21:46:05 UTC
Permalink
Post by Matt
I often find it useful to understand one language in terms of the other.
C and C++ follow two different evolution paths, e.g. C99 provides a complex
type as a built in "exotic" type, while C++98 provides a complex type as
part of the standard library, which can be defined using the core language
(as a template).






Ioannis Vranos
E. Robert Tisdale
2004-04-13 21:58:19 UTC
Permalink
Post by Ioannis Vranos
C and C++ follow two different evolution paths,
?
Post by Ioannis Vranos
e.g. C99 provides a complex type as a built in "exotic" type
while C++98 provides a complex type as part of the standard library
which can be defined using the core language (as a template).
What does the C++03 [draft] standard say about type complex?
Does anything prevent C++ from "absorbing" the C99 complex type?
P.J. Plauger
2004-04-13 22:12:40 UTC
Permalink
Post by E. Robert Tisdale
Post by Ioannis Vranos
C and C++ follow two different evolution paths,
?
Post by Ioannis Vranos
e.g. C99 provides a complex type as a built in "exotic" type
while C++98 provides a complex type as part of the standard library
which can be defined using the core language (as a template).
What does the C++03 [draft] standard say about type complex?
Nothing that wasn't said in C++98.
Post by E. Robert Tisdale
Does anything prevent C++ from "absorbing" the C99 complex type?
Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Ioannis Vranos
2004-04-13 22:19:09 UTC
Permalink
Post by E. Robert Tisdale
Does anything prevent C++ from "absorbing" the C99 complex type?
Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.
And where and why the C99 "library" complex type and similar stuff are
needed in C++?






Ioannis Vranos
P.J. Plauger
2004-04-14 00:14:22 UTC
Permalink
Post by Ioannis Vranos
Post by E. Robert Tisdale
Does anything prevent C++ from "absorbing" the C99 complex type?
Nope, and in fact it just did (sort of). At the meeting last month
in Sydney the committee voted to add *all* the library stuff added
with C99 to the (non-normative) Library TR scheduled for completion
this fall (northern hemisphere). It's done in such a way that you
can write essentially equivalent code using either the builtin
complex of C99 or the template class library version in C++.
And where and why the C99 "library" complex type and similar stuff are
needed in C++?
C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Ioannis Vranos
2004-04-14 00:34:28 UTC
Permalink
Post by P.J. Plauger
Post by Ioannis Vranos
And where and why the C99 "library" complex type and similar stuff are
needed in C++?
C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.
Wouldn't it better if these functions would be new member functions of the
existing complex class?







Ioannis Vranos
Matt
2004-04-14 02:33:22 UTC
Permalink
Post by Ioannis Vranos
Post by P.J. Plauger
Post by Ioannis Vranos
And where and why the C99 "library" complex type and similar stuff are
needed in C++?
C99 defines a handful of complex functions not defined in Standard C++.
The Library TR (aka TR1) adds these functions to C++.
Wouldn't it better if these functions would be new member functions of the
existing complex class?
Amazing. How far can somebody be out of touch with one of the original
essential major design criteria of C++? I am not referring to Mr.
Plauger or any of the committee members.
Kevin Goodsell
2004-04-13 17:52:32 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right
thing to do. While related, these languages are different enough that
answers for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
But they are different languages, so they are two different questions,
with different answers. You wouldn't cross-post a message to a baking
group and an astronomy group just because you had a question about each,
would you?

You'll annoy fewer people and get better results if you follow my
advice. If nothing else, having two separate threads in different groups
makes it easier to spot messages you didn't read yet, and it's generally
less confusing for a number of reasons.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Ioannis Vranos
2004-04-13 20:09:37 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
There is no long long in C++98 standard. I also hope that there will not be
one in C++0x.






Regards,

Ioannis Vranos
PlasmaDragon
2004-04-14 08:43:27 UTC
Permalink
Post by Ioannis Vranos
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?
Ioannis Vranos
2004-04-14 14:10:04 UTC
Permalink
Post by PlasmaDragon
Post by Ioannis Vranos
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
Dan Pop
2004-04-14 15:33:14 UTC
Permalink
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
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: ***@ifh.de
Ioannis Vranos
2004-04-14 15:55:37 UTC
Permalink
Post by Dan Pop
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
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.
Post by Dan Pop
Post by Ioannis Vranos
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.
Post by Dan Pop
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
Dan Pop
2004-04-14 17:16:03 UTC
Permalink
Post by Ioannis Vranos
Post by Dan Pop
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
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...
Post by Ioannis Vranos
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".
Post by Ioannis Vranos
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...
Post by Ioannis Vranos
Post by Dan Pop
Post by Ioannis Vranos
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).
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
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.
Post by Ioannis Vranos
Post by Dan Pop
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: ***@ifh.de
Ioannis Vranos
2004-04-14 18:40:11 UTC
Permalink
Post by Dan Pop
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
Christian Bau
2004-04-14 18:29:51 UTC
Permalink
Post by Ioannis Vranos
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.
red floyd
2004-04-14 16:54:42 UTC
Permalink
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"
Julián Albo
2004-04-14 17:11:43 UTC
Permalink
Post by red floyd
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
Ben Pfaff
2004-04-14 17:55:59 UTC
Permalink
Post by Julián Albo
Post by red floyd
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
Dan Pop
2004-04-15 11:18:51 UTC
Permalink
Post by Ben Pfaff
Post by Julián Albo
Post by red floyd
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: ***@ifh.de
red floyd
2004-04-14 18:25:26 UTC
Permalink
Post by Julián Albo
Post by red floyd
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.
Christian Bau
2004-04-14 18:30:33 UTC
Permalink
Post by red floyd
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.
josh
2004-04-14 18:34:25 UTC
Permalink
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
Keith Thompson
2004-04-15 01:08:44 UTC
Permalink
"Ioannis Vranos" <***@guesswh.at.emails.ru> writes:
[...]
Post by Ioannis Vranos
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) kst-***@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"
PlasmaDragon
2004-04-14 08:57:37 UTC
Permalink
"Ioannis Vranos" <***@guesswh.at.emails.ru> wrote in message news:<c5hhdv$p9v$***@ulysses.noc.ntua.gr>...
-posted because I am asking the questions about both languages.
Post by Ioannis Vranos
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 do you hope so?
Arthur J. O'Dwyer
2004-04-14 09:05:58 UTC
Permalink
Post by Ioannis Vranos
There is no long long in C++98 standard. I also hope that there will
not be one in C++0x.
C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)

-Arthur,
insert "embed" joke here
Irrwahn Grausewitz
2004-04-14 13:31:16 UTC
Permalink
Post by Arthur J. O'Dwyer
Post by Ioannis Vranos
There is no long long in C++98 standard. I also hope that there will
not be one in C++0x.
C++0x will introduce not only "long long int," but also "signed signed
int" for those numerical applications requiring extremely positive and/or
extremely negative numbers, and probably "short short int" for the
convenience of embedded programmers.
(There is also an extremely vocal contingent pushing for the adoption of
the "do do" control structure, but it's way past their bedtime.)
-Arthur,
insert "
AFAIK the dodo concept already died out. However, I'm very
interested in the new additional meanings of 'static'.
Post by Arthur J. O'Dwyer
" joke here
--
Irrwahn Grausewitz (***@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
Dan Pop
2004-04-14 11:31:00 UTC
Permalink
Post by Matt
Post by Kevin Goodsell
Post by Matt
Hi folks. Can you help with some questions?
Cross-posting to comp.lang.c and comp.lang.c++ is rarely the right thing
to do. While related, these languages are different enough that answers
for one frequently don't apply to the other.
I cross-posted because I am asking the questions about both languages.
This is still not the right thing. Post the question separately in both
newsgroups and compare the C answers and the C++ answers.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: ***@ifh.de
Malcolm
2004-04-12 23:10:35 UTC
Permalink
Post by Matt
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?
Traditionally an int is the size of a register, and registers can be used
either to hold addresses or data, so void * is also the same size as an int.
That rule of thumb is breaking down with 64-bit architectures, because
integers usually represent real numbers (say, the number of employees in a
company) and there are only a few cases where you need a number bigger than
4 billion.
long long looks like the most likely convention to emerge for the 64-bit
type. However it will be a long time before 32-bit architectures become
rare, or long long becomes so entrenched that they are forced to support it.
Post by Matt
Is there any good literature on standard techniques related to word > size
and portability?
Not that I know of. The main reason for using a 64-bit type is to represent
a size of memory, in which case you should use size_t. Just occasionally you
will need 64 bits for another purpose (eg give the entire population of the
world an id number). In that case there is no neat solution if the target
compiler won't support 64-bit types - you will have to define a structure
and write your own arithmetical routines. (In C++ it is easier because you
can wrap into a class). typedefing long long is probably a good idea if you
think this might happen.
Kevin Goodsell
2004-04-12 23:57:23 UTC
Permalink
Post by Malcolm
Post by Matt
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?
Traditionally an int is the size of a register,
Not on 8-bit machines. It's a recommendation, not a requirement.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jack Klein
2004-04-13 03:51:43 UTC
Permalink
On Tue, 13 Apr 2004 00:10:35 +0100, "Malcolm"
Post by Malcolm
Post by Matt
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?
Traditionally an int is the size of a register, and registers can be used
either to hold addresses or data, so void * is also the same size as an int.
That rule of thumb is breaking down with 64-bit architectures, because
integers usually represent real numbers (say, the number of employees in a
company) and there are only a few cases where you need a number bigger than
4 billion.
The correspondence in size between ints and registers has been broken
in many, many platforms over the years, long before 64-bit
architectures (other than Cray, perhaps) existed.

The assumption that sizeof(void *) == sizeof(int) is horrible broken
and a crutch for the uninformed or lazy, always has been, and always
will be.

I was working today, and will be for the next few weeks, on a platform
with quite a decent C compiler where int has 16 bits and pointers have
32. Not "far" pointers, but all pointers. At the hardware level,
addresses have 32 bits and there is a 4Gb address space.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Dan Pop
2004-04-13 16:48:57 UTC
Permalink
Post by Malcolm
Post by Matt
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?
Traditionally an int is the size of a register,
This "tradition" has been broken so many times that it ceased being a
tradition long ago. The standard simply doesn't allow it for 8-bit
systems and it is very impractical for many 64-bit systems.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: ***@ifh.de
Martin Ambuhl
2004-04-13 00:35:54 UTC
Permalink
Post by Matt
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?
The C standard has included [signed | unsigned] long long now into its
4th year.

Follow-ups set to comp.lang.c.
jacob navia
2004-04-13 14:04:34 UTC
Permalink
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Ioannis Vranos
2004-04-13 14:16:05 UTC
Permalink
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.






Ioannis Vranos
Matt
2004-04-13 15:23:25 UTC
Permalink
Post by Ioannis Vranos
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.
Ioannis Vranos
Next time reply to the same person you seem to be addressing.

Next time don't post using weirdo fonts.

Next time try to give a reply that is useful to somebody.
Joona I Palaste
2004-04-13 15:43:37 UTC
Permalink
Post by Matt
Post by Ioannis Vranos
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.
Next time reply to the same person you seem to be addressing.
Next time don't post using weirdo fonts.
Next time try to give a reply that is useful to somebody.
Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?
--
/-- Joona Palaste (***@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio
Ioannis Vranos
2004-04-13 20:07:37 UTC
Permalink
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there is not
such a thing as long long type in C++. Next time do not cross post among
irrelevant newsgroups, C & C++ are different languages.
Next time reply to the same person you seem to be addressing.
Next time don't post using weirdo fonts.
Next time try to give a reply that is useful to somebody.
Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?
The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)






Ioannis Vranos
Ioannis Vranos
2004-04-13 20:29:13 UTC
Permalink
Post by Ioannis Vranos
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there
is
Post by Ioannis Vranos
not
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
such a thing as long long type in C++. Next time do not cross post
among
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
irrelevant newsgroups, C & C++ are different languages.
Next time reply to the same person you seem to be addressing.
Next time don't post using weirdo fonts.
Next time try to give a reply that is useful to somebody.
Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?
The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)
However in the new message window in Format::Encoding menu it had Greek as
preselected, i changed it to one message to Westen European (ISO) and now it
seems to remember it. Nice...






Ioannis Vranos
Matt
2004-04-13 21:06:08 UTC
Permalink
Post by Ioannis Vranos
Post by Ioannis Vranos
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
Post by jacob navia
lcc-win32 supports long long. The non-standard
__int64
is supported to maintain compatibility with Microsoft Visual C.
It is a 64 bit integer type
Looking at the subject of your message, the answer is NO since there
is
Post by Ioannis Vranos
not
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
such a thing as long long type in C++. Next time do not cross post
among
Post by Joona I Palaste
Post by Matt
Post by Ioannis Vranos
irrelevant newsgroups, C & C++ are different languages.
Next time reply to the same person you seem to be addressing.
Next time don't post using weirdo fonts.
Next time try to give a reply that is useful to somebody.
Ioannis's post appeared just fine on my newsreader. Ioannis is using
a Greek locale on his newsreader, as apparent from the ISO-8859-7
charset in his NNTP headers, but his post does not use any characters
from that charset. Perhaps your own newsreader insists on using
"weirdo fonts" for any charset that is not ISO-8859-1?
The strange thing is that in my Outlook Express preferences (both the Read
and Send section) i have set Western European (ISO) encoding. It is nice
that my MS program does what i have told it to do. :-)
However in the new message window in Format::Encoding menu it had Greek as
preselected, i changed it to one message to Westen European (ISO) and now it
seems to remember it. Nice...
Ioannis Vranos
The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).
Ioannis Vranos
2004-04-13 21:24:07 UTC
Permalink
Post by Matt
The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).
And entirely off topic in this world, i strongly suggest Mozilla Firefox.
It is my default browser now and i do not switch any kind of programs so
easily. Definetely it is worth to check it out.






Ioannis Vranos
Kevin Goodsell
2004-04-14 05:18:52 UTC
Permalink
Post by Ioannis Vranos
Post by Matt
The post to which I am now replying appears to me in a normal-size font.
Your first post showed up tiny in my browser (Mozilla 1.4.1).
And entirely off topic in this world, i strongly suggest Mozilla Firefox.
It is my default browser now and i do not switch any kind of programs so
easily. Definetely it is worth to check it out.
I use Firefox myself, but I think he mis-spoke when he said "browser".
He was probably referring to his news client (Mozilla is both, and
more). Firefox is, of course, only a web browser. I also use
Thunderbird, the stand-alone version of Mozilla's mail and news client.

In any case, the actual problem is the fonts used by Mozilla,
apparently. I know you can adjust them in Thunderbird, and I'm sure you
can in Mozilla as well. I've seen different fonts used for unusual
character sets before, but it should be easy to fix.

Incidentally Mozilla 1.4.1 is a bit old now. 1.7 is in beta, I think.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Dan Pop
2004-04-14 13:13:28 UTC
Permalink
Post by Matt
The post to which I am now replying appears to me in a normal-size font.
Usenet posts are not written in one font or another.
Post by Matt
Your first post showed up tiny in my browser (Mozilla 1.4.1).
Blame all this nonsense on *your* newsreader. Use a plain text newsreader
to avoid such problems.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: ***@ifh.de
Kevin Goodsell
2004-04-13 17:58:43 UTC
Permalink
Post by Matt
Next time reply to the same person you seem to be addressing.
Next time don't post using weirdo fonts.
Next time try to give a reply that is useful to somebody.
You are being very rude. There was nothing wrong with Ioannis's message
(as far as I can see), and it's not his fault that the person he replied
to didn't include any context to clue him in to who originally asked the
question.

As for the usefulness of replies, as I've already said you can improve
this by posting appropriately (e.g., not cross-posting between
comp.lang.c and comp.lang.c++). And Ioannis's reply was worth every cent
you paid for it and more.

Keep this up and you'll find it difficult to get good responses in the
future.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Matt
2004-04-13 22:29:38 UTC
Permalink
Post by Kevin Goodsell
You are being very rude.
Keep this up and you'll find it difficult to get good responses in the
future.
-Kevin
Well, the general technique is to know the required minimum ranges of the types and write code that doesn't rely on anything beyond those ranges.
Kevin Goodsell
2004-04-14 05:24:09 UTC
Permalink
Post by Kevin Goodsell
Well, the general technique is to know the required minimum ranges of
the types and write code that doesn't rely on anything beyond those
ranges.
Perhaps a more specific question would have gotten a more satisfactory
answer. I'm not psychic, and I cannot guess exactly what you want to do
or what your level of knowledge and experience is. So I answered the
question you asked. If you don't like the answer... well, I'd be happy
to refund the money you paid for it.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Dan Pop
2004-04-14 11:28:50 UTC
Permalink
Post by jacob navia
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...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: ***@ifh.de
CBFalconer
2004-04-14 13:50:20 UTC
Permalink
Post by Dan Pop
Post by jacob navia
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 (***@yahoo.com) (***@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
jacob navia
2004-04-14 23:11:29 UTC
Permalink
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
Ioannis Vranos
2004-04-14 23:29:32 UTC
Permalink
Post by jacob navia
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
Martin Ambuhl
2004-04-15 03:50:27 UTC
Permalink
Post by jacob navia
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.
Post by jacob navia
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.
CBFalconer
2004-04-15 03:58:43 UTC
Permalink
Post by 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.
... snip ...
Post by jacob navia
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.
Irrwahn Grausewitz
2004-04-15 10:53:48 UTC
Permalink
[cross-post to c.l.c++ stripped]
Post by 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.
<snip>
Post by jacob navia
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.
Post by jacob navia
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 (***@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
Dan Pop
2004-04-15 12:43:59 UTC
Permalink
Post by jacob navia
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.
Post by jacob navia
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?
Post by jacob navia
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.
Post by jacob navia
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.
Post by jacob navia
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.
Post by jacob navia
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: ***@ifh.de
Ioannis Vranos
2004-04-15 13:33:05 UTC
Permalink
Post by Dan Pop
Unfortunately, this is not a matter of opinion. Here are a few hard facts
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.
Post by Dan Pop
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.
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
Error test.c: 3 redeclaration of 'fileno' previously declared at
h:\lcc\include\stdio.h 149
Post by Dan Pop
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.
Post by Dan Pop
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.
Post by Dan Pop
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.
Post by Dan Pop
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!
Post by Dan Pop
For reference, this what I get from gcc, when invoked in conforming mode
fangorn:/tmp/lcc 387> gcc -ansi -pedantic -Wall test.c
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>
Post by Dan Pop
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.
Post by Dan Pop
Post by jacob navia
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.
Post by Dan Pop
Post by jacob navia
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.
Post by Dan Pop
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
2004-04-15 13:43:31 UTC
Permalink
Post by Ioannis Vranos
C:\c>\mingw\bin\gcc -std=c99 -pedantic-errors -O3 -Wall temp.c -o temp
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
Irrwahn Grausewitz
2004-04-15 15:08:00 UTC
Permalink
<snip>
Post by Ioannis Vranos
Post by Dan Pop
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>
Post by Ioannis Vranos
Post by Dan Pop
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>
Post by Ioannis Vranos
Post by Dan Pop
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 (***@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
Ioannis Vranos
2004-04-15 15:16:57 UTC
Permalink
Post by Irrwahn Grausewitz
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
2004-04-15 15:23:57 UTC
Permalink
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
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
2004-04-15 18:09:45 UTC
Permalink
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
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.
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
--
Irrwahn Grausewitz (***@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
Ioannis Vranos
2004-04-15 18:17:15 UTC
Permalink
Post by Irrwahn Grausewitz
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.
Perhaps someone will write a Dan Pop to rest human speech translator, it
can't be that difficult. One simple app where one will input Dan Pop
sentences, and read the output. Like something that will replace "B*****IT"
with "Yes, but".

Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere. :-)






Ioannis Vranos
Irrwahn Grausewitz
2004-04-15 19:22:47 UTC
Permalink
<snip>
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
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.
<snip>
Post by Ioannis Vranos
Perhaps someone will write a Dan Pop to rest human speech translator, it
can't be that difficult. One simple app where one will input Dan Pop
sentences, and read the output. Like something that will replace "B*****IT"
with "Yes, but".
Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere. :-)
Nice, I'll port it to a standard C command line version, if I get
your permission. :-) BTW, some more things that need replacement,
from the top of my head:

engage your brain
think harder
patent idiot
resident idiot
idiotic statement
...

Regards
--
Irrwahn Grausewitz (***@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
Ioannis Vranos
2004-04-15 20:10:55 UTC
Permalink
Post by Irrwahn Grausewitz
<snip>
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
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.
<snip>
Post by Ioannis Vranos
Perhaps someone will write a Dan Pop to rest human speech translator, it
can't be that difficult. One simple app where one will input Dan Pop
sentences, and read the output. Like something that will replace "B*****IT"
with "Yes, but".
Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere. :-)
Nice, I'll port it to a standard C command line version, if I get
your permission.
I 'll make also a command-line tgnu/linux port since i don't know X-Windows
programming (QT mainly). The software will be available under the GNU
license and i am thinking it will have an update option to download
dictionary updates from the net. :-)


:-) BTW, some more things that need replacement,
Post by Irrwahn Grausewitz
engage your brain
think harder
patent idiot
resident idiot
idiotic statement
:-))) Think better, "", Be more careful, Why don't you understand?, careless
statement are possible translations.


Also the program will be two way, it will be able to convert normal language
to DP language so as to help DP thinking and reply faster.






Regards,

Ioannis Vranos
Thomas Stegen
2004-04-15 20:39:41 UTC
Permalink
Ioannis Vranos wrote:

[snip]

Yeah, because the conversation you two are engaging in
is of course not rude.
--
Thomas.
Irrwahn Grausewitz
2004-04-15 21:06:27 UTC
Permalink
<snip>
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
Post by Ioannis Vranos
Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere. :-)
I 'll make also a command-line tgnu/linux port since i don't know X-Windows
programming (QT mainly). The software will be available under the GNU
license and i am thinking it will have an update option to download
dictionary updates from the net. :-)
I wonder if one could implement a Bayesian filter and scan the
archives. :o)
Post by Ioannis Vranos
Post by Irrwahn Grausewitz
:-) BTW, some more things that need replacement,
engage your brain
think harder
patent idiot
resident idiot
idiotic statement
:-))) Think better, "", Be more careful, Why don't you understand?, careless
statement are possible translations.
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.
Post by Ioannis Vranos
Also the program will be two way, it will be able to convert normal language
to DP language so as to help DP thinking and reply faster.
Oh, unlimited possibilities... :^]

Regards
--
Irrwahn Grausewitz (***@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
Ioannis Vranos
2004-04-16 03:06:04 UTC
Permalink
Post by Irrwahn Grausewitz
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
Irrwahn Grausewitz
2004-04-16 08:33:46 UTC
Permalink
"Ioannis Vranos" <***@guesswh.at.emails.ru> wrote:
<snip>
Post by Ioannis Vranos
// DP Dictionary file
//
// Syntax: DP term=Human term
<snip>
Post by Ioannis Vranos
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 (***@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
jacob navia
2004-04-15 19:17:19 UTC
Permalink
Post by Dan Pop
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
returning zero when no result is specified. I worked a day to implement
and test this "feature".

This is just bad faith Dan.

This discussion was a few weeks ago!
Ioannis Vranos
2004-04-15 21:17:19 UTC
Permalink
Post by jacob navia
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
returning zero when no result is specified. I worked a day to implement
and test this "feature".
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.






Ioannis Vranos
CBFalconer
2004-04-16 04:29:17 UTC
Permalink
Ioannis Vranos wrote:
... snip ...
Post by Ioannis Vranos
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
Dan Pop
2004-04-16 11:59:37 UTC
Permalink
Post by jacob navia
Post by Dan Pop
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: ***@ifh.de
jacob navia
2004-04-16 22:11:53 UTC
Permalink
----- Original Message -----
From: "Dan Pop" <***@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?
Post by Dan Pop
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
Keith Thompson
2004-04-16 23:59:58 UTC
Permalink
I've removed comp.lang.c++ from the newsgroups header.
[...]
Post by jacob navia
Post by Dan Pop
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?!?
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) kst-***@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
2004-04-17 01:38:36 UTC
Permalink
----- Original Message -----
From: "Keith Thompson" <kst-***@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?
Post by Keith Thompson
I've removed comp.lang.c++ from the newsgroups header.
[...]
Post by jacob navia
Post by Dan Pop
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?!?
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.
Ioannis Vranos
2004-04-17 01:46:50 UTC
Permalink
Post by jacob navia
Post by Keith Thompson
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?
Post by jacob navia
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
2004-04-15 19:20:19 UTC
Permalink
Post by Dan Pop
Error test.c: 3 redeclaration of 'fileno' previously declared at h:\lcc\include
\stdio.h 149
fileno returns the integer value (the file number) of a FILE
structure.

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.

jacob
Sam Dennis
2004-04-15 20:31:32 UTC
Permalink
Post by Dan Pop
Error test.c: 3 redeclaration of 'fileno' previously declared at
h:\lcc\include\stdio.h 149
If I had a team of people working in lcc-win32 and a huge budget I
would fix this and other warnings, looking at each function to see
which is declared in the standard and which not.
I'm sorry, but that is just pathetic. There's a summary in the standard
(at least, in C99; I'd be surprised if it was absent from C90) of what's
declared in every standard header.

Neither a large team nor budget is required to put #ifdefs around all of
the identifiers not in that list. It should not even take much of your,
evidently precious, time.

(#ifdef _POSIX_C_SOURCE seems like a good choice for this feature.)
--
++acr@,ka"
Ioannis Vranos
2004-04-15 21:19:39 UTC
Permalink
Post by Dan Pop
Post by Dan Pop
Error test.c: 3 redeclaration of 'fileno' previously declared at
h:\lcc\include
Post by Dan Pop
\stdio.h 149
fileno returns the integer value (the file number) of a FILE
structure.
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.
The global variables you are using in the library must not have an ordinary
name. The standard tells more on this. Please tell if you have the standard.
For C99 it is ISO/IEC 9899:1999 .






Ioannis Vranos
Dan Pop
2004-04-16 12:18:38 UTC
Permalink
Post by Dan Pop
Post by Dan Pop
Error test.c: 3 redeclaration of 'fileno' previously declared at
h:\lcc\include
Post by Dan Pop
\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 ;-)
Post by Dan Pop
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: ***@ifh.de
James Kuyper
2004-04-15 20:10:17 UTC
Permalink
Post by jacob navia
lcc-win32 implements most of C99.
...
Post by jacob navia
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.
Dan's claim was that lcc-win32 doesn't come close to having a fully
C99-conformant mode. I know nothing about lcc-win32, so I have no idea
whether or not he's right. However, it's not a claim that justifies
your response. A fully conforming mode is not incompatible with a live
language; the live language could be the lcc default, with the
fully-conforming mode being an option. Furthermore, even the fully
conforming mode can have a great many non-standard features, as long
as those features are provided as extensions that can only be invoked
by code that has undefined behaviour as far as the standard is
concerned.
Friedrich Dominicus
2004-04-15 07:48:44 UTC
Permalink
Post by Dan Pop
Post by jacob navia
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
Dan Pop
2004-04-15 11:36:46 UTC
Permalink
Post by Friedrich Dominicus
Post by Dan Pop
Post by jacob navia
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!
Post by Friedrich Dominicus
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.
Post by Friedrich Dominicus
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: ***@ifh.de
Nick Hounsome
2004-04-13 16:57:35 UTC
Permalink
Post by Matt
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?
Even a program using only long is not portable (in the sense that it will
always work correctly).

The only thing that the standard gaurantees (I can't find the reference) is
that int is at least 32 bits.

Therefore if you require an integer > 32 bits the only way for your program
to be
totally portable is to write your own 'BigInteger' class.

Note that you can't even portably check stuff with the preprocessor because
#if LONG_MAX < 73624963649249264926492
Is just not going to work if LONG_MAX is only 2^31-1 (I would hope for a
compiler error)

If you limit portability to machines known to support 64 bits then it is
near certainty that
long will be 64 bits - but check with the preprocessor.

If you want more than 64 bits you are unlikely to be portable to many
machines whether the
compiler supports long long or not.
I would suggest that you try:
#ifdef LONG_LONG_MAX
(or LONGLONG_MAX? )
Post by Matt
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
Martin Ambuhl
2004-04-13 18:59:07 UTC
Permalink
Post by Nick Hounsome
The only thing that the standard gaurantees (I can't find the reference) is
that int is at least 32 bits.
There is a good reason that you can't find the reference: your
assertion is wrong.
Kevin Goodsell
2004-04-13 19:10:59 UTC
Permalink
Post by Martin Ambuhl
Post by Nick Hounsome
The only thing that the standard gaurantees (I can't find the
reference) is
that int is at least 32 bits.
There is a good reason that you can't find the reference: your
assertion is wrong.
True. 'int' is only required to be at least 16 bits. There are also
numerous other guarantees: 'char' must be at least 8 bits, 'long' must
be at least 32, certain types may not have greater precision than
others, etc.

The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Nick Hounsome
2004-04-14 07:51:21 UTC
Permalink
Post by Kevin Goodsell
Post by Martin Ambuhl
Post by Nick Hounsome
The only thing that the standard gaurantees (I can't find the reference) is
that int is at least 32 bits.
There is a good reason that you can't find the reference: your
assertion is wrong.
True. 'int' is only required to be at least 16 bits. There are also
numerous other guarantees: 'char' must be at least 8 bits, 'long' must
be at least 32, certain types may not have greater precision than
others, etc.
The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.
Help me out here - what;s the std reference? The index is useless.
Martin Ambuhl
2004-04-14 08:25:56 UTC
Permalink
Post by Nick Hounsome
Post by Kevin Goodsell
The size requirements are, as far as I know, not stated explicitly, but
are implied from other requirements. In particular, restrictions on how
integers may be represented, plus the required minimum ranges for the
integer types (e.g. -32,767 to 32,767 for 'int'), imply that they must
have at least some easily determined number of bits.
Help me out here - what;s the std reference? The index is useless.
5.2.4.2.1 Sizes of integer types <limits.h>
Dan Pop
2004-04-13 17:16:38 UTC
Permalink
Post by Matt
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?
The C99 standard has adopted them, there is no C++ standard supporting
them, AFAIK. Note, however, that the vast majority of C implementations
in current use do NOT support the C99 standard. At best, they support
a subset of C99 in extended mode. And, of course, each supports a
*different* subset of C99.
Post by Matt
Which compilers support those types, and which do not?
It's not only a matter of compiler support, it's also a matter of
library support (not every compiler comes with its own libraries).
Post by Matt
In a general practical sense, is portability impaired for programs that
use those types?
Yes. A C89 compiler *must* diagnose long long as a syntax error when
invoked in conforming mode. And if you invoke it with extensions enabled
you don't have much control over what other "goodies" you get along with
the long long support and what parts of your program they can (silently)
break.
Post by Matt
Is there any good literature on standard techniques related to word size
and portability?
Each C type has a guaranteed minimal range. If you can afford using only
types whose minimal range is enough for your purposes, your application
is portable.

This is the most elegant approach, but not always the most practical
(using long when you need a 32-bit type is wasteful on platforms with
64-bit longs if you need very large arrays of that type).

Since each implementation must define the range of each standard type
in <limits.h> and <float.h>, you can use the preprocessor to discover
the minimal types that satisfy your needs on a given implementation
and use your own typedef names for them. Use your typedef's when
declaring your own variables. The drawback is that the code becomes less
readable when you don't know the exact type that is behind each variable
and it is also fairly easy to introduce very obscure bugs, this way. So,
restrict this approach to the variables that *really* need it.

C99 comes with a standard set of such typedef's, so you may want to use
the same names in your code, rather than reinventing the wheel. Have a
look at the specification of <stdint.h>.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: ***@ifh.de
Alexander Malkis
2004-04-13 23:13:51 UTC
Permalink
I already needed unsigned long long in a GNU C++ program. It was a good
spare of programming time in comparisson to using some external "big
integer" libraries.
--
Best regards,
Alex.

PS. To email me, remove "loeschedies" from the email address given.
Loading...