[tex-live] Re: [tex-implementors] bug in etex
Peter Breitenlohner
peb at mppmu.mpg.de
Wed Jul 14 17:51:37 CEST 2004
On Wed, 14 Jul 2004, Olaf Weber wrote:
> In particular, it looks like the code
> .....
> if cur_chr=mem_bot then
> begin scan_register_num;
> if cur_val<256 then q:=equiv(toks_base+cur_val)
> else begin find_sa_element(tok_val,cur_val,false);
> if cur_ptr=null then q:=null
> else q:=sa_ptr(cur_ptr);
> end;
> end
> else q:=sa_ptr(cur_ptr) { <---1--- }
> else q:=equiv(cur_chr);
> .....
Hi Olaf,
this was a stupid typo. The line (1) above should read
> else q:=sa_ptr(cur_chr)
^^^
and everything should be fine.
A completely analogous piece of code in etex.ch reads
> if m=mem_bot then
> begin scan_register_num;
> if cur_val<256 then cur_val:=equiv(toks_base+cur_val)
> else begin find_sa_element(tok_val,cur_val,false);
> if cur_ptr=null then cur_val:=null
> else cur_val:=sa_ptr(cur_ptr);
> end;
> end
> else cur_val:=sa_ptr(m)
> else cur_val:=equiv(m);
Could you test this? Right now I have some difficulties recompiling etex.
Some explanation:
cur_cmd == toks_register && cur_chr != mem_bot
indicates a \toksdef'ed sparse array element (which can't disappear due to
its reference count) with cur_chr pointing to the actual array element.
The global variable cur_ptr should only be used in a very local context.
Referencing the (non-existing) \toks265 results in cur_ptr==null. Even
without that, i.e. with cur_ptr!=null the "q:=sa_ptr(cur_ptr)" gives a
wrong value!
regards
Peter Breitenlohner <peb at mppmu.mpg.de>
More information about the tex-live
mailing list