Re: replace strtok()

2024-10-18 Thread Ranier Vilela
Em sex., 18 de out. de 2024 às 06:41, Peter Eisentraut escreveu: > On 16.10.24 09:42, Peter Eisentraut wrote: > > On 15.10.24 14:00, Alexander Lakhin wrote: > >> I also wonder, if other places touched by 5d2e1cc11 need corrections > too. > >> I played with > >> PG_COLOR=always PG_COLORS="error=01

Re: replace strtok()

2024-10-18 Thread Peter Eisentraut
On 16.10.24 09:42, Peter Eisentraut wrote: On 15.10.24 14:00, Alexander Lakhin wrote: I also wonder, if other places touched by 5d2e1cc11 need corrections too. I played with PG_COLOR=always PG_COLORS="error=01;31" .../initdb and it looks like this free() call in pg_logging_init():        

Re: replace strtok()

2024-10-17 Thread Ranier Vilela
Em qui., 17 de out. de 2024 às 07:30, Alexander Lakhin escreveu: > Hello Ranier, > > 16.10.2024 14:14, Ranier Vilela wrote: > > Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut < > pe...@eisentraut.org> escreveu: > >> >> This wouldn't fix anything, I think. If colors is NULL, then strsep()

Re: replace strtok()

2024-10-17 Thread Alexander Lakhin
Hello Ranier, 16.10.2024 14:14, Ranier Vilela wrote: Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut escreveu: This wouldn't fix anything, I think.  If colors is NULL, then strsep() already returns NULL, so the added code does nothing. If *colors* is NULL, then the delimiter

Re: replace strtok()

2024-10-16 Thread Ranier Vilela
Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut escreveu: > On 15.10.24 14:07, Ranier Vilela wrote: > > I also wonder, if other places touched by 5d2e1cc11 need corrections > > too. > > I played with > > PG_COLOR=always PG_COLORS="error=01;31" .../initdb > > > > and it

Re: replace strtok()

2024-10-16 Thread Peter Eisentraut
On 15.10.24 14:07, Ranier Vilela wrote: I also wonder, if other places touched by 5d2e1cc11 need corrections too. I played with PG_COLOR=always PG_COLORS="error=01;31" .../initdb and it looks like this free() call in pg_logging_init():        char       *colors = st

Re: replace strtok()

2024-10-16 Thread Peter Eisentraut
On 15.10.24 14:00, Alexander Lakhin wrote: I also wonder, if other places touched by 5d2e1cc11 need corrections too. I played with PG_COLOR=always PG_COLORS="error=01;31" .../initdb and it looks like this free() call in pg_logging_init():        char       *colors = strdup(pg_colors_env);

Re: replace strtok()

2024-10-15 Thread Ranier Vilela
Em ter., 15 de out. de 2024 às 09:00, Alexander Lakhin escreveu: > Hello Ranier and Peter, > > 15.10.2024 14:44, Ranier Vilela wrote: > > > > Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut < > pe...@eisentraut.org> escreveu: > >> >> Thanks for the analysis. I think moreover we *only* nee

Re: replace strtok()

2024-10-15 Thread Alexander Lakhin
Hello Ranier and Peter, 15.10.2024 14:44, Ranier Vilela wrote: Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut escreveu: Thanks for the analysis.  I think moreover we *only* need to check the "stringp" for NULL, not the return value of strsep(), which would never be NULL

Re: replace strtok()

2024-10-15 Thread Ranier Vilela
Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut escreveu: > On 10.10.24 14:59, Ranier Vilela wrote: > > Please look at the SCRAM secret, which breaks parse_scram_secret(), > > perhaps because strsep() doesn't return NULL where strtok() did: > > > > CREATE ROLE r PASSWORD > >

Re: replace strtok()

2024-10-14 Thread Peter Eisentraut
On 10.10.24 14:59, Ranier Vilela wrote: Please look at the SCRAM secret, which breaks parse_scram_secret(), perhaps because strsep() doesn't return NULL where strtok() did: CREATE ROLE r PASSWORD 'SCRAM- SHA-256$4096:hpFyHTUsSWcR7O9P$LgZFIt6Oqdo27ZFKbZ2nV+=vtnYM995pDh9ca6WSi

