I had a bit of a eureka moment about 03:00 this morning, which leads me to be less adamant about using only bitwise operators to reset bits.

The problem is that scripting languages like KiXtart are "loosely typed". In particular, KiXtart uses sub-types of variant for all it's basic data types.

This is especially an issue when using constructs like the bitwise NOT "~". A bitwise NOT reverses the truth of each bit in the parameter. However, the size of the result is determined by the parameter.

The results of ~0 could be 255, 65535, 4294967295 or 18446744073709551615 depending on whether the "0" is interpreted as (using Windows terminology) an 8 bit byte, a 16 bit word a 32 bit dword or a 64 bit qword.

In KiXtart it is currently simple and everything will be treated as a dword. If you need a byte or word result you have to explicitly cap it, for example "&FF & ~0" for a byte and "&FFFF & ~0" for a word.

In other loosely typed languages small values might be interpreted as a byte or a word which could lead to truncation.

For example, if you wanted to reset flag #5 (value 32) you might do:
Code:
$iFlags=3112
$iFlags & ~32 ?


In KiXtart this will work, and $iFlags will be set to 3080.

But what if you are using a loosely typed language which interprets the 32 as being a byte? You can simulate this in KiXtart:
Code:
$iFlags=3112
$iFlags & ( ~32 & &FF) ?


The result is 8, which is clearly wrong.

The same problem will occur when small numbers are interpreted as being 16 bit integers.

If you know the size of the data that you are attempting to reset the bit in you can explicitly convert the value to the correct type using casts or functions, for example "$iFlags & ~CDbl(32)"

Using a conditional test and subtraction (or XOR) to reset the bit is data size independant and might be preferable where the size of the data cannot be pre-determined or guaranteed.