[tor-bugs] #3894 [Tor Client]: Fix compilation on FreeBSD 4

[Tor Bug Tracker & Wiki]

#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