On Sat, 22 Sep 2018 at 22:20, Andrew Gregory <[email protected]> wrote: > Good catch, but this approach allows lrealpath to allocate a buffer > larger than PATH_MAX only to error if it actually does. lrealpath is > intended to be the same as realpath (aside from not resolving symlinks > obviously), so it should be fixed so that it doesn't write more than > PATH_MAX into a provided buffer.
I tried this initially, not really being that familiar with C I couldn't really figure it out. How exactly would one communicate the error? I can return null but then that could be anything. I could also move the alpm_log_error into lrealpath but just seems messy. Maybe just truncate and don't error? > We could switch to dynamic allocation in addition to fixing lrealpath, > but then the PATH_MAX checks would be pointless and should be removed. I assumed PATH_MAX was an OS limit type of thing, so even if we had a bigger buffer it would be useless as it would not work properly with other functions. I'm guessing that's not the case? > You also never free the malloc'd path. You can run the entire test > suite under valgrind with `make PY_TEST_FLAGS=--valgrind check` to > catch most memory leaks. > > apg I did free it at some point. Must have accidentally checked it out at some point. Whoops
