First post, by megatron-uk
I'm using Openwatcom to write some code for real-mode DOS, so it's a 16bit target, using the 'large' memory model (the -ml flag to the Watcom compiler).
I have an integer, addr, defined as:
long int addr;
According to page 20 of the Openwatcom C Language Reference manual, that corresponds to -2147483648 to 2147483648. That does not look to be ambiguous in any way.
However I do
addr = (256 * 256);
printf("%d\n", addr);
... and the value returned is 0. This appears as if addr is instead being defined as a unsigned int (in the 16bit Openwatcom variant), or as unsigned short int.
This is part of a larger function which takes an x/y screen coordinate and turns it in to the starting offset into the off-screen video buffer. The full function is:
int gfx_GetXYaddr(unsigned short int x, unsigned short int y){
// Turn a screen x/y coordinate into an offset into a vram buffer
long int addr;
addr = VRAM_START;
addr += (GFX_ROW_SIZE * y);
addr += (x * GFX_PIXEL_SIZE);
if ((VRAM_START + addr) > VRAM_END){
if (GFX_VERBOSE){
printf("%s.%d\t XY coords beyond VRAM buffer end address\n", __FILE__, __LINE__);
}
return -1;
}
return addr;
}
In the current implementation, VRAM_START is always 0, GFX_ROW_SIZE is defined as 640, and GFX_PIXEL_SIZE is 1. Unless my coordinates are in the upper left of the screen, all my calculations are coming out overflowing the unsigned int, or unsigned short int type (which I'm not using, as you can see above).
What I can't understand is why the long int addr is overflowing, when it should be well within its storage bounds.
The version of Openwatcom in use is:
Open Watcom C x86 16-bit Optimizing Compiler
Version 2.0 beta Jan 13 2021 00:25:21 (64-bit)
Copyright (c) 2002-2021 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
My collection database and technical wiki:
https://www.target-earth.net