At Sat, 15 May 2021 11:35:13 -0300, Ranier Vilela <ranier.vf@gmail.com> wrote in > 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?
- DWORD attr; - HANDLE h;
Why the patch moves the definitions for "attr" and "h"?
Hi Kyotaro, thank you for reviewing this.
I changed the declarations of variables for reasons of standardization and to avoid fragmentation of memory,
following the same principles of declaration of structures.
+ Assert(path != NULL && buf != NULL);
I don't think it's required. Even if we want to imitate readlink, they should (maybe) return EFALUT in that case.
Yes. It is not a requirement. But I try to take every chance to prevent bugs. And always validating the entries, sooner or later, helps to find errors.
+ buf[r] = '\0';
readlink is defined as not appending a terminator. In the first place the "buf[r] = '\0'" is overrunning the given buffer.