fixes for netbsd #735

Closed
wants to merge 5 commits into
from

Projects

None yet

3 participants

@yamt
Contributor
yamt commented Oct 28, 2012

rebased version of #591
plus one more fix.

yamt added some commits Jul 19, 2012
@yamt yamt don't define _XOPEN_SOURCE for NetBSD
on NetBSD, defining _XOPEN_SOURCE hides extensions
like inet_aton, strcasecmp, etc.
91d9164
@yamt yamt rename popcount to popcount_binary to avoid a conflict with NetBSD libc
NetBSD-current's libc has a function named popcount.
hiding these extensions using feature macros is not possible because
redis uses other extensions covered by the same feature macro.
eg. inet_aton
a6a815f
@yamt yamt use nanosleep instead of usleep
SUSv3 says that:
	The useconds argument shall be less than one million. If the value of
	useconds is 0, then the call has no effect.
and actually NetBSD's implementation rejects such a value with EINVAL.
use nanosleep which has no such a limitation instead.
a696bad
@yamt yamt _XOPEN_SOURCE 600 for NetBSD as well
it's necessary for getaddrinfo etc.
while i'm not sure why this is under #ifdef linux in the first place,
keep non-NetBSD cases as-is for now.
6680349
@yamt yamt don't assume time_t == long
time_t is always 64bit on recent versions of NetBSD.
881f3ea
@yamt yamt referenced this pull request Oct 28, 2012
Closed

fixes for netbsd #591

@antirez
Owner
antirez commented Oct 28, 2012

Everything looks fine to me, only thing I'm not sure is commit 881f3ea since I'm not sure that all the other systems where we build have "j" format specifier support for printf. Maybe we can instead go for casting?

@antirez
Owner
antirez commented Oct 28, 2012

p.s. also, thank you!

@moreaki
moreaki commented Oct 28, 2012

@antirez: With regard to the "j" format specifier, I believe the C99 standard is pretty clear about it (section 7.19.6.1/7). Here's what the convenient POSIX documentation about printf format specifiers has to say:

http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html

So, unless redis is currently supported on operating systems that do not have C99 compliant C compilers, I believe the proposed format specifier "j" is quite safe. YMMV.

@yamt
Contributor
yamt commented Oct 29, 2012

if it's desirable to support non-C99 environments, long long is safer.
do you want me to prepare a patch?

@antirez
Owner
antirez commented Oct 29, 2012

I think we are currently already dependent on C99 in other places, so IMHO it's worth to go into the direction of using C99 specific constructs without too problems as son as they are mature in all the platforms we support currently (Linux, *BSD, OSX, and in a "best effort" way also Solaris-derivates).

Redis currently is compiled using -std=c99 btw.

@yamt
Contributor
yamt commented Oct 30, 2012

Linux, *BSD, OSX, and in a "best effort" way also Solaris-derivates

all of them seem to support 'j' modifier according to their latest man pages.

@antirez
Owner
antirez commented Nov 1, 2012

Thanks @yamt

@yamt
Contributor
yamt commented Apr 4, 2013

please tell me if/when you want me rebase again.

@yamt yamt referenced this pull request May 17, 2013
Merged

netbsd support #1111

@yamt
Contributor
yamt commented May 17, 2013

see #1111 for newer patches

@yamt yamt closed this May 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment