is order urgent doubt
new to c
I write the 2 codes
int i;
i = sizeof(long int);
printf("%i", i);
i = sizeof(int long);
printf("%i", i);
and the first code and second code print 4.
I write another 2 codes
i = sizeof(double int);
printf("%i", i);
i = sizeof(int double);
printf("%i", i);
and the first code print 4 and the second code print 8.
My doubt is why is different number? Is order urgent?
Eric Sosman
> Hi!
>
> I write the 2 codes
>
> int i;
> i = sizeof(long int);
> printf("%i", i);
>
> i = sizeof(int long);
> printf("%i", i);
>
> and the first code and second code print 4.
>
> I write another 2 codes
>
> i = sizeof(double int);
> printf("%i", i);
>
> i = sizeof(int double);
> printf("%i", i);
>
> and the first code print 4 and the second code print 8.
I'm surprised you got any output at all, because neither
`double int' nor `int double' is a valid type name. You
should have received error messages from the compiler.
> My doubt is why is different number? Is order urgent?
Not in C, but your compiler seems to be processing some
other language.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Keith Thompson
> I write the 2 codes
>
> int i;
> i = sizeof(long int);
> printf("%i", i);
>
> i = sizeof(int long);
> printf("%i", i);
>
> and the first code and second code print 4.
Right. It won't necessarily be 4 on all systems, but both are
equivalent.
However, "int long" is very non-idiomatic. The compiler can handle it
with no problem, but human readers are going to stumble over it.
(Please ignore the long flame war that will now begin claiming that
anyone who knows C should be able to read "int long" without any
trouble. The fact that the C standard allows variations in the order
of the keywords is fairly obscure; a member of the standard committee
recently posted here saying he didn't even know about it.)
> I write another 2 codes
>
> i = sizeof(double int);
> printf("%i", i);
>
> i = sizeof(int double);
> printf("%i", i);
>
> and the first code print 4 and the second code print 8.
That's surprising. Your compiler should have rejected it, or at least
warned you about it. Are you sure that's *exactly* what you wrote?
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
<snip>
> (Please ignore the long flame war that will now begin claiming that
> anyone who knows C should be able to read "int long" without any
> trouble.
Well, really, Keith, they *should*. I suppose I differ from the "char
unsigned" camp in that I think that writing "char unsigned" rather than
"unsigned char" is bone-headedly dense and ludicrously unfriendly, but
that doesn't give C programmers an excuse not to know that it's possible -
or at least not to be able to find out quickly that it's possible and
legal, the first time they encounter it, which is admittedly "never" for
most C programmers.
> The fact that the C standard allows variations in the order
> of the keywords is fairly obscure; a member of the standard committee
> recently posted here saying he didn't even know about it.)
I think that says more about the member than it does about the language.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
teapot
It appears to be pseudo legal in <unnamed compiler>.
In case OP is using said compiler, here are some quick observations --
(1) if `signed' and `unsigned' appear in the same declaration, only
the last one specified affects signedness.
[Based on earlier observations, <unnamed compiler> accepts
`signed main()' but rejects `unsigned main()'. Tests show that
`unsigned signed main()' is accepted but `signed unsigned main()'
is not, from that we can conclude that later modifiers affecting
signedness probably overrule earlier ones.]
(2) if more than one base type appears in a declaration, sometimes,
later conflicting types overrule earlier ones.
[The test method here uses the fact that doing something illegal
(assignment to object of incompatible type) produces a diagnostic
that reveals the actual type of the created object. Consider this
code snippet
void *foo;
double int bar; /* line 5 */
int double baz; /* line 6 */
foo = bar; /* line 7 */
foo = baz; /* line 8 */
5: W: multiple use of 'int'
6: W: multiple use of 'double'
7: E: operands of = have illegal types 'pointer to void' and 'int'
8: E: operands of = have illegal types 'pointer to void' and 'double'
From that we can conclude that `bar' probably has type `int' and
`baz' probaby has type `double'.
Using the same procedure it turns out that `long long double' is
seen as plain `double', but `long double int' is `long int'.
`long short' is `short' and `short long' is `long', `long short long'
is `long' and `short long short' is `short' -- the same rules
affecting signedness discovered in (1) probably also apply when
deciding short or longness.
There is, however, a small inconsistency in that `short short short'
is probably `short' but `long long long' is in category (3)]
(3) other combinations are flagged as errors and compilation stops --
[Same method used as before
void *foo;
unsigned double bar; /* line 5 */
double unsigned baz; /* line 6 */
foo = bar; /* line 7 */
foo = baz; /* line 8 */
5: E: invalid type specification
6: E: invalid type specification
In conclusion, <unnamed compiler> treats some illegal combinations
of types/types and types/modifiers as errors, others merely as
warnings; but they are warned about even without any flags
requesting extra warnings and <unnamed compiler> appears to be
conforming in these regards.
Answering the original question, `double int' is not a valid
type, but some implementations, in certain cases, appear to pick
one type if more than one is given. In <unnamed compiler>,
`double int' is seen as `int',
and
`int double' is seen as `double',
in both cases after issuing the required diagnostic (warning).
--
T.Pot.
new to c
He warn "multiple use of int" on first code and "multiple use of double"
on second code but I think is bogus......only one int in first code and
only one double in second code.
I write big international program and need double integer. Why size is
different when other order?
Eric Sosman
> Keith Thompson wrote:
>
>> new to c <n...@spam.invalid> writes:
>>> I write another 2 codes
>>>
>>> i = sizeof(double int);
>>> printf("%i", i);
>>>
>>> i = sizeof(int double);
>>> printf("%i", i);
>>>
>>> and the first code print 4 and the second code print 8.
>> That's surprising. Your compiler should have rejected it, or at least
>> warned you about it. Are you sure that's *exactly* what you wrote?
>>
>
> He warn "multiple use of int" on first code and "multiple use of double"
> on second code but I think is bogus......only one int in first code and
> only one double in second code.
The wording of the diagnostic message may be misleading,
but that's something you should learn to expect when dealing
with computers. You should start by reading the message and
trying to understand its complaint. If it seems to make no
sense, re-interpret it as meaning "Something is wrong here, but
I can't describe it." If even that seems to make no sense,
read it as "Something is wrong somewhere, maybe not close to
the spot the message complains about."
> I write big international program and need double integer. Why size is
> different when other order?
There is no such thing as a `double int' or `int double'
in C. Why do you believe you need a "double integer," that
is, what do you hope a "double integer" variable will do
for your program? What are the characteristics of the "double
integer" you think you need? Perhaps there is some actual C
type that will suit your purpose.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Bartc
"new to c" <n...@spam.invalid> wrote in message
news:6468955.g...@news.aioe.org...
> I write big international program and need double integer. Why size is
> different when other order?
Try: long long int
If you're lucky, this will have size 8.
In C, 'double' is just a bigger version of 'float'
--
Bartc
new to c
>
>"new to c" <n...@spam.invalid> wrote in message
>news:6468955.g...@news.aioe.org...
>
>
>> I write big international program and need double integer. Why size is
>> different when other order?
>
>Try: long long int
>
>If you're lucky, this will have size 8.
>
Problem equal.
int i;
i = sizeof(long long int);
printf("%i", i);
i = sizeof(long int long);
printf("%i", i);
i = sizeof(int long long);
printf("%i", i);
First code warn nothing and print 8.
Second code warn "multiple use of 'long'" and print 4.
Third code warm "multiple use of 'longlong'" and print 8.
Why is different number? Is order urgent?
santosh
As far as I can see, you shouldn't have got any of those warnings.
Keith Thompson
>>"new to c" <n...@spam.invalid> wrote in message
>>news:6468955.g...@news.aioe.org...
>>
>>> I write big international program and need double integer. Why size is
>>> different when other order?
>>
>>Try: long long int
>>
>>If you're lucky, this will have size 8.
>>
>
> Problem equal.
You mean "the same problem".
> int i;
> i = sizeof(long long int);
> printf("%i", i);
>
> i = sizeof(long int long);
> printf("%i", i);
>
> i = sizeof(int long long);
> printf("%i", i);
>
> First code warn nothing and print 8.
>
> Second code warn "multiple use of 'long'" and print 4.
>
> Third code warm "multiple use of 'longlong'" and print 8.
>
> Why is different number? Is order urgent?
You mean "important" or "significant", not "urgent".
Assuming the code you posted is the code you actually compiled and
ran, it appears that your compiler is buggy. What compiler are you
using?
Please post a small complete program that exhibits the problem.
Copy-and-paste the entire exact program; don't re-type it or summarize
it. Show us the compiler's warnings and the program's output
(copy-and-paste them as well).
Change each "%i" to "%i\n" (or "%d\n", which is equivalent but more
common).
Not all compilers support "long long", but most do (the feature was
added in C99, but a lot of pre-C99 compilers support it as an
extension).
All three chunks of code are exactly equivalent. For an integer type,
the order of the keywords is not significant; all of "long long int",
"long int long", and "int long long" mean exactly the same thing. If
your compiler is treating them differently, then there's a bug in your
compiler. (I think we've already told you this.)
As a matter of programming style, messing around with the order of the
keywords isn't a good idea. A properly working compiler won't care,
but using an order other than the usual one will just make your code
(slightly) harder to read, with no real benefit. (It's been argued
that using, for example, "long unsigned" rather than "unsigned long"
helps to remind you to use "%lu" rather than "%ul" for printf; I don't
find that argument convincing.)
Also, if you use the more common orderings, it's likely you can avoid
triggering your compiler's bugs (though I'd recommend finding a
compiler that works properly).
Bartc
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnhccbb...@nuthaus.mib.org...
I tried his code with 4 compilers. Three worked as expected (supporting long
long in any order and giving a size of 8). The fourth (lccwin) didn't seem
to
like 'long' following 'int'. (I don't know what compiler the OP used)
--
Bartc
new to c
I use wedit IDE.
I write this code :
#include <stdio.h>
int main(void)
{
int i;
i = sizeof(long int);
printf("sizeof(long int): %d\n", i);
i = sizeof(int long);
printf("sizeof(int long): %d\n", i);
i = sizeof(double int);
printf("sizeof(double int): %d\n", i);
i = sizeof(int double);
printf("sizeof(int double): %d\n", i);
i = sizeof(long long int);
printf("sizeof(long long int): %d\n", i);
i = sizeof(long int long);
printf("sizeof(long int long): %d\n", i);
i = sizeof(int long long);
printf("sizeof(int long long): %d\n", i);
return 0;
}
Compiler warn
Warning c:\New_Folder\Test.c: 3 old-style definition for 'main'
Warning c:\New_Folder\Test.c: 3 missing prototype for 'main'
Warning c:\New_Folder\Test.c: 12 multiple use of 'int'
Warning c:\New_Folder\Test.c: 15 multiple use of 'double'
Warning c:\New_Folder\Test.c: 21 multiple use of 'long'
Warning c:\New_Folder\Test.c: 24 multiple use of 'longlong'
Compilation + link time 24.2 sec, Return code: 0
Code print
sizeof(long int): 4
sizeof(int long): 4
sizeof(double int): 4
sizeof(int double): 8
sizeof(long long int): 8
sizeof(long int long): 4
sizeof(int long long): 8
Keith Thompson
[...]
>>Please post a small complete program that exhibits the problem.
>>Copy-and-paste the entire exact program; don't re-type it or summarize
>>it. Show us the compiler's warnings and the program's output
>>(copy-and-paste them as well).
> I use wedit IDE.
According to what I've been able to find from a quick Google search,
wedit is an IDE that can be configured to work with different
compilers. Which *compiler* are you using? (I don't recognize the
layout of the warning messages.)
> I write this code :
>
> #include <stdio.h>
> int main(void)
> {
> int i;
>
> i = sizeof(long int);
> printf("sizeof(long int): %d\n", i);
>
> i = sizeof(int long);
> printf("sizeof(int long): %d\n", i);
>
> i = sizeof(double int);
> printf("sizeof(double int): %d\n", i);
>
> i = sizeof(int double);
> printf("sizeof(int double): %d\n", i);
>
> i = sizeof(long long int);
> printf("sizeof(long long int): %d\n", i);
>
> i = sizeof(long int long);
> printf("sizeof(long int long): %d\n", i);
>
> i = sizeof(int long long);
> printf("sizeof(int long long): %d\n", i);
>
> return 0;
> }
>
> Compiler warn
>
> Warning c:\New_Folder\Test.c: 3 old-style definition for 'main'
> Warning c:\New_Folder\Test.c: 3 missing prototype for 'main'
That's just plain wrong. "int main(void)" is a prototype, not an
old-style definition. I'm quite surprised that any compiler would get
this wrong. Are you *sure* that the code you posted is the same as
the code the compiler is seeing? Maybe the IDE is causing confusion
about the code in the editor vs. the code in the source file.
Try inserting a single blank line at the very top of the file and
recompiling. It should change the line numbers in the warning
messages and have no other effect. If you do this experiment, don't
bother posting the full results; just let us know whether it behaves
as I described. If so, it tends to confirm that the compiler is
really seeing the code that you posted.
> Warning c:\New_Folder\Test.c: 12 multiple use of 'int'
For "double int". A diagnostic is required, but the compiler is
confused.
> Warning c:\New_Folder\Test.c: 15 multiple use of 'double'
For "int double". See above.
> Warning c:\New_Folder\Test.c: 21 multiple use of 'long'
This is for "long int long". It would be reasonable if it were a C90
compiler that doesn't accept long long, but it didn't complain about
"long long int" 3 lines up.
> Warning c:\New_Folder\Test.c: 24 multiple use of 'longlong'
And that's just silly. Perhaps "longlong" is some internal name that
leaked out into the warning message.
[snip]
It looks like you've got a seriously buggy compiler on your hands,
though it might be able to handle code that's carefully written to
avoid its shortcomings. We still don't know which compiler it is. If
you can find out, see if there's a newer version.
Ben Bacarisse
> Which *compiler* are you using? (I don't recognize the
> layout of the warning messages.)
It is lcc-win32. At least, this is something I've seen lcc-win32 get
wrong and error message look the same as the ones I see from
lcc-win32.
--
Ben.
Ike Naar
Does it really take 24 seconds to compile such a tiny program?
Are you using very old equipment, and perhaps a very old (pre-ANSI) compiler?
Regards,
Ike
jacob navia
Hi.
I am the author of lcc-win. I have changed the warning messages to a
clearer one. Now your program produces the following warnings:
Warning td.c: 12 multiple types in a declaration. Last will be used: 'int'
Warning td.c: 15 multiple types in a declaration. Last will be used:
'double'
Warning td.c: 21 multiple types in a declaration. Last will be used: 'long'
Warning td.c: 24 multiple types in a declaration. Last will be used:
'longlong'
Maybe this will clarify what lcc-win is doing.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Keith Thompson
> new to c wrote:
[...]
> clearer one. Now your program produces the following warnings:
> Warning td.c: 12 multiple types in a declaration. Last will be used: 'int'
> Warning td.c: 15 multiple types in a declaration. Last will be used:
> 'double'
> Warning td.c: 21 multiple types in a declaration. Last will be used: 'long'
> Warning td.c: 24 multiple types in a declaration. Last will be used:
> 'longlong'
>
> Maybe this will clarify what lcc-win is doing.
lcc-win appears to meet the standard's requirement of issuing at
least one diagnostic for any translation unit containing a constraint
violation or syntax error.
Some questions, though:
1. Why not make "double int" and "int double" fatal errors?
IMHO you're not doing the user any favors by accepting these
and arbitrarily guessing what was meant.
2. Why do you warn about "long int long" and "int long long", both
of which are perfectly legal? I consider them both poor style,
but that's not what the warnings say.
3. Why does one of your warnings refer to "longlong" (presumably
something internal to the compiler)?
4. Do you still treat "long int long" as "long"? If so, that's
just a bug; "long int long" is equivalent to "long long".
Flash Gordon
> new to c wrote:
<snip>
>> Code print
>>
>> sizeof(long int): 4
>> sizeof(int long): 4
>> sizeof(double int): 4
>> sizeof(int double): 8
>> sizeof(long long int): 8
>> sizeof(long int long): 4
<snip>
Jacob, in addition to Keith's questions did you notice that the above is
wrong? As "long int long" is the same as "long long" the above should be 8.
<snip>
> Maybe this will clarify what lcc-win is doing.
Those warnings made it clearer in my opinion, but I agree with Keith's
comments.
--
Flash Gordon
jacob navia
> jacob navia wrote, On 03/06/08 07:21:
>> new to c wrote:
>
> <snip>
>
>>> Code print
>>>
>>> sizeof(long int): 4
>>> sizeof(int long): 4
>>> sizeof(double int): 4
>>> sizeof(int double): 8
>>> sizeof(long long int): 8
>>> sizeof(long int long): 4
>
> <snip>
>
> Jacob, in addition to Keith's questions did you notice that the above is
> wrong? As "long int long" is the same as "long long" the above should be 8.
>
6.7.2 Type specifiers
Syntax
1 type-specifier:
void char short int long float double signed unsigned _Bool _Complex
_Imaginary struct-or-union-specifier enum-specifier typedef-name
Constraints
2 At least one type specifier shall be given in the declaration
specifiers in each declaration, and in the specifier-qualifier list in
each struct declaration and type name. Each list of type specifiers
shall be one of the following sets (delimited by commas, when there is
more than one set on a line); the type specifiers may occur in any
order, possibly
intermixed with the other declaration specifiers.
— void
— char
— signed char
— unsigned char
— short, signed short, short int, or signed short int
— unsigned short, or unsigned short int
— int, signed, or signed int
— unsigned, or unsigned int
— long, signed long, long int, or signed long int
— unsigned long, or unsigned long int
— long long, signed long long, long long int, or
signed long long int
— unsigned long long, or unsigned long long int
— float
— double
— long double
— _Bool
— float _Complex
— double _Complex
— long double _Complex
— float _Imaginary
— double _Imaginary
— long double _Imaginary
— struct or union specifier
— enum specifier
— typedef name
OK, then , I see:
— long long, signed long long, long long int, or signed long long int
— unsigned long long, or unsigned long long int
as legal declarations for long long variants.
long int long is a double declaration:
long int, and then long.
> <snip>
>
>> Maybe this will clarify what lcc-win is doing.
>
> Those warnings made it clearer in my opinion, but I agree with Keith's
> comments.
??? I do not see any message from Keith in this thread.
Could you clarify?
Walter Roberson
>6.7.2 Type specifiers
>Each list of type specifiers
>shall be one of the following sets (delimited by commas, when there is
>more than one set on a line); the type specifiers may occur in any
>order, possibly
>intermixed with the other declaration specifiers.
Notice that bit about "in any order". So long long int is the
same as long int long .
--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest
jacob navia
> In article <g248q6$3u7$1...@aioe.org>, jacob navia <ja...@nospam.org> wrote:
>
>> 6.7.2 Type specifiers
>
>> Each list of type specifiers
>> shall be one of the following sets (delimited by commas, when there is
>> more than one set on a line); the type specifiers may occur in any
>> order, possibly
>> intermixed with the other declaration specifiers.
>
> Notice that bit about "in any order". So long long int is the
> same as long int long .
And why is not long int, then long?
What about
int int int m;
And any kind of nonsense you can think about?
long signed long int,
signed long int long,
signed long signed long,
signed int long signed long int
long int long int
long int int long
ad nauseum?
I just use the last one parsed.
Antoninus Twink
> ??? I do not see any message from Keith in this thread.
> Could you clarify?
I believe Keith's news provider is under a UDP for flooding Usenet with
SPAM, so your news server may not be carrying his messages. Whether
that's a bad thing or not is for you to decide...
(I think he switched to aioe for a while, but gave up when they went
down for a couple of days - they're back now.)
Antoninus Twink
> And any kind of nonsense you can think about?
>
> long signed long int,
> signed long int long,
> signed long signed long,
> signed int long signed long int
> long int long int
> long int int long
Don't look now, but I wouldn't be surprised if Tomas
OEh_weird_non_ASCII_characters_ilde uses at least one of these as a
completely normal piece of syntax that he thinks no one should bat an
eyelid at.
jacob navia
Strange. I see some messages from Keith in other threads but not in
this one... Go figure
Keith Thompson
> Flash Gordon wrote:
[...]
>> Those warnings made it clearer in my opinion, but I agree with
>> Keith's comments.
>
> ??? I do not see any message from Keith in this thread.
> Could you clarify?
This is my fifth article in this thread.
Apparently my postings aren't getting through to your server. I know
there was a UDP against rr.com. After aioe.org went away temporarily,
I tried posting from rr.com again, and I was getting responses here,
so I assumed the UDP had been lifted. Apparently it was only
partially lifted.
I'll consider going back to posting through aioe.org. In the meantime,
my postings are appearing on groups.google.com. This thread is at
http://groups.google.com/group/comp.lang.c/browse_frm/thread/bb79fcbc32e45a5d/459429dfa58200bf
In the meantime, will somebody (not using rr.com) please post a
followup quoting this entire article?
james...@verizon.net
> jacob navia <ja...@nospam.com> writes:
> > Flash Gordon wrote:
> [...]
> >> Those warnings made it clearer in my opinion, but I agree with
> >> Keith's comments.
>
> > ??? I do not see any message from Keith in this thread.
> > Could you clarify?
>
> This is my fifth article in this thread.
>
> Apparently my postings aren't getting through to your server. I know
> there was a UDP against rr.com. After aioe.org went away temporarily,
> I tried posting from rr.com again, and I was getting responses here,
> so I assumed the UDP had been lifted. Apparently it was only
> partially lifted.
>
> I'll consider going back to posting through aioe.org. In the meantime,
> my postings are appearing on groups.google.com. This thread is at
>
>
> In the meantime, will somebody (not using rr.com) please post a
> followup quoting this entire article?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
> Nokia
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
Glad to be of service.
Harald van Dijk
> Walter Roberson wrote:
>> In article <g248q6$3u7$1...@aioe.org>, jacob navia <ja...@nospam.org>
>> wrote:
>>
>>> 6.7.2 Type specifiers
>>
>>> Each list of type specifiers
>>> shall be one of the following sets (delimited by commas, when there is
>>> more than one set on a line); the type specifiers may occur in any
>>> order, possibly
>>> intermixed with the other declaration specifiers.
>>
>> Notice that bit about "in any order". So long long int is the same as
>> long int long .
>
> And why is not long int, then long?
Because type specifiers are interpreted as a group, not individually.
> What about
>
> int int int m;
No, not that. "In any order" means just that: you can shuffle all you
want, but you can't add or remove keywords.
> And any kind of nonsense you can think about?
>
> long signed long int,
> signed long int long,
Both are valid, and mean signed long long int, as signed and int each
appear once, and long appears twice.
> signed long signed long,
> signed int long signed long int
> long int long int
> long int int long
All of these are invalid. Neither signed nor int may occur more than once
in a series of type specifiers.
Flash Gordon
> Walter Roberson wrote:
>> In article <g248q6$3u7$1...@aioe.org>, jacob navia <ja...@nospam.org>
>> wrote:
>>
>>> 6.7.2 Type specifiers
>>
>>> Each list of type specifiers shall be one of the following sets
>>> (delimited by commas, when there is
>>> more than one set on a line); the type specifiers may occur in any
>>> order, possibly
>>> intermixed with the other declaration specifiers.
>>
>> Notice that bit about "in any order". So long long int is the
>> same as long int long .
>
> And why is not long int, then long?
"long int" *is* "long", just as "unsigned char" and "char unsigned" are
the same.
> What about
>
> int int int m;
The standard does not list any options with multiple int type specifiers.
Also note that is specifies that "long" is a type specifier but does
*not* list "long long" as a type specifier, so "long long" is two "long"
type specifiers.
> And any kind of nonsense you can think about?
>
> long signed long int,
Yes.
> signed long int long,
Yes.
> signed long signed long,
No because you have "signed" twice and that is not listed as allowed.
> signed int long signed long int
> long int long int
> long int int long
>
> ad nauseum?
Not anything, only "long" is allowed to appear twice. However you can
also have:
int long const long volatile unsigned
> I just use the last one parsed.
Well, that is a bug then. I'm surprised you did not raise this not long
back when there was another long discussion about "unsigned long" verses
"long unsigned".
--
Flash Gordon
Flash Gordon
Jacob, I've quoted Keith's message in its entirety for you as you could
not see it. As I say, I agree with his comments although strangely
enough I managed to miss his last one when reading first time or I would
not have made the same point!
--
Flash Gordon
Eric Sosman
> Walter Roberson wrote:
>> In article <g248q6$3u7$1...@aioe.org>, jacob navia <ja...@nospam.org>
>> wrote:
>>
>>> 6.7.2 Type specifiers
>>
>>> Each list of type specifiers shall be one of the following sets
>>> (delimited by commas, when there is
>>> more than one set on a line); the type specifiers may occur in any
>>> order, possibly
>>> intermixed with the other declaration specifiers.
>>
>> Notice that bit about "in any order". So long long int is the
>> same as long int long .
>
> And why is not long int, then long?
... but it is: All of `long', `long int', and `int long'
describe the same type.
> What about
>
> int int int m;
Doesn't match any of the combinations listed as legal,
and is thus illegal.
> And any kind of nonsense you can think about?
>
> long signed long int,
Legal.
> signed long int long,
Legal.
> signed long signed long,
Illegal; no listed combination has `signed' twice.
> signed int long signed long int
Illegal; no listed combination has `signed' twice or
`int' twice.
> long int long int
> long int int long
Both illegal; no listed combination has `int' twice.
> I just use the last one parsed.
As long as you issue a diagnostic for the unlicensed
combinations, you can do whatever you like with the faulty
source code. (Hmmm: How do you distinguish `long' from
`long long' on a "last one parsed" basis? Maybe that's
the crux of the issue ...)
I'll agree that the Standard's language in this section
is deficient in one respect: It speaks of the combinations
as "sets" when it really ought to say "multisets." In C89
"sets" was fine, but C99's introduction of `long long' brought
in the notion of the number of times an element is present,
and this is foreign to a plain set (it either contains the
element or it does not; there's no "how many" idea). 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.
Bartc
"jacob navia" <ja...@nospam.com> wrote in message
news:g2499u$5e2$1...@aioe.org...
> Walter Roberson wrote:
>> In article <g248q6$3u7$1...@aioe.org>, jacob navia <ja...@nospam.org>
>> wrote:
>>
>>> 6.7.2 Type specifiers
>>
>>> Each list of type specifiers shall be one of the following sets
>>> (delimited by commas, when there is
>>> more than one set on a line); the type specifiers may occur in any
>>> order, possibly
>>> intermixed with the other declaration specifiers.
>>
>> Notice that bit about "in any order". So long long int is the
>> same as long int long .
>
> And why is not long int, then long?
>
> What about
>
> int int int m;
>
> And any kind of nonsense you can think about?
>
> long signed long int,
> signed long int long,
> signed long signed long,
> signed int long signed long int
> long int long int
> long int int long
>
> ad nauseum?
>
> I just use the last one parsed.
It seems you are allowed to have any of the possibilities in the list, and
to vary the order of the terms.
You probably /can't/ make up your own combinations. You can't have two ints
for example.
I've had a look at what's involved to parse and check these type specifiers,
and came up with the following ungainly code which uses random logic to
check the combinations. It seems the C language is at fault for allowing
type specifiers to be so untidy.
In this code, I've only bothered with type specifiers involving 'int' and
'double', and ignored complex and typedefs.
/* play with checking C type specifiers; input is from array input[] */
#include <stdio.h>
#include <stdlib.h>
#define kshort 1
#define klong 2
#define ksigned 3
#define kunsigned 4
#define kint 5
#define kchar 6
#define kfloat 7
#define kdouble 8
#define kvoid 9
int counts[kvoid+1]={0}; /* how many of each of the above is present */
void badtype(char *m) {
printf("Illegal type combination: %s\n",m);
exit(0);
}
void check(int t,int a,int b){
if (counts[t]<a || counts[t]>b) badtype("Too few or too many");
}
void checkz(int a,int b,int c,int d) { /* 1 to 4 params; unused param is 0
*/
if (counts[a]) badtype("Not allowed");
if (counts[b]) badtype("Not allowed");
if (counts[c]) badtype("Not allowed");
if (counts[d]) badtype("Not allowed");
}
int main(void) {
//int input[]={kshort, kshort, kint, 0};
//int input[]={kint, kshort, kshort, kint, 0};
//int input[]={kint, kshort, klong, 0};
//int input[]={ksigned, kint, klong, klong, 0};
//int input[]={klong, kint, klong, 0};
int input[]={kunsigned, klong, klong, kint, 0};
//int input[]={kdouble, klong, 0};
int i,t;
/* Scan input (highly stylised form, this is not a compiler) and count each
kind of term */
i=0;
while (1) {
t=input[i++];
if (t==0) break;
++counts[t];
};
puts("Counts=");
for (i=kshort; i<=kvoid; ++i)
printf(" %d",counts[i]);
puts("");
/* Try and figure out, not the actual type, but whether this is legal or not
*/
if (counts[kint]) { /* Contains an int */
check(kint,1,1); /* One int only */
checkz(kchar,kfloat,kdouble,kvoid); /* No other types */
if (counts[kshort]) { /* Short (1 or 2), excludes long? */
check(kshort,1,2);
check(klong,0,0);
}
else if (counts[klong]) {
check(kshort,0,0);
check(klong,1,2);
}
if (counts[ksigned]) { /* Signed excludes unsigned */
check(ksigned,1,1);
check(kunsigned,0,0);
};
if (counts[kunsigned]) {
check(ksigned,0,0);
check(kunsigned,1,1);
};
}
else if (counts[kchar]) {
}
else if (counts[kvoid]) {
}
else if (counts[kfloat]) {
}
else if (counts[kdouble]) {
check(kdouble,1,1);
checkz(kchar,kfloat,kint,kvoid);
checkz(kshort,ksigned,kunsigned,0);
check(klong,0,1);
}
else if (counts[kshort]) {
}
else if (counts[klong]) {
}
else if (counts[ksigned]) {
}
else if (counts[kunsigned]) {
}
else { /* empty type or contains elements not considered here */
badtype("Unknown");
};
puts("The type seems to be legal:");
/* Try and display it in normalised form: */
if (counts[ksigned]) printf("signed ");
if (counts[kunsigned]) printf("unsigned ");
if (counts[klong]==1) printf("long ");
if (counts[klong]==2) printf("long long ");
if (counts[kshort]==1) printf("short ");
if (counts[kshort]==2) printf("short short ");
if (counts[kvoid]) printf("void ");
if (counts[kint]) printf("int ");
if (counts[kchar]) printf("char ");
if (counts[kfloat]) printf("float ");
if (counts[kdouble]) printf("double ");
puts("");
}
--
Bartc
Flash Gordon
<snip>
> Apparently my postings aren't getting through to your server. I know
> there was a UDP against rr.com. After aioe.org went away temporarily,
> I tried posting from rr.com again, and I was getting responses here,
> so I assumed the UDP had been lifted. Apparently it was only
> partially lifted.
Keith, if you want I can give you an account on my news server which
hooks up to enough free servers to keep me running. Email me and I'll
give you details.
--
Flash Gordon
The from email address is valid and I do read it.
Keith Thompson
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. jacob navia reports that he's seeing my posts to this
newsgroup, but didn't see anything from me in this thread. Nobody
else has complained (but then I wouldn't expect anyone to complain
about not seeing my messages). (Cue lame attempted sarcasm from the
trolls.)
The following are message-ids of articles I've posted to this thread,
all through rr.com:
<lniqwud...@nuthaus.mib.org>
<lnhccbb...@nuthaus.mib.org>
<ln8wxna...@nuthaus.mib.org>
<lnve0r8...@nuthaus.mib.org>
<lnod6i6...@nuthaus.mib.org>
I have two requests, which everyone is of course free to ignore.
1. Somebody please post a followup quoting this entire article.
2. Anyone who is so inclined, if your newsreader lets you access
articles by message-id, please see if the above listed articles are on
your server, and let me know *by e-mail* either way. I'm particularly
interested in hearing from jacob, since he's the one who didn't see
the messages when I posted them. (jacob posts through aioe.org, which
happens to be the server I'm considering switching back to if rr.com
is unsuitable.)
Thank you for your time.
Richard Heathfield
block. Please ignore.]
Keith Thompson said:
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
santosh
There you go.
I'll tackle 2 later, but I strongly suspect that I have read all your
articles since you switched to rr.com. I'm using the server at
motzarella.org. Maybe aioe.org still has their block on rr.com in
place. You should probably post to a group under the news.admin
hierarchy, where you might get a direct response from the people who
control aioe.org and other servers.
Keith Thompson
> articles since you switched to rr.com. I'm using the server at
> motzarella.org. Maybe aioe.org still has their block on rr.com in
> place. You should probably post to a group under the news.admin
> hierarchy, where you might get a direct response from the people who
> control aioe.org and other servers.
I just checked aioe.org. They have 2483 articles in comp.lang.c, of
which only 2 are from me, both dated May 11, which seems to be as far
back as they go.
Ron Ford
I remember a time when Keith and the MI5 persecution dude were the only
persons whom I could not find on the net.
Then, using the same techniques, I couldn't find myself. A bit of an
existential crisis.
I assumed he had a poor NSP.
--
Ron Ford
Richard Harter
<ks...@mib.org> wrote:
I've seen lots of articles by you including the below.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
Keith Thompson
> On Tue, 03 Jun 2008 16:23:07 -0700, Keith Thompson
> <ks...@mib.org> wrote:
>
> I've seen lots of articles by you including the below.
Thank you.
Again, please reply *by e-mail*; there's no need for everyone to have
to read the responses.
(I don't have much information, but so far my hunch is that it's an
issue between rr.com and aioe.org.)
Richard Bos
> ad nauseum?
Quand on ne parle pas latin, moet men ook niet doen alsof.
Richard
CBFalconer
English is not queasy about adopting words and phrases from other
languages. Ad nauseum so qualifies.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Antoninus Twink
> Richard Bos wrote:
>> jacob navia <ja...@nospam.com> wrote:
>>> ad nauseum?
>>
>> Quand on ne parle pas latin, moet men ook niet doen alsof.
>
> English is not queasy about adopting words and phrases from other
> languages. Ad nauseum so qualifies.
Glad to see it's not just C programming questions where CBF always gets
the wrong end of the stick and ends up embarrassing himself.
The point of the joke is that Jacob (and then CBF) mis-spelt nauseam -
it's actually a first declension noun.
Richard Heathfield
> Richard Bos wrote:
>> jacob navia <ja...@nospam.com> wrote:
>>
>>> ad nauseum?
>>
>> Quand on ne parle pas latin, moet men ook niet doen alsof.
>
> English is not queasy about adopting words and phrases from other
> languages. Ad nauseum so qualifies.
From which language do you think "ad nauseum" stems? Hint: it certainly
isn't Latin.
Antoninus Twink
> 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've seen plenty of posts by you over the past few weeks. Maybe the UDP
is still being observed by a few news servers, including aioe. You could
try asking on one of the aioe.* groups - maybe aioe.news.helpdesk or
aioe.news.assistenza.
Richard Bos
> Richard Bos wrote:
> > jacob navia <ja...@nospam.com> wrote:
> >
> >> ad nauseum?
> >
> > Quand on ne parle pas latin, moet men ook niet doen alsof.
>
> English is not queasy about adopting words and phrases from other
> languages. Ad nauseum so qualifies.
I know the English have a habit of perverting any phrases they steal
from other languages, but I was not yet aware that they'd done this with
ad nauseam.
Richard
Richard Heathfield
Chuck isn't English.
jacob navia
>>> Notice that bit about "in any order". So long long int is the
>>> same as long int long .
>>
>> And why is not long int, then long?
>
> "long int" *is* "long", just as "unsigned char" and "char unsigned" are
> the same.
>
Following your logic we should accept
signed long int double | int long signed double
as equivalent to
long double
since "signed long int" or "int long signed" *is* a long
Eric Sosman
> Flash Gordon wrote:
>>>> Notice that bit about "in any order". So long long int is the
>>>> same as long int long .
>>>
>>> And why is not long int, then long?
>>
>> "long int" *is* "long", just as "unsigned char" and "char unsigned"
>> are the same.
>>
>
>
> Following your logic we should accept
>
> signed long int double | int long signed double
>
> as equivalent to
>
> long double
>
> since "signed long int" or "int long signed" *is* a long
The conclusion does not follow from the premise.
`while' has multiple meanings in C, depending on context.
`static' has multiple meanings in C, depending on context.
`long' has multiple meanings in C, depending on context. The
contexts `long double' and `long int' and `long long' and
`long complex register unsigned volatile double extern' are
different contexts, three valid and one invalid.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Keith Thompson
> 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. jacob navia reports that he's seeing my posts to this
> newsgroup, but didn't see anything from me in this thread.
It turns out that aioe.org had placed a ban on rr.com. I posted to
aioe.news.helpdesk, and the ban has now been lifted.
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
> CBFalconer <cbfal...@yahoo.com> wrote:
>
>> Richard Bos wrote:
>>> jacob navia <ja...@nospam.com> wrote:
>>>
>>>> ad nauseum?
>>> Quand on ne parle pas latin, moet men ook niet doen alsof.
>> English is not queasy about adopting words and phrases from other
>> languages. Ad nauseum so qualifies.
>
> 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
Yes, I am English.
Flash Gordon
> Flash Gordon wrote:
Please don't snip attributions for material that is still quoted.
>>>> Notice that bit about "in any order". So long long int is the
>>>> same as long int long .
>>>
>>> And why is not long int, then long?
>>
>> "long int" *is* "long", just as "unsigned char" and "char unsigned"
>> are the same.
>
> 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?
--
Flash Gordon
CBFalconer
> Richard Bos said:
>
... snip ...
>
>> I know the English have a habit of perverting any phrases they
>> steal from other languages, but I was not yet aware that they'd
>> done this with ad nauseam.
>
> Chuck isn't English.
However somewhere there is, or was, a passport for me (of some age)
which says something like: "is a Canadian citizen and a British
subject". There was a time when I had unfettered access to about
one fifth of the world.
Richard
> Richard Bos wrote:
>> jacob navia <ja...@nospam.com> wrote:
>>
>>> ad nauseum?
>>
>> Quand on ne parle pas latin, moet men ook niet doen alsof.
>
> 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.
lawrenc...@siemens.com
>
> 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
Kenny McCormack
So? What's your point? CBF has never been one to be bound by his own
rules.
Eric Sosman
> Eric Sosman <Eric....@sun.com> wrote:
>> 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.)
Not surprising[*], and perhaps there are compilers that
implement `long long long', too. Nonetheless, these are
"illegitimate" in the sense that the compiler is required
to emit a diagnostic for any use, no matter what it then
decides to do with the declaration.
[*] Although one wonders why `long double' wasn't used
instead.
--
Eric Sosman
eso...@ieee-dot-org.invalid
lawrenc...@siemens.com
>
> [*] 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
> Eric Sosman <eso...@ieee-dot-org.invalid> wrote [re double double]:
>>
>> [*] 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
Keith Thompson <ks...@mib.org> wrote:
>How is a pair of doubles used to represent a single floating-point
>number anyway?
One particular implementation:
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.
--
"The shallow murmur, but the deep are dumb." -- Sir Walter Raleigh
lawrenc...@siemens.com
>
> 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
[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
--
John J. Smith
Compiler Tester
Flash Gordon
> 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".
--
Flash Gordon