>
> Do changes 25821 and 25823 take things in the right direction
> for this?
Yes.
> I'm not sure what's needed next. I have a suspicion that
>
> $ nm ext/Encode/def_t.o | egrep -v ' [TURtr] '
> 000000d8 D ascii_ctrl_encoding
> 0000010c d ascii_ctrl_utf8
> 00000124 D ascii_encoding
> 00000158 d ascii_utf8
> 00000034 D iso_8859_1_encoding
> 000000c0 d iso_8859_1_utf8
> 00000000 D null_encoding
> 00000028 d null_utf8
> 00000140 d utf8_ascii
> 000000f4 d utf8_ascii_ctrl
> 00000060 d utf8_iso_8859_1
> 000000a8 d utf8_iso_8859_1_c2
> 00000090 d utf8_iso_8859_1_c3
> 0000001c d utf8_null
>
> is because of the self-referential nature of things like
>
> static const encpage_t ascii_utf8[2] = {
> {enctable + 256,ascii_utf8,0x00,0x7f,1,1},
> {0,ascii_utf8,0x80,0xff,0,0},
> };
Yup.
> and the only way to make these totally static is to change all the named
> encpage_t structures to a per-file array, and have the structures hold
> offsets into that array rather than pointers. This would require code changes,
> and might not be backwards compatible.
Surely noone else than Encode should be peeking inside these tables
so how could backward compat be a problem?
Thread Previous
|
Thread Next