GNOME Bugzilla – Bug 764116
doc: explicitely specify if typelib is or not arch dependent
Last modified: 2017-09-11 01:57:22 UTC
Created attachment 324645 [details] [review] Enhance doc From what I understood from bug 592311 comment 18, the typelib format depends on the endianness of g-ir-compiler: explicitely say so in the doc.
Created attachment 324646 [details] [review] I screwed the old docblock.
Review of attachment 324646 [details] [review]: Sure. I'd also note that what the typelib is *describing* is also architecture-independent.
So it is the other way around: apart the endianness everything is portable. Ok, I updated the patch to reflect this fact: fill free to reword it.
Created attachment 324765 [details] [review] Reword to say typelib is portable *but* the endianness of its scalar values
Review of attachment 324765 [details] [review]: Sorry for taking this long. LGTM.
commit dbf2106c68829141403c4877b4ed8dffaf6802c5 Author: Nicola Fontana <ntd@entidi.it> Date: Thu Mar 24 05:15:51 2016 +0100 docs: manifest typelib format portability Apart the endianness of its scalar values the typelib binary format must be considered arch-independent: make it clear in the docs.
This is in fact incorrect: both the typelib and the gir are architecture dependent. They are generated from information that comes after (architecture-dependent) preprocessing of C sources. In the extreme case, the API could be architecture dependent, as in #ifdef __x86_64__ void example_foo_bar (void); #endif will add the .foo_bar() function only on x86_64. In the common, and real case, macro values containing integer sizes, minimum and maximum values (eg. G_MAXINT) are architecture dependent and are copied verbatim in the gir and typelib.