Hello Rodrigo, Thank you for getting back to me. On Mon, Aug 31, 2026 at 09:02:25PM +0200, Rodrigo Arias wrote:
So I don't see a need for it to be longer than 4096 bytes, but let me know otherwise. Notice that asprintf() is not portable, is a GNU extension.
It is my understanding that asprintf has been added to the POSIX 2024 standard https://pubs.opengroup.org/onlinepubs/9799919799/functions/fprintf.html But if you prefer to avoid it there are off course other ways to achieve the same thing.
The utility of having a compile time limit is to be able to build the ctlpath in the stack and avoid freeing the heap on errors, as you see in your 5 extra calls to free().
If your preference is to allocate on the stack that is what is achieved with my first proposed patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146261#5 but it seems that allocation on the heap is usually preferred https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146261#6
Having an unbounded path means that any untrusted input path from the user is potentially a DoS as the path can happily take 1 TiB. It might be worth reconsidering this decision on GNU/hurd.
It is not so much that the path length is unbound, there will be a limit in practice, but the arbitrariness of the value (which often does not actually correspond to a maximum), whether this should be defined at the ABI level and the problems and inconsistencies that arise from it. I am not the best person to to make a convincing argument about this, but others have done, and I don't see GNU/Hurd changing on this (it would be very easy to do so, so the reasons for not doing it hold). How you deal with how Dillo builds on the hurd if off course your call, and thank you for caring about making your software available on this OS. Best regards, João