No subject
Fri Sep 2 03:59:05 CDT 2011
struct foo *tmp;
...
tmp =3D ast_calloc(1, sizeof(*tmp));
Avoid the combination of ast_malloc() and memset(). Instead, always use ast=
_calloc(). This will allocate and zero the memory in a single operation. In=
the case that uninitialized memory is acceptable, there should be a commen=
t in the code that states why this is the case.
Considering that this would be initialization code and not something that w=
ould be run in a tight loop, the optimization isn't a particularly big deal=
. We decided long ago to err on the side of caution to protect against peop=
le checking if (!foo->bar) against unitialized data. In this case, I would =
assume that it would be safe since __ast_string_field_init initializes the =
strings to empty (if I'm reading it correctly, I haven't looked at the stri=
ngfields code much). We just have a strong preference to using calloc as a =
general rule unless it is in an area where performance is really greatly af=
fected during normal runtime.
- Terry
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1549/#review4615
-----------------------------------------------------------
On Oct. 31, 2011, 3:47 a.m., wdoekes wrote:
> =
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1549/
> -----------------------------------------------------------
> =
> (Updated Oct. 31, 2011, 3:47 a.m.)
> =
> =
> Review request for Asterisk Developers.
> =
> =
> Summary
> -------
> =
> This patch fixes that Asterisk can be properly built on certain architect=
ures that dislike misalignment. (In the case of the bug reporter, an ARM.)
> =
> =3D=3DBackground=3D=3D
> Currently the 16bit ast_string_field_allocation used in the is not aligne=
d, it can be stored on an 8bit boundary. Certain machines will either SIGBU=
S over this or simply give wrong results. For the Sparc an #ifdef was added=
to alleviate the problem.
> =
> =3D=3DProblems with current approach=3D=3D
> (1) The x86 can cope with misaligned integers, but for performance, align=
ed ints are better.
> (2) The #ifdef did not catch all architectures that dislike misalignment.
> (3) The code in the #ifdef falsely assumes that the ast_string_field_allo=
cation is at most 2 bytes large. If this were to change one day, things wou=
ld start to fail again.
> =
> =3D=3DPossible fixes=3D=3D
> (1) Remove the #ifdef, always run the Sparc code and patch it to cope wit=
h larger than 16bit ast_string_field_allocation's.
> (2) Alter all ast_string_field_allocation code to ensure that base and us=
ed stay aligned. Then we won't need to check and re-align later on.
> =
> I chose fix #2 because I believe this to be marginally faster and more lo=
gical. This does involve the use of the gcc __attribute__((aligned)). But t=
he other code is full of gcc attributes, so I don't think I'm breaking a bu=
ild anywhere with this.
> =
> Regards,
> Walter
> =
> =
> This addresses bug ASTERISK-17310.
> https://issues.asterisk.org/jira/browse/ASTERISK-17310
> =
> =
> Diffs
> -----
> =
> /branches/1.8/include/asterisk/utils.h 342659 =
> /branches/1.8/main/utils.c 342659 =
> /branches/1.8/include/asterisk/stringfields.h 342659 =
> =
> Diff: https://reviewboard.asterisk.org/r/1549/diff
> =
> =
> Testing
> -------
> =
> I replaced:
> typedef uint16_t ast_string_field_allocation;
> with:
> typedef uint64_t ast_string_field_allocation;
> =
> Then I looked at a small sample of base and used during operation.
> =
> They were always 64bit aligned.
> =
> =
> Thanks,
> =
> wdoekes
> =
>
--===============4642281535179558935==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
<html>
<body>
<div style=3D"font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor=3D"#f9f3c9" width=3D"100%" cellpadding=3D"8" style=3D"bor=
der: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href=3D"https://reviewboard.asterisk.org/r/1549/">https://reviewbo=
ard.asterisk.org/r/1549/</a>
</td>
</tr>
</table>
<br />
<blockquote style=3D"margin-left: 1em; border-left: 2px solid #d0d0d0; padd=
ing-left: 10px;">
<p style=3D"margin-top: 0;">On October 31st, 2011, 12:34 p.m., <b>mjordan<=
/b> wrote:</p>
<blockquote style=3D"margin-left: 1em; border-left: 2px solid #d0d0d0; pad=
ding-left: 10px;">
=
<table width=3D"100%" border=3D"0" bgcolor=3D"white" style=3D"border: 1px s=
olid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan=3D"4" bgcolor=3D"#F0F0F0" style=3D"border-bottom: 1px solid =
#C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href=3D"https://reviewboard.asterisk.org/r/1549/diff/2/?file=3D21505=
#file21505line1548" style=3D"color: black; font-weight: bold; text-decorati=
on: underline;">/branches/1.8/main/utils.c</a>
<span style=3D"font-weight: normal;">
(Diff revision 2)
</span>
</th>
</tr>
</thead>
<tbody style=3D"background-color: #e4d9cb; padding: 4px 8px; text-align: c=
enter;">
<tr>
<td colspan=3D"4"><pre style=3D"font-size: 8pt; line-height: 140%; margi=
n: 0; ">static int add_string_pool(struct ast_string_field_mgr *mgr, struct=
ast_string_field_pool **pool_head,</pre></td>
</tr>
</tbody>
=
=
<tbody>
<tr>
<th bgcolor=3D"#e9eaa8" style=3D"border-right: 1px solid #C0C0C0;" alig=
n=3D"right"><font size=3D"2">1548</font></th>
<td bgcolor=3D"#fdfebc" width=3D"50%"><pre style=3D"font-size: 8pt; lin=
e-height: 140%; margin: 0; "> <span class=3D"k">if</span> <span class=3D"p"=
>(</span><span class=3D"o">!</span><span class=3D"p">(</span><span class=3D=
"n">pool</span> <span class=3D"o">=3D</span> <span class=3D"n">__ast_<span =
class=3D"hl">c</span>alloc</span><span class=3D"p">(</span><span class=3D"m=
i"><span class=3D"hl">1</span></span><span class=3D"p"><span class=3D"hl">,=
</span></span><span class=3D"hl"> </span><span class=3D"n">alloc_size</span=
><span class=3D"p">,</span> <span class=3D"n">file</span><span class=3D"p">=
,</span> <span class=3D"n">lineno</span><span class=3D"p">,</span> <span cl=
ass=3D"n">func</span><span class=3D"p">)))</span> <span class=3D"p">{</span=
></pre></td>
<th bgcolor=3D"#e9eaa8" style=3D"border-left: 1px solid #C0C0C0; border=
-right: 1px solid #C0C0C0;" align=3D"right"><font size=3D"2">1548</font></t=
h>
<td bgcolor=3D"#fdfebc" width=3D"50%"><pre style=3D"font-size: 8pt; lin=
e-height: 140%; margin: 0; "> <span class=3D"k">if</span> <span class=3D"p"=
>(</span><span class=3D"o">!</span><span class=3D"p">(</span><span class=3D=
"n">pool</span> <span class=3D"o">=3D</span> <span class=3D"n">__ast_<span =
class=3D"hl">m</span>alloc</span><span class=3D"p">(</span><span class=3D"n=
">alloc_size</span><span class=3D"p">,</span> <span class=3D"n">file</span>=
<span class=3D"p">,</span> <span class=3D"n">lineno</span><span class=3D"p"=
>,</span> <span class=3D"n">func</span><span class=3D"p">)))</span> <span c=
lass=3D"p">{</span></pre></td>
</tr>
</tbody>
</table>
<pre style=3D"white-space: pre-wrap; white-space: -moz-pre-wrap; white-sp=
ace: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This actu=
ally goes against the recommendations in the coding guidelines (2.17.3) - i=
s there a specific reason to not use ast_calloc?</pre>
</blockquote>
<p>On October 31st, 2011, 12:39 p.m., <b>David Vossel</b> wrote:</p>
<blockquote style=3D"margin-left: 1em; border-left: 2px solid #d0d0d0; pad=
ding-left: 10px;">
<pre style=3D"white-space: pre-wrap; white-space: -moz-pre-wrap; white-sp=
ace: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The memse=
t after the malloc is for a smaller amount of memory than the entire alloca=
tion. The change appears safe, but I question why we'd even care about=
this optimization when it adds more complexity.</pre>
</blockquote>
<p>On November 1st, 2011, 1:18 a.m., <b>wdoekes</b> wrote:</p>
<blockquote style=3D"margin-left: 1em; border-left: 2px solid #d0d0d0; pad=
ding-left: 10px;">
<pre style=3D"white-space: pre-wrap; white-space: -moz-pre-wrap; white-sp=
ace: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This isn&=
#39;t an increase in complexity, this is a fix. The original author should =
never have used calloc here. This is a very common pattern.
I don't see how you could not care about the overhead of hundreds of by=
tes getting nulled for nothing when only a handful (struct ast_string_field=
_pool) should get nulled. Especially in core functions that were created to=
reduce load (individual string field mallocs) in the first place.</pre>
</blockquote>
</blockquote>
<pre style=3D"margin-left: 1em; white-space: pre-wrap; white-space: -moz-pr=
e-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-=
word;">From the coding guidelines:
When allocating/zeroing memory for a structure, use code like this:
struct foo *tmp;
...
tmp =3D ast_calloc(1, sizeof(*tmp));
Avoid the combination of ast_malloc() and memset(). Instead, always use ast=
_calloc(). This will allocate and zero the memory in a single operation. In=
the case that uninitialized memory is acceptable, there should be a commen=
t in the code that states why this is the case.
Considering that this would be initialization code and not something that w=
ould be run in a tight loop, the optimization isn't a particularly big =
deal. We decided long ago to err on the side of caution to protect against =
people checking if (!foo->bar) against unitialized data. In this case, I=
would assume that it would be safe since __ast_string_field_init initializ=
es the strings to empty (if I'm reading it correctly, I haven't loo=
ked at the stringfields code much). We just have a strong preference to usi=
ng calloc as a general rule unless it is in an area where performance is re=
ally greatly affected during normal runtime.</pre>
<br />
<p>- Terry</p>
<br />
<p>On October 31st, 2011, 3:47 a.m., wdoekes wrote:</p>
<table bgcolor=3D"#fefadf" width=3D"100%" cellspacing=3D"0" cellpadding=3D"=
8" style=3D"background-image: url('https://reviewboard.asterisk.org/media/r=
b/images/review_request_box_top_bg.png'); background-position: left top; ba=
ckground-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By wdoekes.</div>
<p style=3D"color: grey;"><i>Updated Oct. 31, 2011, 3:47 a.m.</i></p>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Descripti=
on </h1>
<table width=3D"100%" bgcolor=3D"#ffffff" cellspacing=3D"0" cellpadding=3D"=
10" style=3D"border: 1px solid #b8b5a0">
<tr>
<td>
<pre style=3D"margin: 0; padding: 0; white-space: pre-wrap; white-space:=
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap=
: break-word;">This patch fixes that Asterisk can be properly built on cert=
ain architectures that dislike misalignment. (In the case of the bug report=
er, an ARM.)
=3D=3DBackground=3D=3D
Currently the 16bit ast_string_field_allocation used in the is not aligned,=
it can be stored on an 8bit boundary. Certain machines will either SIGBUS =
over this or simply give wrong results. For the Sparc an #ifdef was added t=
o alleviate the problem.
=3D=3DProblems with current approach=3D=3D
(1) The x86 can cope with misaligned integers, but for performance, aligned=
ints are better.
(2) The #ifdef did not catch all architectures that dislike misalignment.
(3) The code in the #ifdef falsely assumes that the ast_string_field_alloca=
tion is at most 2 bytes large. If this were to change one day, things would=
start to fail again.
=3D=3DPossible fixes=3D=3D
(1) Remove the #ifdef, always run the Sparc code and patch it to cope with =
larger than 16bit ast_string_field_allocation's.
(2) Alter all ast_string_field_allocation code to ensure that base and used=
stay aligned. Then we won't need to check and re-align later on.
I chose fix #2 because I believe this to be marginally faster and more logi=
cal. This does involve the use of the gcc __attribute__((aligned)). But the=
other code is full of gcc attributes, so I don't think I'm breakin=
g a build anywhere with this.
Regards,
Walter</pre>
</td>
</tr>
</table>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing <=
/h1>
<table width=3D"100%" bgcolor=3D"#ffffff" cellspacing=3D"0" cellpadding=3D"=
10" style=3D"border: 1px solid #b8b5a0">
<tr>
<td>
<pre style=3D"margin: 0; padding: 0; white-space: pre-wrap; white-space:=
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap=
: break-word;">I replaced:
typedef uint16_t ast_string_field_allocation;
with:
typedef uint64_t ast_string_field_allocation;
Then I looked at a small sample of base and used during operation.
They were always 64bit aligned.</pre>
</td>
</tr>
</table>
<div style=3D"margin-top: 1.5em;">
<b style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href=3D"https://issues.asterisk.org/jira/browse/ASTERISK-17310">ASTERIS=
K-17310</a>
</div>
<h1 style=3D"color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b>=
</h1>
<ul style=3D"margin-left: 3em; padding-left: 0;">
<li>/branches/1.8/include/asterisk/utils.h <span style=3D"color: grey">(34=
2659)</span></li>
<li>/branches/1.8/main/utils.c <span style=3D"color: grey">(342659)</span>=
</li>
<li>/branches/1.8/include/asterisk/stringfields.h <span style=3D"color: gr=
ey">(342659)</span></li>
</ul>
<p><a href=3D"https://reviewboard.asterisk.org/r/1549/diff/" style=3D"margi=
n-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============4642281535179558935==--
More information about the asterisk-dev
mailing list