Re: [9front] rc: null list in concatenation line numbers

[ori@eigenstate.org]

> +		if(f|l != 0){
> +			emitf(Xloc);
> +			emiti(f|l);
> +		}
> 
> you need parentesis there around: f|l

Or I can get rid of the check entirely; if it ever happens,
it's harmless.

> +		/*
> +		 * These are small enough that with a ton of sourcing,
> +		 * overflow is a realistic risk. If we run out of files,
> +		 * set to file 0, which is always '???'
> +		 */
> +		f = (t->file > LFMAX) ? 0 : t->file << LSHIFT;
> +		l = (t->line > LMASK) ? -1 : t->line;
> 
> setting line to -1 also implicitely makes the file all ones...

Oops -- fixed. Good catch.
 
> +	if(i == nlexpath){
> +		if(nlexpath < LFMAX){
> +			lexpath = erealloc(lexpath, (nlexpath + 1)*sizeof(char*));
> +			lexpath[nlexpath] = estrdup(zero);
> +			lexfile = nlexpath++;
> +		}else
> +			lexfile = 0;
> +	}
> 
> might want to use doubling the size for each realloc...

Easy enough to do, but by the time we're sourcing a file,
we're already doing so much other work that doing an extra
realloc probably won't matter. We're currently limiting to
2048 calls over the lifetime of a shell anyways.

Even if that restriction is limited, I'd like to put a
relatively small cap on this, so we're not doing a ton
of O(n) searches -- the only way I can imagine someone
running into the limit is if they generate scripts to
source in a long running script, and an unlimited table
here would be a memory leak.

Still, it's a couple of lines, I'll make the change.

> also wonder if the file can even change in the tree...
> the file would only change when we source a file, no?
> 
> so i wonder if we need to keep track of the file in
> the tree at all, and not just update it at runtime
> in the thread.

You're right, we can just use lexfile directly; the
trees never come from a file other than the one we're
parsing.