This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Projects for beginners
- To: zackw at Stanford dot EDU
- Subject: Re: Projects for beginners
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 8 Mar 2001 12:39:51 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk, neil at daikokuya dot demon dot co dot uk
> From: "Zack Weinberg" <zackw@Stanford.EDU>
>
> On Wed, Jan 31, 2001 at 08:48:58AM -0500, Kaveh R. Ghazi wrote:
> >
> > > - Get rid of all remaining uses of bcopy (requires understanding
> > > the code well enough to tell whether they should be memcpy or
> > > memmove).
> > >
> > > - Then apply #pragma GCC poison to bcmp/bzero/bcopy/rindex
> > > <URL:http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00432.html>
> >
> > I'd like to poison malloc/realloc/calloc/strdup too and enforce using
> > the "x" versions from libiberty. But two or three legit uses still
> > occur. Is there a way to say use malloc even though its poisoned?
> >
> > Perhaps instead we could #define malloc() to #error and make the legit
> > uses call (malloc)() which bypasses the macro?
>
> I hesitate to use #pragma GCC poison at all because it's such a big
> hammer. It will barf, for instance, if the system headers define
> macros which refer to any of the above and we use them.
>
> There is no way to #define something to a compile-time #error, however
> we could do something like
>
> #define malloc(x) dont_use_malloc_you_luser(x)
>
> then the linker will trap them, and the legitimate users can do
> (malloc)(x) as you suggest. This too is not safe if the system
> headers define macros which use malloc. The only example I can find
> is glibc's "optimized" strdup, which we don't want to use anyway, but
> I wouldn't rule out others.
> zw
Harking back to the above discussion, I was wondering how hard it
would be to create a new directive that's slightly less "hammerish"
than "poison". (Let's call it "contaminate" for lack of a better
name.)
The way I envision this operating would be to only disallow a token if
it appeared in the actual sources. If instead it appears in a macro
expansion (defined before the directive was issued) it wouldn't
complain. This allows one to "contaminate" bzero, malloc, etc as
preferred above while not killing calls created by e.g. system
headers, etc.
Here are some examples:
> #define memcpy bcopy
> #define strdup(x) strcpy(malloc(strlen(x)+1), x, strlen(x)) /* e.g. */
>
> #pragma GCC contaminate bcopy
> #pragma GCC contaminate malloc
>
> strdup(foo, bar, baz) /* OK */
> memcpy(foo, bar, baz) /* OK */
>
> bcopy(foo, bar, baz) /* FAIL */
> malloc(foo) /* FAIL */
>
> #define memcpy bcopy /* FAIL */
Whether a FAILure is a warning or error is open to discussion, (or we
could implement both.)
Anyway, two questions:
1. Is this (within reason) possible?
2. Do ya'll think it's worthwhile?
Thanks,
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions