Post B5NPi7vFsUriCvQysy by nothings@mastodon.gamedev.place
 (DIR) More posts by nothings@mastodon.gamedev.place
 (DIR) Post #B5NPi7h4jDWTUwneme by nothings@mastodon.gamedev.place
       0 likes, 0 repeats
       
       Someone submitted a bug report on stb_truetype which included the following presumably false sentence."I reproduced a heap-buffer-overflow with malformed TTF input by setting LOCA entries or the GLYF table offset so that the computed glyph offset points past the end of the file."Note the 'or'.People just lying now (or more likely having an LLM lie for them). This user has been banned, but overall: this sucks.(The bug IS "valid" stb_truetype API lacks font file length so CANNOT be fixed)
       
 (DIR) Post #B5NPi7vFsUriCvQysy by nothings@mastodon.gamedev.place
       0 likes, 0 repeats
       
       10 most recently closed Issues on stb github.
       
 (DIR) Post #B5NPi87f8Mn2pPEtE0 by rygorous@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @nothings some context for why LLM PRs _suck_ if you're a maintainer (in case this makes the rounds)1. LLM *code* was trained on scraped internet data, including other libs for the same problem, with no consent of the original authors, and with no consideration for the original licensing terms. Irrespective the legal situation on the matter (which is not fully settled), this is a lottery where you get fenced goods on a regular basis, and should be ethically considered such.
       
 (DIR) Post #B5NPi8LUIxqhWHhvm4 by rygorous@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @nothings 2. LLM *text* like in PR descs tends towards the verbose, meandering, and frequently bears no resemblance to the actual contents of a PR. This alone is sufficient grounds for rejection of any PR but the sheer volume of text wastes extra time.3. Anecdotally, the friction for LLM-generated word salad seems to be low enough that submitters don't even bother with a cursory check for whether they're re-filing a known issue. (More maintainer work.)
       
 (DIR) Post #B5NPi8YFXW3c9rg7fM by rygorous@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @nothings 4. Non-trivial percentage of complete non-sequitur PRs where the desc doesn't match the code diff, and the code diff also just seems random5. In the best of times, most submitters quietly disappear after landing a PR, and you're stuck with the resulting code forever. That's how this usually works (and why maintainers don't like taking random feature-add PRs even if it "works fine for me"). But a shockingly large fraction of LLM PRs is abandonware before they're even landed.
       
 (DIR) Post #B5NPi8lMkkY6oXob6u by wolf480pl@mstdn.io
       0 likes, 0 repeats
       
       @rygorousbut I was making abandonware PRs way before LLMs... (following up is stressful so I never do it)@nothings
       
 (DIR) Post #B5NPiA7NiNkn177h44 by rygorous@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @nothings "Authors" clearly not understanding the code they submitted and responding to follow-up questions and requests not with answers or targeted fixes, but ever more LLM spew. So even more maintainer shit work.In short, signal/noise ratio is way out of whack. It's one thing if it happens every once in a while, but this is the majority of submissions now (by a margin), and frankly, we were burned out enough on the stb libs to begin with as it was.
       
 (DIR) Post #B5NPiBWaU9VhNZvKzY by rygorous@mastodon.gamedev.place
       0 likes, 0 repeats
       
       @nothings "But I'm using LLMs responsibly..."Doubt it, but realistically, if you have a LLM-generated fix that you then manually massage so it looks and feels like a human-written commit with a targeted fix and not a venerable slop avalanche, we will probably never know.If we're even having this discussion, this PR was so bad that we never would've accepted it anyway.