Re: [PATCH] Cygwin: ptsname_r: always return an error number on failure

. Returning 0 > > violates the requirement in > > https://man7.org/linux/man-pages/man3/ptsname_r.3.html that an error > > number should be returned on failure. (That man page doesn't specify > > setting errno.) > > > > Addresses: > > https://lists.

Re: [PATCH] Cygwin: ptsname_r: always return an error number on failure

On 1/20/2021 1:00 PM, Ken Brown via Cygwin-patches wrote: Following Linux, return ENOTTY on a bad file descriptor and also set errno to ENOTTY. Previously 0 was returned and errno was set to EBADF. Returning 0 violates the requirement in https://man7.org/linux/man-pages/man3/ptsname_r.3.html

[PATCH] Cygwin: ptsname_r: always return an error number on failure

Following Linux, return ENOTTY on a bad file descriptor and also set errno to ENOTTY. Previously 0 was returned and errno was set to EBADF. Returning 0 violates the requirement in https://man7.org/linux/man-pages/man3/ptsname_r.3.html that an error number should be returned on failure. (That

Re: ptsname_r

; should we be sticking that in a thread-local buffer rather >>>> than in static storage, similar to how other functions like strerror() >>>> are thread-safe? >> >>I didn't tackle that, >> >>> >>> Also, should we have an efault handler

Re: ptsname_r

static storage, similar to how other functions like strerror() >>> are thread-safe? > >I didn't tackle that, > >> >> Also, should we have an efault handler in syscalls.cc ptsname_r(), >> similar to ttyname_r(), so as to gracefully reject invalid buffers >>

Re: ptsname_r

that, Also, should we have an efault handler in syscalls.cc ptsname_r(), similar to ttyname_r(), so as to gracefully reject invalid buffers rather than faulting? but I had this additional code in my sandbox right before your commit hit CVS; should I add a ChangeLog and make it a formal