Re: A platform-specific defect in the ODBC driver

Hi Alex,

Alex Goncharov wrote:
> Hello Hiroshi,
>
> I hope I am addressing this message correctly.
>
> Consider this code in `statement.c':
>
> ------------------------------------------------------------
> static void SC_init_parse_method(StatementClass *self)
> {
> if (self->multi_statement <= 0 && ...)
> SC_set_parse_tricky(self);
> }
>
> StatementClass *
> SC_Constructor(ConnectionClass *conn)
> {
> rv->multi_statement = -1; /* unknown */
> }
> ------------------------------------------------------------
>
> There is obviously an assumption here that `multi_statement' can,
> under certain circumstances, be negative. And, indeed, this is what
> `statement.h' says about it:
>
> ------------------------------------------------------------
> struct StatementClass_
> {
> char multi_statement; /* -1:unknown 0:single 1:multi */
> };
>
> ------------------------------------------------------------
>
> so, `multi_statement' is a three-valued entity, with -1 being one of
> the possible values.
>
> But what if `char' is an unsigned type? Then assigning -1 to
> `multi_statement' will result in it being 255, and comparisons like
> `<= 0' won't make sense.
>
> Can `char' be unsigned? Yes, it can, per paragraph 15 in the ISO
> C, Section 6.2.5:
>
> 15 The three types char, signed char, and unsigned char are
> collectively called the character types. The implementation
> shall define char to have the same range, representation, and
> behavior as either signed char or unsigned char.35)
>
> Various compilers on AIX consider `char' to be unsigned, and the code
> compiled there (with gcc), will fail miserably on some operations.

I see.

> A possible and probably the best resolution is to give
> `multi_statement' and similar "to-be-three-valued" variables a good
> "indicator" type, which can allow all the expected values, -1, 0 and 1
> and legit comparisons between them.
>
> The enclosed patch does it and resolves the failures on AIX
> completely.
>
> Please consider including this or a similar fix into the official
> distribution of the ODBC driver.

OK I would take care of it in 8.4.0100 release.

regards,
Hiroshi Inoue