I can think of two ways to think about the purpose of this test:
1. distinguish stack overflow from an access to an invalid address
("programm error")
2. distinguish stack overflow from other cases when SIGSEGV is sent
Under view 2, then the access to an invalid address is just an
implementation
The "symlink ownership not supported" condition is expected to be
indicated by EOPNOTSUPP, as opposed to the "no support for ownership",
which is indicated by ENOSYS.
The latter condition is checked for earlier in this test on a
directory (rather than on a symlink). And if ENOSYS is raised for a
s
his on the various platforms. As
> pointed out above, various errno values should be acceptable.
>
> I've pushed this instead:
I have no objections. Thank you!
> 2018-12-19 Bruno Haible
>
> lchown tests: Be more permissive regarding errno values.
> Report
er to the old code in the involved
operations, and who knows, there might be some architecture where one
needs to read to cause a fault.)
--
Best regards,
IvanFrom 057259bd81fbb60233df00d0a2846304088e1d47 Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev
Date: Fri, 28 Dec 2018 17:03:18 +0300
Subject: [P
Hi Bruno,
On Sat, 29 Dec 2018, Bruno Haible wrote:
> > "system in development" is the one which suits
> > Linux/E2k better. The port to E2K (MCST Elbrus general purpose hardware
> > architecture) is quite mature, but not yet released publicly.
>
> Thanks for the info. Based on it, I found a co
Hi,
On Sat, 29 Dec 2018, Dmitry V. Levin wrote:
> On Fri, Dec 28, 2018 at 05:23:09PM +0300, Ivan Zakharyaschev wrote:
> > As for the SIGILL peculiarity, it has a reason in the Elbrus architecture.
> No, this particular case (++*argv[argc]) has nothing to do with tagged memory,
&
.
On Sat, 29 Dec 2018, Ivan Zakharyaschev wrote:
> > > As for the SIGILL peculiarity, it has a reason in the Elbrus
> > > architecture.
> I've studied the assembler code and found the other true
> reason in this specific case: these are faults "hidden
