is order urgent doubt

[Default User]

Warning: the following is entirely off-topic.

There appear to have been some problems with my posts getting through.
My provider, rr.com, was under a UDP for some time; I was under the
impression that it had been lifted, but it may sill be partially in
place.

I'm seeing messages from you with no problem that I can tell. I use
news.individual.net.




Brian

 

[Flash Gordon]

Richard Bos wrote, On 04/06/08 09:47:

I know the English have a habit of perverting any phrases they steal
from other languages,

Yes, we pervert the phases ad nausium.

but I was not yet aware that they'd done this with
ad nauseam.

If we haven't yet then I'm sure we will soon.

 

[Flash Gordon]

jacob navia wrote, On 04/06/08 12:54:

Flash Gordon wrote:

Please don't snip attributions for material that is still quoted.

Following your logic we should accept

signed long int double | int long signed double

as equivalent to

long double

Well, you have snipped all the material which explains why you should not.

since "signed long int" or "int long signed" *is* a long

The types are the same but "int long signed" is NOT a type specifier so
there is absolutely NO reason to think it can be used as one. This was
all perfectly clear in the material already posted.

Anyone have an old copy of lcc (as opposed to Jacob's compiler) that
they can test to see if this is a problem in the original compiler?

 

[lawrence.jones]

By concentrating too closely on the "set" notion you may have
been misled into thinking that `double double trouble;' is
a legitimate declaration of what's normally called a `double',
but it's not.

In fact, there are compilers that implement a double double type as an
extension. (As the name implies, it's a floating point type consisting
of a pair of doubles, which allows some strange and wonderful split-
precision operations.)

-- Larry Jones

I don't think that question was very hypothetical at all. -- Calvin

 

[Richard]

English is not queasy about adopting words and phrases from other
languages. Ad nauseum so qualifies.

English is an amalgamation of many languages from day one so I'm not
sure I see the relevance of your post. And it is certainly not On Topic
by your own strict standards.

 

[Kenny McCormack]

English is an amalgamation of many languages from day one so I'm not
sure I see the relevance of your post. And it is certainly not On Topic
by your own strict standards.

So? What's your point? CBF has never been one to be bound by his own
rules.

 

[lawrence.jones]

[*] Although one wonders why `long double' wasn't used
instead.

Because double double (using a pair of doubles to represent a single
floating-point number) in the general case doesn't adhere to the
standard's floating-point model and thus isn't a valid implementation of
long double. To be a valid long double implementation, you would have
to restrict the exponents to make the fraction bits contiguous rather
than allowing a gap or overlap.

-- Larry Jones

I think grown-ups just ACT like they know what they're doing. -- Calvin

 

[Keith Thompson]

[*] Although one wonders why `long double' wasn't used
instead.

Because double double (using a pair of doubles to represent a single
floating-point number) in the general case doesn't adhere to the
standard's floating-point model and thus isn't a valid implementation of
long double. To be a valid long double implementation, you would have
to restrict the exponents to make the fraction bits contiguous rather
than allowing a gap or overlap.

I don't quite understand. Are you talking about the layout of the
fraction bits in the representation of the type? I don't see how
making then non-contiguous would violate the C standard (assuming
__STDC_IEC_559__ isn't defined).

How is a pair of doubles used to represent a single floating-point
number anyway?

 

[Walter Roberson]

How is a pair of doubles used to represent a single floating-point
number anyway?

One particular implementation:

http://techpubs.sgi.com/library/tpl...e/catman/p_man/cat3/standard/math.z&srch=math


Long double arithmetic is supported by the compiler. The
representation used is not IEEE compliant; long doubles are
represented on this system as the sum or difference of two doubles,
normalized so that the smaller double is <= .5 ULP of the larger.
This is equivalent to a 107 bit mantissa with an 11 bit biased
exponent (bias = 1023), and 1 sign bit. In terms of decimal
precision, this is approximately 34 decimal digits.

Long double constants are coded as double precision constants followed
by the letter 'l' (upper or lower case). The largest (finite) long
double constant is 1.797693134862315807937289714053023e308L.

The smallest long double precision constant is
4.940656458412465441765687928682213e-324L.

Long doubles less than 1.805194375864829576069262081173746e-276L may
require a double denormal in their representation and therefore
contain less than 107 bits precision.

Long double NaNs and (signed) infinities are supported by the
compiler. Long double infinity is represented as the sum of a double
infinity and a double zero; similarly for NaNs.

 

[lawrence.jones]

Long double arithmetic is supported by the compiler. The
representation used is not IEEE compliant; long doubles are
represented on this system as the sum or difference of two doubles,
normalized so that the smaller double is <= .5 ULP of the larger.
This is equivalent to a 107 bit mantissa with an 11 bit biased
exponent (bias = 1023), and 1 sign bit. In terms of decimal
precision, this is approximately 34 decimal digits.

Which is a perfectly valid implementation, but only because of the
normalization. Without it, the number of bits in the (virtual) mantissa
is not fixed (there can be arbitrarily many virtual zero bits between
the actual bits from the two double, or they can overlap), which doesn't
conform to C's floating point model.

-- Larry Jones

What a stupid world. -- Calvin

 

[John J. Smith]

Flash Gordon wrote:

[snip]

Anyone have an old copy of lcc (as opposed to Jacob's compiler) that
they can test to see if this is a problem in the original compiler?

I believe Jacob once said that lcc-win is originally based on lcc-3.6;
which was released in 1996 and did not support `long long'.

lcc-4.2 (released in 2002?) is still C89, but recognizes `long long'
as a type (though it's just an alias for `long').

The major difference between lcc and lcc-win seems to be that whenever
lcc-win (based on other articles in this thread) warns about

multiple use of 'foo'

lcc (3.6 as well as 4.2) issues a hard error

invalid use of 'foo'

and does /not/ produce an object file.

With lcc-4.2, `[signed] long long [int]' and `unsigned long long [int]'
are recognized correctly in all variations.

Below is a test case with most of the constructs that appeared in this
thread so far, plus two more. Most of the diagnostics look similar to
what other posters have seen from lcc-win, with the two exceptions noted
above.

/* 1 */ /* begin foo.c */
/* 2 */ long long int ll_1;
/* 3 */ long int long ll_2;
/* 4 */ int long long ll_3;
/* 5 */
/* 6 */ double int di_1;
/* 7 */ int double di_2;
/* 8 */
/* 9 */ int int int iii;
/* 10 */ long signed long int lsli;
/* 11 */ signed long int long slil;
/* 12 */ signed long signed long slsl;
/* 13 */ signed int long signed long int silsli;
/* 14 */ long int long int lili;
/* 15 */ long int int long liil;
/* 16 */
/* 17 */ signed long int double v_1;
/* 18 */ int long signed double v_2;
/* 19 */
/* 20 */ static typedef int t_1;
/* 21 */ typedef static int t_2;
/* 22 */
/* 23 */ struct s union u { int foo; };
/* 24 */ union u struct s { int foo; };
/* 25 */
/* 29 */ main() { return 0; }
/* 30 */ /* end foo.c */

$ lcc-4.2 -A -A -c foo.c
foo.c:2: warning: `long long int' is a non-ANSI type
foo.c:3: warning: `long long int' is a non-ANSI type
foo.c:4: warning: `long long int' is a non-ANSI type
foo.c:6: invalid use of `int'
foo.c:7: invalid use of `double'
foo.c:9: invalid use of `int'
foo.c:9: invalid use of `int'
foo.c:10: warning: `long long int' is a non-ANSI type
foo.c:11: warning: `long long int' is a non-ANSI type
foo.c:12: invalid use of `signed'
foo.c:12: warning: `long long int' is a non-ANSI type
foo.c:13: invalid use of `signed'
foo.c:13: invalid use of `int'
foo.c:13: warning: `long long int' is a non-ANSI type
foo.c:14: invalid use of `int'
foo.c:14: warning: `long long int' is a non-ANSI type
foo.c:15: invalid use of `int'
foo.c:15: warning: `long long int' is a non-ANSI type
foo.c:17: invalid use of `double'
foo.c:17: invalid type specification
foo.c:18: invalid use of `double'
foo.c:18: invalid type specification
foo.c:20: invalid use of `typedef'
foo.c:21: invalid use of `static'
foo.c:23: invalid use of `union'
foo.c:24: invalid use of `struct'
foo.c:34: warning: old-style function definition for `main'
foo.c:34: warning: missing prototype for `main'
foo.c:34: warning: `int main()' is a non-ANSI definition
foo.c:21: warning: static `int t_2' is not referenced

 

[Flash Gordon]

John J. Smith wrote, On 09/06/08 21:37:

Flash Gordon wrote:

[snip]

Anyone have an old copy of lcc (as opposed to Jacob's compiler) that
they can test to see if this is a problem in the original compiler?

I believe Jacob once said that lcc-win is originally based on lcc-3.6;
which was released in 1996 and did not support `long long'.

<snip>

Ah, but did it support "long int" and "int long" as both being long? If
int and long are the same size then try it with "short int" and "int short".