Re: RFC: [PATCH] Portability by avoiding PATH_MAX

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1463760128-1189495328-1399533335=:19700
Content-Type: TEXT/PLAIN; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Today Svante Signell wrote:

> On Thu, 2014-05-08 at 07:56 +0200, Tobias Oetiker wrote:
> > Hi Svante,
> >
> > Today Svante Signell wrote:
> >
> > > On Thu, 2014-05-08 at 02:41 +0200, Steve Schnepp wrote:
> > > > Le 7 mai 2014 16:10, "Tobias Oetiker" <[email protected]> a =E9crit=
 :
> > > > > Today Svante Signell wrote:
> > > >
> > > > > > Well, the PATH_MAX patches affect all architectures, but with=
out
> > > > 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 eith=
er
> > > > 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.
> > >
> > > People are advising you to not have several code patch to ease
> > > maintenance. Of course such a decision is up to Tobi. The reason I'=
m
> > > asking here is that I would like to be sure there are no problems b=
efore
> > > proposing the patches. They are non-trivial.
> >
> > since the hurd has probably a rather low penetration, and if the
> > code path is essentially just adding extra complexity to compensate
> > for a problem with a particular system, I don't see a problem
> > only having it active on a particular platform ... we already have
> > several such instances to deal with windows issues ...
>
> Yes Hurd does not have much penetration yet, right. Hopefully that will
> change in due time. I can make the code conditional but as said before,
> but it makes code maintenance more complicated. When the malloc/free
> solution is bug-free there is no need to distinguish between *nix*
> systems, only *nix* and windows.
>
> Additionally, I normally get my patches reviewed by the Hurd developers=
,
> and I can do this for the PATH_MAX patches too. It is considered sloppy
> coding to use PATH_MAX, see
> https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.=
html
> and
> http://insanecoding.blogspot.se/2007/11/pathmax-simply-isnt.html
>
> In Debian there is an increasing number of people adhering to this too.
>
> You either use a fixed number of elements when allocating an array on
> the stack or malloc/free for the heap. I think it is worthy the effort
> to get things right once and for all.

ok :-) how about a pull request ?

cheers
tobi
>
>

--=20
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch [email protected] +41 62 775 9902

---1463760128-1189495328-1399533335=:19700
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

---1463760128-1189495328-1399533335=:19700--