<pre class="notranslate">Forwarded conversation
Subject: [golang-dev] unsafe.Sizeof
------------------------

From: Anthony Martin &lt;ality@pbrane.org&gt;
Date: Sat, Jun 4, 2011 at 13:10
To: golang-dev@googlegroups.com


I've been working out some issues in the compiler related to
types with very large sizes and I'm almost ready to send out
a CL.  Before doing so, however, I'd like some clarification
on the intended semantics of unsafe.Sizeof.

Should unsafe.Sizeof be able to represent the size of every
valid type and if so, should we allow types larger than the
maximum positive signed 32-bit integer?

Right now, there are a few parts of the compiler that are a
bit too cavalier with the width of a type.

Thanks,
 Anthony

----------
From: Ian Lance Taylor &lt;iant@google.com&gt;
Date: Sat, Jun 4, 2011 at 16:20
To: Anthony Martin &lt;ality@pbrane.org&gt;
Cc: golang-dev@googlegroups.com


My opinion: Yes.  No.  (Or, rather, we should not allow types larger
than the size of int, which is currently 32 bits.)

Ian

----------
From: Russ Cox &lt;rsc@golang.org&gt;
Date: Tue, Jun 7, 2011 at 14:51
To: Ian Lance Taylor &lt;iant@google.com&gt;
Cc: Anthony Martin &lt;ality@pbrane.org&gt;, golang-dev
&lt;golang-dev@googlegroups.com&gt;


I think unsafe.Sizeof should return uintptr.
It's possible that unsafe.Alignof should too.
This would be a language change.

----------
From: Ian Lance Taylor &lt;iant@google.com&gt;
Date: Tue, Jun 7, 2011 at 15:45
To: rsc@golang.org
Cc: Anthony Martin &lt;ality@pbrane.org&gt;, golang-dev
&lt;golang-dev@googlegroups.com&gt;


Works for me.

Ian

----------
From: Rob 'Commander' Pike &lt;r@google.com&gt;
Date: Fri, Jun 10, 2011 at 03:22
To: Ian Lance Taylor &lt;iant@google.com&gt;
Cc: rsc@golang.org, Anthony Martin &lt;ality@pbrane.org&gt;, golang-dev
&lt;golang-dev@googlegroups.com&gt;


LGTM</pre>
<p dir="auto">I regret having to bring up anything related to sockets. I hate them as much as the next gopher.</p>
<p dir="auto">There are some cases[1] where setting socket options (like <code class="notranslate">SO_REUSEPORT</code>) is just unavoidable. In most cases, we can pull out the <code class="notranslate">conn.File()</code> and set them. But those few annoying cases where the option must be set on the socket <em>before</em> listening or dialing are impossible to handle with today's net package. (please tell me i'm wrong!)</p>
<p dir="auto">"Setting the socket up yourself" <em>is not</em> a good option. Getting sockets right is not trivial-- there are bound to be dozens of tricky corner cases across platforms. <a href="https://github.com/jbenet/go-reuseport">I gave it a shot</a>, but I keep finding problems in various OSes. It would be much more user friendly to stick to the <code class="notranslate">net</code> interface which already had to do all this hard work.</p>
<p dir="auto">Now, I would even go as far as to copy the <code class="notranslate">net</code> package wholesale just to add this feature, but AFAIK the existence of the <code class="notranslate">runtime·</code> functions makes this also impossible (such a <code class="notranslate">netcopy</code> wont compile). Without them, we're left up to whittling down <code class="notranslate">netcopy</code> (and exchanging the runtime polling for <code class="notranslate">select/epoll/ugliness</code>) , most likely introducing more bugs.</p>
<p dir="auto">A nice way to solve this -- I think -- is to make listeners and dialers have "tuners", as implemented in <a href="https://github.com/benburkert/net.tune/">https://github.com/benburkert/net.tune/</a> [3]. This approach is based on rob's <a href="http://commandcenter.blogspot.nl/2014/01/self-referential-functions-and-design.html" rel="nofollow">self-referential functions</a>, and manages to contain the ugly, exposing a nice interface.[4] But I imagine there are many other approaches that are even nicer and idiomatic.</p>
<p dir="auto">I know-- the stdlib is trying to contain the ugly as much as possible and prevent it from spreading. But in this type of case, the current state of affairs brings it out more for some of us.</p>
<hr>
<p dir="auto">[1] One example: being able to dial out from the same TCP port you're listening on is a <em>requirement</em> for some kinds of NAT traversal.</p>
<p dir="auto">[2] There's issues in this very tracker showing <em>years</em> of tuning the use of sockets.</p>
<p dir="auto">[3] Specifically: <a href="https://github.com/benburkert/net.tune/blob/master/dial.go#L59-L63">https://github.com/benburkert/net.tune/blob/master/dial.go#L59-L63</a></p>
<p dir="auto">[4] It could be done with new functions -- or if the goal is to keep the interface thin, a variadic argument to the existing functions should be backwards compatible.</p>