some doubts in glib code

**Barry Schwarz** · Jun 29 '08, 10:05 PM

Re: some doubts in glib code

On Sun, 29 Jun 2008 04:26:20 -0700 (PDT),
"ramasubramania n.rahul@gmail.c om" <ramasubramania n.rahul@gmail.c om>
wrote:

>hi people..
>dont know if this the right forum for this doubt ... so sorry if i am
>mis-posting...
>i was looking at the way glib 2.10.3 does export optimization using a
>list of "to be exposed" function names in a file caleed glib.symbols.
>this file is used by a perl script to generate a header a .c file
>( galias.h and galiasdefs.c). This files essentially enusres default
>visibility for these functions (using the __attribute__(( default))__
>option) , while building the rest of the functions with -
>fvisibility=hi dden.
>i have two doubt regarding this.
>1in the generated header galias.h there is a syntax
>#define IN_FILE(x) 1
>#define IN_HEADER defined
>
>#if IN_HEADER(__G_A RRAY_H__)
>#if IN_FILE(__G_ARR AY_C__)
>extern __typeof (g_array_append _vals) IA__g_array_app end_vals
>__attribute((v isibility("hidd en")));
>#define g_array_append_ vals IA__g_array_app end_vals
>...
>.....
>#endif
>#endif
>
>whnat does #define IN_HEADER defined mean.. and how is it used
>in this context.

It tells the compiler that whenever it sees the token
IN_HEADER
it should substitute the token
defined

Consequently, the directive
#if IN_HEADER(__G_A RRAY_H__)
is processed as if it were
#if defined(__G_ARR AY_H__)

It takes some reasonably obvious syntax and obfuscates it by adding an
alias. In my opinion, this is one of those bad ideas along the lines
of
#define BEGIN {

>
>2secondly , how does glib maintain the glib.symbols list .. is it
>manual or does it use some kind of a parser to parse through the
>include folder of glib to come up with the list...
>hope i have been able to clearly state my doubts....

Ask in a glib group.

Remove del for email

some doubts in glib code

some doubts in glib code

Comment