Hey Przemek,
* harbour/include/hbdefs.h
+ added #include <limits.h>
It should hide some warnings related to redefined integer size
constants
Viktor if it will not help for BCC58 warnings then you will
have to add
#include <stdint.h>
few lines below but please remember that older BCC version does
not
have it so check for the exact compiler version.
As per Andi's and your suggestion, I've included <stdint.h> #if
__BORLANDC_ > 1410,
then the redefinition warnings indeed go, but these new ones appear:
Warning W8041 source\compiler\hbmain.c 3410: Negating unsigned value
in function hb_compGenPushLong
Warning W8041 source\compiler\hbmain.c 3427: Negating unsigned value
in function hb_compGenPushLong
Warning W8041 source\vm\macro.c 1199: Negating unsigned value in
function hb_macroGenPushLong
Warning W8041 source\rtl\itemseri.c 281: Negating unsigned value in
function hb_itemSerialSize
Warning W8041 source\rtl\itemseri.c 421: Negating unsigned value in
function hb_serializeItem
Warning W8056 source\rdd\dbf1.c 2379: Integer arithmetic overflow in
function hb_dbfPutValue
Warning W8041 source\rdd\dbf1.c 2386: Negating unsigned value in
function hb_dbfPutValue
Warning W8056 source\rdd\dbf1.c 2398: Integer arithmetic overflow in
function hb_dbfPutValue
Warning W8041 source\rdd\dbf1.c 2405: Negating unsigned value in
function hb_dbfPutValue
Warning W8041 source\rdd\dbf1.c 2422: Negating unsigned value in
function hb_dbfPutValue
Warning W8041 source\rdd\dbf1.c 2466: Negating unsigned value in
function hb_dbfPutValue
Warning W8041 source\rdd\dbf1.c 2467: Negating unsigned value in
function hb_dbfPutValue
Warning W8041 source\rdd\dbffpt\dbffpt1.c 1254: Negating unsigned
value in function hb_fptCountSMTItemLength
Warning W8041 source\rdd\dbffpt\dbffpt1.c 1379: Negating unsigned
value in function hb_fptStoreSMTItem
Warning W8041 source\rdd\dbffpt\dbffpt1.c 1704: Negating unsigned
value in function hb_fptStoreSixItem
Warning W8041 source\rdd\dbffpt\dbffpt1.c 1905: Negating unsigned
value in function hb_fptCountFlexItemLength
Warning W8041 source\rdd\dbffpt\dbffpt1.c 1981: Negating unsigned
value in function hb_fptStoreFlexItem
Warning W8041 source\rdd\dbffpt\dbffpt1.c 3019: Negating unsigned
value in function hb_fptPutMemo
Warning W8041 source\rdd\dbffpt\dbffpt1.c 3512: Negating unsigned
value in function hb_fptPutVarField
Warning W8041 source\rdd\dbffpt\dbffpt1.c 3513: Negating unsigned
value in function hb_fptPutVarField
Warning W8041 source\rdd\dbffpt\dbffpt1.c 3570: Negating unsigned
value in function hb_fptPutVarField
! changed macros which setting default numeric item size for more
strict
Clipper compatible mode. I'm not a fun of some Clipper behavior
in
calculating number size and I left some notes about it in
hbdefs.h
Anyhow this and some other modifications below should cover the
differences you've found recently. Some things are not
addressed by
me intentionally, f.e. _itemPutNL() in Clipper always set size
to 10
without checking the maximum size so it's too small for values
less
then -999999999. Harbour compiler makes more compile time
optimizations
then Clipper. The formatting rules used by compiler are a
little bit
different then by VM so this can be source of some other
differences
to Clipper. I can easy create some examples. Harbour supports
64bit
signed integers and Clipper doesn't. This is yet another
situation
when we may have different results then Clipper. Most of them can
be hidden if we add new PCODE(s) for integer number with explicit
size but I do not think it's such important to increase PCODE
list.
In few cases it will be necessary to disable some optimizations
at
all and I do not like it. In the future when I will be adding
some
new optimizations I also add compiler switch to disable/enable
optimizations which can have such side effects for people who
need
strict formatting.
I would also vote for strict mode unless it has any undesired
side effects with regards to future expandability or development
possibilities.
I trust your judgment on these issues, and also many thanks for
the fixes.
[ Demagog story warning: This small difference caused my app to
actually not start at all, showing an invalid license. Once finding
the problem it was easy to fix with a few LTrim()s, but even
such a subtle detail can have this big effect. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
