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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
