<p><a href="https://gerrit.osmocom.org/c/libosmocore/+/20332">View Change</a></p><p>2 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/libosmocore/+/20332/1/src/gsm/gad.c">File src/gsm/gad.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/libosmocore/+/20332/1/src/gsm/gad.c@37">Patch Set #1, Line 37:</a> <code style="font-family:monospace,monospace">     OSMO_VALUE_STRING(OSMO_GAD_TYPE_ELL_POINT),</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">that's the style you guys use, yes. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">I'm sorry to always "fight" against your instincts here, neels. I am with pespin, though, as to me, consistency almost always overrides all other arguments.  We don't do it in general, traditionally.  So rather than having some parts of the code do A and other parts do B, we stick with "A" unless there is a strong move to migrate everything to "B".</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/libosmocore/+/20332/1/src/gsm/gad.c@250">Patch Set #1, Line 250:</a> <code style="font-family:monospace,monospace">     *gad = (struct osmo_gad){};</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">No I don't agree, there's no point in memzeroing padding unless the chunk of memory needs to be tran […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">pespin: I think we ha that discussion before, and the language construct neels uses here should be equivalent to a memset, without any room for interpretation.</p><p style="white-space: pre-wrap; word-wrap: break-word;">I would assume that for small amounts of padding between [typical integer sized] fields, there is virtually no overhead, neither in code size nor in execution time.  The CPU works on muhc larger loads/stores anyway, and I would expect the compiler to motsly optimize that away. </p><p style="white-space: pre-wrap; word-wrap: break-word;">So I don't think we should be discussing this. I think there are arguments both ways, but non of them is strong.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/libosmocore/+/20332">change 20332</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/libosmocore/+/20332"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: libosmocore </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c </div>
<div style="display:none"> Gerrit-Change-Number: 20332 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-CC: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-CC: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 01 Oct 2020 18:00:58 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Comment-In-Reply-To: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Comment-In-Reply-To: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>