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/.
Holger Hans Peter Freyther holger at freyther.deOn Fri, Feb 28, 2014 at 08:47:46PM +0100, Jacob Erlbeck wrote: Good Morning, I welcome any change that makes it more difficult to create the mess that LAPD/LAPDm is in. I have some questions and comments though. > 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? > This patch declares these fields as const if > MSGB_DISABLE_DIRECT_WRITE is defined. Doing so may lead to warnings > and errors, therefore this macro is only defined for libosmocore yet, > where at least the errors are also fixed by this patch. 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. > -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? > +#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 > + const uint16_t data_len; /*!< \brief length of underlying data array */ > + const uint16_t len; /*!< \brief length of bytes used in msgb */ > + unsigned char const *head; /*!< \brief start of underlying memory buffer */ > + unsigned char const *tail; /*!< \brief end of message in buffer */ > + unsigned char const *data; /*!< \brief start of message in buffer */ > +#else > + union { > + MSGB_CONST uint16_t data_len; > + uint16_t __data_len; > + }; Anyone knows an ABI where alignment for const/non-const is different? :) cheers holger