[tex-live] Re: bug in etex

David Kastrup dak at gnu.org
Tue Jul 13 18:40:51 CEST 2004


Taco Hoekwater <taco at elvenkind.com> writes:

> ------
> @ @<If the right-hand side is a token parameter...@>=
> if (cur_cmd=toks_register)or(cur_cmd=assign_toks) then
>   begin if cur_cmd=toks_register then
>     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)  {HERE! }

Unless I am very much mistaken, this `else' belongs to `if
cur_chr=mem_bot', and from the surface look of the code I don't see
why cur_ptr should have any sensible value at that point.  Where would
it come from?  Or should the comparison be `if cur_ptr=mem_bot' and
the cur_ptr is set some time before?  It would appear more sensible if
some _pointer_ would be compared here to something called `mem_bot'.

>   else q:=equiv(cur_chr);

And this `else' belongs to `if cur_cmd=toks_register'.  Hm, looks
like q get set in every path after all.

Ok, just some musings.  Maybe it will give somebody with more of a
clue an idea what happens here.

>   if q=null then sa_define(p,null)(p,undefined_cs,null)
>   else  begin add_token_ref(q); sa_define(p,q)(p,call,q);
>     end;
>   goto done;
>   end

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum



More information about the tex-live mailing list