linux-gcc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Riepe <michael@stud.uni-hannover.de>
To: Denis Zaitsev <zzz@cd-club.ru>
Cc: Andreas Jaeger <aj@suse.de>, Ulrich Drepper <drepper@redhat.com>,
	libc-alpha@sources.redhat.com, linux-gcc@vger.kernel.org
Subject: Re: glibc 2.3.1: fix for the i386 inline strings code
Date: Tue, 7 Jan 2003 19:40:08 +0100	[thread overview]
Message-ID: <20030107194008.43255@thrai.stud.uni-hannover.de> (raw)
In-Reply-To: <20030107084301.A21395@natasha.zzz.zzz>; from Denis Zaitsev on Tue, Jan 07, 2003 at 08:43:01AM +0500

On Tue, Jan 07, 2003 at 08:43:01AM +0500, Denis Zaitsev wrote:
[...]
> 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*...

To be more specific: __STRING_SMALL_GET expects the (str) argument to
be an `unsigned char *'. Everything else will make it do funny things
when (signed) characters have values >= 128. Since __strcpy_a_small()
and __stpcpy_a_small() pass the pointer unmodified, they're broken as
well.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"

  reply	other threads:[~2003-01-07 18:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-06  1:30 glibc 2.3.1: fix for the i386 inline strings code Denis Zaitsev
     [not found] ` <u8u1gm7fwy.fsf@gromit.moeb>
2003-01-07  3:43   ` Denis Zaitsev
2003-01-07 18:40     ` Michael Riepe [this message]
2003-01-08  5:35       ` Denis Zaitsev
2003-01-14  6:43 ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030107194008.43255@thrai.stud.uni-hannover.de \
    --to=michael@stud.uni-hannover.de \
    --cc=aj@suse.de \
    --cc=drepper@redhat.com \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-gcc@vger.kernel.org \
    --cc=zzz@cd-club.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).