[SCM] strace branch, master, updated. v4.6-207-g3449ae8
Dmitry V. Levin
ldv at altlinux.org
Mon Jan 30 14:10:21 UTC 2012
On Sun, Jan 29, 2012 at 09:26:26PM +0100, Denys Vlasenko wrote:
> On 01/28/2012 01:38 AM, Dmitry V. Levin wrote:
> > On Fri, Jan 27, 2012 at 04:27:32PM +0000, Denys Vlasenko wrote:
> > [...]
> >> commit 3449ae83c26d159dddc8573dc22b867feb0f49c6
> >> Author: Denys Vlasenko<vda.linux at googlemail.com>
> >> Date: Fri Jan 27 17:24:26 2012 +0100
> >>
> >> Fix readlink result display - was printing bogus "..." semi-randomly
> >>
> >> * file.c (decode_readlink): Use printstr() instead of printpathn().
> >
> > Another difference between printstr() and printpathn() is that printstr's
> > output is limited to the maximum string size limit specified by -s option
> > (the default is 32). If readlink's result should be considered the same
> > way as file names, then it shouldn't be subject to this limit.
>
> One possible way to achieve this is to add a flag variable to printpathn()
> which would prevent "..." from printing even if NUL is not found.
>
> Do you want this fix?
> Have better idea?
The value returned by readlink(2) is arbitrary string. It may be a file
name, and it may be not. I'm aware of a system where symlinks are used
as a configuration storage with very fast access mechanism: only one
syscall is necessary to fetch the value of one configuration parameter.
That is, I'm inclined to treat readlink result as an arbitrary string
rather than a file name.
So, while the change in behaviour might be an unintentional one, on second
thought it seems to be desirable.
--
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20120130/f771e788/attachment.bin>
More information about the Strace-devel
mailing list