Patch for locale/programs/3level.h

[Andreas Jaeger]

Bruno Haible <haible@ilog.fr> writes:

[...]

> So here is a patch to use the second expression.
>
>
> 2001-08-07  Andreas Jaeger  <aj@suse.de>
>             Andreas Schwab  <schwab@suse.de>
>             Bruno Haible  <haible@clisp.cons.org>
>
> 	* locale/programs/3level.h (EMPTY): New macro.
> 	(*_get, *_add, *_iterate, *_finalize): Use it instead of ~(uint32_t)0.

We should also change the occurences of this construct, e.g. in
ld-ctype.c.  I can send a patch tomorrow,

Andreas
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7cAAhOJpWPMJyoSYRAumaAJ4zaJgHXptuqDe6w8OIdu+L6p6v2ACfahVf
PaLC0O8fla43JNbpbcBdB3k=
=SRYX
-----END PGP SIGNATURE-----From hjl@lucon.org Tue Aug 07 08:56:00 2001
From: "H . J . Lu" <hjl@lucon.org>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Ulrich Drepper <drepper@redhat.com>, GNU libc testers <libc-alpha@sourceware.cygnus.com>, rth@redhat.com, kettenis@wins.uva.nl
Subject: Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch
Date: Tue, 07 Aug 2001 08:56:00 -0000
Message-id: <20010807085652.A5784@lucon.org>
References: <m3u1znm0g0.fsf@otr.mynet> <u8wv4ior56.fsf@gromit.moeb> <m3hevmmzkx.fsf@otr.mynet> <20010806164136.K12476@sunsite.ms.mff.cuni.cz>
X-SW-Source: 2001-08/msg00068.html
Content-length: 994

On Mon, Aug 06, 2001 at 04:41:36PM +0200, Jakub Jelinek wrote:
> Unlike the previous one, it does not care which gcc was used to build GLIBC
> - everywhere but on Linux/IA-64 it exports the new GCC 3.0 unwind
> register/deregister routines plus _Unwind_Find_FDE (using gcc's
> unwind-dw2-fde.c with just a few changes for glibc), plus on platforms which
> used to export __frame_state_for from glibc it does so. __frame_state_for
> implementation in GLIBC means first try to dlopen libgcc_s.so.1 if it exists
> and call __frame_state_for in there, if it does not exist, it has a
> fallback, so that GLIBC 2.2.4 does not require GCC 3.0.1+'s libgcc to be
> installed.

One more comment, I don't know what you will gain by dlopening
libgcc_s.so.1, given that those functions are also available in
libc.so. You can't say which ones are newer at the run-time, those
in libc.so or those in libgcc_s.so.1. I believe we should do a
run-time/link-time version check of those functions instead.


H.J.