[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