Fix compilation on macOS

[sdlyyxy]

No description provided.

[resuna]

Technically these should really be included unconditionally, since they're standard headers.

[sdlyyxy]

Technically these should really be included unconditionally, since they're standard headers.

Hi resuna, thank you for your comment. I checked the man page of these two headers. <strings.h> is in POSIX standard. For <alloca.h>, though it is not part of Standard C or any POSIX standard, it is actually available on many OS/compilers. Changed to unconditional inclusion.

[mutability]

Thanks for the PR! I will probably go with removing the use of alloca entirely instead (it's the only use of it in the source tree)

[mutability]

What's the failure that requires strings.h? (strcasecmp, I'm guessing?)

[mutability]

Could you check if #185 works for you?

[sdlyyxy]

Thanks for the PR! I will probably go with removing the use of alloca entirely instead (it's the only use of it in the source tree)

I agree!

[sdlyyxy]

What's the failure that requires strings.h? (strcasecmp, I'm guessing?)

Yes...

[sdlyyxy]

Could you check if #185 works for you?

Yes, it works well on my M1 Mac. I noticed #181, the problem is probably that libusb is not located at standard library search path. On my system, libusb's dylib installed by Homebrew cannot be found without manually setting LDFLAGS="-L/opt/homebrew/lib" environment variable.

[resuna]

Yeh, alloca is a gcc thing but since pretty much every compiler is based on gcc or clang these days ...

Anyway, Oliver has a separate pull request for this that replaces alloca with malloc, and I think we're going with that.

Good to know on the libusb thing. I have requested an M1 laptop from work but my current laptop is a 2019 MBP so I don't think I'm going to get a refresh this year.

[sdlyyxy]

Glad to use Oliver's PR. Closing this one. 👍