Re: replace strtok()

2024-10-10 Thread Ranier Vilela
Hi Alexander, Em qui., 10 de out. de 2024 às 02:00, Alexander Lakhin escreveu: > Hello Peter, > > 23.07.2024 15:38, Peter Eisentraut wrote: > > This has been committed. Thanks. > > Please look at the SCRAM secret, which breaks parse_scram_secret(), > perhaps because strsep() doesn't return NULL

Re: replace strtok()

2024-10-09 Thread Alexander Lakhin
Hello Peter, 23.07.2024 15:38, Peter Eisentraut wrote: This has been committed.  Thanks. Please look at the SCRAM secret, which breaks parse_scram_secret(), perhaps because strsep() doesn't return NULL where strtok() did: CREATE ROLE r PASSWORD 'SCRAM-SHA-256$4096:hpFyHTUsSWcR7O9P$LgZFIt6Oqd

Re: replace strtok()

2024-07-23 Thread Peter Eisentraut
On 08.07.24 07:45, David Steele wrote: On 6/24/24 19:57, Peter Eisentraut wrote: On 24.06.24 02:34, Michael Paquier wrote: On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote: Peter Eisentraut writes: On 18.06.24 13:43, Ranier Vilela wrote: I found another implementation of strsep, it

Re: replace strtok()

2024-07-07 Thread David Steele
On 6/24/24 19:57, Peter Eisentraut wrote: On 24.06.24 02:34, Michael Paquier wrote: On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote: Peter Eisentraut writes: On 18.06.24 13:43, Ranier Vilela wrote: I found another implementation of strsep, it seems lighter to me. I will attach it fo

Re: replace strtok()

2024-06-24 Thread Peter Eisentraut
On 24.06.24 02:34, Michael Paquier wrote: On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote: Peter Eisentraut writes: On 18.06.24 13:43, Ranier Vilela wrote: I found another implementation of strsep, it seems lighter to me. I will attach it for consideration, however, I have not done a

Re: replace strtok()

2024-06-23 Thread Michael Paquier
On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote: > Peter Eisentraut writes: > > On 18.06.24 13:43, Ranier Vilela wrote: > >> I found another implementation of strsep, it seems lighter to me. > >> I will attach it for consideration, however, I have not done any testing. > > > Yeah, surely

Re: replace strtok()

2024-06-22 Thread Tom Lane
Peter Eisentraut writes: > On 18.06.24 13:43, Ranier Vilela wrote: >> I found another implementation of strsep, it seems lighter to me. >> I will attach it for consideration, however, I have not done any testing. > Yeah, surely there are many possible implementations. I'm thinking, > since we a

Re: replace strtok()

2024-06-22 Thread Peter Eisentraut
On 18.06.24 13:43, Ranier Vilela wrote: But I would like to see more const char * where this is possible. For example, in pg_locale.c IMO, the token variable can be const char *. At least strchr expects a const char * as the first parameter. This would not be future-proof. In C23, if you pas

Re: replace strtok()

2024-06-19 Thread Kyotaro Horiguchi
At Tue, 18 Jun 2024 09:18:28 +0200, Peter Eisentraut wrote in > Under the topic of getting rid of thread-unsafe functions in the > backend [0], here is a patch series to deal with strtok(). > > Of course, strtok() is famously not thread-safe and can be replaced by > strtok_r(). But it also has

Re: replace strtok()

2024-06-18 Thread Ranier Vilela
Em ter., 18 de jun. de 2024 às 04:18, Peter Eisentraut escreveu: > Under the topic of getting rid of thread-unsafe functions in the backend > [0], here is a patch series to deal with strtok(). > > Of course, strtok() is famously not thread-safe and can be replaced by > strtok_r(). But it also ha

replace strtok()

2024-06-18 Thread Peter Eisentraut
Under the topic of getting rid of thread-unsafe functions in the backend [0], here is a patch series to deal with strtok(). Of course, strtok() is famously not thread-safe and can be replaced by strtok_r(). But it also has the wrong semantics in some cases, because it considers adjacent delim