<p style="white-space: pre-wrap; word-wrap: break-word;">more replies in the form of comments in the next patch set... in general, let's cut the time spent here (at least sysmocom time) since we don't really have a need to support big endian. Free time is a different matter.</p><p><a href="https://gerrit.osmocom.org/11786">View Change</a></p><p>6 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py">File contrib/struct_endianess.py:</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/11786/2/contrib/struct_endianess.py@80">Patch Set #2, Line 80:</a> <code style="font-family:monospace,monospace">    # now the interesting part, go over the defs, and reverse the sub-byte ints</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">You can probably split into a different function starting from here.</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">you're right style wise, but it doesn't really have a practical benefit</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py@118">Patch Set #2, Line 118:</a> <code style="font-family:monospace,monospace">                    raise Exception('sub-byte int breaks clean byte bounds: %s -- %d + %d = %d bits'</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">what about eg. […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">Even if you use uint16_t, it must still reverse at byte boundaries.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Technically we parse any integer types, including uint16_t, but this is identical:</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">  uint8_t a:3, b:5;</pre><p style="white-space: pre-wrap; word-wrap: break-word;">and</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">  uint16_t a:3, b:5;</pre><p style="white-space: pre-wrap; word-wrap: break-word;">and in practice *all* of our sub-byte integers today are defined by uint8_t.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py@189">Patch Set #2, Line 189:</a> <code style="font-family:monospace,monospace">        if not 'packed' in struct[-1]:</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">probably better/easier to look for __atribute((packed)) or whatever is called, and check  all lines  […]</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">the regex for top-level structs only matches the end-of-struct being at the line start</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">  };</pre><p style="white-space: pre-wrap; word-wrap: break-word;">or</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">  } __attribute....;</pre><p style="white-space: pre-wrap; word-wrap: break-word;">This condition only exists because in some places we have weird booleans in the form of</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">  integer flag:1;</pre><p style="white-space: pre-wrap; word-wrap: break-word;">and these don't add up to bytes, and cause errors. So I thought let's skip all non-packed structs, then all of those are out of the picture.</p><p style="white-space: pre-wrap; word-wrap: break-word;">For the current code base that holds true...</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py@248">Patch Set #2, Line 248:</a> <code style="font-family:monospace,monospace">                        j += 1</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Not sure if this j += 1 in here applied for all cases is correct. Have a look.</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">it is correct, all ifs break, this is the iteration case</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py@276">Patch Set #2, Line 276:</a> <code style="font-family:monospace,monospace">            end_def()</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">afaiu this end_def() should be one lne above and indented one more level (inside while).</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">nope. it flushes what is left at the end</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/11786/2/contrib/struct_endianess.py@308">Patch Set #2, Line 308:</a> <code style="font-family:monospace,monospace">            raise Exception('do not know where to include osmocom/core/endian.h in %r' % f)</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Just add it around first empty line (to avoid adding if before guard IFDEF or pragma once).</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">there are currently no cases where this would be needed... am reluctant to add dead code</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/11786">change 11786</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/11786"/><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-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I8e75b17d8071c7b3a2a171ba776fb76854b28a53 </div>
<div style="display:none"> Gerrit-Change-Number: 11786 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Neels Hofmeyr <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder (1000002) </div>
<div style="display:none"> Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Pau Espin Pedrol <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Mon, 19 Nov 2018 15:31:00 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-HasLabels: No </div>