Re: databases/sqlite on powerpc

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

I said...

> In other words, he@'s patch is correct and was applied by upstream a
> decade ago -- except as `unsigned hash' instead of `unsigned int
> hash', and with several other related fixes that we should probably
> apply too if anyone cares about building sqlite.

However, I missed a part:

> Date: Fri, 24 Jun 2022 10:48:54 +0200 (CEST)
> From: Havard Eidnes <he%NetBSD.org@localhost>
> 
> +@@ -3016,7 +3016,7 @@ int mhflag;                 /* True if g
> +   int maxdtlength;          /* Maximum length of any ".datatype" field. */
> +   char *stddt;              /* Standardized name for a datatype */
> +   int i,j;                  /* Loop counters */
> +-  int hash;                 /* For hashing the name of a type */
> ++  unsigned int hash;        /* For hashing the name of a type */
> +   char *name;               /* Name of the parser */
> + 
> +   /* Allocate and initialize types[] and allocate stddt[] */

This hunk looks fine, but...

> +@@ -3068,7 +3068,7 @@ int mhflag;                 /* True if g
> +     for(j=0; stddt[j]; j++){
> +       hash = hash*53 + stddt[j];
> +     }
> +-    hash = (hash & 0x7fffffff)%arraysize;
> ++    hash = hash % arraysize;

It is not a priori clear that this hunk is correct, and this hunk is
not replicated upstream; upstream still has `hash & 0x7fffffff'.

If the hash is ever computed anywhere else that it has to agree with
(which I don't see on quick skim but it could be hidden somewhere not
obvious), this hunk is probably wrong.

I suggest just taking the upstream patch:

https://sqlite.org/src/info/8d399a03de63c159