From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Sun Oct 25 21:00:47 -0400 2020 Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 4851f3af (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Sun, 25 Oct 2020 18:00:38 -0700 (PDT) Message-ID: <91F59916ECF05672C8A64212B2416426@eigenstate.org> To: cinap_lenrek@felloff.net, 9front@9front.org Subject: Re: [9front] rc: null list in concatenation line numbers Date: Sun, 25 Oct 2020 18:00:36 -0700 From: ori@eigenstate.org In-Reply-To: <41990F43512FF80F5598EE88078499ED@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic ORM table interface > + 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.