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/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Fri, Apr 15, 2016 at 09:49:55PM +0200, Harald Welte wrote: > Hi Neels, > > On Thu, Apr 14, 2016 at 02:45:56PM +0200, Neels Hofmeyr wrote: > > It's useless to declare the str arg as const when all the function does is > > assign it to a non-const pointer. > > The point of doing it this way is that we don't have to write our code > in a sub-standard way, just because asn1c is written in a way that you > cannot have 'const' buffers as input into encoding. > > So 'const' here is used as a hint to the programmer, that a read-only > string is passed into this function, and hence it is input data. > > So this was very intentional. Now you can argue that my line of > thinking above is basically ignoring the reality of asn1c. But then, > don't we have actual real issues to address, than to debate about thing > slike this? Sorry... I would prefer not to debate about this as extensively, but you guys won't stop bickering ;) To resolve, I would appreciate if you either apply my patch or add the cast within the function. I still disagree and think it is the caller's duty to be aware that the asn1c struct entry is not const, and that passing such a buffer around possibly results in overwriting the data. That ugly cast should be in plain sight wherever it is necessary, not hidden away in a function call, invisible until your code breaks. I still see only the single caller that employs const data, and this caller can easily justify casting to non-const, as the use is well contained. Feel free to overrule, just please get rid of the warning... ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160418/650b4f63/attachment.bin>