Re: BUG #18708: regex problem: (?:[^\d\D]){0} asserts with "lp->nouts == 0 && rp->nins == 0"

I wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> (Un)fortunately, tern (which is also a ppc animal) has produced the same
>> failure:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2024-11-16%2022%3A00%3A12

> Yeah, I saw that.  Even more confused now about what it could be.

After testing on hornet's host, it seems that this is a pre-existing
issue that we didn't happen to hit before.  Since the regex
'[^\d\D]' is unsatisfiable, it collapses to nothing (start state,
end state, and no arcs) in the first cleanup() call in optimize().
Then fixempties() counts the number of in-arcs and gets zero,
and then it does

    arcarray = (struct arc **) MALLOC(totalinarcs * sizeof(struct arc *));
    if (arcarray == NULL)
    {
        NERR(REG_ESPACE);
        ...

On a machine where malloc(0) returns NULL, this mistakenly
thinks that's an error.

I verified that

-    if (arcarray == NULL)
+    if (arcarray == NULL && totalinarcs != 0)

makes the failure go away, but I wonder if any other places in
backend/regex/ are at the same hazard.  Maybe the smartest fix
would be to put in a wrapper layer that does what pg_malloc
does:

    /* Avoid unportable behavior of malloc(0) */
    if (size == 0)
        size = 1;

One other point is that this theory fails to explain why
hornet didn't fail in the v16 branch ... oh, wait:
v15 has

#define MALLOC(n)        malloc(n)

where later branches have

#define MALLOC(n)        palloc_extended((n), MCXT_ALLOC_NO_OOM)

So the right answer seems to be to figure out why we didn't
back-patch that change.

            regards, tom lane