From: Ulrich Drepper on
On Fri, Mar 26, 2010 at 14:06, Luca Barbieri <luca.barbieri(a)gmail.com> wrote:
>>> None of these perfectly fit, but EINVAL seems the closest.
>>
>> No.  ENOENT is the right value.
>
> Not according to POSIX 2008, which does not explicitly specify this case.

That argumentation is bogus. You wrote yourself, this situation isn't
(and cannot) be described in POSIX. For such cases the any error
value is consistent with POSIX.


Again: any value is as good as any other. The existing value works
and changing it breaks existing code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Olaf van der Spek on
On Fri, Mar 26, 2010 at 10:15 PM, Ulrich Drepper <drepper(a)gmail.com> wrote:
>> Not according to POSIX 2008, which does not explicitly specify this case.
>
> That argumentation is bogus.  You wrote yourself, this situation isn't
> (and cannot) be described in POSIX.  For such cases the any error
> value is consistent with POSIX.
>
>
> Again: any value is as good as any other.  The existing value works
> and changing it breaks existing code.

It didn't 'work' for me.
What code would break?

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ulrich Drepper on
On Sat, Mar 27, 2010 at 04:50, Olaf van der Spek <olafvdspek(a)gmail.com> wrote:
> It didn't 'work' for me.

You still don't get it? No shell provides you with a correct error
message. There is quite some work involved (reading program header,
finding the interpreter entry, checking the file) to give a meaningful
error message. Changing the error code alone achieves nothing.


> What code would break?

At the very least the shells in Red Hat releases for many years.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Luca Barbieri on
> That argumentation is bogus. �You wrote yourself, this situation isn't
> (and cannot) be described in POSIX. �For such cases the any error
> value is consistent with POSIX.

Sure, but that means POSIX also does not forbid changing it.

> Again: any value is as good as any other. �The existing value works
> and changing it breaks existing code.

Yes, this is an argument in favor of leaving it as is.

> Changing the error code alone achieves nothing.

If you were to change it to a new error value, such that
strerror(errno) == "unable to open ELF interpreter" (or similar), that
would just work.

The problem is that would only work after upgrading glibc, and would
probably break the error reporting code in RH shells if only the
kernel is upgraded.

A possibly better option is to add the ability to the kernel to report
extended error strings (was proposed some time ago), and use that.

It's a small issue, but I recently stumbled on it when running an x86
binary on an x86-64 machine lacking the compat libraries, and it's
quite suprising at first to have the shell claim the file does not
exist when it clearly does (and would be even more so for people who
don't know anything about executables or ELF).

The idea of parsing the ELF file in the shell seems quite ugly, since
you need to add a non-trivial piece of code at least to all shells and
all graphical file managers.
glibc itself could conceivably provide functions to do that
(strerror_for_exec* or exec*_with_extended_error ?).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Olaf van der Spek on
On Sat, Mar 27, 2010 at 1:05 PM, Ulrich Drepper <drepper(a)gmail.com> wrote:
> On Sat, Mar 27, 2010 at 04:50, Olaf van der Spek <olafvdspek(a)gmail.com> wrote:
>> It didn't 'work' for me.
>
> You still don't get it?  No shell provides you with a correct error
> message.  There is quite some work involved (reading program header,
> finding the interpreter entry, checking the file) to give a meaningful
> error message.  Changing the error code alone achieves nothing.

File not found is a very common error message with a pretty will
understood meaning. Overloading it in this way causes confusion.
Overloading another error code would avoid this confusion, especially
since it's far less used.

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/