Hi Svante, Today Svante Signell wrote:
> On Fri, 2013-08-16 at 11:15 +0200, Tobias Oetiker wrote: > > Hi Svante, > > > > Today Svante Signell wrote: > > > > > On Fri, 2013-08-16 at 09:08 +0200, Tobias Oetiker wrote: > > > > Hi Svante, > > > > > > > > So you wan one megapatch for PATH_MAX/MAXPATH issues? Isn't it better to > > > create smaller patches that can easily be reverted if something goes > > > wrong? > > > > many small patches are fine ... I was just asking, whether you were > > plannig to build on this patch > > OK, I will continue next with rrd_client.c. Is that one built into the > library librrd*.so* ? yes, but it can also be used standalone > Is there an easy way to test with valgrind, as > rrd_deamon.c is, issuing suitable commands? nothing ready-made > One issue with rrd_client:get_path is the const definitions. In order to > free the dynamically allocated strings, to avoid memory leaks const has > to be abandoned in some places. OK? I can only tell you when I see the patch ... > > > Another issue is if code should be #ifdef-ed or unconditional, e.g. > > > using > > > #ifdef MAX_PATH or > > > #ifndef MAX_PATH > > > ... > > > #else > > > ... > > > #endif > > > or completely removing the PATH_MAX (MAXPATH) dependency. What about the > > > Win32 port? I haven't looked into that. > > > > well, if there IS a limit to the path length by the OS, the code > > should observe it I think, or how would you deal with this ? > > What about removing the #ifdef MAXPATH construct from the patch? By > dynamically allocating strings the only limitation is by malloc. That > should work also for win32? I don't know much about win32 limitations ... I was just wondering, what would happen, if you hand a string longer than MAXPATH to a filesystem function, but I guess they will take care of checking their input as well .. cheers tobi > thanks, > Svante > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
