[GRASS-dev] GRASS 7: Potential ctype issue? "Could not parse macro"

[Glynn Clements]

Markus Neteler wrote:

> I just recompiled G7 and saw this one:
> Warning: Could not parse macro "#define serialize_int32_le(buf,x) do {
> ( buf ) [ i0 ] = ( ( x ) >> i0 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
> i8 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i16 ) & i255 ; ( buf ) [ i3
> ] = ( ( x ) >> i24 ) & i255 ; } while ( i0 )"
> Warning: Could not parse macro "#define serialize_int32_be(buf,x) do {
> ( buf ) [ i0 ] = ( ( x ) >> i24 ) & i255 ; ( buf ) [ i1 ] = ( ( x ) >>
> i16 ) & i255 ; ( buf ) [ i2 ] = ( ( x ) >> i8 ) & i255 ; ( buf ) [ i3
> ] = ( ( x ) >> i0 ) & i255 ; } while ( i0 )"

> Anything serious (esp. "Could not parse macro") or can it be happily ignored?

This is not new, and it can be ignored.

ctypes tries to convert macro definitions to either variables or
functions, but there are limits to what it can handle. Specifically,
the macro body must be either empty, a type name, or a constant
expression.

So e.g. the deserialize_int32_le and deserialize_int32_be macros in
gis.h get converted to Python functions in gis.py, but the
corresponding serialize macros can't be handled as their bodies are
statements rather than constant expressions, and so no equivalents
exist in the generated gis.py file.

I doubt that anyone would actually want to use these macros from
Python anyhow. The struct, ctypes or numpy modules would be more
appropriate.

The warnings can be avoided by guarding the macro definitions with
"#ifndef CTYPESGEN".

-- 
Glynn Clements <glynn at gclements.plus.com>