nox@jelal.north.de (Juergen Lock) (06/03/91)
From article <2330@do.maus.de>, by Martin_Koehling@do.maus.de (Martin Koehling): > > Juergen Lock nox @ jelal.north.de: > <a5434559@jelal.north.de> >>[description of zoo/TC array index bug deleted] > The bug was fixed in Turbo C version 2.00. hmm, sure? i know someone who i'm sure has some version >= 2.00 and he had to do this same [(long) foo] thing to get `compress' running. i know that 'cause i was it who told him the `trick'... :-) > It wasn't really a bug but a "design restriction" - it made programs both > smaller and faster (it's even mentioned somewhere in the manual!). not in my manual (TC 1.1 that is). and besides, what does ANSI say about this? > The new compiler uses only 16 bits for array addressing if and only if it is > sure that the array addressed is smaller than 32 KBytes. ummm... how can it be sure when i, for example calloc()ed the thing? confused, :-) Juergen -- J"urgen Lock / ..!nicedel!lynx1!jelal!nox / ** !! dead{hanseat!jelal} !! ** ...ohne Gewehr
Martin_Koehling@do.maus.de (Martin Koehling) (06/06/91)
Juergen Lock nox @ jelal.north.de wrote:
<a1465268@jelal.north.de>
JL>From article <2330@do.maus.de>, by Martin_Koehling@do.maus.de (Martin
JL>Koehling):
JL>>
JL>> Juergen Lock nox @ jelal.north.de:
JL>> <a5434559@jelal.north.de>
JL>>>[description of zoo/TC array index bug deleted]
JL>> The bug was fixed in Turbo C version 2.00.
JL>
JL> hmm, sure? i know someone who i'm sure has some version >= 2.00
JL>and he had to do this same [(long) foo] thing to get `compress'
JL>running. i know that 'cause i was it who told him the `trick'... :-)
I'm rather sure; I tested several cases which were compiled into
16-Bit-Code by the 1.x compiler: the 2.0 compiler generated the correct
code for 32 bit indexing.
But of course there could still be some bug lurking...
JL>> It wasn't really a bug but a "design restriction" - it made programs both
JL>> smaller and faster (it's even mentioned somewhere in the manual!).
JL>
JL> not in my manual (TC 1.1 that is). and besides, what does ANSI
JL>say about this?
I got it mixed up - it's not in the 1.0/1.1 manual but in the accompanying
README file!
And since it is documented, it can't be a bug - it must be a feature! ;-))
(But of course you're right: from an ANSI point of view the compiler is
"broken" since it violates the "model" of the C language.)
The funny thing is: in version 2.0, they moved this info from the README
file into the printed manual; at the same time, they fixed the problem!
JL>> The new compiler uses only 16 bits for array addressing if and only if it
JL>is
JL>> sure that the array addressed is smaller than 32 KBytes.
JL>
JL> ummm... how can it be sure when i, for example calloc()ed the thing?
It's simple: it can't be sure - and so of course it will not use 16 bit
("short") addressing! :-)
As far as I know, the compiler uses "short" addressing only on arrays<=32KB
if they are declared in the same module, and _never_ on poiners...
Martin