Bug 24521 - void* arithmetic in string2.h for memset()
Summary: void* arithmetic in string2.h for memset()
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i686 Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-21 21:59 UTC by Need Real Name
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-23 17:31:25 UTC
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 14:13 UTC, Need Real Name
no flags Details

Description Need Real Name 2001-01-21 21:59:49 UTC
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 11:06:45 UTC
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 14:13:44 UTC
Created attachment 8069 [details]
preprocessed output of "try_memset" testcase, gcc -O -E.

Comment 3 Need Real Name 2001-01-23 14:22:56 UTC
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 14:39:05 UTC
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 17:31:22 UTC
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.