Change in osmo-bts[master]: common/rsl.c: fix unaligned pointers in rsl_add_rtp_stats()

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/gerrit-log@lists.osmocom.org/.

Harald Welte gerrit-no-reply at lists.osmocom.org
Wed Apr 24 07:47:17 UTC 2019


Harald Welte has posted comments on this change. ( https://gerrit.osmocom.org/13768 )

Change subject: common/rsl.c: fix unaligned pointers in rsl_add_rtp_stats()
......................................................................


Patch Set 1:

I actually think this is bogus. We are not type-casting uint32_t values (or structs containing uint32_t) to random locations in memory.  Rather, we are puting a struct if uint32_t on the stack and then passing pointers to members of it.  I would have assumed that the compiler puts the structure on the stack in a way that the uint32_t are properly aligned.

After all, if you had all those uint32_t individually on the stack, you would also expect they're all 32bit aligned and you could use them as uint32_t.

Maybe it's the __attribute((packed)) which is putting clang off?  It's not really needed here, as all (I hope at least) architectures are putting two uint32_t next to each other in a struct, without any padding.  Maybe there were any early "true" 64bit architectures like ppc64 or itanium or sparc65 that would align them on 64bit boundaries, but I somehow doubt it.


-- 
To view, visit https://gerrit.osmocom.org/13768
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
Gerrit-Change-Number: 13768
Gerrit-PatchSet: 1
Gerrit-Owner: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-CC: Harald Welte <laforge at gnumonks.org>
Gerrit-Comment-Date: Wed, 24 Apr 2019 07:47:17 +0000
Gerrit-HasComments: No
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190424/a3023ae3/attachment.htm>


More information about the gerrit-log mailing list