On Mon, May 11, 2009 at 04:23:52PM -0400, John Baldwin wrote: > 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. > For the record. I also suggest (re-)reading a thread
http://lists.freebsd.org/pipermail/freebsd-current/2008-February/thread.html#83314 that resulted from the original commit where I try to make it clear that a scary ABI breakage Konstantin mentions is pure artificial. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer _______________________________________________ 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"