If you're expecting long, shouldn't you be using %ld in printf() instead of %d?
You could also try adding cast in there, to prevent any unwanted type conversion taking place.

Yes, that was throwing me off the scent... the problem turns out to the caller of gfx_GetXYaddr(), it was doing:

1int status;
2status = gfx_GetXYaddr(100, 220);  // As an example

I had a check in there to always make sure the function hadn't returned <0 (as in the case of a coordinate outside the vram buffer)... and you can immediately see that the storage class of the returned value is smaller than that needed to contain the number of bytes offset into the buffer. Thus unless the coords where in the top left, the value was nearly always overflowing, wrapping around to negative and (correctly!) causing my error handling code to have a fit and say "whoah! You can't plot a bitmap/font/line outside the visible video buffer area!".

I guess I need to make a further in-depth check of this code to make sure I've got the right storage sizes - it was all lifted from the previous implementation, but on DJGPP and GCC for the Sharp and NEC int is always 32bits....

There's some definite weirdness with integer type conversions and casts with Open Watcom that I've never come across before.

Take the following example (where all the window_* variables have been previously declared as long int; -2147483648 to 2147483648). This is a small section of my code where I'm calculating the size of a screen fragment that can fit in each of the 64K memory windows of the current screen mode (640x400 for now, but left as a dynamic calculation in case I use different resolutions in the future):

1window_segment = vesamodeinfo->WinASegment;
2window_bytes = vesamodeinfo->WinSize * 1024;
3window_x_max = (window_bytes - 1) % GFX_COLS;
4window_y_max = (window_bytes - 1) / GFX_COLS;
5windows_in_use = (GFX_COLS * GFX_ROWS) * (GFX_BPP / 8);
6
7printf("%s.%d\t VESA memory window segment address: %xh\n", __FILE__, __LINE__, window_segment);
8printf("%s.%d\t VESA memory window size: %ld bytes (at %d bytes/pixel)\n", __FILE__, __LINE__, window_bytes, GFX_PIXEL_SIZE);
9printf("%s.%d\t VESA memory window columns: %ld\n", __FILE__, __LINE__, window_x_max);
10printf("%s.%d\t VESA memory window rows: %ld\n", __FILE__, __LINE__, window_y_max);
11printf("%s.%d\t VESA memory windows needed: %ld\n", __FILE__, __LINE__, windows_in_use);

That produces the following output:

src/gfx.c.124 VESA memory window segment address: a000h
src/gfx.c.125 VESA memory window size: 0 bytes (at 1 bytes/pixel)
src/gfx.c.126 VESA memory window columns: -1
src/gfx.c.127 VESA memory window rows: 0
src/gfx.c.128 VESA memory windows needed: -6144

That just looks crazy to me.

If I add an explicit type cast to long int in the window_bytes calculation as follows:

1window_bytes = (long int) vesamodeinfo->WinSize * 1024;

Then I instead get the following output:

src/gfx.c.124 VESA memory window segment address: a000h
src/gfx.c.125 VESA memory window size: 65536 bytes (at 1 bytes/pixel)
src/gfx.c.126 VESA memory window columns: 255
src/gfx.c.127 VESA memory window rows: 102
src/gfx.c.128 VESA memory windows needed: -6144

I've not used a C compiler before where the individual operands of an arithmetic operation needed explicitly casting to the larger type of the destination variable. That just seems wacky to me.

It's almost as if at runtime the storage size of the window_* variables is being redefined as short int, which is the type of vesamodeinfo->WinSize. This seems a different behaviour than what I've come to expect on something ubiquitous like gcc. e.g. I wouldn't expect gcc to truncate the value of an int if I was calculating the product of two shorts. I'd expect overflow if I was storing it in another short, but not an int.

Yeah, this is utterly crazy:

1#DEFINE GFX_COLS 640
2#DEFINE GFX_ROWS 400
3long int windows_in_use;
4
5windows_in_use = (GFX_COLS * GFX_ROWS);

That gives a result of -6144, because it has overflowed.

Explicitly cast both of those defined values:

1windows_in_use = ((long int) GFX_COLS * (long int) GFX_ROWS);

That gives the correct result of 256000.

Can anyone tell me why I have to explicitly cast those two defined values?

C performs implicit promotion to int, that's why you can usually do things like adding two shorts and assign the result to int without caring about overflow. But your (16-bit) ints aren't big enough so you need explicit promotion.

(Literal values are typically interpreted as ints unless postfixed with l,ll,etc.)

Ok, so I'll need to be careful wherever I've used these (or other) literal values throughout the code - thank you so much for the clarification.

Most of my C knowledge comes from a unix background (started back in the 90's on Sun OS, then IRIX, various BSD's and Linux), so the vagaries of some of the restrictions on machines with a 16bit word size are new to me.

megatron-uk wrote on 2021-01-31, 11:19:

Most of my C knowledge comes from a unix background (started back in the 90's on Sun OS, then IRIX, various BSD's and Linux), so the vagaries of some of the restrictions on machines with a 16bit word size are new to me.

It's exactly the same rules you have on 32 bit systems if you want to do 64-bit arithmetic.

1     long long int foo = 65536*65536;
2     long long int foo2 = 65536LL * 65536;

foo will have the value zero on any typical 32-bit unix system (because the calculation is done using 32-bit arithmetic and overflows), even if it supports 64-bit long or long long variables. foo2 will have the expected value.

Or the same rules you get with integers and floating point:

1    float two = 5 / 2;
2    float two_and_a_half = 5.0 / 2;

The first calculation is done using integers, the second one with floating point arithmethics. You just need to get used to those rules already kicking in if you exceed 16 bits, not only if you exceed 32 bits.

megatron-uk wrote on 2021-01-31, 10:58:

Yeah, this is utterly crazy: […]
Show full quote

Yeah, this is utterly crazy:

Copy code to clipboard

1#DEFINE GFX_COLS 640
2#DEFINE GFX_ROWS 400
3long int windows_in_use;
4
5windows_in_use = (GFX_COLS * GFX_ROWS);

That gives a result of -6144, because it has overflowed.

In my understanding (but I may be wrong) both 640 and 400 are of type `int`. The result of int * int is also int.
However, because your ints are only 16-bit, you get overflow. Signed overflow in C is undefined behavior, so the exact value is irrelevant.

Define your constants as long, and you'll get correct result.

#define GFX_COLS 640L
#define GFX_ROWS 400L

so openwatcom has several things going on here.

one you should use inttypes.h for printing so like printf("%"PRIu32"\n", var); (PRIu32, PRIu16, etc). check out inttypes.
two, never use int/long/short. use stdint.h and use portable types in16_t, uint16_t, int32_t, uint32_t etc.

if your using real mode, even with with 386 cpu (-3/-4/-5 etc), its promoting to 16bit, not 32bit unless your explicit in one of the source types

1#include <stdio.h>
2#include <inttypes.h>
3#include <stdint.h>
4
5void main(void)
6{
7	uint32_t a;
8
9	// causes OW to do 16bit * 16bit, fixing result as 16bit.
10	a = 0xF000 + 0xF000;
11	printf("%"PRIu32"\n", a);
12
13	// causes OW to do proper promotion because it does not
14	// take lvalue type into consideration when calcuating result.
15	a = (uint32_t)0xF000 + 0xF000;
16	printf("%"PRIu32"\n", a);
17}
18
19wcl -3 test.c && test.exe
2057344
21122880
22
23wcl386 -3 test.c && test.exe
24122880
25122880