[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