Bug 24521 - void* arithmetic in string2.h for memset()
void* arithmetic in string2.h for memset()
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
6.2
i686 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-21 16:59 EST by Need Real Name
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-23 12:31:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
preprocessed output of "try_memset" testcase, gcc -O -E. (19.01 KB, text/plain)
2001-01-23 09:13 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2001-01-21 16:59:49 EST
The macros that get expanded for "memset()" in /usr/include/bits/string2.h
trigger a boatload of GCC warnings when compiling with extensive warnings
enabled.  As best as I can tell, the code which triggers this warning can
be fixed by changing the (void *) casts to (char *) casts in places where
the macro does such questionable acts at this:   "((void *) __u + 4)"  (In
ANSI C at least, pointer arithmetic on (void *) is undefined.  GCC seems to
treat it as identical to arithmetic on a (char *).)

To give you an idea of what's going on, consider the following short
program, and what happens when it is compiled with "gcc -Wpointer-arith
-O":

#include <string.h>

void try_memset(char *x, int y, int z)
{
        memset(x, y, z);
}


GCC spews the following warnings:

$ gcc -Wpointer-arith -O -c foo.c
/usr/include/bits/string2.h: In function `__strcpy_small':
In file included from /usr/include/string.h:346,
                 from foo.c:1:
/usr/include/bits/string2.h:419: warning: pointer of type `void *' used in
arithmetic
/usr/include/bits/string2.h:427: warning: pointer of type `void *' used in
arithmetic
/usr/include/bits/string2.h:432: warning: pointer of type `void *' used in
arithmetic
/usr/include/bits/string2.h:437: warning: pointer of type `void *' used in
arithmetic
/usr/include/bits/string2.h:439: warning: pointer of type `void *' used in
arithmetic
/usr/include/bits/string2.h:444: warning: pointer of type `void *' used in
arithmetic
foo.c: In function `try_memset':
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic
foo.c:5: warning: pointer of type `void *' used in arithmetic

That's just simply BOGUS in my opinion. 

FWIW, here is the pertinent information on my system:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

$ rpm -q -f /usr/include/bits/string2.h 
glibc-devel-2.1.3-21



Regards,

--Joe ( im14u2c@primenet.com )
Comment 1 Jakub Jelinek 2001-01-23 06:06:45 EST
Cannot reproduce it on either 6.2 with glibc-devel-2.1.3-21/egcs-1.1.2-29
nor on 7.0 with glibc-devel-2.2.1-2/gcc-2.96-71.
AFAIC all void * arithmetics is done in __extension__ marked statements.
Can you make sure you really have bits/string2.h from glibc-devel-2.1.3-21?
Can you attach here preprocessed source?
gcc -E foo.c -o foo.i
Comment 2 Need Real Name 2001-01-23 09:13:44 EST
Created attachment 8069 [details]
preprocessed output of "try_memset" testcase, gcc -O -E.
Comment 3 Need Real Name 2001-01-23 09:22:56 EST
Ack... After filing the bug, I upgraded to "glibc-devel-2.1.3-22" in a (failed)
attempt to solve the problem on my machine.  (I still do have the same problem
with 2.1.3-22, though.)  I can't readily find "2.1.3-21" this morning,
so the attached preprocessed output is from "2.1.3-22".  Sorry about that.  :-/

The main thing to note is that you must use "-O".  I've attached the requested
preprocessed output using "gcc -E foo.c -O -o foo.i".  Without -O, the call to
memset remains a function call.

And yes, the (void*) arithmetic is in an __extension__ block.

I verified that the bits/strings2.h I'm seeing is from the
glibc-devel-2.1.3-22.rpm with the following commands:

# rpm -q -f /usr/include/bits/string2.h
glibc-devel-2.1.3-22
# rpm --verify glibc-devel-2.1.3-22

Is there something else I should try?  Also, can you point me to where I can get
glibc-devel-2.1.3-21 in case you need me to produce pre-processed output w/ -21?

Regards,

--Joe
Comment 4 Jakub Jelinek 2001-01-23 09:39:05 EST
You cannot use 6.2 egcs though, this was fixed by
Wed Sep  1 09:12:02 1999  Jim Kingdon  <http://developer.redhat.com>

        * c-parse.in: save and restore warnpointerarith on __extension__
        along with pedantic.
        * extend.texi (Alternate Keywords): Adjust documentation.
patch (egcs-1.1.2-warn.patch) which appeared already in egcs-1.1.2-24
(released in Red Hat Linux 6.1). The same patch is in egcs-1.1.2-30 (RHL 6.2)
and on Sep 22th, 1999 made it into CVS gcc (thus is e.g. in gcc-2.96-RH,
gcc-2.97 (CVS head), it did not make it into gcc-2.95.2 though).
Comment 5 Need Real Name 2001-01-23 12:31:22 EST
Ok, you spotted the problem.  For some reason I have "egcs-1.1.2-12".  I thought
I had fully upgraded this particular box to RH6.2, but I guess not.  (The box
has been running RH since 4.2, and I usually upgrade it every second version or
so.) 

Thank you for your help.  I apologize for the confusion.

Note You need to log in before you can comment on or make changes to this bug.