On Fri, 24 Apr 2009, Ranier Vilela wrote:
> cl.exe -nologo -I. -I../../../../include -Gs -TP -W4 -wd4127 -Wall -O2xtyb1
> -Gy -GS- -GR- -EHs- -DNDEBUG -DHB_FM_STATISTICS_OFF -MT -c
> ../../hvmall.c -Fohvmall.obj
> hvmall.c
> e:\harbour\harbour-1.1.0\source\vm\hvm.c(1764) : warning C4365: '=' :
> conversion from 'int' to 'USHORT', signed/unsigned mismatch
> hvm.c:
> line 1764: pItem->item.asRecover.flags = HB_SEQ_DOALWAYS | (
> bCanRecover ? HB_SEQ_CANRECOVER : 0 );
> line 1855: pItem->item.asRecover.flags = bCanRecover ?
> HB_SEQ_CANRECOVER : 0;
> I not a "bits operations" guru, but, doing bit operation in INT and store
> in SHORT maybe UNSAFE?
The above warning message is the side effect of C compiler logic
limitation. In this line:
pItem->item.asRecover.flags = HB_SEQ_DOALWAYS |
( bCanRecover ? HB_SEQ_CANRECOVER : 0 );
only constant values are used and they never cannot exceed USHORT.
But internally the result of ( USHORT | USHORT ) is converted to int
and then warning message is generated. In fact here we have two things
which should be improved fixed in MSVC.
1. detect that the value is result of bit operation on some smaller values
which cannot exceed the size of result
2. add some pseudo constant detection with list of possible values which can
be used in optimization. In this case compiler can detect that the result
can be HB_SEQ_DOALWAYS or ( HB_SEQ_DOALWAYS | HB_SEQ_CANRECOVER )
and both values can be perfectly sored in USHORT.
Implementing any of the above in C compiler should fix this false warning
message. Now we can only add some unnecessary decoration (explicit casting)
to pacify this warning. I only want to notice that if you increase the
warning messages over some resonable limit in such compilers then we begin
to introduce casting which will hide the real bugs, f.e.:
pItem->item.asRecover.flags = ( USHORT ) ( HB_SEQ_DOALWAYS |
( bCanRecover ? HB_SEQ_CANRECOVER : 0 ) );
will pacify warnings even if someone by mistake change HB_SEQ_DOALWAYS or
HB_SEQ_CANRECOVER to value larger then USHRT_MAX. It means that we will
have less readable code and less safe. Please remember about it and use
some reasonable warning limits in compilers which produce too much of false
alarms. Otherwise we begin to strongly reduce code quality. F.e. even now
I think that a lot of casting we added to pacify bit losing conversion
warning messages will badly hide possible errors when we begin to convert
basic types. Explicit casting of all expressions simply can hide important
bugs.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
