[rrd-developers] RFC: [PATCH] Portability by avoiding PATH_MAX

[Tobias Oetiker]

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" <tobi at oetiker.ch> a écrit :
> > > > > 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.
> > >
> > > 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 before
> > > 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
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902