Re: refactoring - share str2*int64 functions
| От | Fabien COELHO |
|---|---|
| Тема | Re: refactoring - share str2*int64 functions |
| Дата | |
| Msg-id | alpine.DEB.2.21.1909141007560.13770@lancre обсуждение исходный текст |
| Ответ на | Re: refactoring - share str2*int64 functions (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: refactoring - share str2*int64 functions
|
| Список | 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 по дате отправления: