Re: refactoring - share str2*int64 functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: refactoring - share str2*int64 functions
Date
Msg-id alpine.DEB.2.21.1909141007560.13770@lancre
Whole thread Raw
In response to Re: refactoring - share str2*int64 functions  (Michael Paquier <michael@paquier.xyz>)
Responses Re: refactoring - share str2*int64 functions
List pgsql-hackers
Bonjour Michaël,

> - Switching INT to use pg_strtoint32() causes a set of warnings as for
> example with AttrNumber:
> 72 |  (void) pg_strtoint32(token, &local_node->fldname)
>   |                              ^~~~~~~~~~~~~~~~~~~~~
>   |                              |
>   |                              AttrNumber * {aka short int *}

> And it is not like we should use a cast either, as we could hide real
> issues.

It should rather call pg_strtoint16? And possibly switch the "short int" 
declaration to int16?

About batch v14: applies cleanly and compiles without warnings. "make 
check" ok.

I do not think that "pg_strtoint_error" should be inlinable. The function 
is unlikely to be called, so it is not performance critical to inline it, 
and would enlarge the executable needlessly. However, the 
"pg_strto*_check" variants should be inlinable, as you have done.

About the code, on several instances of:

        /* skip leading spaces */
          while (likely(*ptr) && isspace((unsigned char) *ptr)) …

I would drop the "likely(*ptr)".

And on several instances of:

    !unlikely(isdigit((unsigned char) *ptr)))

ISTM that we want "unlikely(!isdigit((unsigned char) *ptr)))". Parsing 
!unlikely leads to false conclusion and a headache:-)

Otherwise, this batch of changes looks ok to me.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Psql patch to show access methods info
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks