Thanks for the quick responses and convincing feedback. Mind my goal is
not to become a supported platform - at all - but rather to lower the
portability barrier where reasonable. I can easily patch around any
other concerns locally.
Brent: I'll email you the changes that there's agreement on so you can
review and integrate them:
* Fix link order of libcrypto and libssl (with Jan's improvement).
* <sys/select.h> inclusions for good measure (see below).
* O_NONBLOCK instead of FIONBIO.
* Use fprintf and exit instead of err() in the core library (only used
once). Perhaps the regression tests too.
* Check for explicit_bzero in configure.ac so the standard library can
provide a good implementation.
* The header inclusion and non-standard types patches (for good measure,
you said you are already are on the task).
* A consistency fix for the guard macro in include/machine/endian.h.
* Add a const keyword to a variable in crypto/err/err.c (though that
doesn't really matter).
I haven't received any response on these and I might not have the
autoconf skills to properly deal with them:
* --program-transform-name defaulting to the host triplet when cross-
compiling (it shouldn't do this).
* Man-page hardlinks not honoring --program-transform-name leading to
ln errors during make install.
* The include/ wrapper headers should not duplicate function prototypes
if they are already in the standard library.
The rest of my miscellaneous thoughts aren't important and wasn't
agreed on, so I'll drop those. Here's some responses:
On 07/17/2014 05:05 AM, Philip Guenther wrote:
> Check again. To quote SUSv4 XBD lines 13376-13381:
Sorry. Looks like I misread POSIX. I would still prefer if you also
include <sys/select.h>, but I'll fix my libc so <sys/time.h> does that.
On 07/17/2014 05:05 AM, Philip Guenther wrote:
> As you may know, there's traction in getting these into a future
> version of POSIX, so get on the bandwagon now while it's still edgy.
I don't get that impression when looking at the Austin Group bug tracker
proposal and discussion about the err(3) functions - but that might
change. I personally prefer the GNU error(3) extension as it handles
all the {err,warn}{,x} cases by having an error number parameter and not
exiting the process on exit code zero. It doesn't seem to have been
submitted for standardization though.
On 07/17/2014 05:05 AM, Philip Guenther wrote:
> explicit_memset()? Can you describe a reason to use it with a value
> other than zero that wouldn't also work with memset()? If the whole
> point is that the buffer is unobserved by the flow and there the call
> needs protection from being optimized away, then the contents of the
> buffer cannot matter!
Good point. I mostly wanted the memset semantics just because it could
be a safe counterpart to the traditional memset. I'll adopt the
explicit_bzero function and remove explicit_memset. This is possible
assuming configure is patched so it checks whether the function is
already provided by the standard library.
On 07/17/2014 05:02 AM, Brent Cook wrote:
> What sort of OS is this?
It's a Unix-like system written from scratch that implements large parts
of POSIX-2008 with useful extensions from GNU and BSD as well as my own.
I have the fortune that older and non-standard code break when I port
it, which gives me a chance to upstream such issues. There is no need or
desire to upstream anything specific to my OS. OpenBSD has interesting
extensions that libressl takes advantage of - I'm adding some of those
to my project's libc (strl*, reallocarray, timingsafe_memcmp, and
getentropy are already done and the rest pending).
On 07/17/2014 05:02 AM, Brent Cook wrote:
> This didn’t cause a const-ripple through the code? Color me surprised!
It did and doing so was a mistake (but it didn't trigger for most ports
as they don't need the provide-all-extensions feature macro). It doesn't
matter - that bullet point was just a suggestion to make a particular
variable a const string pointer.
Jonas
