[patch] bus error in gcry_free

Christian Biere christianbiere at gmx.de
Fri Feb 2 16:31:41 CET 2007

Werner Koch wrote:
>        6.5.8  Relational operators
>    =>  expression P points to an element of an array object and the
>    =>  expression  Q  points  to the last element of the same array
>    =>  object, the pointer expression Q+1 compares greater than  P.
>        In all other cases, the behavior is undefined.
> Well, strictly interpreting you may be right.  However, this is
> irrelevant given that we assume a linear address space.  I also doubt
> that C-89 has the same requirements and that is what we code for.

GCC cannot be used as a strict C89 compiler and by default it assumes
C99ish flavour.
> Anyway, such an interpretation of the specs is similar to the rule
> that you can't clear a structure with pointer elements by using
> memset.

Well, for float/double this isn't an esoteric issue at all. Also similar code
can easily cause aliasing issues. I find it much cleaner to clear structures
using struct copying using a static const variable. This will definitely do the
right thing and isn't any more effort. Typically this happens in one or two
places for each struct only anyway.

> Almost everyone is ignoring that and I don't want to get
> back to the time of segmented memory architectures.

This has nothing to do with segmented memory. That's just one example to
illustrate why such code might fail. The standard does not define this as
"implementation-defined" in which case declaring platforms with segmented
memory as unsupported would be fine. The standard say "undefined behavior" and
that's emphasized by mentioning it. It would still be "undefined behavior"
without the last sentence, as explained in some earlier section of the

In your case you might (still) be lucky because the compiler isn't sufficiently
smart but since everything happens in a single file with static variables, it
would be easy to prove that pool points to a memory object of pool_size bytes.

For example, very similar checks definitely do not work at all with GCC 4.x:


Casting pointers to integers and vice-versa is implementation-defined and will
typically do exactly what you expect. So if I wanted to use such checks at all,
I'd certainly use size_t (or unsigned long) because arithmetic with unsigned
integers is well-defined.


More information about the Gcrypt-devel mailing list