Re: Linux 2.1.125 doesn't dump core on SIGSEGV

Ken Pizzini (ken@halcyon.com)
Fri, 13 Nov 1998 09:23:48 -0800


> > (bit patterns made up for example purposes):
> > #define O_CREAT 0x50
> > #define O_EXCL 0xa0
> > #define O_NOFOLLOW 0xc0
> >
> > Then we get (O_CREAT|O_EXCL) == (O_CREAT|O_EXCL|O_NOFOLLOW),
> > but we can detect that none of O_CREAT, O_EXCL, ((O_CREAT|O_EXCL)&~O_NOFOLLOW)
> > match (x&O_NOFOLLOW)==O_NOFOLLOW.
> >
> > Would this be an acceptable solution?
>
> No, because open(..,O_RDWR|O_NOFOLLOW) won't work as expected then.

Why not? The O_NOFOLLOW is distinguishable, so NOFOLLOW semantics
would be enabled, and RDWR is distinguishable, so RDWR mode would
be enabled.

> For now, I think things should stay as they are... people have
> pointed out examples of thing that will go bad and have horribly
> failure modes if its changed - something that won't help linux's
> reputation.

It depends on how the change is made, and what flavor of compatability
one is worried about. For binary compatability, I can see that this
would be a problem, especially if we are unwilling to add new flavors
of open and fcntl to further this minor cause. But if we are allowed
to change the bits chosen for O_CREAT, O_EXCL, and O_NOFOLLOW, I still
think that my suggestion should work fine at the source compatability
level.

> I think this thread should be left to die now...
If the argument is that we must remain binary compatable and without
new versions of the open and fcntl system calls, then I guess I'll
drop the subject. Otherwise I still think that there is room for
discussion.

--Ken Pizzini

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/