mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: futimens on musl libc (fwd)
Date: Sun, 24 Mar 2019 19:42:55 +0100	[thread overview]
Message-ID: <20190324184255.GA18043@voyager> (raw)
In-Reply-To: <20190324142118.GS23599@brightrain.aerifal.cx>

On Sun, Mar 24, 2019 at 10:21:18AM -0400, Rich Felker wrote:
> I think this needs action but I'm not clear what the exact mechanism
> is yet, so I'm forwarding to the list.
>
> ----- Forwarded message from Bruno Haible <bruno@clisp.org> -----
>
> From: Bruno Haible <bruno@clisp.org>
> To: bug-gnulib@gnu.org, Rich Felker <dalias@libc.org>
> Subject: futimens on musl libc
> Date: Sat, 23 Mar 2019 21:40:33 +0100
> Message-ID: <4061903.SY8uJAIc8I@omega>
>
> The gnulib configure test in m4/futimens.m4, when run on Alpine Linux 3.7,
> determines that the errno value is not as expected for a wrong fd.
>
> Let me document this in gnulib and update the cross-compilation guess
> accordingly.
>
> Rich, FYI: The test program is this one:
>
> #include <fcntl.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <time.h>
> #include <errno.h>
> int main ()
> {
>       struct timespec ts[2];
>       int fd = creat ("conftest.file", 0600);
>       struct stat st;
>       if (fd < 0) return 1;
>       ts[0].tv_sec = 1;
>       ts[0].tv_nsec = UTIME_OMIT;
>       ts[1].tv_sec = 1;
>       ts[1].tv_nsec = UTIME_NOW;
>       errno = 0;
>       if (futimens (AT_FDCWD, NULL) == 0) return 2;
>       if (errno != EBADF) return 3;     /* <== It fails here */

Ah! There are multiple errors present in the call, but gnulib expects a
certain one of these to be returned.

futimens() should return EBADF for invalid FD, and EFAULT for invalid
buffer address (second argument, according to manpage). However, musl
implements futimens in terms of utimensat(), which just wraps a syscall
of the same name on recent kernels (i.e. there's an optional fallback
there that won't be used if the error from the first try isn't ENOSYS).

According to the manpage, utimensat() returns EFAULT for invalid buffer
address, and if the fd happens to be AT_FDCWD, but the path name is NULL
(which it is when the call comes in from futimens()).

POSIX is also rather clear on the matter:
|The futimens() function shall fail if:
|
|[EBADF]
|    The fd argument is not a valid file descriptor.

If the test program were patched to provide a propper buffer to
futimens(), musl's implementation would still return EFAULT instead of
the required EBADF. We might have to test for AT_FDCWD in futimens(),
before passing it on to utimensat(). Are there other special FDs we have
to consider?

Ciao,
Markus


      reply	other threads:[~2019-03-24 18:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-24 14:21 Rich Felker
2019-03-24 18:42 ` Markus Wichmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190324184255.GA18043@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).