RE: Windows port minor fixes - Mailing list pgsql-hackers

From Ranier Vilela
Subject RE: Windows port minor fixes
Date
Msg-id CO2PR05MB2629840448907444C86E47E2E3500@CO2PR05MB2629.namprd05.prod.outlook.com
Whole thread Raw
In response to Windows port minor fixes  (Ranier Vilela <ranier_gyn@hotmail.com>)
Responses Re: Windows port minor fixes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
De: Michael Paquier
Enviadas: Terça-feira, 17 de Dezembro de 2019 04:45
>And if you actually group things together so as any individual looking
>at your patches does not have to figure out which piece applies to
>what, that's also better.
I'm still trying to find the best way.

>Anyway, the patch for putenv() is wrong in the way the memory is freed, but this >has been mentioned on another thread.
Oh yes, putenv depending on glibc version, copy and not others, the pointer.
At Windows side, the Dr.Memory, reported two memory leaks, with strdup.
The v2 is better, because, simplifies the function.
Submitted a proposal for setenv support for Windows, in other thread.

>We rely on MAXPGPATH heavily so your patch trying to change
>the buffer length does not bring much,
I am a little confused about which path you are talking about.
If it about var path at function validate_exec, I believe that there is a mistake.

char path_exe[MAXPGPATH + sizeof(".exe") - 1];
The -1, its suspicious and can be removed.

Once there, I tried to improve the code by simplifying and removing the excessive number of functions.

At Windows side, the code paths, is less tested.
The Dr.Memory, reported 3794 potential unaddressable access at WIN32 block, pipe_read_line function, wich call validade_exec.

Best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: non-exclusive backup cleanup is mildly broken
Next
From: Christoph Moench-Tegeder
Date:
Subject: Re: Improvement to psql's connection defaults