I recently stumbled across this problem with Borland C (Affects all
borland 16bit C compilers, TC, BCPP).
The problem of a 2byte size_t....
farcalloc was the solution to allocate a 256k buffer in my case.
But a part of your text gives me a question....
On 07/29/2018 05:17 AM, TK Chia wrote:
Actually, I just found that both malloc( ) and calloc( ) do not work
for the purpose, and we _do_ need to use something like halloc( ).
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.
HOW does a 16bit truncate limit to 16384bytes?
b1 b0 (byte 1, byte 0)
b2 | | (byte 2)
| | |
decimal 81920 = hex 014000
decimal 65536 = hex FFFF size of size_t = 2 bytes
16k is far less than 64k, why does it truncate to 16k? why not 64k if
greater than 64k?
Maybe you can instruct your compiler to warn about integer overflows. I
changed my codestyle on 16bit-int-platforms to use for example 0x1FFFFul
(for unsigned long). If I have
a value greater than 0xFFFF and not have added "ul", compiler warns and
I get what happens. This helped me a lot...
Or did I get something wrong?
(I assume we are rediscovering well-known programming techniques from
the 80s here...)
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
