Re: RFC: [PATCH] Portability by avoiding PATH_MAX

--===============0431076926==
Content-Type: multipart/alternative; boundary=089e01176ac5a83a8e04f8d8bd8c

--089e01176ac5a83a8e04f8d8bd8c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le 7 mai 2014 16:10, "Tobias Oetiker" <[email protected]> a =C3=A9crit :
> Today Svante Signell wrote:

> > Well, the PATH_MAX patches affect all architectures, but without them
> > rrdtool FTBFS for Hurd. For other architectures, like Linux, the code
> > should work the same. With the patches memory is allocated on the heap,
> > without on the stack. There should be no memory leaks in either case.
>
> ok :-) that might be a bit tricky

Would it be acceptable to revert to malloc() if and only if PATH_MAX is not
defined ?

That would nicely minimize the patch impact on already working platforms.

--=20
Steve Schnepp

--089e01176ac5a83a8e04f8d8bd8c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Le 7 mai 2014 16:10, &quot;Tobias Oetiker&quot; &lt;<a href=3D"mailto:to=
[email protected]">[email protected]</a>&gt; a =C3=A9crit=C2=A0:<br>
&gt; Today Svante Signell wrote:</p>
<p>&gt; &gt; Well, the PATH_MAX patches affect all architectures, but witho=
ut them<br>
&gt; &gt; rrdtool FTBFS for Hurd. For other architectures, like Linux, the =
code<br>
&gt; &gt; should work the same. With the patches memory is allocated on the=
 heap,<br>
&gt; &gt; without on the stack. There should be no memory leaks in either c=
ase.<br>
&gt;<br>
&gt; ok :-) that might be a bit tricky</p>
<p>Would it be acceptable to revert to malloc() if and only if PATH_MAX is =
not defined ?</p>
<p>That would nicely minimize the patch impact on already working platforms=
.</p>
<p>-- <br>
Steve Schnepp<br>
</p>

--089e01176ac5a83a8e04f8d8bd8c--


--===============0431076926==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rrd-developers mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

--===============0431076926==--