[SOLVED] Constant definition out of range problem

[440bx]

I want the code to compile in both 32 and 64 bit, ideally without any warnings.

the xor is perfect because it does not cause arithmetic promotion.  Good thinking and thank you again Nitorami.   I'm going to be using that xor operation instead of a not.

[creaothceann]

Why 32-bit?

[jamie]

Code: Pascal  [Select][+][-]

1. Const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS    = DWord(not $80000007 and $ffffffff);      
3.  

How about that?

Jamie

[440bx]

Code: Pascal  [Select][+][-]

1. Const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS    = DWord(not $80000007 and $ffffffff);      
3.  

How about that?

Jamie

Try it in both 32 and 64 bits and you'll answer your own question.


ETA:

Why 32-bit?

because IMO simple code like a constant declaration should "perform" equally well regardless of bitness. 

Whenever possible I compile for both bitnesses, occasionally this reveals subtle potential problems.

[MathMan]

I propose

Code: Pascal  [Select][+][-]

1. const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS = DWord( not DWord( $80000007 ) );
3.  

Rational:
- the high bit is set in $80000007 <= requires a cast to avoid the warning in 32 bit environment
- not will again promote to 64 bit in 64 bit environment <= needs another cast to bring down to 32 bit

Caveats:
- it is still not a real 32 bit constant <= can only be achieved by typing the constant itself
- at the position in source it is used the compiler may choose to again promote to larger ordinal type

Cheers,
MathMan

[440bx]

@MathMan,

That still causes the compiler to emit a warning when compiling for 32 bit. 

The only thing that works so far is Nitorami's xor method.

[nanobit]

Code: Pascal  [Select][+][-]

1. c = (not uint64($80000007)) and $FFFFFFFF;

[440bx]

Code: Pascal  [Select][+][-]

1. c = (not uint64($80000007)) and $FFFFFFFF;

That works too.  Nice... good example of "if you can't beat them, join them" by explicitly typecasting to int64

I still prefer Nitorami's solution, it's more compact.

[MathMan]

Code: Pascal  [Select][+][-]

1. c = (not uint64($80000007)) and $FFFFFFFF;

That works too.  Nice... good example of "if you can't beat them, join them" by explicitly typecasting to int64

I still prefer Nitorami's solution, it's more compact.

Hm, I obviously was wrong the first time. But now, as you bring compactness into play, why not

Code: Pascal  [Select][+][-]

1. const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS = $7ffffff8; // <=> not $80000007
3.  

I mean, if you accept Nitorami's solution you can as well directly resolve as above ...

[440bx]

Code: Pascal  [Select][+][-]

1. const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS = $7ffffff8; // <=> not $80000007
3.  

I mean, if you accept Nitorami's solution you can as well directly resolve as above ...

Just as general information...

That definition comes from one of the .c header files (winnt.h) and after unsuccessfully trying a number of ways using typecasts to get rid of the compiler warning, I figured I'd use the result of "not" just as you suggested above.

The problem I have with that one is that it is not "parallel" to the original definition and it is not visually obvious that not $80000007 is $7ffffff8 and a visual comparison of the original has 0x80000007 while the ported definition has a number that is visually totally different ($7ffffff8).  That bothered me.

Nitorami's solution is my preferred one because when visually comparing (~0x80000007) with $80000007 xor $FFFFFFFF  there are two ops, a "not" in one and an "xor" in the other, that makes the operator count "parallel" (the same) and, it should be reasonably easy for a programmer to quickly figure out that the "xor $FFFFFFFF" is equivalent to the "not" in this case and the original value is there to be visually matched.

For that reason, I prefer Nitorami's solution over simply using the result of the "not" operation.

[creaothceann]

If you want it to be "visually obvious" you shouldn't use hexadecimal to begin with. Flags are usually binary:

Code: Pascal  [Select][+][-]

1. const
2.         DIAGNOSTIC_REASON_INVALID_FLAGS = NOT (Bit31 + 7);        // 7FFF FFF8
3.         DIAGNOSTIC_REASON_INVALID_FLAGS = NOT (Bit31 + Bits3);    // alternative
4.  

(bit contants & types defined here)

[440bx]

If you want it to be "visually obvious" you shouldn't use hexadecimal to begin with.

That's fine with me.   Tell that to the MS programmers. 

When I port definitions from the C headers, I try to make the Pascal definition as "parallel" as reasonably possible to the C definition.

The original C definition is:

Code: C  [Select][+][-]

1. #define DIAGNOSTIC_REASON_INVALID_FLAGS  (~0x80000007)
2.  

My Pascal definition (using Nitorami's xor):

Code: Pascal  [Select][+][-]

1. const
2.   DIAGNOSTIC_REASON_INVALID_FLAGS        = $80000007 xor $FFFFFFFF;
3.  

It's fairly parallel.

[nanobit]

Another alternative (if literal has negative value) is:

Code: Pascal  [Select][+][-]

1. c = not int32($80000007);

[440bx]

Another alternative (if literal has negative value) is:

Code: Pascal  [Select][+][-]

1. c = not int32($80000007);

Yes, a very good alternative indeed.  It's very parallel to the original C declaration. 

Definitely worth considering.  Thank you!.