> On Sun, 29 Jul 2018 11:17:08 +0800, TK Chia wrote:
>> I double-checked the compiler output (using `wdis test.o') for the
>> malloc( ) call under the huge model, and found that it actually clips
>> the size to a `size_t', and `size_t' is a 16-bit integer type even for
>> the huge model. I.e. malloc(81920) only allocates 16384 bytes.
> Indeed! OpenWatcom's malloc() prototype accepts a size_t argument, even
> in the huge model, and sizeof(size_t) tells that it's a 16-bit value.
> This is extremely deceiving. I would at least expect the compiler to warn
> about argument truncation because of incompatible data type being passed.
while he didn't specify a warning level, WCL doesn't even warn with
-W=9 :-< (watcom 1.9)
> In such case the halloc() & hfree() pair does seem to be the only way.
> Although for handling amounts of data > 64K one should definitely think
> about relying on XMS,
how would you implement this code
buf[80000l] = '!';
buf[80001l] = 0;
printf("success%s\n", buf + 80000l);
using XMS?
> or going the (so much easier) protected mode way.
he explicitly wants 16-bit code, even 8086 compatible. no XMS, no
protected mode available.
however
buf[80000l] = '!';
translates to
mov bx,0x3880
mov cx,0x0001
call __PIA
mov word ptr -0x2[bp],ax
mov ds,dx
mov bx,ax
mov byte ptr [bx],0x21
mov ax,di
mov dx,si
mov bx,0x3881
mov cx,0x0001
call __PIA
mov bx,ax
mov es,dx
mov byte ptr es:[bx],0x00
not sure how much time it would take a 8086 to paint the screen
using such code bloat ;)
compare this to small model:
buf[80000l] = '!';
buf[80001l] = 0;
compiles (in small model) to
mov word ptr 0x3880[bx],0x0021
note: huge model is hugely EXPENSIVE!
Tom
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
