<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>On 03/09/2015 04:38, Salz, Rich
wrote:</tt><tt><br>
</tt></div>
<blockquote class=" cite"
id="mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com"
cite="mid:d94ce72a658b40c9b20333e532d32249@ustx2ex-dag1mb3.msg.corp.akamai.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<tt>
</tt>
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<tt>
</tt>
<style>#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com p.MsoNormal,
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com li.MsoNormal,
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com div.MsoNormal { margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri","sans-serif"; }
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com a:link,
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com span.MsoHyperlink { color: blue; text-decoration: underline; }
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com a:visited,
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com span.MsoHyperlinkFollowed { color: purple; text-decoration: underline; }
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com span.EmailStyle17 { font-family: "Calibri","sans-serif"; color: windowtext; }
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com .MsoChpDefault { font-family: "Calibri","sans-serif"; }
#mid_d94ce72a658b40c9b20333e532d32249_ustx2ex_dag1mb3_msg_corp_akamai_com div.WordSection1 { page: WordSection1; }
</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><tt>We are considering a big cleanup to the
memory-allocation API’s in the next release.</tt><tt><o:p></o:p></tt></p>
<p class="MsoNormal"><tt>Please take a look at the attached
documentation, which describes *</tt><tt><b>ALL</b></tt><tt>*
of the public functions, and let us know if it will cause a
problem.</tt><tt><o:p></o:p></tt></p>
</div>
</blockquote>
<tt>A few practical notes:</tt><tt><br>
</tt><tt><br>
</tt><tt>1. I trust that functions to allocate specific data <br>
types (such as bignums) are not changed by this.</tt><tt><br>
</tt><tt><br>
</tt><tt>2. Macros that take zero arguments (such as <br>
"OPENSSL_malloc_init()") are not accepted by all <br>
compilers. In my own API designs this has forced <br>
me to give such macros a dummy argument (which is <br>
never used, it just pleases the preprocessor).</tt><tt><br>
</tt><tt><br>
</tt><tt>3. When compiling without compile-time debug flags, <br>
the various debug arguments should not be passed <br>
(or otherwise referenced) by the macros, avoiding <br>
a bunch of "foo.c" and line number values from <br>
filling up the compiled binary. Something like</tt><tt><br>
</tt><tt><br>
</tt><tt>#ifdef SOME_DEBUG_DEFINE</tt><tt><br>
</tt><tt>#define OPENSSL_malloc(num) (CRYPTO_malloc(num, __FILE__,
__LINE__))</tt><tt><br>
</tt><tt>...</tt><tt><br>
</tt><tt>#else</tt><tt><br>
</tt><tt>#define OPENSSL_malloc(num) (CRYPTO_malloc(num, NULL, 0))</tt><tt><br>
</tt><tt>// OR</tt><tt><br>
</tt><tt>#define OPENSSL_malloc(num) (CRYPTO_malloc_nodbg(num))</tt><tt><br>
</tt><tt>
...</tt><tt><br>
</tt><tt>
#endif</tt><tt><br>
</tt><tt><br>
</tt><tt>4. For the basic functions (not the callbacks), there <br>
seems to be no reason not to change to size_t now.</tt><tt><br>
</tt><tt><br>
</tt><tt>5. Given the huge number of backward incompatibilities <br>
in OpenSSL 1.1.x, this seems a good time to change to <br>
size_t in the callbacks too.</tt><tt><br>
</tt><tt><br>
</tt><tt>6. Maybe there should be an alternate get/set_mem_functions
<br>
with non-linenumber callbacks (behind the scenes, either <br>
would set the the other callbacks to stubs that add/remove <br>
the extra args, the initial defaults would be direct for <br>
speed and to support the "defer to default implementation" <br>
scenarios).</tt><tt><br>
</tt><tt><br>
</tt><tt>7. Maybe the get/set_mem_functions should (in their debug <br>
variant) should also be able to change the backend for <br>
debug_push/_pop.</tt><tt><br>
</tt><tt><br>
</tt><tt>8. For readability, defines with omitted (opaque) <br>
definitions should be documented with elided args such <br>
as #define OPENSSL_malloc(num) ... and <br>
#define CRYPTO_MEM_CHECK_ON 0x... to indicate that they <br>
do not (typically) expand to nothing/typically do expand <br>
to a numeric constant</tt><tt><br>
</tt><tt><br>
</tt><tt>9. Typo: "pointers for with the current functions"</tt><tt><br>
</tt><tt><br>
</tt><tt>10. It would be helpful to clarify which older functions
are <br>
getting removed. It's a bit like reading a patch without <br>
the removed lines. Kind of impossible to tell what you <br>
propose to remove.<br>
</tt><tt><br>
</tt><tt><br>
<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy (NOT A CONTRIBUTION)
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>