On Tue, Jan 20, 2004 at 02:51:17PM +0100,  Marc A. Lehmann  wrote:
> On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh <[EMAIL PROTECTED]> wrote:
> > Well, the bulk of the code in gimp that causes warnings is stuff like:
> > void foo (void **p);
> > 
> > void bar (void)
> > {
> >   int *i;
> >   foo ((void **) &i);
> > }
> > 
> > While it does break the letter of the law wrt aliasing rules, are there any
> > assumptions that the compiler can legally make that would cause problems?
> Well, troubling to me would be the fact that a int is not the same as
> a void *, so this very example is a bit strange and could likely cause
> problems on 64-bit (or else) architectures, but that is, of course, not
> the main point.

You misread. To explain further:

void set_null (void **p)
  *p = NULL;

void foo (void)
  int *i;
  set_null ((void **) &i);  

Which basically sets i = NULL. I don't see how this can be a problem on a
64-bit architectures, since pointers to all types are the same size.

gimp actually only does this with external functions, like:

void        g_object_add_weak_pointer         (GObject        *object,
                                               gpointer       *weak_pointer_location);


gboolean              g_module_symbol        (GModule      *module,
                                              const gchar  *symbol_name,
                                              gpointer     *symbol);

Perhaps the API should be fixed, I dunno.

> I don't know the real case this is based on, but I'd wonder what this code
> is supposed to do then. Please note that the warning will not happen when
> you cast to a void *, since the pointers might alias then.

Sure, I know ways of working it around it. My preferred fix is not to
cast to a void *, but use a temporary void * and assign back, since that
adds some type safety instead of casting.

> Legally, the compiler could cache the contents of i in a register before
> and after the call, because foo is not allowed to change it's value.  (And
> I might guess that foo will not do that, but it's equally hard to see this
> as a compiler as it is for a human, so the warning is IMnsO justified).

Ah, that answers my question, thanks.

> It's unlikely that this will happen with gcc <= 3.5, which is, IMHO,
> a viable platform to tie oneself to, but there are no guarentees that
> this won't happen in more complicated cases, with other (less or more
> intelligent) compilers or with future gcc versions.
> It's hard to judge from his example, but right now it's difficult for
> me to imagine a valid use for the above that couldn't easily be written
> correctly.
> To repeat it: I am quite certain that the above example will simply work
> for quite some time in the future, because of some gcc assumptions about
> pointers that are difficult to change but make no good otimized code.
> Perl does similar pointer castings and has opted the safe way by simply
> using -fno-strict-aliasing to compile itself at all times, after being
> bitten once.
> That might be easier then going through all the code and fixing it, and
> will of course silence the warning. Right now, it doesn't make much of a
> difference in generated code with gcc, as it is not very good at taking
> advantage of (no-) aliasing yet, but this is a hot area in gcc, since
> exploiting aliasing rules allow a great deal of optimizations in typical
> numerical code.

Well, one problem is that flagging every violation like this makes people
tend to ignore the warning, which means real problems which affect gcc's
alias analysis *now* are likely to be overlooked, or heavy handed solutions
like -fno-strict-aliasing put in. It'd be much nicer if this warning didn't
trigger for function parameters (except with -pedantic) until gcc was closer
to doing the alias analysis that would manifest a problem.

As it stands, right now the warning mainly confuses people. It doesn't help
that the aliasing rules aren't spelled out anywhere in the gcc docs. I was
actually skeptical that gcc might be buggy in this regard, until I dug up
the appropriate bits of the standard that say what's going on.

Gimp-developer mailing list

Reply via email to