Re: work in progress: [PATCH 0/2+] open_memstream

[Eric Wong]

Eric Blake  wrote:
> The libvirt project would be very interested in using open_memstream,
> since it is now part of POSIX 2008.

Hi, I realize this thread for open_memstream support in gnulib is now
several years old.  Just wondering why it was never completed/merged
into gnulib...

I assume it's too much time/effort to get working on some platforms; and
perhaps not worth it.  It'd be nice to have, but I can live without it,
too: tmpfile()+rewind()+fread() seems good enough for the few *BSD users
I support.

Re: work in progress: [PATCH 0/2+] open_memstream

[Eric Blake]

On 02/07/2013 02:54 AM, Eric Wong wrote:
> Eric Blake  wrote:
>> The libvirt project would be very interested in using open_memstream,
>> since it is now part of POSIX 2008.
> 
> Hi, I realize this thread for open_memstream support in gnulib is now
> several years old.  Just wondering why it was never completed/merged
> into gnulib...

Mainly because it turned out to be very difficult to hook enough of
stdio in a reasonable manner in order to ensure that things work, and
libvirt in the meantime has managed to cope without open_memstream.
It's one of those projects that therefore sunk lower on my to-do list,
with it no longer being one of my itches.

> 
> I assume it's too much time/effort to get working on some platforms; and
> perhaps not worth it.  It'd be nice to have, but I can live without it,
> too: tmpfile()+rewind()+fread() seems good enough for the few *BSD users
> I support.

open_memstream still sounds like a nice project for anyone interested in
implementing, though.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: PATCH: numerous warnings from gnulib header files.

[Eric Blake]

On 02/06/2013 11:14 PM, Paul Eggert wrote:
> In 
> on 02/06/2013 12:13 AM, John Darrington wrote:
> 
>> ./SOURCE/gl/xalloc.h:176: error: no previous prototype for 'x2nrealloc'
> 
> I looked into this, and apparently it's a bug in GCC 4.4.5.
> The bug causes GCC to generate a bogus warning if one
> compiles with '-Wmissing-prototypes' and if a program
> contains an inline function that is not static.
> 
> Gnulib's general rule is to cater to GCC non-default compiler warnings
> only for the latest stable version of GCC, since older GCCs are
> fairly buggy in this area, and it's too much hassle to try
> to pacify them all.

Indeed, at least libvirt and coreutils are both using conditional
warnings, where certain warnings are only turned on for new-enough gcc.
 Maybe I should revisit the manywarnings module to hoist that logic up
into gnulib, instead of making each downstream project reinvent it.  The
question has come up in the past, though:
https://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg6.html

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Roland McGrath]

The substance of the change seems fine.  It needs a proper ChangeLog entry.
See the glibc wiki for full instructions on posting patches.

> +  struct stat64 st;
> +  int r = fd >= 0 ? fstat64(fd, &st) : stat64(name, &st);

Put space before paren in those calls.
It's shorter and more common to invert the sense and use < 0.

> +  if (r == -1)
>  return 0;

There is no need for a variable here.
Also, it's more usual to test for failure with < 0:

if ((fd < 0 ? stat64 (name, &st) : fstat64 (fd, &st)) < 0)
  return 0;


Thanks,
Roland

Re: work in progress: [PATCH 0/2+] open_memstream

[Eric Wong]

Eric Blake  wrote:
> open_memstream still sounds like a nice project for anyone interested in
> implementing, though.

Thanks for the reply, I've also been able to cope without it.
Hopefully somebody has spare cycles pick this up (or more platforms can
just support it natively).

Re: secure_getenv is broken on FreeBSD.

[Mats Erik Andersson]

onsdag den  6 februari 2013 klockan 22:31 skrev Paul Eggert detta:
> On 02/06/2013 05:10 PM, Mats Erik Andersson wrote:
> > Does not suffice! Same error as before
> 
> I assume you tried it by hand?

Yes. Checking the sequence once more:

  * Inetutils with gnulib-7517e2 builds on FreeBSD-9.0
since "secure_getopt" is not used.

  * Inetutils with gnulib-f65962 is broken on FreeBSD-9.0
since "tempname" is making "secure_getenv" mandatory,
against my will!

  * Cherrypicking the __need_getopt fix, removes the error

  ./getopt.h:199: error: redefinition of 'struct option'.

However, the two more serious errors

  In file included from ./stdlib.h:96,
   from secure_getenv.c:18:
  ./unistd.h:548: error: expected '=', ',', ';', 'asm' or
  '__attribute__' before 'extern'
  ./stdlib.h:607: error: expected '=', ',', ';', 'asm' or
  '__attribute__' before 'extern'

which appeared with gnulib-f65962 are still present,
and they prevent any progress.

> > a sed-scissor reveals
> > that "lib/unistd.h" and "lib/stdlib.h" both stumble into problems
> > when evaluating _GL_CXXALIAS_SYS.
> 
> That sounds like a different issue, which would presumably neeed
> a different patch.

Question: How do I test whether _GL_CXXALIAS_SYS is intelligibly
expanded? The build system stands in my way, making the preprocessed
intermediaries inaccessible. The two abortive errors are pointing
in this direction, though.

Regards,
  Mats Erik Andersson

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Eric Wong]

Roland McGrath  wrote:
> The substance of the change seems fine.  It needs a proper ChangeLog entry.
> See the glibc wiki for full instructions on posting patches.
> 
> > +  struct stat64 st;
> > +  int r = fd >= 0 ? fstat64(fd, &st) : stat64(name, &st);
> 
> Put space before paren in those calls.
> It's shorter and more common to invert the sense and use < 0.
> 
> > +  if (r == -1)
> >  return 0;
> 
> There is no need for a variable here.
> Also, it's more usual to test for failure with < 0:
> 
>   if ((fd < 0 ? stat64 (name, &st) : fstat64 (fd, &st)) < 0)
> return 0;

Thanks for the comments, here is an updated patch with your suggestions
and ChangeLog entry:

--- 8< 
>From ed01f553461357e6c9ef40efd2910d897d72ddea Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Fri, 1 Feb 2013 01:55:27 +
Subject: [PATCH] avoid stat/fstat in statvfs/fstatvfs

Delay the use of stat/fstat until stat data is required.
When the kernel returns ST_VALID, stat data is not used
by __internal_statvfs.

2013-02-07  Eric Wong  

* sysdeps/unix/sysv/linux/internal_statvfs.c (__statvfs_getflags):
Call fstat64 or stat64 internally, depending on arguments passed.
Replace stat buffer argument with file descriptor argument,
update all callers.

diff --git a/sysdeps/unix/sysv/linux/fstatvfs.c 
b/sysdeps/unix/sysv/linux/fstatvfs.c
index 8f08d14..6a03a87 100644
--- a/sysdeps/unix/sysv/linux/fstatvfs.c
+++ b/sysdeps/unix/sysv/linux/fstatvfs.c
@@ -22,7 +22,7 @@
 #include 
 
 extern void __internal_statvfs (const char *name, struct statvfs *buf,
-   struct statfs *fsbuf, struct stat64 *st);
+   struct statfs *fsbuf, int fd);
 
 
 int
@@ -36,7 +36,7 @@ fstatvfs (int fd, struct statvfs *buf)
 return -1;
 
   /* Convert the result.  */
-  __internal_statvfs (NULL, buf, &fsbuf, fstat64 (fd, &st) == -1 ? NULL : &st);
+  __internal_statvfs (NULL, buf, &fsbuf, fd);
 
   /* We signal success if the statfs call succeeded.  */
   return 0;
diff --git a/sysdeps/unix/sysv/linux/fstatvfs64.c 
b/sysdeps/unix/sysv/linux/fstatvfs64.c
index 2dcef94..3b49ab2 100644
--- a/sysdeps/unix/sysv/linux/fstatvfs64.c
+++ b/sysdeps/unix/sysv/linux/fstatvfs64.c
@@ -25,7 +25,7 @@
 
 
 extern void __internal_statvfs64 (const char *name, struct statvfs64 *buf,
- struct statfs64 *fsbuf, struct stat64 *st);
+ struct statfs64 *fsbuf, int fd);
 
 
 /* Return information about the filesystem on which FD resides.  */
@@ -60,12 +60,8 @@ __fstatvfs64 (int fd, struct statvfs64 *buf)
 #endif
 
   if (res == 0)
-{
-  /* Convert the result.  */
-  struct stat64 st;
-  __internal_statvfs64 (NULL, buf, &fsbuf,
-   fstat64 (fd, &st) == -1 ? NULL : &st);
-}
+/* Convert the result.  */
+__internal_statvfs64 (NULL, buf, &fsbuf, fd);
 
   return res;
 }
diff --git a/sysdeps/unix/sysv/linux/internal_statvfs.c 
b/sysdeps/unix/sysv/linux/internal_statvfs.c
index 4cd4f04..1e1ad5f 100644
--- a/sysdeps/unix/sysv/linux/internal_statvfs.c
+++ b/sysdeps/unix/sysv/linux/internal_statvfs.c
@@ -43,9 +43,11 @@
 
 # ifndef __ASSUME_STATFS_F_FLAGS
 int
-__statvfs_getflags (const char *name, int fstype, struct stat64 *st)
+__statvfs_getflags (const char *name, int fstype, int fd)
 {
-  if (st == NULL)
+  struct stat64 st;
+
+  if ((fd < 0 ? stat64 (name, &st) : fstat64 (fd, &st)) < 0)
 return 0;
 
   const char *fsname = NULL;
@@ -153,7 +155,7 @@ __statvfs_getflags (const char *name, int fstype, struct 
stat64 *st)
  /* Find out about the device the current entry is for.  */
  struct stat64 fsst;
  if (stat64 (mntbuf.mnt_dir, &fsst) >= 0
- && st->st_dev == fsst.st_dev)
+ && st.st_dev == fsst.st_dev)
{
  /* Bingo, we found the entry for the device FD is on.
 Now interpret the option string.  */
@@ -216,14 +218,13 @@ __statvfs_getflags (const char *name, int fstype, struct 
stat64 *st)
 }
 # endif
 #else
-extern int __statvfs_getflags (const char *name, int fstype,
-  struct stat64 *st);
+extern int __statvfs_getflags (const char *name, int fstype, int fd);
 #endif
 
 
 void
 INTERNAL_STATVFS (const char *name, struct STATVFS *buf,
- struct STATFS *fsbuf, struct stat64 *st)
+ struct STATFS *fsbuf, int fd)
 {
   /* Now fill in the fields we have information for.  */
   buf->f_bsize = fsbuf->f_bsize;
@@ -266,7 +267,7 @@ INTERNAL_STATVFS (const char *name, struct STATVFS *buf,
the /etc/mtab file and search for the entry which matches the given
file.  The way we can test for matching filesystem is using the
device number.  */
-buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, st);
+buf->f_flag = __statvfs_getflags (name, fsbuf->f_type, fd);
   else
 #en

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Roland McGrath]

The patch itself now looks fine to me.  The log entry is inadequate.
It needs to mention each file and function touched and say what was
done there.  "Update caller." is sufficient text for a function to
which the only change was trivial argument reordering or whatnot.  But
in most of these cases, each caller dropped a stat* call as well and
so it needs to say "Pass it -1 instead of calling stat64." or suchlike.


Thanks,
Roland

Re: secure_getenv is broken on FreeBSD.

[Paul Eggert]

On 02/07/2013 02:28 PM, Mats Erik Andersson wrote:
>   * Inetutils with gnulib-f65962 is broken on FreeBSD-9.0
> since "tempname" is making "secure_getenv" mandatory,
> against my will!

Why against your will?  Isn't it better for tempname to avoid
insecure usage?  But I do see that we can do a better job of this
on FreeBSD, so I pushed the following further patch.  I'll try
to follow up on your other comments soon.

>From bac78fc4126870cfc6792048edf7f028d7700593 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 7 Feb 2013 15:34:23 -0800
Subject: [PATCH] secure_getenv: port better to FreeBSD and Solaris

* lib/secure_getenv.c [!HAVE___SECURE_GETENV]:
Include unistd.h if HAVE_ISSETUGID, otherwise define a dummy issetugid.
(secure_getenv) [!HAVE___SECURE_GETENV]: Use getenv if not issetugid.
This works better on BSDish platforms.
* m4/secure_getenv.m4 (gl_PREREQ_SECURE_GETENV):
Test for issetugid if __secure_getenv is missing.
---
 ChangeLog   | 10 ++
 lib/secure_getenv.c | 13 -
 m4/secure_getenv.m4 |  3 +++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index e3fb3bd..4dc8f2c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2013-02-07  Paul Eggert  
+
+   secure_getenv: port better to FreeBSD and Solaris
+   * lib/secure_getenv.c [!HAVE___SECURE_GETENV]:
+   Include unistd.h if HAVE_ISSETUGID, otherwise define a dummy issetugid.
+   (secure_getenv) [!HAVE___SECURE_GETENV]: Use getenv if not issetugid.
+   This works better on BSDish platforms.
+   * m4/secure_getenv.m4 (gl_PREREQ_SECURE_GETENV):
+   Test for issetugid if __secure_getenv is missing.
+
 2013-02-06  Paul Eggert  
 
extensions: port better to MINUX 3, HP-UX, autoheader 2.62
diff --git a/lib/secure_getenv.c b/lib/secure_getenv.c
index 0b91a99..2859522 100644
--- a/lib/secure_getenv.c
+++ b/lib/secure_getenv.c
@@ -17,12 +17,23 @@
 
 #include 
 
+#if !HAVE___SECURE_GETENV
+# if HAVE_ISSETUGID
+#  include 
+# else
+#  undef issetugid
+#  define issetugid() 1
+# endif
+#endif
+
 char *
 secure_getenv (char const *name)
 {
 #if HAVE___SECURE_GETENV
   return __secure_getenv (name);
 #else
-  return 0;
+  if (issetugid ())
+return 0;
+  return getenv (name);
 #endif
 }
diff --git a/m4/secure_getenv.m4 b/m4/secure_getenv.m4
index 1ab5b2d..5da5298 100644
--- a/m4/secure_getenv.m4
+++ b/m4/secure_getenv.m4
@@ -19,4 +19,7 @@ AC_DEFUN([gl_FUNC_SECURE_GETENV],
 # Prerequisites of lib/secure_getenv.c.
 AC_DEFUN([gl_PREREQ_SECURE_GETENV], [
   AC_CHECK_FUNCS([__secure_getenv])
+  if test $ac_cv_func___secure_getenv = no; then
+AC_CHECK_FUNCS([issetugid])
+  fi
 ])
-- 
1.7.11.7

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Eric Wong]

Roland McGrath  wrote:
> The patch itself now looks fine to me.  The log entry is inadequate.
> It needs to mention each file and function touched and say what was
> done there.  "Update caller." is sufficient text for a function to
> which the only change was trivial argument reordering or whatnot.  But
> in most of these cases, each caller dropped a stat* call as well and
> so it needs to say "Pass it -1 instead of calling stat64." or suchlike.

Sorry about that.  Here is an updated patch with ChangeLog.
--- 8< ---
>From 92f694865d0014bffd0069c549c4a6274e2f1430 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Fri, 1 Feb 2013 01:55:27 +
Subject: [PATCH] avoid stat/fstat in statvfs/fstatvfs

Delay the use of stat/fstat until stat data is required.
When the kernel returns ST_VALID, stat data is not used
by __internal_statvfs.

2013-02-08  Eric Wong  

* sysdeps/unix/sysv/linux/internal_statvfs.c (__statvfs_getflags):
Call fstat64 or stat64 internally, depending on arguments passed.
Replace stat buffer argument with file descriptor argument.
(INTERNAL_STATVFS): Update arguments to match __statvfs_getflags.
* sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
Pass fd to __internal_statvfs instead of calling fstat64.
* sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
Pass fd to __internal_statvfs64 instead of calling fstat64.
* sysdeps/unix/sysv/linux/statvfs.c (statvfs):
Pass -1 to __internal_statvfs instead of calling stat64.
* sysdeps/unix/sysv/linux/statvfs64.c (__statvfs64):
Pass -1 to __internal_statvfs64 instead of calling stat64.

diff --git a/sysdeps/unix/sysv/linux/fstatvfs.c 
b/sysdeps/unix/sysv/linux/fstatvfs.c
index 8f08d14..6a03a87 100644
--- a/sysdeps/unix/sysv/linux/fstatvfs.c
+++ b/sysdeps/unix/sysv/linux/fstatvfs.c
@@ -22,7 +22,7 @@
 #include 
 
 extern void __internal_statvfs (const char *name, struct statvfs *buf,
-   struct statfs *fsbuf, struct stat64 *st);
+   struct statfs *fsbuf, int fd);
 
 
 int
@@ -36,7 +36,7 @@ fstatvfs (int fd, struct statvfs *buf)
 return -1;
 
   /* Convert the result.  */
-  __internal_statvfs (NULL, buf, &fsbuf, fstat64 (fd, &st) == -1 ? NULL : &st);
+  __internal_statvfs (NULL, buf, &fsbuf, fd);
 
   /* We signal success if the statfs call succeeded.  */
   return 0;
diff --git a/sysdeps/unix/sysv/linux/fstatvfs64.c 
b/sysdeps/unix/sysv/linux/fstatvfs64.c
index 2dcef94..3b49ab2 100644
--- a/sysdeps/unix/sysv/linux/fstatvfs64.c
+++ b/sysdeps/unix/sysv/linux/fstatvfs64.c
@@ -25,7 +25,7 @@
 
 
 extern void __internal_statvfs64 (const char *name, struct statvfs64 *buf,
- struct statfs64 *fsbuf, struct stat64 *st);
+ struct statfs64 *fsbuf, int fd);
 
 
 /* Return information about the filesystem on which FD resides.  */
@@ -60,12 +60,8 @@ __fstatvfs64 (int fd, struct statvfs64 *buf)
 #endif
 
   if (res == 0)
-{
-  /* Convert the result.  */
-  struct stat64 st;
-  __internal_statvfs64 (NULL, buf, &fsbuf,
-   fstat64 (fd, &st) == -1 ? NULL : &st);
-}
+/* Convert the result.  */
+__internal_statvfs64 (NULL, buf, &fsbuf, fd);
 
   return res;
 }
diff --git a/sysdeps/unix/sysv/linux/internal_statvfs.c 
b/sysdeps/unix/sysv/linux/internal_statvfs.c
index 4cd4f04..1e1ad5f 100644
--- a/sysdeps/unix/sysv/linux/internal_statvfs.c
+++ b/sysdeps/unix/sysv/linux/internal_statvfs.c
@@ -43,9 +43,11 @@
 
 # ifndef __ASSUME_STATFS_F_FLAGS
 int
-__statvfs_getflags (const char *name, int fstype, struct stat64 *st)
+__statvfs_getflags (const char *name, int fstype, int fd)
 {
-  if (st == NULL)
+  struct stat64 st;
+
+  if ((fd < 0 ? stat64 (name, &st) : fstat64 (fd, &st)) < 0)
 return 0;
 
   const char *fsname = NULL;
@@ -153,7 +155,7 @@ __statvfs_getflags (const char *name, int fstype, struct 
stat64 *st)
  /* Find out about the device the current entry is for.  */
  struct stat64 fsst;
  if (stat64 (mntbuf.mnt_dir, &fsst) >= 0
- && st->st_dev == fsst.st_dev)
+ && st.st_dev == fsst.st_dev)
{
  /* Bingo, we found the entry for the device FD is on.
 Now interpret the option string.  */
@@ -216,14 +218,13 @@ __statvfs_getflags (const char *name, int fstype, struct 
stat64 *st)
 }
 # endif
 #else
-extern int __statvfs_getflags (const char *name, int fstype,
-  struct stat64 *st);
+extern int __statvfs_getflags (const char *name, int fstype, int fd);
 #endif
 
 
 void
 INTERNAL_STATVFS (const char *name, struct STATVFS *buf,
- struct STATFS *fsbuf, struct stat64 *st)
+ struct STATFS *fsbuf, int fd)
 {
   /* Now fill in the fields we have information for.  */
   buf->f_bsize = fsbuf->f_bsize;
@@ -266,7 +267,7 @@ IN

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Roland McGrath]

That looks fine.  

>   * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
>   Pass fd to __internal_statvfs instead of calling fstat64.
>   * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
>   Pass fd to __internal_statvfs64 instead of calling fstat64.

In a case like this, it's usual practice to write just "Likewise."
for the second one.  But that's not mandatory.

Ideally there should be a bugzilla item filed for this issue.
Even though it's not really user-visible per se (for user-visible changes
we have a hard rule requiring bugzilla filings), a change that is being
tracked by downstream bug reports and such is easier for everyone to
keep track of if there is a BZ# to go with it.  If you file one,
use [BZ #nnn] in the log entry as you see done elsewhere in ChangeLog.

Do you have copyright papers on file with the FSF?  I don't see a record
for you.

Do you want someone to commit this for you?  If you think it likely you'll
post more changes in the future, then we encourage you to get set up to do
your own commits (on specific approval, of course).  The details are on
the wiki.


Thanks,
Roland

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Eric Wong]

Roland McGrath  wrote:
> That looks fine.  
> 
> > * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> > Pass fd to __internal_statvfs instead of calling fstat64.
> > * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> > Pass fd to __internal_statvfs64 instead of calling fstat64.
> 
> In a case like this, it's usual practice to write just "Likewise."
> for the second one.  But that's not mandatory.

Ah, I considered "Likewise." but figured maybe the difference between
"__internal_statvfs64" and "__internal_statvfs" might be significant
(even though it's really the same function)

> Ideally there should be a bugzilla item filed for this issue.
> Even though it's not really user-visible per se (for user-visible changes
> we have a hard rule requiring bugzilla filings), a change that is being
> tracked by downstream bug reports and such is easier for everyone to
> keep track of if there is a BZ# to go with it.  If you file one,
> use [BZ #nnn] in the log entry as you see done elsewhere in ChangeLog.

I'm not fan of signing into websites or filling out  elements,
so I am hoping to avoid that.  I haven't looked too closely at BZ,
maybe there's an email/command-line interface like Debian BTS?

> Do you have copyright papers on file with the FSF?  I don't see a record
> for you.

No.  I consider this a trivial change, so I hope I don't have to.

> Do you want someone to commit this for you?  If you think it likely you'll
> post more changes in the future, then we encourage you to get set up to do
> your own commits (on specific approval, of course).  The details are on
> the wiki.

I would like somebody to commit this for me, I don't expect more
changes.  It took me many, many years of using glibc to find my first
minor issue with it :)

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Roland McGrath]

> Roland McGrath  wrote:
> > That looks fine.  
> > 
> > >   * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> > >   Pass fd to __internal_statvfs instead of calling fstat64.
> > >   * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> > >   Pass fd to __internal_statvfs64 instead of calling fstat64.
> > 
> > In a case like this, it's usual practice to write just "Likewise."
> > for the second one.  But that's not mandatory.
> 
> Ah, I considered "Likewise." but figured maybe the difference between
> "__internal_statvfs64" and "__internal_statvfs" might be significant
> (even though it's really the same function)

Oh, I didn't notice they weren't identical.  You're right that it shouldn't
use plain "Likewise." then.  But you could write:

* sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
Likewise for __internal_statvfs64.

> I'm not fan of signing into websites or filling out  elements,
> so I am hoping to avoid that.  I haven't looked too closely at BZ,
> maybe there's an email/command-line interface like Debian BTS?

Not that I'm aware of, though perhaps there is some way.  
Using bugzilla is a prerequisite for participating in glibc development.

> > Do you have copyright papers on file with the FSF?  I don't see a record
> > for you.
> 
> No.  I consider this a trivial change, so I hope I don't have to.

The FSF guidelines don't classify it that way, because trivialness for
copyright purposes is about number of lines more than it's about conceptual
complexity.  If you are really averse to the paperwork, someone with papers
can reimplement the change.


Thanks,
Roland

Re: [PATCH] avoid stat/fstat in statvfs/fstatvfs

[Eric Wong]

Roland McGrath  wrote:
> Oh, I didn't notice they weren't identical.  You're right that it shouldn't
> use plain "Likewise." then.  But you could write:
> 
>   * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
>   Likewise for __internal_statvfs64.
> 
> > I'm not fan of signing into websites or filling out  elements,
> > so I am hoping to avoid that.  I haven't looked too closely at BZ,
> > maybe there's an email/command-line interface like Debian BTS?
> 
> Not that I'm aware of, though perhaps there is some way.  
> Using bugzilla is a prerequisite for participating in glibc development.

OK, I'll create a BZ entry and resend after the paperwork is done.

> > > Do you have copyright papers on file with the FSF?  I don't see a record
> > > for you.
> > 
> > No.  I consider this a trivial change, so I hope I don't have to.
> 
> The FSF guidelines don't classify it that way, because trivialness for
> copyright purposes is about number of lines more than it's about conceptual
> complexity.  If you are really averse to the paperwork, someone with papers
> can reimplement the change.

OK, I'll go through the paperwork.  As I understand it, you (or another
maintainer) selects the appropriate form for me?
I'm fine with assigning copyright to FSF.

Re: secure_getenv is broken on FreeBSD.

[Paul Eggert]

On 02/07/2013 02:28 PM, Mats Erik Andersson wrote:
>   ./unistd.h:548: error: expected '=', ',', ';', 'asm' or
>   '__attribute__' before 'extern'

Most likely this has to do with something before the declaration
in question, not being properly terminated or something like that.
It could be many lines earlier.

> Question: How do I test whether _GL_CXXALIAS_SYS is intelligibly
> expanded? The build system stands in my way, making the preprocessed
> intermediaries inaccessible.

Sorry, I don't know how hydra works.  But if you control its inputs,
you could use a modified version of Gnulib that runs gcc -E all
the time, for debugging.

The hydra output did suggest one fix, though.  I pushed the following into
gnulib.  The patch is needed, even if it doesn't fix your bug.
Does it help?

---
 ChangeLog   | 3 +++
 lib/secure_getenv.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 4dc8f2c..5439c05 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 2013-02-07  Paul Eggert  
 
+   secure_getenv: fix include typo
+   * lib/secure_getenv.c: Include config.h.  Somehow I forgot!
+
secure_getenv: port better to FreeBSD and Solaris
* lib/secure_getenv.c [!HAVE___SECURE_GETENV]:
Include unistd.h if HAVE_ISSETUGID, otherwise define a dummy issetugid.
diff --git a/lib/secure_getenv.c b/lib/secure_getenv.c
index 2859522..1fb61bb 100644
--- a/lib/secure_getenv.c
+++ b/lib/secure_getenv.c
@@ -15,6 +15,8 @@
You should have received a copy of the GNU Lesser General Public License
along with this program.  If not, see .  */
 
+#include 
+
 #include 
 
 #if !HAVE___SECURE_GETENV
-- 
1.7.11.7