[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3894 [Tor Client]: Fix compilation on FreeBSD 4
#3894: Fix compilation on FreeBSD 4
---------------------------+------------------------------------------------
Reporter: nickm | Owner:
Type: defect | Status: needs_revision
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version: Tor: 0.2.2.35
Resolution: | Keywords:
Parent: | Points:
Actualpoints: |
---------------------------+------------------------------------------------
Comment(by grarpamp):
Hi :) I just have no idea how to do anything with autoconf so I
didn't try that. And not being a programmer, sure, maybe on a C
level some parts could go closer to torint.h and compat.h. I'll
try a sleepy reply though...
> It's probably better to define SIZE_MAX in torint.h, if it's not
> already defined.
SIZE_MAX is not defined in 4.x's /usr/include or in Tor, unless
this limited scope is counted...
./src/common/OpenBSD_malloc_Linux.c:#define SIZE_MAX SIZE_T_MAX
/usr/include/machine/limits.h:#define SIZE_T_MAX UINT_MAX
I'm pretty sure it was born past the noted __FreeBSD_version as...
/usr/include/machine/_stdint.h:#define SIZE_MAX UINT32_MAX
> happy with... #ifdef checks for questions like "Is SIZE_MAX
> defined."
Maybe must be something better to put in place of the literal
'SIZE_MAX' then, even maybe something local defined based on the
various systems, so as not to ever redefine/undeclare the literal
up against any system provided entity, or lack thereof. Which I'm
guessing is the base problem.
> doesn't FreeBSD work on 64-bit systems? On such systems, size_t
> can get up to UINT64_MAX.
Yes it does work, with non-ancient releases... there is no such
UINT64_MAX on 4.11 :) And both 4.x and 8.x have SIZE_T_MAX as a
32bit UINT_MAX-alike. FreeBSD became 64bit aware around the version
noted in the patch, which is a bit before 5.1 in layman term.
A non exhaustive inventory yielded some 'sys' stuff already directly
included and some various comparisons, some some of this stuff may
lint deeper...
./src/common/OpenBSD_malloc_Linux.c:#include <sys/param.h>
./src/common/address.c:#include <sys/param.h>
./src/common/compat.c:#include <sys/param.h>
./src/or/or.h:#include <sys/param.h>
./src/common/OpenBSD_malloc_Linux.c:#ifdef __FreeBSD__
./src/common/torint.h:#if !defined(__FreeBSD__) &&
!defined(__FreeBSD_kernel__)
Here are some links.
http://www.freebsd.org/cgi/cvsweb.cgi/src/include/?only_with_tag=RELENG_4
http://www.freebsd.org/cgi/cvsweb.cgi/src/include/?only_with_tag=RELENG_9
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/?only_with_tag=RELENG_4
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/?only_with_tag=RELENG_9
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/include/?only_with_tag=RELENG_9
At least it's identified and fix[ed/able], just how best.
> fine to initialize the two variables above at declaration time
> to suppress those warnings.
Never got that far yet :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3894#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs