Re: portability to Debian's non-linux architectures

On Mon, Sep 07, 2015 at 11:16:33AM -0400, Peter Piwowarski wrote:
> 
> The biggest problem is HURD, which does not define PATH_MAX. (yes, you read
> that correctly.) The choices there are to either turn a lot of
> PATH_MAX-sized static buffers into dynamic ones (the HURD people think
> that's the right way to go about it[1]), or to do something cheesy like:
> 
> #ifndef PATH_MAX
> #define PATH_MAX your favorite bogus number
> #endif
>
> I have put together a patch taking the former course (but which I'm not
> absolutely certain is regression/leak free, more experienced eyes than mine
> would need to see it); the latter is pretty obvious. (My patch does not
> convert occurences of PATH_MAX in the ALSA backend, since that's
> Linux-specific. I have patches for that as well if that's considered
> helpful. I am also not a habitual KNF speaker; despite my proofreading
> efforts something may possibly have snuck through.)

I also prefer using malloc() rather than defining PATH_MAX (to
what??). I'll start with your diff and try to avoid hardcoding the
string lengths, like these ones:

> +		buf = malloc(path_len = strlen(path) + 14 + 1);

> The other major unsupported preprocessor symbol is SOCK_CLOEXEC, which the
> kFreeBSD architectures do not seem to define (though FreeBSD itself
> apparently does, or will do in the future).

fwiw, before SOCK_CLOEXEC introduction, the code used to call

fcntl(fd, F_SETFD, 1);

to set the CLOEXEC flag;

I'd prefer we add the #define in bsd-compat.h to minimise
differences with the openbsd repo.
 
> I understand if this stuff (especially the PATH_MAX diff) isn't considered
> helpful in the official portable sndio tree, though I'll probably end up
> carrying some sort of portability goo in Debian packaging if this isn't
> merged. (not the PATH_MAX patch though, that's a bit much...)

IMO it's useful, as long it doesn't complicate the code :)