Hi Branden,

On 2026-04-22T12:23:28-0500, G. Branden Robinson wrote:
[...]
> > However, 2 lines below there the patch introduced a line using BR
> > perfectly.  That very much read like random LLM stuff.
> 
> Nice catch.  I like the way you sussed that out.  While humans are not
> immune from this class of error (forgetting something you "knew" 60
> seconds ago--maybe more like 60 nanoseconds in LLM time), it's uncommon
> among mentally healthy people who haven't been hitting the "substances".
> 
> I'm reminded of how toddlers acquire object permanence.[1]  Not _quite_
> the same thing, as abstract knowledge is more easily lost ("what are the
> conventional units of the ideal gas constant?  how many operator
> precedence levels does C have, again?

Off-topic, but in case you have the doubt, it can be settled:

There are as many levels as subclauses under 6.5 ("Expressions")
--I don't know the number of subclauses from the top of my head, though,
of course--, excluding of course 6.5.1 ("General").

In C23 (n3220), that is documented in footnote 82:

	The syntax specifies the precedence of operators
	in the evaluation of an expression,
	which is the same as the order of
	the major subclauses of this subclause,
	highest precedence first.
	[...]

Checking the number of subclauses, it happened to be 17 (18 - 1) in C23,
and remains the same number in C2y.  That number seems to have stayed
stable: we already had 17 categories in C89 (but "Expressions" was then
3.3).

:)

> ")--but it seems close.
> 
> A course for people red-teaming LLMs to pursue, maybe.
> 
> > There was also the arbitrary combined use of .P and .PP.  I suspect no
> > human would use both in a document, unless the surrounding style
> > already uses both (which could confuse).  Since we only have .P, the
> > .PP came out of nowhere.
> 
> Another good catch.  As you note, the domain is limited.  In documents
> with long histories and multiple contributors, the pointless profusion
> of paragraphing macros with identical semantics is sadly common.
> 
> > And then there's the extensive use of \f (without brackets)
> 
> Still _really_ common in the global man page corpus.  But yeah, a hard
> mistake to make for someone who's a total n00b to man page writing in
> general _and_ to the Linux man-pages project.  People don't think up
> that syntax, they crib it from somewhere.  Or an LLM does it for them.
> 
> > and \(bu, of which we have no cases anymore.
> 
> Unlike `\f`, I regard `\(bu` [preferably spelled `\[bu]`] as cromulent
> usage.  We need not be afraid of bullet characters.  They degrade to
> US-ASCII perfectly well in groff (and mandoc(1) too) and I'm confident
> that this special character will work everywhere the Linux man-pages are
> likely to be formatted.  See groff_char(7).

Here we exclusively use the spelling \f[] and \[bu].  That's why \(bu
was suspicious.  I could expect it from an expert in the matter who
didn't know our style, but the author didn't seem one.

> 
> > All of this was very suspicious, so I had to ask.
> 
> Is there a resource that collects "here's how I caught an LLM-generated
> software patch/research paper/court filing" stories?

I haven't heard of any, but I suspect there is.  I've seen some good
amount of LLM crap that I think I have a good eye for catching it (even
if sometimes I may not say it explicitly, especially when the author
knows it's not allowed --I may prefer to wait for the author to disclose
it voluntarily; that has the benefit of allowing me to evaluate the
limits of the honesty of the human--).


Cheers,
Alex

> Regards,
> Branden
> 
> [1] https://en.wikipedia.org/wiki/Object_permanence

-- 
<https://www.alejandro-colomar.es>