At Sat, 15 May 2021 11:35:13 -0300, Ranier Vilela <ranier...@gmail.com> wrote in > Em sex., 14 de mai. de 2021 às 19:52, Tom Lane <t...@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"? + 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. + buf[r] = '\0'; readlink is defined as not appending a terminator. In the first place the "buf[r] = '\0'" is overrunning the given buffer. - return 0 <= readlink(name, &c, 1); + return 0 <= readlink(name, linkpath, sizeof(linkpath)); According to the discussion, we don't want to modify zic.c at all. (Maybe forgot to remove?) regards. -- Kyotaro Horiguchi NTT Open Source Software Center
