Incomplete getaddrinfo module
Hi, The getaddrinfo module in GnuLib will often result in broken application behavior because it is really a simple replacement which fail to handle very common getaddrinfo usage pattern. A common example of why it might fail is: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. What is people opinion concerning an eventual drop of the current module to replace it by the GLIBC implementation ? Regards, -- Yoann Vandoorselaere [EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Incomplete getaddrinfo module
Yoann Vandoorselaere [EMAIL PROTECTED] writes: Hi, The getaddrinfo module in GnuLib will often result in broken application behavior because it is really a simple replacement which fail to handle very common getaddrinfo usage pattern. A common example of why it might fail is: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. It could be extended to work better. What is people opinion concerning an eventual drop of the current module to replace it by the GLIBC implementation ? That would make the implementation complete, but there are some problems with the glibc code: - FSF doesn't own the copyright of the code and the license isn't (L)GPL. - Making it work stand-alone is non-trivial. The code calls some non-standard functions that would have to be re-implemented as well. I began making it work standalone at some point, but eventually gave up, but that was mostly because of the license issue. If you'd like to port it, please do. But maybe someone could say if the license would be acceptable for a gnulib module first. The license is from libc/sysdeps/posix/getaddrinfo.c below. Thanks. /* The Inner Net License, Version 2.00 The author(s) grant permission for redistribution and use in source and binary forms, with or without modification, of the software and documentation provided that the following conditions are met: 0. If you receive a version of the software that is specifically labelledas not being for redistribution (check the version message and/or README), you are not permitted to redistribute that version of the software in any way or form. 1. All terms of the all other applicable copyrights and licenses must be followed. 2. Redistributions of source code must retain the authors' copyright notice(s), this list of conditions, and the following disclaimer. 3. Redistributions in binary form must reproduce the authors' copyright notice(s), this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 4. [The copyright holder has authorized the removal of this clause.] 5. Neither the name(s) of the author(s) nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY ITS AUTHORS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. If these license terms cause you a real problem, contact the author. */ /* This software is Copyright 1996 by Craig Metz, All Rights Reserved. */ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Incomplete getaddrinfo module
Yoann Vandoorselaere wrote: The getaddrinfo module in GnuLib will often result in broken application behavior because it is really a simple replacement which fail to handle very common getaddrinfo usage pattern. A common example of why it might fail is: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; If you say which flags your application needs to work, maybe Simon can do something about it? This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. I agree. If we provide a function in gnulib, it should attempt to be an as complete replacement for the standard one as possible. What is people opinion concerning an eventual drop of the current module to replace it by the GLIBC implementation ? Have you looked at the glibc implementation of getaddrinfo? It's impossible. There's no way to make __nss_database_lookup work in the scope of gnulib. Bruno ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Incomplete getaddrinfo module
On Thu, 2005-09-15 at 13:35 +0200, Bruno Haible wrote: Yoann Vandoorselaere wrote: The getaddrinfo module in GnuLib will often result in broken application behavior because it is really a simple replacement which fail to handle very common getaddrinfo usage pattern. A common example of why it might fail is: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; If you say which flags your application needs to work, maybe Simon can do something about it? For my own use, I simply remove this check. This is due to the use of AI_PASSIVE or AI_ADDRCONFIG, which can not easily be implemented without very specific support. This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. I agree. If we provide a function in gnulib, it should attempt to be an as complete replacement for the standard one as possible. What is people opinion concerning an eventual drop of the current module to replace it by the GLIBC implementation ? Have you looked at the glibc implementation of getaddrinfo? It's impossible. There's no way to make __nss_database_lookup work in the scope of gnulib. Yes I did, and yes, we could not backport everything to GnuLib. Although I think we could use a stripped version of the code. -- Yoann Vandoorselaere [EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: config.h inclusion
Ralf Wildenhues [EMAIL PROTECTED] writes: I learned about this issue while actually trying to make use of a module with one of the unguarded files; I did not use AC_CONFIG_HEADERS. Ok, sorry, I didn't know people still did that. In that case, let's keep the #if. Surely there are also reasons for `#if'. Yes: basically it's easier to read. But given your list of problems we might as well stick with #ifdef. It's no big deal either way. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Incomplete getaddrinfo module
On Thu, 2005-09-15 at 10:41 -0400, Derek Price wrote: Yoann Vandoorselaere wrote: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; If you say which flags your application needs to work, maybe Simon can do something about it? For my own use, I simply remove this check. This is due to the use of AI_PASSIVE or AI_ADDRCONFIG, which can not easily be implemented without very specific support. I don't like the idea of silently ignoring flags that are not implemented to POSIX specifications. At the least, any ignored flags that make it into the GNULIB module deserve a healthy comment about any potential dangers and why it was deemed worthwhile to ignore the flag rather than adding an implementation up to POSIX specs. I think these flags are part of POSIX. Quote from the POSIX manpage: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. If the AI_PASSIVE flag is specified, the returned address information shall be suitable for use in binding a socket for accepting incoming connections for the specified service. In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. (...) This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. I agree. If we provide a function in gnulib, it should attempt to be an as complete replacement for the standard one as possible. As long as, possible, means that someone has submitted a patch containing proposed enhancements and not that function replacements without a full POSIX implementation need to be backed out, though I agree that incomplete implementations may deserve a note about their incompleteness in the docs. As things stand, the GNULIB getaddrinfo provides enough functionality, at the least, for CVS, canon-host as used by coreutils, and I believe one of Simon's applications (please forgive me for forgetting where you have this installed, Simon). These applications simply don't request the information that is not available from the GNULIB getaddrinfo, not because it isn't implemented, but because the applications have no need, I presume. I know that this is true in the case of CVS. As an example, libprelude will break with GnuLib getaddrinfo due to the usage of the AI_ADDRCONFIG option (if available), and AI_PASSIVE. -- Yoann Vandoorselaere [EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Incomplete getaddrinfo module
Yoann Vandoorselaere wrote: if (hints (hints-ai_flags ~AI_CANONNAME)) /* FIXME: Support more flags. */ return EAI_BADFLAGS; If you say which flags your application needs to work, maybe Simon can do something about it? For my own use, I simply remove this check. This is due to the use of AI_PASSIVE or AI_ADDRCONFIG, which can not easily be implemented without very specific support. I don't like the idea of silently ignoring flags that are not implemented to POSIX specifications. At the least, any ignored flags that make it into the GNULIB module deserve a healthy comment about any potential dangers and why it was deemed worthwhile to ignore the flag rather than adding an implementation up to POSIX specs. This is not right since it tend to break application that trust the GnuLib module to provide a viable getaddrinfo replacement. I agree. If we provide a function in gnulib, it should attempt to be an as complete replacement for the standard one as possible. As long as, possible, means that someone has submitted a patch containing proposed enhancements and not that function replacements without a full POSIX implementation need to be backed out, though I agree that incomplete implementations may deserve a note about their incompleteness in the docs. As things stand, the GNULIB getaddrinfo provides enough functionality, at the least, for CVS, canon-host as used by coreutils, and I believe one of Simon's applications (please forgive me for forgetting where you have this installed, Simon). These applications simply don't request the information that is not available from the GNULIB getaddrinfo, not because it isn't implemented, but because the applications have no need, I presume. I know that this is true in the case of CVS. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
strstr redefinition fix
The new strstr module is causing a redefinition warnings from many files
and then strstr.c fails to compile thus on an Alpha Linux 2.2.20 system
running gcc 2.95.4:
gcc -DHAVE_CONFIG_H -I. -I/home/users/d/de/derekrprice/cvs-nightly/lib -I..
-Ino/include -g -O2 -c /home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c
In file included from /usr/include/string.h:360,
from /home/users/d/de/derekrprice/cvs-nightly/lib/mbchar.h:149,
from
/home/users/d/de/derekrprice/cvs-nightly/lib/mbuiter.h:101,
from /home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:29:
/usr/include/bits/string2.h:1068: warning: `strstr' redefined
../config.h:1235: warning: this is the location of the previous definition
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:34: parse error before
`__extension__'
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:46: parse error before `.'
...and so on. It looks like a pretty straightforward case of the strstr
definintion in string.h overwriting the one required by the strstr
module. The attached untested patch should fix this:
2005-09-15 Derek Price [EMAIL PROTECTED]
* lib/strstr.h: #include string.h before possibly redefining strstr.
* m4/strstr.m4 (gl_FUNC_STRSTR): Don't define strstr here.
Regards,
Derek
--
Derek R. Price
CVS Solutions Architect
Ximbiot http://ximbiot.com
v: +1 717.579.6168
f: +1 717.234.3125
mailto:[EMAIL PROTECTED]
? strstr.h-include-string.h.diff
Index: lib/strstr.h
===
RCS file: /cvsroot/cvs/ccvs/lib/strstr.h,v
retrieving revision 1.3
diff -u -p -r1.3 strstr.h
--- lib/strstr.h4 Sep 2005 05:58:56 - 1.3
+++ lib/strstr.h15 Sep 2005 15:10:21 -
@@ -19,6 +19,12 @@
extern C {
#endif
+/* string.h may #define strstr. */
+#include string.h
+
+#undef strstr
+#define strstr rpl_strstr
+
/* Find the first occurrence of NEEDLE in HAYSTACK. */
extern char *strstr (const char *haystack, const char *needle);
Index: m4/strstr.m4
===
RCS file: /cvsroot/cvs/ccvs/m4/strstr.m4,v
retrieving revision 1.2
diff -u -p -r1.2 strstr.m4
--- m4/strstr.m44 Sep 2005 05:58:36 - 1.2
+++ m4/strstr.m415 Sep 2005 15:10:21 -
@@ -9,7 +9,6 @@ AC_DEFUN([gl_FUNC_STRSTR],
dnl No known system has a strstr() function that works correctly in
dnl multibyte locales. Therefore we use our version always.
AC_LIBOBJ(strstr)
- AC_DEFINE(strstr, rpl_strstr, [Define to rpl_strstr always.])
gl_PREREQ_STRSTR
])
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] Incomplete getaddrinfo module
Yoann Vandoorselaere wrote: I think these flags are part of POSIX. Quote from the POSIX manpage: I'm not arguing that. I'm simply stating that if the GNULIB module is going to *ignore* these POSIX specified flags, as you said your app does, then the reasons for this and any potential dangers involved in doing so should be well-documented. As an example, libprelude will break with GnuLib getaddrinfo due to the usage of the AI_ADDRCONFIG option (if available), and AI_PASSIVE. I understand that. I was simply stating that, while I believe a more complete implementation of getaddrinfo would be wonderful, many applications get along just fine with the current, incomplete implementation. I just wanted to be sure that the phrasing of Bruno's statement about GNULIB modules being complete if possible didn't imply that incomplete modules should be removed when so many apps get along without the missing functionality. If the getaddrinfo module doesn't get completed, documentation of the missing functionality would probably be nice so that no one else is so surprised when getaddrinfo fails. I came up with the attached patch, but perhaps a shorter note in the modules file like, * Incomplete - see lib/getaddrinfo.c. would be better. The extra notes my patch adds to modules/getaddrinfo could then be added to lib/getaddrinfo.c, then, but I think they would be superfluous. 2005-09-15 Derek Price [EMAIL PROTECTED] * modules/getaddrinfo: Document shortcomings of this module. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] Index: modules/getaddrinfo === RCS file: /cvsroot/gnulib/gnulib/modules/getaddrinfo,v retrieving revision 1.4 diff -u -p -r1.4 getaddrinfo --- modules/getaddrinfo 13 Sep 2005 04:15:15 - 1.4 +++ modules/getaddrinfo 15 Sep 2005 15:36:02 - @@ -1,5 +1,9 @@ Description: -getaddrinfo() function: Get address information. +getaddrinfo() function: Get address information. This implementation is +currently incomplete. It supports returning basic connection information for +outgoing IPV4 IPV6 udp tcp connections, and only supports AI_CANONNAME in +hints-ai_flags. It returns what are hoped to be useful error codes when +unsupported functionality is requested. Files: lib/getaddrinfo.h ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Incomplete getaddrinfo module
Yoann Vandoorselaere [EMAIL PROTECTED] writes: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. This looks tricky to implement. Looking at libc code, it uses getifaddrs, which appear tricky to implement portably. But we could support multiple implementations of getifaddrs, one for each system where we know how to implement it. I don't see how we could hope to do better. If the AI_PASSIVE flag is specified, the returned address information shall be suitable for use in binding a socket for accepting incoming connections for the specified service. In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. (...) I don't think this would be that difficult to implement. As an example, libprelude will break with GnuLib getaddrinfo due to the usage of the AI_ADDRCONFIG option (if available), and AI_PASSIVE. Without the current gnulib getaddrinfo module, you are even worse off because there is no portable replacement for this functionality. Or what were you doing before? Perhaps that code could be integrated into the gnulib module. Generally, I agree with you that much of the glibc getaddrinfo code could and should be merged with the gnulib module. It would be very useful to work on this, but I can't promise to commit to this soon myself. Thanks, Simon ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] request for new modules for portable pseudo-terminal allocation functions
--- Bruno Haible [EMAIL PROTECTED] wrote: Hello, allocating pseudo-terminals in a portable way is a nightmare. I agree. You also find some source code in this direction in glibc, I found the relevant source in glibc much more readable than my previous attempt with expect. in xterm (horrible mess of #ifdefs), in kdebase/konsole, in rxvt, in gnome-terminal, ... It would be nice if gnulib included portable replacements for GNU C library functions getpt, grantpt, unlockpt, ptsname, ptsname_r, openpty, forkpty, Is this API sufficient? I think so. The really needed op (for me) is to get a master-slave pair (openpty). I will implement something similar to forkpty myself, because forkpty closes 1 and 2 to redirect them to the pseudo-terminal, while I need to redirect them to pipes, and only 0 should refer to the pty (I hope that will work portably). The example in the glibc manual indicates that some STREAMS operations are necessary as well, no? As far as I know (which is not that far), it is something specific of ptsname and ptsname_r (if you want to open the pseudoterminals from their name yourself). My guess is that the higher level APIs, openpty and forkpty, are unaffected. The usual way for some code to come into gnulib is that someone who needs it writes it, and then submits it into gnulib. Someone with a stronger knowledge of the glibc than me could maybe extract those functions from the codebase. If no one steps up in some time, I will give it a try (since I need it to complete libsrcinst). Thanks for pointing at the glibc sources, they helped me understand some things better. Claudio __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: Incomplete getaddrinfo module
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
On Thu, 2005-09-15 at 17:36 +0200, Simon Josefsson wrote:
Yoann Vandoorselaere [EMAIL PROTECTED] writes:
If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system, and
IPv6 addresses shall be returned only if an IPv6 address is configured
on the local system.
This looks tricky to implement. Looking at libc code, it uses
getifaddrs, which appear tricky to implement portably. But we could
support multiple implementations of getifaddrs, one for each system
where we know how to implement it. I don't see how we could hope to
do better.
In the meantime, a good workaround would be to remove the definition for
AI_ADDRCONFIG from GnuLib provided getaddrinfo.h. This way, application
can test for the flag and avoid to use it if it is not present.
Yes, this may work.
Libprelude for example won't use AI_ADDRCONFIG in case the header does
not export it because this is known to not be portable. However, since
GnuLib export the flags, it get used, and getaddrinfo() will fails due
to the usage of unsupported flags.
On the other hand, if the AI_ADDRCONFIG flag is POSIX, applications
really should not have to test for it. The gnulib approach is that
applications assume POSIX, and is written for that. Maybe it is
better to use a runtime test, i.e.:
rc = getaddrinfo (...AI_ADDRCONFIG...)
if (rc == EAI_BADFLAGS) {
/* Try it without AI_ADDRCONFIG, we may have the incomplete gnulib
getaddrinfo implementation, or the system implementation may not
support AI_ADDRCONFIG. */
rc = getaddrinfo(..)
}
...normal error checking...
What do people think?
I do not know of any other getaddrinfo implementations that lack
support of AI_ADDRCONFIG, though.
Btw, perhaps it is possible to implement something clever to portably
figure out whether IPv4 or IPv6 is configured on the local machine.
How about trying to send a packet to the 127.0.0.1 or ::1/128? That
should work if IPv4/IPv6 is properly configured, right? And sending
shouldn't be that difficult. Maybe it is even sufficient to try to
bind a server socket for IPv4 or IPv6. Or something.
Thanks,
Simon
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] strstr redefinition fix
Derek Price wrote:
The new strstr module is causing a redefinition warnings from many files
and then strstr.c fails to compile thus on an Alpha Linux 2.2.20 system
running gcc 2.95.4:
gcc -DHAVE_CONFIG_H -I. -I/home/users/d/de/derekrprice/cvs-nightly/lib -I..
-Ino/include -g -O2 -c
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c In file included from
/usr/include/string.h:360,
from
/home/users/d/de/derekrprice/cvs-nightly/lib/mbchar.h:149, from
/home/users/d/de/derekrprice/cvs-nightly/lib/mbuiter.h:101, from
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:29:
/usr/include/bits/string2.h:1068: warning: `strstr' redefined
../config.h:1235: warning: this is the location of the previous definition
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:34: parse error
before `__extension__'
/home/users/d/de/derekrprice/cvs-nightly/lib/strstr.c:46: parse error
before `.'
...and so on. It looks like a pretty straightforward case of the strstr
definintion in string.h overwriting the one required by the strstr
module. The attached untested patch should fix this:
Thanks. I applied the appended patch, very similar to yours. (But move
the #include outside the extern C { ... }.)
Bruno
Index: m4/strstr.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/strstr.m4,v
retrieving revision 1.4
diff -c -3 -r1.4 strstr.m4
*** m4/strstr.m417 Aug 2005 14:05:33 - 1.4
--- m4/strstr.m415 Sep 2005 16:25:13 -
***
*** 1,4
! # strstr.m4 serial 3
dnl Copyright (C) 2002-2003, 2005 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
--- 1,4
! # strstr.m4 serial 4
dnl Copyright (C) 2002-2003, 2005 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
***
*** 9,15
dnl No known system has a strstr() function that works correctly in
dnl multibyte locales. Therefore we use our version always.
AC_LIBOBJ(strstr)
- AC_DEFINE(strstr, rpl_strstr, [Define to rpl_strstr always.])
gl_PREREQ_STRSTR
])
--- 9,14
Index: lib/strstr.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/strstr.h,v
retrieving revision 1.5
diff -c -3 -r1.5 strstr.h
*** lib/strstr.h17 Aug 2005 14:05:33 - 1.5
--- lib/strstr.h15 Sep 2005 16:25:13 -
***
*** 15,23
--- 15,33
along with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */
+
+ /* Include string.h: on glibc systems, it contains a macro definition of
+strstr() that would collide with our definition if included afterwards. */
+ #include string.h
+
#ifdef __cplusplus
extern C {
#endif
+
+ /* No known system has a strstr() function that works correctly in
+multibyte locales. Therefore we use our version always. */
+ #undef strstr
+ #define strstr rpl_strstr
/* Find the first occurrence of NEEDLE in HAYSTACK. */
extern char *strstr (const char *haystack, const char *needle);
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] strstr redefinition fix
Bruno Haible wrote:
Thanks. I applied the appended patch, very similar to yours. (But move
the #include outside the extern C { ... }.)
Any reason why you left this inside?
+ #undef strstr
+ #define strstr rpl_strstr
Just because it didn't matter?
Thanks,
Derek
--
Derek R. Price
CVS Solutions Architect
Ximbiot http://ximbiot.com
v: +1 717.579.6168
f: +1 717.234.3125
mailto:[EMAIL PROTECTED]
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
regex warnings
I'm seeing warning: `pure' attribute directive ignored warnings from regex_internal.h regex_internal.c compiling with GCC 2.95.4 on Alpha Linux 2.2.20. Similarly, I see warning: `always_inline' attribute directive ignored warnings compiling regcomp.c regexec.c. Is this something worth working around or should I just ignore it? Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib features.h? (was regex warnings)
Paul Eggert wrote: I'd fix it if I were you. You can use the __GNUC_PREREQ macro of md5.h. I've installed the attached patch. It compiles cleanly on the offending alpha-linux system. I pretty-much cut pasted the __GNUC_PREREQ macro out of md5.h, as you suggested, and used it, except in regex_internal.h, where I stumbled across a convenient #if __GNUC__ = 3 switch already being used to protect usage of inline, and used that. 2005-09-15 Derek Price [EMAIL PROTECTED] * regex_internal.h: Blank `pure' for GNUC 3. * regex_internal.c: Ditto, using this... (__GNUC_PREREQ): ...new macro. * regcomp.c, regexec.c: Blank `always_inline' for GNUC 3.1 using... (__GNUC_PREREQ): ...this new macro. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] Index: lib/regcomp.c === RCS file: /cvsroot/gnulib/gnulib/lib/regcomp.c,v retrieving revision 1.17 diff -u -p -r1.17 regcomp.c --- lib/regcomp.c 6 Sep 2005 07:36:48 - 1.17 +++ lib/regcomp.c 15 Sep 2005 19:08:52 - @@ -17,6 +17,19 @@ with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ +#ifndef __GNUC_PREREQ +# if defined __GNUC__ defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ 16) + __GNUC_MINOR__ = ((maj) 16) + (min)) +# else +# define __GNUC_PREREQ(maj, min) 0 +# endif +#endif + +#if !__GNUC_PREREQ (3, 1) +# define always_inline +#endif + static reg_errcode_t re_compile_internal (regex_t *preg, const char * pattern, Idx length, reg_syntax_t syntax); static void re_compile_fastmap_iter (regex_t *bufp, Index: lib/regexec.c === RCS file: /cvsroot/gnulib/gnulib/lib/regexec.c,v retrieving revision 1.18 diff -u -p -r1.18 regexec.c --- lib/regexec.c 6 Sep 2005 07:36:48 - 1.18 +++ lib/regexec.c 15 Sep 2005 19:08:52 - @@ -17,6 +17,19 @@ with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ +#ifndef __GNUC_PREREQ +# if defined __GNUC__ defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ 16) + __GNUC_MINOR__ = ((maj) 16) + (min)) +# else +# define __GNUC_PREREQ(maj, min) 0 +# endif +#endif + +#if !__GNUC_PREREQ (3, 1) +# define always_inline +#endif + static reg_errcode_t match_ctx_init (re_match_context_t *cache, int eflags, Idx n) internal_function; static void match_ctx_clean (re_match_context_t *mctx) internal_function; Index: lib/regex_internal.c === RCS file: /cvsroot/gnulib/gnulib/lib/regex_internal.c,v retrieving revision 1.17 diff -u -p -r1.17 regex_internal.c --- lib/regex_internal.c6 Sep 2005 07:36:48 - 1.17 +++ lib/regex_internal.c15 Sep 2005 19:08:53 - @@ -17,6 +17,19 @@ with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ +#ifndef __GNUC_PREREQ +# if defined __GNUC__ defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ 16) + __GNUC_MINOR__ = ((maj) 16) + (min)) +# else +# define __GNUC_PREREQ(maj, min) 0 +# endif +#endif + +#if !__GNUC_PREREQ (3, 0) +# define pure +#endif + static void re_string_construct_common (const char *str, Idx len, re_string_t *pstr, REG_TRANSLATE_TYPE trans, bool icase, Index: lib/regex_internal.h === RCS file: /cvsroot/gnulib/gnulib/lib/regex_internal.h,v retrieving revision 1.14 diff -u -p -r1.14 regex_internal.h --- lib/regex_internal.h6 Sep 2005 17:50:47 - 1.14 +++ lib/regex_internal.h15 Sep 2005 19:08:53 - @@ -89,6 +89,7 @@ #else # define BE(expr, val) (expr) # define inline +# define pure #endif /* Number of single byte character. */ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib features.h? (was regex warnings)
Paul Eggert wrote: I'd fix it if I were you. You can use the __GNUC_PREREQ macro of md5.h. I know I've already installed this fix but, for future reference, is there a simple reference I could use to find what version of GCC an attribute first appeared in? Something easier than fumbling through the CVS history, that is. :) Thanks, Derek -- Derek R. Price CVS Solutions Architect Ximbiot http://ximbiot.com v: +1 717.579.6168 f: +1 717.234.3125 mailto:[EMAIL PROTECTED] ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: [bug-gnulib] strstr redefinition fix
Derek Price wrote:
Bruno Haible wrote:
Thanks. I applied the appended patch, very similar to yours. (But move
the #include outside the extern C { ... }.)
Any reason why you left this inside?
+ #undef strstr
+ #define strstr rpl_strstr
Just because it didn't matter?
Yes, because it didn't matter, and because I'm following the same pattern
as I would use if there were several functions, not just one.
#include ...
#undef func1
#define func1 rpl_func1
#undef func2
#define func2 rpl_func2
extern C {
extern foo func1();
extern foo func2();
}
looks somewhat weirder than
#include ...
extern C {
#undef func1
#define func1 rpl_func1
extern foo func1();
#undef func2
#define func2 rpl_func2
extern foo func2();
}
Bruno
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib features.h?
Derek Price [EMAIL PROTECTED] writes: I've attached hte following for review since I took the liberty of replacing two #if __GNUC__ = constructs in regex_internal.h with __GNUC_PREREQ calls. Let's avoid that, since we want to minimize the differences from glibc. Other than that, it looks good. As I understand it, you want the following change from a day ago. This is pretty simple. --- regex_internal.h.~1.14~ 2005-09-15 16:10:09.0 -0700 +++ regex_internal.h2005-09-15 16:13:16.0 -0700 @@ -84,11 +84,25 @@ # define RE_ENABLE_I18N #endif +#ifndef __GNUC_PREREQ +# if defined __GNUC__ defined __GNUC_MINOR__ +# define __GNUC_PREREQ(maj, min) \ + ((__GNUC__ 16) + __GNUC_MINOR__ = ((maj) 16) + (min)) +# else +# define __GNUC_PREREQ(maj, min) 0 +# endif +#endif + +#if !__GNUC_PREREQ (3,1) +# define always_inline +#endif + #if __GNUC__ = 3 # define BE(expr, val) __builtin_expect (expr, val) #else # define BE(expr, val) (expr) # define inline +# define pure #endif /* Number of single byte character. */ ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
