Probleme mit Macros...

[Lin728]

Grüssi!

Ich habe jetzt schon ein wenig mit Tuxracer herumgespielt, weil ich ein paar features dazustopfen will.
Leider kann ich ein File nicht mit GCC 3.3 kompilieren, es enthält Macros dieser art:



#define FN_PARAM( name, typename, type ) \
type getparam_ ## name() { \
if ( !Params. ## name ## .loaded ) { \
fetch_param_ ## typename( &( Params. ## name ) ); \
} \
return Params. ## name ## .val. ## typename ## _val; \
} \
void setparam_ ## name( type val) { \
set_param_ ## typename( &( Params. ## name ), val ); }


#define FN_PARAM_STRING( name ) \
FN_PARAM( name, string, char* )

FN_PARAM_STRING( data_dir )


die es dann so benutzt:


void init_game_configuration()
{
INIT_PARAM_STRING(
data_dir, DATA_DIR,
"# The location of the Tux Racer data files" );
}


Der GCC 3.3 regt sich dann so auf:


game_config.c:420:27: pasting "." and "data_dir" does not give a valid preprocessing token
game_config.c:420:27: pasting "data_dir" and "." does not give a valid preprocessing token
game_config.c:420:27: pasting "." and "data_dir" does not give a valid preprocessing token
game_config.c:420:27: pasting "." and "data_dir" does not give a valid preprocessing token
game_config.c:420:27: pasting "data_dir" and "." does not give a valid preprocessing token
game_config.c:420:27: pasting "." and "string" does not give a valid preprocessing token
game_config.c:420:27: pasting "." and "data_dir" does not give a valid preprocessing token

Nachdem ich eher überhaupt kein C-Hacker bin, sagen mir weder die Fehlermeldungen noch die Macros wirklich was.
Die Macros dienen anscheinend dazu, setters/getters für eine Struktur die die Konfigurationsoptionen beinhaltet zu erzeugen.
Es scheint erst Probleme mir GCC 3.x zu geben, weil mit den älteren Compiliert muss es ja funktioniert haben, sonst hätten dies nicht so gemacht :-)

[wraith]

Original geschrieben von ceisserer

Es scheint erst Probleme mir GCC 3.x zu geben, weil mit den älteren Compiliert muss es ja funktioniert haben, sonst hätten dies nicht so gemacht :-)

Der Code is' nicht korrekt,denn wie die Fehlermeldung bereits sagt,ist das Ergebnis kein gültiges Preprocessing Token.
Das Verhalten in einem solchen Fall ist undefiniert,daher kann ein Compiler eine Warnung ausgeben (wie der gcc 3.x),oder es fehlerfrei kompilieren (wie der gcc 2.x),oder was ganz ausgefallenens machen.

Wenn es nur eine Warnung is',dann ignoriere sie,ist wohl das beste was du machen kannst.

[Lin728]

Nun, warnungen macht der Tuxracer-Code genug, da mach ich mir keine Sorgen :-)
Leider bricht make bei diesem Code hart ab und nix geht mehr weiter...

Hast du eventuelle eine Idee was genau nicht stimmt. Ich weiß dass ist viel verlangt, gerade wo diese macros so schwer zu lesen sind, aber ich hab mit Macros noch nie wirklich gearbeitet.

[wraith]

Ich hab' mal gesucht,also der gcc kennt ein Flag -traditional,dann frißt er den Code,aber
GNU C no longer supports -traditional without -E

Das macht es etwas umständlicher,also schickst du die Datei vorher durch den Preprozessor.

[Lin728]

Hast du eventuell eine Idee wie man den Quellcode oben verändern könnte, dass er ohne Gemurkse auf GCC 3.x funktioniert?

[wraith]

Probier's mal hiermit


#define FN_PARAM( name, typename, type ) \
type getparam_##name() { \
if ( !Params . name .loaded ) { \
fetch_param_##typename( &( Params. name ) ); \
} \
return Params .name .val. typename##_val; \
} \
void setparam_ ## name( type val) { \
set_param_ ## typename( &( Params . name ), val ); }

[Lin728]

Danke!

Jup, jetzt funktioniert preprocessing und compiliren einwandfrei, danke.

Allerdings hab ich jetzt wieder ein problem:

Wenn ich das gerade kompilierte Tuxracer starte, becomme ich die meldung (oder so ähnlich):

SDL_Parachute(Deployed)
Segfault

...obwohl ich bis auf die Makro-Änderung gar nichts verändert habe. Und selbst die Makros müssten wenigstens beim Kompilieren oder Linken spucken....

Ich habe das ganze mit dem GDB verfolgt und dabei kam das raus (backtrace)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 4224)]
0x404ffdd7 in __strtod_internal () from /lib/i686/libc.so.6
(gdb) bt
#0 0x404ffdd7 in __strtod_internal () from /lib/i686/libc.so.6
#1 0x080aaf96 in text_colour ()
#2 0xbfffe588 in ?? ()
#3 0x40231b5e in TclGetNamespaceForQualName () from /usr/lib/libtcl8.4.so
Previous frame inner to this frame (corrupt stack?)

Ist dies ein SDL-Problem (NWN hatte ja auch dieses Problem ziemlich lange auf manchen Rechnern), oder ein Problem mit TCL.
Hat irgendjemand eine Idee an was das liegen könnte?

[Lin728]

Werd das mal i Scriptsprachen-Forum posten.

Danke für die Hilfe,