This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc v2][4/6] Readlink as file I/O target operation
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: eliz at gnu dot org
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 16 Jan 2012 13:32:23 +0100 (CET)
- Subject: Re: [rfc v2][4/6] Readlink as file I/O target operation
Eli Zaretskii wrote:
> > Date: Fri, 13 Jan 2012 19:15:12 +0100 (CET)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > @@ -36193,6 +36197,16 @@ error occurred.
> > Delete the file at @var{pathname} on the target. Return 0,
> > or -1 if an error occurs. @var{pathname} is a string.
> >
> > +@item vFile:readlink: @var{pathname}
> > +Read value of symbolic link @var{pathname} on the target. Return
> > +the number of bytes read, or -1 if an error occurs.
>
> This part is okay, but please don't use "pathname" when you really
> mean "file name". GNU Coding Standards frown on using "path" or its
> derivatives for anything but PATH-style directory lists.
I'll be happy to use "filename" instead, but the currently existing
packets (open, unlink) also use "pathname" today. Should those be
changed to "filename" too?
(B.t.w. note that those packets are directly related to the corresponding
POSIX routines open/unlink/readlink -- the documentation of those routines,
whether in POSIX itself or in the corresponding Linux man pages consistently
refers to those arguments as "path" or "pathname" ... I'm wondering whether
it is a deliberate decision on the part of the GNU Coding Standards to deviate
from established terminology in that area?)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com