This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Jacob Erlbeck jerlbeck at sysmocom.deHi, On 02.03.2014 08:24, Holger Hans Peter Freyther wrote: > On Fri, Feb 28, 2014 at 08:47:46PM +0100, Jacob Erlbeck wrote: > >> Writing directly to following struct fields may cause inconsistencies >> that hard to debug: > >> In general, the available macros and functions should be used to >> modify them instead. > > ^ must as in RFC? Rather "should" as in RFC2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. But I don't really see many 'particular circumstances' that would justify that. Perhaps something like: It's impossible to achieve with the existing API _and_ the current libosmocore must be used _and_ the new functionality is wrapped in a new macro/function written specifically for that purpose. Or did you mean "MUST (...)" as in RFC6919 ;-) > > I will get back to this later as well. Have you looked at GSEAL > of GTK+ 2.0? Their goal was to hide direct access to variables too > and they introduced a macro like: > > #ifndef GSEAL > /* introduce GSEAL() here for all of Gdk and Gtk+ without the need to modify GLib */ > # ifdef GSEAL_ENABLE > # define GSEAL(ident) _g_sealed__ ## ident > # else > # define GSEAL(ident) ident > # endif > #endif /* !GSEAL */ > > It is not making the variables const but hiding them with a rename > and causing a compilation failure when being accessed. I'm only addressing write access (yet), so sealing wouldn't help here. That would be different, if we was forbidding direct access to the fields completely, e.g. to make certain optimizations possible. > >> -AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include >> +export AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -DMSGB_DISABLE_DIRECT_WRITE > > Is that really necessary? AM_CPPFLAGS has not been passed to the sub-makes and thus wasn't honoured at all. But I'll remove the 'include' stuff from that variable, because it had worked pretty well without them so far. > >> +#ifdef DOXYGEN > > My take would be that we try to avoid direct access so we don't need > to document these variables and can use \internal here. I think it is > preferable to avoid the situation where the ABI changes based on an > external define (even if it is just for documentation now). I have seen > a lot of wild CFLAGS/CPPFLAGS that users set while working on OpenEmbedded Ok, I didn't want to break the Doxygen output, but having inconsistent variants is worse (it's already broken, see the 'const'). I'll gladly remove it. > > Anyone knows an ABI where alignment for const/non-const is different? :) It's a qualifier only, and according to C99, 6.2.5 (23): "the qualified or unqualified versions of a type are distinct types that belong to the same type category and have the same representation and alignment requirements." and "The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions." Jacob