Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code |
Дата | |
Msg-id | CAB7nPqSDiNAyv8OkK3DXKkfd2tovSkaj1EhJW1DwRDnR7AypsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code (Aleksander Alekseev <a.alekseev@postgrespro.ru>) |
Ответы |
Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code
|
Список | pgsql-hackers |
On Fri, Dec 9, 2016 at 3:23 AM, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote: >> You could just change it to >> if (str[strspn(str, " \t\n\r\f")] == '\0') >> to mitigate calling strlen. It's safe to do so because strspn will >> only return values from 0 to strlen(str). > >> [...] I have serious doubts that the "optimized" implementation >> you propose is actually faster than a naive one; it may be slower, and >> it's certainly longer and harder to understand/test. > > I would like to point out that I never said it's optimized. However I > like the code Geoff proposed. It definitely doesn't make anything worse. > I decided to keep pg_str_contansonly procedure (i.e. not to inline this > code) for now. Code with strspn looks OK in a simple example. However in > a concrete context it looks like a bad Perl code in ROT13 to me: Looking at this patch, I am not sure that it is worth worrying about. This is a receipt to make back-patching a bit more complicated, and it makes the code more complicated to understand. So I would vote for rejecting it and move on. By the way, as you are placing this routine in src/common/, you may want to consider updating the code in src/bin/ that use libpqcommon. -- Michael
В списке pgsql-hackers по дате отправления: