Re: stat-time.h vs. -Waggregate-return

2012-08-02 Thread Eric Blake
On 08/02/2012 04:49 PM, Paul Eggert wrote: > On 08/02/2012 03:40 PM, Eric Blake wrote: >> /* Store *ST's access time into *TS. */ >> static inline void >> get_stat_atime (struct stat const *st, struct timespec *ts) > > I'd rather not go that route, as the functional style is easier > to read -- i

Re: stat-time.h vs. -Waggregate-return

2012-08-02 Thread Paul Eggert
On 08/02/2012 03:40 PM, Eric Blake wrote: > /* Store *ST's access time into *TS. */ > static inline void > get_stat_atime (struct stat const *st, struct timespec *ts) I'd rather not go that route, as the functional style is easier to read -- in particular, it tends to avoid aliasing issues. In t

stat-time.h vs. -Waggregate-return

2012-08-02 Thread Eric Blake
The manywarnings module enables -Waggregate-return, but stat-time.h provides functions that return a struct timespec value and therefore trigger this compiler warning. Would anyone object if I rewrote this header to change the signature of the various functions from the current: /* Return *ST's a

Re: [PATCH] lib/base64.h: wrap declarations in extern "C" scope when included from C++

2012-08-02 Thread Simon Josefsson
Carlo de Falco writes: > Hi, > > In order to use base64.h in GNU/Octave we had to wrap the #include > <"base64.h"> in extern "C" scope. We believe it would have been better > if this had been done upstream. Would it be possible to apply the > patch below to lib/base64.h ? Hi. I agree. Fixed in

[PATCH] stat-time, timespec, u64: support naive out-of-dir builds

2012-08-02 Thread Paul Eggert
* lib/stat-time.c, lib/timespec.c, lib/u64.c: Use '#include "foo.h"', not '#include ', when including one's own interface. This works better when configuring with out-of-directory builds, since packages need not add an otherwise-unnecessary -I$(topdir_src)/lib to DEFAULT_INCLUDES. --- ChangeLog

Re: [PATCH] base64: Allow URL-safe base64 strings to be decoded

2012-08-02 Thread Simon Josefsson
Bruno Haible writes: > Hi, > > Wido den Hollander wrote: >> With URL-safe base64 the + and / are replaced by - and _ >> >> This way we can accept base64 strings which are URL-safe. > > There are many more variants of base64, see > http://en.wikipedia.org/wiki/Base64 > > The current code is mea

Re: [PATCH] gnumakefile: better interaction with Automake-NG

2012-08-02 Thread Eric Blake
On 08/02/2012 11:00 AM, Eric Blake wrote: > On 08/02/2012 10:53 AM, Stefano Lattarini wrote: >> * modules/gnumakefile [Makefile.am]: The makefiles generated by >> Automake-NG always contain a definition of VPATH, even in non-VPATH >> builds (its value being simply '.' in that case). So, in the >>

Re: [PATCH] gnumakefile: better interaction with Automake-NG

2012-08-02 Thread Eric Blake
On 08/02/2012 10:53 AM, Stefano Lattarini wrote: > * modules/gnumakefile [Makefile.am]: The makefiles generated by > Automake-NG always contain a definition of VPATH, even in non-VPATH > builds (its value being simply '.' in that case). So, in the > 'clean-GNUmakefile' rule, to determine whether r

[PATCH] gnumakefile: better interaction with Automake-NG

2012-08-02 Thread Stefano Lattarini
* modules/gnumakefile [Makefile.am]: The makefiles generated by Automake-NG always contain a definition of VPATH, even in non-VPATH builds (its value being simply '.' in that case). So, in the 'clean-GNUmakefile' rule, to determine whether running under a VPATH setup, compare '$(srcdir)' to '.' ra

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Daniel P. Berrange
On Thu, Aug 02, 2012 at 03:14:27PM +0200, Wido den Hollander wrote: > On 08/02/2012 01:37 PM, Daniel P. Berrange wrote: > >On Thu, Aug 02, 2012 at 01:18:12PM +0200, Wido den Hollander wrote: > >>On 07/08/2012 07:51 PM, Bruno Haible wrote: > >>>Daniel P. Berrange wrote: > If its better to just d

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Wido den Hollander
On 08/02/2012 01:37 PM, Daniel P. Berrange wrote: On Thu, Aug 02, 2012 at 01:18:12PM +0200, Wido den Hollander wrote: On 07/08/2012 07:51 PM, Bruno Haible wrote: Daniel P. Berrange wrote: If its better to just do it in libvirt config.h, then we can do that too Yes, doing '#define foo libvirt

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Bruno Haible
Daniel P. Berrange wrote: > Try applying this patch to your source tree > > diff --git a/configure.ac b/configure.ac > index 6b189db..4f906bb 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2876,6 +2876,10 @@ test "x$lv_cv_static_analysis" = xyes && t=1 > AC_DEFINE_UNQUOTED([STATIC_ANALYSI

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Daniel P. Berrange
On Thu, Aug 02, 2012 at 01:18:12PM +0200, Wido den Hollander wrote: > On 07/08/2012 07:51 PM, Bruno Haible wrote: > >Daniel P. Berrange wrote: > >>If its better to just do it in libvirt config.h, then we > >>can do that too > > > >Yes, doing '#define foo libvirt_foo' in config.h is the preferred wa

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Wido den Hollander
On 07/08/2012 07:51 PM, Bruno Haible wrote: Daniel P. Berrange wrote: If its better to just do it in libvirt config.h, then we can do that too Yes, doing '#define foo libvirt_foo' in config.h is the preferred way of achieving a namespace clean shared library. There are two ways to generate th