POSIXfy readlink() call
John Baldwin
jhb at freebsd.org
Mon May 11 22:14:26 UTC 2009
On Monday 11 May 2009 2:58:14 pm Kostik Belousov wrote:
> On Mon, May 11, 2009 at 02:46:14PM -0400, John Baldwin wrote:
> > On Monday 11 May 2009 2:33:09 pm Kostik Belousov wrote:
> > > On Mon, May 11, 2009 at 02:05:07PM -0400, John Baldwin wrote:
> > > > On Friday 28 September 2007 10:39:56 pm Ighighi wrote:
> > > ^^^^^
> >
> > Yes, I had this stuck in the back of my head from when it first appeared.
> >
> > > > > The POXIX prototype for readlink(2) is:
> > > > > ssize_t readlink(const char *restrict path, char *restrict buf,
size_t
> > > > > bufsize);
> > > >
> > > > It can't simply be corrected as it would change the ABI and thus
requires
> > a
> > > > new system call, etc. However, do you really expect a symlink to be
> > longer
> > > > than 2^31 on a 64-bit machine?
> > >
> > > Yes, I agree that this is ABI change.
> > >
> > > Meantime,
> > > r176215 | ru | 2008-02-12 22:09:04 +0200 (Tue, 12 Feb 2008) | 5 lines
> > >
> > > Change readlink(2)'s return type and type of the last argument
> > > to match POSIX.
> > >
> > > Prodded by: Alexey Lyashkov
> > >
> > > I tried to convince ru@ that ABI breakage is not good, but has not
> > > succeeded.
> >
> > Ugh, is this only in HEAD? If so, I will back it out for 8.0. If this
made
> > it into a release then this is a far bigger mess. Oh, good, this is only
in
> > 8. I will fix this ASAP. I can just add the new syscall I guess.
>
> You need to symver the syscalls. It requires some ugly games with our
> syscall stubs, because gnu ld only honor .symver in the same object where
> the symbol is defined. I did prototyped this some time ago, by including
> a file with appropriate .symver from all stubs.
So, after thinking about this out loud some more, it seems the ABI breakage
would only be for 64-bit platforms that passed a -ve value as the buffer
size. However, doing so would already either panic due to triggering an
assertion, or result in otherwise undefined behavior and that making the new
parameter unsigned actually results in the same undefined behavior in the
non-panic case.
--
John Baldwin
More information about the freebsd-hackers
mailing list