[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