Re: replace strtok()
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
David Steele <david@pgmasters.net>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-17T12:35:40Z
Lists: pgsql-hackers
Em qui., 17 de out. de 2024 às 07:30, Alexander Lakhin <exclusion@gmail.com> escreveu: > Hello Ranier, > > 16.10.2024 14:14, Ranier Vilela wrote: > > Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut < > peter@eisentraut.org> 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 is not found and strsep will > return the entire > string **stringp, so the token becomes invalid*. > > IMO, I think it must be necessary to check if *colors* are NULL too. > > > I've tested your proposed change and what I'm seeing is that: > PG_COLOR=always PG_COLORS="error=01;31" initdb > doesn't color the "error" word: > > while with only Peter's patch it works as expected: > > > Does your change work differently for you? > No. Thanks for the test. It seems to me that with strsep, the only alternative is to run the risk of processing an invalid token? I ran the test with Peter's patch in Windows and the terminal doesn't color the "error" word, perhaps this feature does not work with Windows. [image: error1.png] I withdraw the proposed patch. best regards, Ranier Vilela
Commits
-
Fix memory leaks from incorrect strsep() uses
- 4b652692e979 18.0 landed
-
Fix strsep() use for SCRAM secrets parsing
- 24a36f91e32d 18.0 landed
-
Replace remaining strtok() with strtok_r()
- 65504b747f3c 18.0 landed
-
Windows replacement for strtok_r()
- 4d130b28727c 18.0 landed
-
Replace some strtok() with strsep()
- 5d2e1cc117b3 18.0 landed
-
Add port/ replacement for strsep()
- 683be87fbba0 18.0 landed