From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11015 Path: news.gmane.org!.POSTED!not-for-mail From: "A. Wilcox" Newsgroups: gmane.linux.lib.musl.general Subject: Re: The Great Big POSIX Conformance Thread [phase 1] Date: Sun, 5 Feb 2017 18:26:55 -0600 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <5897C2CF.1060104@adelielinux.org> References: <5897AF8B.9020208@adelielinux.org> <20170206000100.GX1533@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="57JqiLQF5Rvll6DwJk8seljPbXtQE4OTs" X-Trace: blaine.gmane.org 1486340834 3945 195.159.176.226 (6 Feb 2017 00:27:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 00:27:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 To: musl@lists.openwall.com Original-X-From: musl-return-11030-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 06 01:27:09 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 1caX9B-0000nY-BE for gllmg-musl@m.gmane.org; Mon, 06 Feb 2017 01:27:09 +0100 Original-Received: (qmail 2028 invoked by uid 550); 6 Feb 2017 00:27:12 -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 2004 invoked from network); 6 Feb 2017 00:27:12 -0000 X-Enigmail-Draft-Status: N1110 In-Reply-To: <20170206000100.GX1533@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11015 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --57JqiLQF5Rvll6DwJk8seljPbXtQE4OTs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/02/17 18:01, Rich Felker wrote: > On Sun, Feb 05, 2017 at 05:04:43PM -0600, A. Wilcox wrote: >> catopen ------- >>=20 >> 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. >=20 > 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. Sounds good to me. >> getservbyport ------------- >>=20 >> 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. >>=20 >>=20 >> [1]:=20 >> https://code.foxkit.us/adelie/patches/raw/master/sys-libs/musl/musl-1.= 1.15-posix-getservbyport.patch > >>=20 > This patch probably needs to be checked better still. Knowing the=20 > 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. getservbyport_r is not specified in POSIX. The problem is that musl uses getnameinfo which returns the number if nothing matches. getservbyport is specifically supposed to return NULL if nothing matches. Since getservbyport calls into getservbyport_r, I was able to fix its behaviour in addition to getservbyport with the single patch. >> if_nameindex ------------ >>=20 >> 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]. >>=20 >>=20 >> [2]: >> https://code.foxkit.us/adelie/musl-posix/tree/master/if_nameindex >> >>=20 [3]: >> https://code.foxkit.us/adelie/patches/raw/master/sys-libs/musl/musl-1.= 1.15-if_nameindex-errno.patch > >>=20 > 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. You are indeed correct; this could still be an effort to be cleaner with errno. If you do not want the patch, it should be fine. >> pathconf -------- >>=20 >> This function does not provide a reference for timestamp >> resolution. See the POSIX reference[4] for more information. >> This should be easy to fix. >>=20 >>=20 >> [4]:=20 >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html= #tag_13_77_03_03 > >>=20 > If the following symbolic constants are defined in the =20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ header, they apply > to files and all paths in all file systems on the implementation: >=20 > 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? I do not know the correct way to compute it and I will do further investigation. It is not legal to omit it[1]. [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/pathconf.html >> confstr ------- >>=20 >> musl returns the empty string ("") for options where it does not >> have any values. >>=20 >> 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. >>=20 >>=20 >> [5]:=20 >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/confstr.html= > >>=20 > 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). I do not believe musl should define _CS_POSIX_V7_WIDTH_RESTRICTED_ENVS. musl sysconf.c: [_SC_V7_ILP32_OFF32] =3D -1, means these should be NULL: _CS_POSIX_V7_ILP32_OFF32_CFLAGS _CS_POSIX_V7_ILP32_OFF32_LDFLAGS _CS_POSIX_V7_ILP32_OFF32_LIBS musl sysconf.c: [_SC_V7_LPBIG_OFFBIG] =3D -1, means these should be NULL: _CS_POSIX_V7_LPBIG_OFFBIG_CFLAGS _CS_POSIX_V7_LPBIG_OFFBIG_LDFLAGS _CS_POSIX_V7_LPBIG_OFFBIG_LIBS >> getlogin -------- >>=20 >> musl simply returns getenv("LOGNAME"). getlogin(3) is used to=20 >> 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: >=20 > What do you expect, vs what happens, in the case of su/sudo? sudo -i and su -/-l both set LOGNAME. That means running 'logname' that uses getlogin(3) on musl fails to return the correct value. >=20 >> ``` awilcox on ciall ~ $ su Password: ciall ~ # >> LOGNAME=3Dhelloworld logname helloworld ``` >>=20 >> The correct behaviour is shown here on glibc: >>=20 >> ``` awilcox on ciall [pts/16 Sun 5 16:51] ~: su Password: ciall >> awilcox # LOGNAME=3Dhelloworld logname awilcox ``` >>=20 >> The POSIX standard states that implementations generally check >> the terminal of fds 0/1/2, then fall back to /dev/tty.[6] >>=20 >>=20 >> [6]:=20 >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getlogin.htm= l > >>=20 > 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). Good to hear. >> Discussion required =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>=20 >> getdate ------- >>=20 >> 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]. >>=20 >> 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 =3D 5; else getdate_err =3D 7; could >> suffice, IMO. However, it would be nice to see better, more >> robust error handling for condition 8 as well. >>=20 >>=20 >> [7]: >> http://git.musl-libc.org/cgit/musl/tree/src/time/getdate.c#n32=20 >> [8]:=20 >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getdate.html= > >>=20 > 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. When I send the timestamp resolution patch I can send this too if you like. >=20 > Rich >=20 Best, --arw --=20 A. Wilcox (awilfox) Project Lead, Ad=C3=A9lie Linux http://adelielinux.org --57JqiLQF5Rvll6DwJk8seljPbXtQE4OTs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYl8LPAAoJEMspy1GSK50U2ekP/2JVd28I+Q5gp0UWePwMsmOF TpROdYJU1H8w2OS21rSy5Zb1nfawvN26KSFihZthspyLRfOdjfVTPl3kapLVqWru qsqpJ2zz5IgRVwOHPHYxioxUtuzZliEo6F5aLUPMhVoaHdozpXF9arCgcK5Mmb/J eiWZyb1xHar97sNgYO1LEWTmStGTsh3mXWLu/YPklgZuQxnP32INPHVMVAxjfO8w 1sw9U5Xg8UNVmL1wXmHT/hN5mC489AQIZZH1pzLLUTmB3iEUNkrWMoFHS0LrIG/H 60Ml8FAIECC1hRZZfLwEwR/fNWRTovAFZOsi0LIF36ZltRs2PEhwvdSaeRNGr6dy dw30nKXYkpBeYnDl+xFGZt0bTavwD4rUpqPGpk7AP27llPrEjB5Lto+Fz3oZtekt 4YjIIFmOsegOIr3/7I1PhJ3gZWqDbXP67/JJAbU9jUu6T7CjTPIHXlhOcIIJmj/F 22OLo5vmJi3Mt1EcfGsB8vQD6jS/xMPlJJ6erDUqSRNVWcMRIQs7mogAH0bBnXa3 njzSv8V9jO1RnAZK8vPv0kFmjIV+TfleRXQJeaoyUo17CZE5eK7lzB5UbRMy/M27 DfE03Oi5zV1gLszBemwR1yaJbGPJMkmdaacch/De9fJKKq2Ns3nSnlwj35CnqBir fmWipJFgIpIGkh0bsC51 =ZQ4Q -----END PGP SIGNATURE----- --57JqiLQF5Rvll6DwJk8seljPbXtQE4OTs--