From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Portable check for unportable <ctype.h> macro usage |
Date: | 2016-10-19 17:32:03 |
Message-ID: | 20161019173203.qma436jinyisvqqp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-10-19 12:14:50 -0400, Tom Lane wrote:
> A portability hazard that we fight constantly is that the <ctype.h>
> macros such as isalpha() can't safely be called on "char" values.
> Per POSIX, you have to make sure the input is cast to "unsigned char".
> That's far too easy to forget, but on most machines you won't get any
> warning about it.
> We have a couple of buildfarm machines that will generate "char value
> used as array subscript" warnings for this, because their implementations
> of these macros are indeed just array lookups. But I think gaur is
> the only one that's still active, and it's not going to last forever.
>
> Ralph Corderoy, one of the nmh hackers, was looking at this problem
> and came up with this cute solution [1]:
>
> #ifndef NDEBUG
> #if EOF != -1
> #error "Please report this to nmh's authors."
> #endif
>
> extern int ctype_identity[257]; /* [n] = n-1 */
> #define isupper(c) ((isupper)((ctype_identity + 1)[c]))
> ...
> #endif
Hm. I'd be kind of inclined to instead do something akin to
#include <ctype.h>
#define system_isupper(c) isupper(c)
#undef isupper
#define isupper(c) (AssertVariableIsOfTypeMacro(c, unsigned char), isupper(c))
=>
/home/andres/src/postgresql/src/include/c.h:745:7: error: static assertion failed: "c does not have type unsigned char"
that would probably result in better error messages,and we can leave it
enabled regardless of debug mode.
That requires one usage adoption in wparser_def.c's p_iswhat()
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2016-10-19 17:34:41 | Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods. |
Previous Message | Tom Lane | 2016-10-19 17:25:33 | Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods. |