Am Sa., 8. Jan. 2022 um 11:51 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > I submitted a patch. An email will follow.
>
> Ah, you already pushed it. Good!
My workflow is not optimized yet. Pushing and sending out the email
with the patch has to happen in two steps.
Marc Nieper-Wißkirchen wrote:
> I submitted a patch. An email will follow.
Ah, you already pushed it. Good!
Bruno
Am Fr., 7. Jan. 2022 um 21:54 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > I just noticed that doesn't include extern "C" guards
> > so that inclusion in a C++ source file becomes easier (see 4.2 in the
> > Gnulib manual).
>
> Patches are welcome.
I submitted a patch. An email
Marc Nieper-Wißkirchen wrote:
> I just noticed that doesn't include extern "C" guards
> so that inclusion in a C++ source file becomes easier (see 4.2 in the
> Gnulib manual).
Patches are welcome.
> I don't know what the general policy is
For these extern "C" guards, we do it on demand, i.e. th
I just noticed that doesn't include extern "C" guards
so that inclusion in a C++ source file becomes easier (see 4.2 in the
Gnulib manual).
I don't know what the general policy is, but including
in a C++ makes sense to me and could be made easier.
Marc
PS I haven't systematically checked other
e-c++' to
> ./configure.
OK, so I guessed wrong regarding the cause of the problem.
Did some experiments, and it seems the cause is the combination of the
'posixcheck' module and C++. With a testdir created through
./gnulib-tool --create-testdir --dir=../testdir1 --singl
Florian Weimer wrote:
> Since gnulib is a copylib, it doesn't have much control over how it is
> built. It's one of the issues that came up while trying to build
> things with a C++ compiler instead of a C compiler.
gnulib code is meant to be compiled with a C compiler. The header files
are suppo
On Fri, Feb 14, 2020, 13:46 Bruno Haible wrote:
> Hi Christian,
>
> > This was previously fixed but I again see a compile error (with gnulib
> > at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4)
> >
> > In file included from /usr/share/mingw-w64/include/io.h:10,
> > from gnulib/import
Hi Christian,
> This was previously fixed but I again see a compile error (with gnulib
> at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4)
>
> In file included from /usr/share/mingw-w64/include/io.h:10,
> from gnulib/import/stdio.h:146,
> from gnulib/import/wchar.h:80
On Wed, Feb 12, 2020 at 4:12 PM Christian Biesinger
wrote:
> This was previously fixed but I again see a compile error (with gnulib
> at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4)
The previous breakage was reported at
https://lists.gnu.org/archive/html/bug-gnulib/2019-11/msg00027.html
I suspect t
Hello!
This was previously fixed but I again see a compile error (with gnulib
at 4fcedca004fd13aecb5c6f235a988a5548bcb9a4)
In file included from /usr/share/mingw-w64/include/io.h:10,
from gnulib/import/stdio.h:146,
from gnulib/import/wchar.h:80,
C2X and C++17 finally added support for a simple, single-argument
‘static_assert’ that implements what the Gnulib ‘verify’ macro was
doing back in 2005. Implement static_assert on older platforms.
The only remaining advantage of ‘verify’ is a shorter name.
* doc/posix-headers/assert.texi
IMHO, it should be gl-* everywhere.
On 12/12/2013 10:14 AM, Pádraig Brady wrote:
> I was just being consistent with other lib/gl_*.h
> There are no lib/gl-*
Ah, never mind then.
It's odd that we use one pattern in lib and another in m4,
but I guess it's a pattern now
On 12/12/2013 05:44 PM, Paul Eggert wrote:
> But while we're on the subject, shouldn't
> it be 'gl-openssh.h', not 'gl_openssh.h'?
I was just being consistent with other lib/gl_*.h
There are no lib/gl-*
On 12/12/2013 03:32 AM, Pádraig Brady wrote:
> I'm not too sure of the long term status of this code,
Me neither. But while we're on the subject, shouldn't
it be 'gl-openssh.h', not 'gl_openssh.h'?
On 12/12/2013 08:12 AM, Alexander V. Lukyanov wrote:
> Hello!
>
> This patch is required to compile gl_openssl.h in c++ mode.
>
I've pushed that fix thanks.
I'm not too sure of the long term status of this code,
but we should at least make it correct and we can go from there.
thanks,
Pádraig.
Hello!
This patch is required to compile gl_openssl.h in c++ mode.
--
Alexander.
diff --git a/lib/gl_openssl.h b/lib/gl_openssl.h
index 1fb6106..bcdbbef 100644
--- a/lib/gl_openssl.h
+++ b/lib/gl_openssl.h
@@ -91,18 +91,18 @@ GL_CRYPTO_FN (_process_block) (const void *buf, size_t len,
struct
b/doc/posix-headers/assert.texi
@@ -10,7 +10,7 @@ See also the Gnulib module @code{assert}.
Portability problems fixed by Gnulib:
@itemize
@item
-The draft C1X and C++0X @code{static_assert}, and the draft C1X
+The C11 and C++11 @code{static_assert}, and the C11
@code{_Static_assert}, are not
On 04/11/2011 12:48 AM, Nikos Mavrogiannopoulos wrote:
> As an unrelated suggestion for memxor.c I had a discussion with
> another project about that and we concluded on a gmp-based
> version that is orders of magnitude faster. It would
> be nice if gnulib included the optimized code by default.
P
On 04/11/2011 12:56 AM, Paul Eggert wrote:
> On 04/10/2011 03:07 PM, Nikos Mavrogiannopoulos wrote:
>> As I understand it AC_C_RESTRICT checks whether restrict
>> is supported by the C compiler. I'm using the C++ compiler.
>
> In that case, AC_C_RESTRICT should report that your C++
> compiler does
Nikos Mavrogiannopoulos wrote:
> I'm using the C++ compiler.
> (in gnutls, that has C and C++ components).
Please, when reporting a bug, _always_ provide a "How to reproduce" recipe.
In particular, you missed two occasions to tell which C compiler and which
C++ compiler
On 04/10/2011 03:07 PM, Nikos Mavrogiannopoulos wrote:
> As I understand it AC_C_RESTRICT checks whether restrict
> is supported by the C compiler. I'm using the C++ compiler.
In that case, AC_C_RESTRICT should report that your C++
compiler does not support 'restrict' when compiling C code.
What g
C_RESTRICT checks whether restrict
is supported by the C compiler. I'm using the C++ compiler.
(in gnutls, that has C and C++ components).
regards,
Nikos
On 04/10/2011 12:53 AM, Nikos Mavrogiannopoulos wrote:
> Attached is a patch that fixes the time.h compilation under C++.
This shouldn't be needed, since gl_HEADER_TIME_H requires
gl_HEADER_TIME_H_BODY, which requires AC_C_RESTRICT, which
is supposed to arrange for 'restrict' to be #define'd to
no
Attached is a patch that fixes the time.h compilation under C++.
regards,
Nikos
>From 6bdd56fbd4ecad4b00d3bbd76dd343a52622a876 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Sun, 10 Apr 2011 09:51:58 +0200
Subject: [PATCH] Fix compilation issue under C++ due to restrict C qualifier.
I'm thinking that gettext.h needs a slight tweak to work with C++. I'm
going off a report from Nelson H. F. Beebe, who tried building m4 on a
Linux system with CC=g++:
g++ -I. -pedantic -Wall -W -Wfloat-equal -Wshadow -Wpointer-arith
-Wcast-qu
al -Wcast-align -Wwrite-strings -Wredundant-decl
Hi Jim,
> Currently I've been creating a tiny script like this for each
> program I want to wrap, git-adding it, and listing it in Files:, too.
> Taking test-areadlink-with-size as an example,
>
> #!/bin/sh
> . "${srcdir=.}/init.sh"; path_prepend_ .
> test-areadlink-with-size
> Ex
Bruno Haible wrote:
>> Not having to worry about cleaning up temporary files
>> and not having to choose "parallel-safe" names for them
>> leads to much cleaner tests.
>> Not having to add signal handlers in every single one
>> avoids duplication and would make them robust by default.
>>
>> IMHO, a
Hi Jim,
> Not having to worry about cleaning up temporary files
> and not having to choose "parallel-safe" names for them
> leads to much cleaner tests.
> Not having to add signal handlers in every single one
> avoids duplication and would make them robust by default.
>
> IMHO, all new tests shou
Hi John,
> But how about the following example? Does it have all the required
> features? It seems to work for me
Indeed, it works for me too. Apparently it was the
'using namespace gnulib_system_namespace;' that collided with
'using gnulib::open;'.
But there's a big caveat: I don't know wheth
On 20-Feb-2010, Bruno Haible wrote:
| And when I change the first line to
|
| namespace system {
| #include
| }
| using namespace system;
|
| then there is a different error message:
|
| $ g++ -S foo.cc
| foo.cc: In function ‘int bar_uses_gnulib_implicitly()’:
| foo.cc:37: error: reference to
Ralf Wildenhues wrote:
> ... even if in the end it makes it harder to use CC=g++
I plan to make the changes conditional on
#if defined __cplusplus && defined GNULIB_NAMESPACE
So that
1. It will have no effect on CC=g++,
2. A C++ package can turn on GNULIB_NAMESPACE in some
translation
* Bruno Haible wrote on Thu, Feb 18, 2010 at 11:57:15PM CET:
> Ralf proposes:
> > I suggest you could
> > produce a helper header to #undef them again; you could even do that
> > automatically during bootstrap with above. Then only a portability
> > layer would need to avoid using these symbols in
John W. Eaton wrote:
> If I add "using gnulib::open;" inside the "#ifdef __cplusplus" block,
> ...
> then I don't even have to prefix all of the uses of open in my code
> with gnulib::. This seems like the best solution for me.
A good idea. Unfortunately I cannot see how to make it work: This pro
John W. Eaton wrote:
> Maybe I'm missing something, but what happens if @GNULIB_OPEN@ is 0?
> It doesn't look like we get the symbol inside the gnulib namespace in
> that case.
Yes. This is intentional. When @GNULIB_OPEN@ expands to 0, it means that
the programmer has not asked for the function 'o
On 19-Feb-2010, I wrote:
| To handle all the cases, I find that I need to write
|
| #ifdef __cplusplus
| namespace gnulib
| {
| int (*const open) (const char *filename, int flags, ...) =
| # if @GNULIB_OPEN@
| # if @REPLACE_OPEN@
| ::rpl_open;
| # else
| ::open;
|
On 18-Feb-2010, Bruno Haible wrote:
| Ralf proposes:
| > I suggest you could
| > produce a helper header to #undef them again; you could even do that
| > automatically during bootstrap with above. Then only a portability
| > layer would need to avoid using these symbols in another namespace.
|
|
The idiom for declaring the 'open' override can be simplified as follows,
through the definition of three new macros _GL_DECL_NAMESPACE_C,
_GL_ALIAS_RPL, _GL_ALIAS_STD.
*** lib/fcntl.in.h.orig Fri Feb 19 00:25:00 2010
--- lib/fcntl.in.h Fri Feb 19 00:14:03 2010
***
*** 79,87
Hi John,
Ralf proposes:
> I suggest you could
> produce a helper header to #undef them again; you could even do that
> automatically during bootstrap with above. Then only a portability
> layer would need to avoid using these symbols in another namespace.
This would only be a makeshift. Your exa
* John W. Eaton wrote on Thu, Feb 18, 2010 at 09:49:05PM CET:
> On 18-Feb-2010, Ralf Wildenhues wrote:
> | * John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
> | > On 18-Feb-2010, Ralf Wildenhues wrote:
> | > | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
> | >
> | > Runnin
On 18-Feb-2010, Ralf Wildenhues wrote:
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
| > On 18-Feb-2010, Ralf Wildenhues wrote:
| > | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
| >
| > Running this with the Octave configure.ac file produces only
| >
| > gmtime:
* John W. Eaton wrote on Thu, Feb 18, 2010 at 09:22:39PM CET:
> On 18-Feb-2010, Ralf Wildenhues wrote:
> | $ autoconf '--trace=AC_DEFINE:$1:$2' | grep ':rpl_[^:]*$'
>
> Running this with the Octave configure.ac file produces only
>
> gmtime:rpl_gmtime
> localtime:rpl_localtime
>
> but I know
On 18-Feb-2010, Ralf Wildenhues wrote:
| Hello John,
|
| * John W. Eaton wrote on Thu, Feb 18, 2010 at 08:37:30PM CET:
| > However, there is one issue that has caused a bit of trouble as I
| > have started using more gnulib modules.
| >
| > Octave is mostly written in C++ and am having some diff
Hello John,
* John W. Eaton wrote on Thu, Feb 18, 2010 at 08:37:30PM CET:
> However, there is one issue that has caused a bit of trouble as I
> have started using more gnulib modules.
>
> Octave is mostly written in C++ and am having some difficulty with the
> rpl_ redefinitions of symbols that h
Hi,
I'm trying to use gnulib with GNU Octave and am overall very pleased,
as it is allowing me to remove a lot of cruft from Octave's source
files and just assume that a POSIX environment is available without
having to use a lot of #ifdefs. To me, that's a significant
improvement.
However, there
Albert Chin wrote:
> gl_REGEX from m4/regex.m4 cannot be reliably tested under C++. The
> problem is:
> static struct re_pattern_buffer regex;
> unsigned char folded_chars[UCHAR_MAX + 1];
> ...
> regex.translate = folded_chars;
>
> If the `translate'
gl_REGEX from m4/regex.m4 cannot be reliably tested under C++. The
problem is:
static struct re_pattern_buffer regex;
unsigned char folded_chars[UCHAR_MAX + 1];
...
regex.translate = folded_chars;
If the `translate' member is char * on some platforms
Yoann Vandoorselaere wrote:
> > I don't think Chinese users will find it nice if you exclude them from
> > correct functioning of your program because of "performance" or "library
> > size".
>
> I don't think you are qualified to decide in place of the application
> developer whether the applicat
Yoann Vandoorselaere wrote:
> "However, if we have a platform missing strcasestr, then using
> c_strcasestr as the substitute implementation is probably okay, because
> that platform would probably be broken in other areas, such as locale
> support, ...
Solaris 9 and Solaris 10 (which also doesn't
On Tue, 2006-11-14 at 13:38 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > "However, if we have a platform missing strcasestr, then using
> > c_strcasestr as the substitute implementation is probably okay, because
> > that platform would probably be broken in other areas, such as loca
On Tue, 2006-11-14 at 14:58 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > > I don't think Chinese users will find it nice if you exclude them from
> > > correct functioning of your program because of "performance" or "library
> > > size".
> >
> > I don't think you are qualified to
Yoann Vandoorselaere wrote:
> Solaris 9 apparently lack the strcasestr() function.
If the program needs strcasestr(), then it needs the 'strcasestr' module.
It defines a replacement for strcasestr().
> Might we modify the
> c-strcasestr module so that it provide a replacement for platform
> lack
On Tue, 2006-11-14 at 11:40 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > Solaris 9 apparently lack the strcasestr() function.
>
> If the program needs strcasestr(), then it needs the 'strcasestr' module.
> It defines a replacement for strcasestr().
>
> > Might we modify the
> > c
On Fri, 2006-09-15 at 05:35 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> > Hi,
> >
> > The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> > i
Yoann Vandoorselaere wrote:
> The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> implement their replacement functions using a "c_" prefix.
>
> However, there is no autoconf test implemented by these modules that
> redefine the original function (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yoann Vandoorselaere on 9/15/2006 5:40 AM:
>
> I recall platform missing strcasestr, although I can't remember which.
> Anyway, what's the purpose of these modules if they are not used
> anywhere ?
The c_* modules ARE used, particularly
On Fri, 2006-09-15 at 05:35 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> > Hi,
> >
> > The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> > i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> Hi,
>
> The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> implement their replacement functions using a "c_" prefix.
>
> However, there is
Hi,
The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
implement their replacement functions using a "c_" prefix.
However, there is no autoconf test implemented by these modules that
redefine the original function (in case it is missing) to point to their
GnuLib r
60 matches
Mail list logo
