[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Simplify use of apr_hash_this()

From: Philip Martin <philip_at_codematters.co.uk>
Date: Tue, 30 Jun 2009 19:19:39 +0100

Julian Foad <julianfoad_at_btopenworld.com> writes:

> We're still not on the same page. That's not "the" problem, but "a"
> problem. The problem you are describing is that apr_hash_this() is not
> safe on mixed-pointer-size systems. I believe that is a problem with the
> API of apr_hash_this().

It's standard C, it's even in the comp.lang.c FAQ:


> I am not trying to solve that problem. I am happy to let that problem
> continue to exist.
> I am trying to solve the problem of source code verbosity. We currently
> use verbose code (either temporary variables or explicit casts) at the

Are we using explicit casts? I thought we always used temporary

> point of use of apr_hash_this() to achieve correct and warning-free
> compilation (on a restricted but generally sufficient set of machine
> architectures), whereas we could (and I want to) achieve the same with
> terse code.
> I believe that introducing intermediate type casts to the arguments to
> apr_hash_this() silences the "incompatible pointer" warnings without
> being any more unsafe than the API already is, and without worsening the
> mixed-pointer-size problem that already exists.

If you are replacing the temporary variables with casts you are making
the code worse (strictly speaking you are making the code invalid).

> I'm not clear whether you think I'm trying to (or need to) solve the
> mixed-pointer-size problem, or whether you think my addition of an
> intermediate cast introduces the mixed-pointer-size problem or makes it
> worse, or something else.
> Another clarification please?

I think we should be writing valid code.

Received on 2009-06-30 20:20:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.