<div class="gmail_quote"><div>Hello Ovanes,</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This over-allocation is pretty much the same as reserving some space at the<br>

end of the data structure to place data together. Am I right? Why isn&#39;t it<br>
possible to just write char[128] or char[16] instead of char[1]?</blockquote><div>�</div><div>I can&#39;t change that code because it lives in a system header.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And if<br>
you know that this buffer represents some special case, why don&#39;t you pass<br>
it as such to filesystem? &amp;char[0], than boost::filesystem will not assume<br>
it got char[1] and will be looking to &#39;\0&#39; marker...<br></blockquote><div><br></div><div>How would I know that this buffer represents some special case?</div><div>FTS(3) library documentation says something like that:</div>
<div><br></div><div>struct _ftsent</div><div>{</div><div>� �...</div><div>� �char *fts_name;</div><div>};</div><div><br></div><div>But the structure is really defined another way (Linux, Mac OS X):</div><div><br></div><div>
<div>struct _ftsent</div><div>{</div><div>� �...</div><div>� �char fts_name[1];</div><div>};</div></div><div><br></div><div>I believe this discrepancy is pretty much negligible anyway.</div><div>There are huge number of programs utilizing fts(3) APIs and they don&#39;t break.</div>
<div><br></div><div>Unfortunately boost::filesystem is another story.</div><div>It does break and it does break silently.</div><div><br></div></div>