This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc 2.3.1: fix for the i386 inline strings code
- From: Denis Zaitsev <zzz at cd-club dot ru>
- To: Andreas Jaeger <aj at suse dot de>
- Cc: Ulrich Drepper <drepper at redhat dot com>, libc-alpha at sources dot redhat dot com,linux-gcc at vger dot kernel dot org
- Date: Tue, 7 Jan 2003 08:43:01 +0500
- Subject: Re: glibc 2.3.1: fix for the i386 inline strings code
- References: <20030106063048.A32392@natasha.zzz.zzz> <u8u1gm7fwy.fsf@gromit.moeb>
On Mon, Jan 06, 2003 at 11:04:29AM +0100, Andreas Jaeger wrote:
> Denis Zaitsev <zzz@cd-club.ru> writes:
>
> > Nobody has answered to me for a while, so I'm resending this
> > politely...
> >
> > This is a trivial patch for the inlined i386 strings' header. Without
> > it, say, X11 can't be compiled with -D__USE_STRING_INLINES - a
> > problems will be caused by XtNewString and X11's own bzero. These
>
> What exactly is the problem with X11?
>
> Andreas
>
The exact problem with XtNewString is that we have the "void pointer
dereference" error when it is used with void* argument: XtNewString is
a macros which uses strcpy, whose inline variant, in turn, uses
__STRING_SMALL_GET(16|32), which don't cast their (str) argument to
(char*). The patch inserts such a casting. But this is not the
X-specific problem, I just met it when was compiling X. It's a
general error - string functions should work happily with void*
arguments, so __STRING_SMALL_GET macros' must not assume their (str)
argument can't be of type void*...
Again, the second problem is not X-specific, but X-exposed (for me).
X's bzero is defined as memset, and when we have something like
bzero(..., col = screen->max_col + 1)
the inlined memset, which is a macros, dies, because there is no
brackets around the second bzero's argument, where it is used in the
macros. And, again, it is a general error - the brackets must be
there. The second chunk of the patch cures this.