D
Dan Pop
They already had complex arithmetic, because it was a GNU C feature long
before C99.
Dan
They already had complex arithmetic, because it was a GNU C feature long
before C99.
Dan
K
Kevin Easton
jacob navia said:
Really? Can't you just mask out the highest bit, use the signed conversion
to convert the lower 63 bits, then if the highest bit was set add a
floating point constant to the result?
- Kevin.
K
Kevin Easton
Randy Howard said:
That's quite well known already. GCC's design is based around
portability, and some design decisions to improve this (particularly the
split between front end and back end portions) rule out some kinds of
optimisations. There's also other optimisations that can't be included
because they're patented.
- Kevin.
J
Jarno A Wuolijoki
#if LDBL_MANT_DIG>63
Add 2^63, load signed, add 2^63.
#endif
L
lawrence.jones
Randy Howard said:
One of the things we discovered working on the original C standard was
that nearly every C programmer believes that the implementation they use
is clearly the one that most people use.
-Larry Jones
Why can't I ever build character in a Miami condo or a casino somewhere?
-- Calvin
R
Richard Heathfield
Serve said:
That's right. As long as at least one C99 implementation exists for the
target platform, portability of C99 code to that platform is not an issue,
even if some vendors are slow to support C99. So, if VC doesn't conform,
find a compiler that does, and use that instead.
See above. As far as I'm concerned, it's our job to write portable code, and
the compiler vendor's job to provide conforming compilers. If the vendor
can't manage it, then buy from someone who can. Or use a free conforming
compiler if you wish and if one exists.
The inability of Microsoft to produce a C99 compiler is not a good reason
not to embrace the current C standard. (There may well /be/ good reasons,
but that isn't one of them.)
D
Dan Pop
In said:
Things are more complex than that, in real life. What if VC generates
much better object code, has much better diagnostics and debugging
facilities? Wouldn't it be sheer foolishness to ignore all these
advantages for the sake of being able to use the few bells and whistles
added by C99?
Dan
L
lawrence.jones
Dan Pop said:
That depends on how important said "bells and whistles" are to you.
After all, if you're working on a railroad, bells and whistles are
*very* important.
-Larry Jones
They can make me do it, but they can't make me do it with dignity. -- Calvin
R
Richard Heathfield
Dan said:
As I'm sure you already know, real life is off-topic in this newsgroup.
Could a strictly-conforming program tell the difference? If not, it really
doesn't matter.
That is by no means certain. It depends entirely on your priorities.
S
Simon Josefsson
Cannot easily be implemented, or not at all? Do you have an example
of something that would be impossible to translate into C89?
Thanks.
K
Kevin Easton
Simon Josefsson said:
I'm fairly sure you could write a C99 interpreter in standard C89, so a
simple proof would be to write a translator which just outputs the
interpeter source code, along with the C89 program text in an array.
- Kevin.
D
Dan Pop
In said:
External identifiers wider than six characters. Internal identifiers
wider than 31 characters. The rest of the extended translation limits.
I'm not sure if flexible array members can be implemented in truly
portable C89 code.
A large chunk of the C99 library support cannot be implemented in portable
C89 code, as well as non-library related macros, like va_copy(). Without
a portable library implementation (i.e. one relying exclusively on the
standard C89 library features), there isn't much point in translating
portable C99 code to portable C89 code.
One important reason for using C99 is to take advantage of its advanced
optimisation features: restrict and inline. Both keywords would simply
get dropped by a C99 to C89 translator, because they have no C89
counterparts.
Dan
S
Simon Josefsson
Good summary, thanks. I think a c99toc89 (c-10? c99toc90? c992c89?)
could be useful anyway, so people could start to use (some) C99
features, but still have the code compile on older systems. At least
I wouldn't consider using C99 for anything but experiments, until a
translator into C89 was available.
Kevin Easton said:
Well, yes, of course. Although strictly not impossible, I wouldn't
count this as a realistic solution, though.
C
Clint Olsen
Which kinds of optimizations? Who are the primary patent holders? I am
certainly no expert of software patents. It seems unusual that patents
would be enforced against the freeware community. It's not like anyone
working on gcc is making any money out of it.
-Clint
W
William Ahern
whether anybody is making money or not is arguable, but certainly
*many* people are deriving value. and so, then the question becomes
is the value derived more than any patent liabilities would cost.
if so, then expect rent-seekers to come out of the woodwork, a la
SCO (tho, AFAIK SCO isn't making patent claims in its current litigation).
GCC's primary goal is freedom, and that means freedom from insecurity
and doubt. having patents hanging over one's head sucks.
K
Kevin Easton
Clint Olsen said:
I don't know the specific details (though when you're talking software
patents and compilers, the names "IBM", "Intel" and "DEC" are likely to
come up). However, there are people making money out of gcc - I believe
several makers of embedded systems supply toolchains for their products
built on gcc, and Apple's OS X uses a modified gcc.
- Kevin.
D
Dan Pop
In said:
DEC has been history for quite a while...
Even if no one made any money from gcc, a gcc performing as well as the
commercial products based on the respective patents would significantly
reduce the sales of the commercial compilers (why pay big bucks for a
product that doesn't outperform a free one?).
Dan
L
lawrence.jones
Dan Pop said:
Support. Lots of people spend lots of money for compilers that don't
outperform GCC just so they have someone to complain to and, if
necessary, sue when there are problems.
-Larry Jones
Fortunately, that was our plan from the start. -- Calvin
M
Mark McIntyre
Support. Lots of people spend lots of money for compilers that don't
outperform GCC just so they have someone to complain to and, if
necessary, sue when there are problems.[/QUOTE]
And before anyone says "but GCC has a huge support team" remember that
none of them are paid to do it, and, unlike your contracted commercial
supplier, can walk away if they don't fancy fixing the bug.
G
goose
please point out exactly *which* vendor got sued as a result of an error
on the vendors part. the standard clause when buying software is *always*
along the lines of "we dont make any gaurantees as to the suitability
of this product for your use neither do we make any gaurantees or accept
any liabilities arising from the proper use of this product. this product
comes with no warranties whatsoever."
there is no one to "sue" if you use the product for the purpose it was
advertised for and it breaks. they *tell* you beforehand that even if the
product is at fault, their responsibility ends with "sorry" and a refund
on the purchase price.
When you go and purchase compiler X, you yourself *know* that you will
never sue them, and not only because they disclaim all liability, but
because a civil case of this type has never yet been successfully won,
(courts place a great deal of importance on 'precedents') you will probably
not win it unless you have deep pockets.
hth
goose,
at least gcc is better documented than most of the commercial products.
I'm still trying to find literature for builderX that will indicate the
level of c99 conformance, our local supplier insists that it is fully
compliant, but is unable thus far to point me to the documents that say
so. its been two weeks already, and i'm still waiting ...