From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11014 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: The Great Big POSIX Conformance Thread [phase 1] Date: Sun, 5 Feb 2017 19:01:00 -0500 Message-ID: <20170206000100.GX1533@brightrain.aerifal.cx> References: <5897AF8B.9020208@adelielinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1486339274 30019 195.159.176.226 (6 Feb 2017 00:01:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 00:01:14 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11029-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 06 01:01:10 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1caWk1-0007dS-JM for gllmg-musl@m.gmane.org; Mon, 06 Feb 2017 01:01:09 +0100 Original-Received: (qmail 17521 invoked by uid 550); 6 Feb 2017 00:01:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17503 invoked from network); 6 Feb 2017 00:01:12 -0000 Content-Disposition: inline In-Reply-To: <5897AF8B.9020208@adelielinux.org> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11014 Archived-At: On Sun, Feb 05, 2017 at 05:04:43PM -0600, A. Wilcox wrote: > Hello fellow muslers, > > I have been reading through the source tree of musl for two reasons. > One is to familiarise myself with the codebase more so that I can be > of better use if/when patches need to be written. The other is doing > a cursory audit of POSIX conformance per XSH 2008 (2016 ed.); we at > Adélie are in the beginning stages of acquiring a license to the > VSX-PCTS2016 test suite (which would be phase 2) and I thought it'd be > prudent to find any obvious errors before obtaining it. > > I have found some non-conformant functions through my audit. Four are > (hopefully) easy to fix; two require more thought; and one will likely > need to be discussed. > > > > Easy fixes > ========== > > catopen > ------- > > This function is not implemented, and always fails. This is [barely] > legal in POSIX, but the failure must set errno. None of the errors > are very appropriate (unfortunately ENOSYS is invalid); maybe ENOMEM > will work. For any interface that has standard errors, additional errors are also valid as long as they don't overlap one of the standard error codes for the interface. As such, it would not be appropriate to use ENOMEM. EOPNOTSUPP might be appropriate. Eventually this should be fixed with a non-stub implementation. > getservbyport > ------------- > > Non-conformance of this function was discussed on IRC. Rich Felker > had said he would apply the patch I wrote[1], but it has not been > applied yet. If there is an issue with said patch, please let me know > so that I may fix it. > > > [1]: > https://code.foxkit.us/adelie/patches/raw/master/sys-libs/musl/musl-1.1.15-posix-getservbyport.patch This patch probably needs to be checked better still. Knowing the legaycy get*by*_r interfaces, I suspect it's invalid to return without setting *res to something. Also it might be better to just check earlier (at the top) if the argument parses as a number, and bail immediately, rather than first doing all the work then throwing the result away. > if_nameindex > ------------ > > This function always sets errno to ENOBUFS, even when the function > completes succesfully. A full test case is available[2], and a > suggested patch is also available[3]. > > > [2]: https://code.foxkit.us/adelie/musl-posix/tree/master/if_nameindex > [3]: > https://code.foxkit.us/adelie/patches/raw/master/sys-libs/musl/musl-1.1.15-if_nameindex-errno.patch There's nothing wrong about this. Any interface that's not explicitly documented to preserve errno on success (only a few of these exist) is free to clobber it with any nonzero value. > pathconf > -------- > > This function does not provide a reference for timestamp resolution. > See the POSIX reference[4] for more information. This should be easy > to fix. > > > [4]: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html#tag_13_77_03_03 If the following symbolic constants are defined in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ header, they apply to files and all paths in all file systems on the implementation: I suspect it's intentionaly omitted because the resolution may vary by pathname. Are you saying we should support _POSIX_TIMESTAMP_RESOLUTION to get a per-pathname result? Do you know the correct way to compute it? > Further thought required > ======================== > > confstr > ------- > > musl returns the empty string ("") for options where it does not have > any values. > > The POSIX standard states[5] that if an option is > recognised but does not have a value, errno should not be set and NULL > should be returned. > > > [5]: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html Can you clarify which _CS_* values you're saying it doesn't have any values for? For many of them (all that make sense but _CS_PATH) it does have a value, the empty string. It looks like you might be right that some of them are non-supported options and should return a null pointer and leave errno unchanged (this is one of the few functions explicitly documented not to change errno in that case). > getlogin > -------- > > musl simply returns getenv("LOGNAME"). getlogin(3) is used to > determine the login name of the controlling terminal for the process. > In addition to getenv("LOGNAME") being improper behaviour (since > getlogin(3) could be used within a su or sudo-run shell), it also > causes both coreutils and busybox logname(1) to break conformance: What do you expect, vs what happens, in the case of su/sudo? > ``` > awilcox on ciall ~ $ su > Password: > ciall ~ # LOGNAME=helloworld logname > helloworld > ``` > > The correct behaviour is shown here on glibc: > > ``` > awilcox on ciall [pts/16 Sun 5 16:51] ~: su > Password: > ciall awilcox # LOGNAME=helloworld logname > awilcox > ``` > > The POSIX standard states that implementations generally check the > terminal of fds 0/1/2, then fall back to /dev/tty.[6] > > > [6]: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getlogin.html This one has been discussed and I have a mostly-done proposed function that can determine the owner of the controlling tty (dependent of course on /proc). > Discussion required > =================== > > getdate > ------- > > The musl implementation of getdate(3)[7] sets getdate_err to 7 for any > of the reasons that it should set to 5 (I/O error while reading > template file - i.e., fgets fails), 7 (there is no line in the > template that matches the input), or 8 (invalid input specification)[8]. > > While I realise musl will probably never implement all conditions that > could provide error condition 8, I feel that error condition 5 should > at least be implemented. Something as simple as if (ferror(f)) > getdate_err = 5; else getdate_err = 7; could suffice, IMO. However, > it would be nice to see better, more robust error handling for > condition 8 as well. > > > [7]: http://git.musl-libc.org/cgit/musl/tree/src/time/getdate.c#n32 > [8]: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getdate.html This all seems reasonable. I think error 8 really only makes sense for implementations that go through an intermediate time_t as part of the processing. Otherwise there is no way to ascertain whether an input specification is valid without having it match one of the formats. Rich