Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)
Date
Msg-id CAEudQAqH7J8wSjSPwPx6_Pk4yyvF+NnHPagJqwZvpb7bqc3UEQ@mail.gmail.com
Whole thread Raw
In response to Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)
List pgsql-hackers
Em sex., 14 de mai. de 2021 às 19:52, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
I wrote:
> So the question for us is whether it's worth trying to make pgreadlink
> conform to the letter of the POSIX spec in this detail.  TBH, I can't
> get excited about that, at least not so far as zic's usage is concerned.

Hmmm ... on closer inspection, though, it might not be that hard.
pgreadlink is already using a fixed-length buffer (with only enough
room for MAX_PATH WCHARs) for the input of WideCharToMultiByte.  So
it could use a fixed-length buffer of say 4 * MAX_PATH bytes for the
output, and then transfer just the appropriate amount of data to the
caller's buffer.
Following your directions, maybe something like this will solve?

regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Robert Haas
Date:
Subject: Re: amvalidate(): cache lookup failed for operator class 123