Walter Bright wrote:
Rainer Schuetze wrote:
Walter, is optlink able to deal with this 3rd representation in all
places, so we can get rid of those other two encodings?
The way long symbols on Windows are dealt with:
1. if they fit, they fit
2. try using the extended length method
3. try compressing the string
4. use a hash for the string
1..3 are reversible, 4 is not.
Doing it always in this order would be fine, because 2. is bound to
never fail.
Checking the source (but probably missing some places), I see that
- obj_namestring uses 1,2
- obj_mangle uses 1,3,4,2 with a length limit of 128
- Library::FillDict uses 1,2, but might crash due to limited buffer size
(for symbols longer than 468 characters - is this a limitation of the
library format?)
- cv_namestring uses 1,2
So I tried compiling ddmd skipping 3 and 4 in obj_mangle, but that
caused crashes for symbols longer than IDMAX (=900). Increasing that
limit (max length was >5600) caused a crash in optlink. But as far as I
can see, limiting the usage of 3 and 4 to symbols longer than IDMAX
seems to work (though I have not done any more testing). Actually, this
version is already in the code, but deliberately replaced by the limit
of 128 characters, so there might be a reason...
Rainer
