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 по дате отправления: