Re: spurious C warnings..
Digby Tarvin wrote:
Thanks - that would appear to be exactly the link I needed...
The ULL suffix does indeed seem to have the desired effect, however I
was under the impression that
((long)0xFFFFFFFF)
was supposed to be a more syntactically consistent and equivalent form of
(0xFFFFFFFFL)
They mean different things, especially with sixteen bit compilers.
in which case ((long long)0xFFFFFFFFFFFFFFFF), which I tried,
should have worked...
It would have, if (long long)0xFFFFFFFFFFFFFFFF and
0xFFFFFFFFFFFFFFFFLL meant the same thing, but they do not.
This suggests the former just promotes the default type, and a
suffix is the only way to really control the type of a literal.
You have struck the nail upon the head with perfect orthogonality.
Well, almost. It first tries for int, then for unsigned int.
Part of the reason for this is historical, and another part
is for consistency with other type qualifiers, especially floats.
For example, consider the differences between
float
double
long double
There is a vast difference between a double 0.1 promoted
to a long double, and a long double 0.1, so the syntax needs to
be fleximble enough to express those constants in the appropriate
type.
(long double)0.1
and
0.1L
have DIFFERENT VALUES on my system.
$ cat d.c
#include <stdlib.h>
#include <stdio.h>
int main(void) {
printf("Difference = %Lg\n",(long double)0.1 - 0.1L);
return EXIT_SUCCESS;
}
$ gcc -o d d.c
$ ./d
Difference = 5.54976e-18
It also seems inconsitent that no warning is generated for
long l = 0xffffffff;
given that the literal should be defaulting to int, which on
some architectures is 16 bits so the construct is just as
questionable from a portability standpoint..
You need to read the Standard about the Integral Promotions.
Also, no diagnostic is required. This is possibly, as you
suggest, inconsistent. But I find that the 32 bit int guys
usually look upon 16 bit compilers and machines with disdain.
Anyway, thanks for the pointer (no pun intended...)..
Ten guys were trying to win a woman's favor, each by using a
play on words. No pun in ten did.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply to: