<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at 12:55 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/12/23 09:32, enh wrote:> On Sat, Jun 10, 2023 at 1:41 PM Rob Landley<br>
<<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
> On 6/10/23 00:05, enh via Toybox wrote:<br>
> > This was segfaulting because the loop copying the chips into the array<br>
> > was corrupting the list, and because the llist_traverse was being given<br>
> > the wrong pointer.<br>
> <br>
> Huh, I wonder how that segfaults. I still don't have a test environment for<br>
> this, but foreach_chip() is called exactly once (from three different command<br>
> main functions) so consuming the list in the one and only pass seemed<br>
> reasonable? I see I forgot to remove the free before exit but the only way there<br>
> should be anything left is if TT.chip_count was < than the number of entries in<br>
> the list, and even then the remains of the list should still be in their<br>
> original order...?<br>
> <br>
> oh, yeah, just not trying to free the now-corrupted list would have been fine<br>
> too. (really there were two unrelated bugs: the traversal meant that there was a<br>
> leak, and the free was using the wrong pointer, which was the segfault. just<br>
> fixing the segfault didn't make any sense on its own.)<br>
> <br>
> *shrug* Applied your patch as-is, I shouldn't poke at code I can't test...<br>
> <br>
> i can send you a tested patch for not freeing if you prefer.<br>
<br>
Six of one... I was just saying "when I changed this bit I forgot to change that<br>
bit".<br></blockquote><div><br></div><div>so my argument for preferring to not corrupt the list was "one could imagine calling foreach_chip() more than once in a toy; gpiomon, say [which i haven't actually written because i've never used it, and the people who've asked for the gpio tools have also denied wanting that one, and it has a lot of options and i don't want to guess at the useful subset without a user], might do this between each sleep". in which case, the freeing would be a _bug_.</div><div><br></div><div>but that's arguable enough (and a problem that my first attempt to run gpiomod would demonstrate via crash) that i won't send you the one-line patch, even though i think removing the llist_traverse() line would be fine.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In theory making the free() optional reduces the size of the binary, and various<br>
embedded environments still use brk() under the covers, meaning to free the<br>
entire heap at exit() they just have to move one pointer. A lot of "what can we<br>
do in 64k of ram" embedded environments look back at what Unix v6 and friends<br>
_did_ in similarly sized environments, and it still works. If you want a posix<br>
programming environment in tiny RTOS, what's old is often new again. And yes, we<br>
have reached the "on-chip battery" stage of embedded chicanery:<br>
<br>
<a href="https://www.independent.co.uk/tech/battery-smallest-computer-wearables-b2021494.html" rel="noreferrer" target="_blank">https://www.independent.co.uk/tech/battery-smallest-computer-wearables-b2021494.html</a><br>
<br>
> > The strdup wasn't failing, but should be an xstrdup anyway. (I think<br>
> > all the strdups in toys/ should actually be xstrdups. Maybe we should<br>
> > even poison strdup, or just `#define strdup xstrdup`?)<br>
> <br>
> I've historically done some poisoning, but it tended to cause weird build breaks<br>
> with macros in header files and so on? <br>
> <br>
> <br>
> there's a #pragma `poison` in both gcc and clang (specifically for this<br>
> problem). as long as we're building with those compilers, that should prevent<br>
> any uses creeping in?<br>
<br>
Is there a list of clang pragmas anywhere? The llvm documentation at<br>
<a href="https://clang.llvm.org/docs/UsersManual.html" rel="noreferrer" target="_blank">https://clang.llvm.org/docs/UsersManual.html</a> does not seem to have one...</blockquote><div><br></div><div>yeah, don't get me started ... afaict even our own llvm people either look embarrassed and back away or recommend you read the gcc docs instead. or that old classic, "check the source". which doesn't work so well for projects on the scale of gcc or clang, but the llvm source does include a test for `#pragma GCC poison rindex`.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>