You may be right.

DIM i(20) AS INTEGER
PRINT LEN(i)

The output is 4. I might have found a bug in QB as a result of that little bit of code too. After all, the size of an INTEGER is 2, not 4. In the above code, 'i' is treated as a SINGLE. Putting a DEFDBL A-Z at the very top confirms this by outputting 8. It happens in QB 4.5 and PDS (7.1)

Note that PRINT LEN(i(1)) does correctly return 2.

Anyway, sizeof wouldn't be ideal for arrays. I believe 64-bit platforms would evaluate sizeof(int*) to 8. On 32-bit platforms, sizeof(int*) would evaluate to 4. With static arrays, it might be sizeof(int[2]), which refers to an integer array with 2 elements. This would result in 8 on both 32-bit and 64-bit platforms (short=2, int=4, long=8 on 64-bit, short=2, int=long=4 on 32-bit) because of the fact that a single int is 4 bytes, so two ints would be 8 bytes. Well... That's with gcc anyway...

As a result, I would recommend using other methods to implement this aspect of LEN. For example, run-time type information would be a good idea. If singvar is of type SINGLE, LEN(singvar) would return 4. Likewise if illvar is an _INTEGER64, LEN(illvar) would return 8.

As for the quirkiness with arrays, I'm unsure of whether to change the behavior or not. If it is changed, should it match the behavior of C/C++, or should it actually return the length of the array, which could be found using (UBOUND(arr) - LBOUND(arr) + 1)?

Poll, anybody?

------------------
Waiting patiently for Windows 7, XHTML 2.0, CSS 3.0, PHP 6.0, the ratification of C++0x, and the day that I can code without logic troubles.