Em ter., 15 de out. de 2024 às 09:00, Alexander Lakhin <exclus...@gmail.com>
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* need to check the
>> "stringp" for NULL, not the return value of strsep(), which would never
>> be NULL in our case. So I propose the attached patch as a variant of
>> yours.
>>
> I'm not 100% sure, but the contrib passwordcheck uses and It's not very
> safe.
> The checks of NULL return are cheap, and will protect unwary users.
>
> So I'm neutral here.
>
>
> 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);
>
> if (colors)
> {
> ...
> while ((token = strsep(&colors, ":")))
> {
> ...
> }
>
> free(colors);
> }
> gets null in colors.
>
Yeah, I also saw this usage, but I was waiting for a definition for the
first report.
The solution IMO, would be the same.
diff --git a/src/common/logging.c b/src/common/logging.c
index aedd1ae2d8..45b5316d48 100644
--- a/src/common/logging.c
+++ b/src/common/logging.c
@@ -121,7 +121,7 @@ pg_logging_init(const char *argv0)
{
char *token;
- while ((token = strsep(&colors, ":")))
+ while ((token = strsep(&colors, ":")) != NULL && colors != NULL)
{
char *e = strchr(token, '=');
The advantage of this change is that it would avoid processing unnecessary
tokens.
best regards,
Ranier Vilela
>
