Problems compiling with --enable-int64

Zeek
1

I'm working on updating the FreeBSD port of bro (I'm the port maintainer), and I've been testing various combinations of options. I've run into a problem compiling with --enable-int64.

Val.cc: In member function 'virtual Val* Val::SizeVal() const':
Val.cc:567: error: call of overloaded 'abs(const bro_int_t&)' is ambiguous
/usr/include/stdlib.h:84: note: candidates are: int abs(int)
/usr/include/c++/4.2/cstdlib:143: note: long int std::abs(long int)
*** Error code 1

Is this a bug in the code? Or do I need to point to a library that's not found? Configure works fine, but make fails.

Compiler is gcc 4.2.1. OS version is 7.0 STABLE.

2

Val.cc: In member function 'virtual Val* Val::SizeVal() const':
Val.cc:567: error: call of overloaded 'abs(const bro_int_t&)' is ambiguous

I'm guessing that the line you're looking at is

  return new Val(abs(val.int_val), TYPE_COUNT);

(it's at a different location in the latest snapshot). If so, try

  return new Val(bro_int_t(abs(val.int_val)), TYPE_COUNT);

and see if that fixes the problem.

    Vern

3

That did not fix the problem.

Val.cc: In member function 'virtual Val* Val::SizeVal() const':
Val.cc:567: error: call of overloaded 'abs(const bro_int_t&)' is ambiguous
/usr/include/stdlib.h:84: note: candidates are: int abs(int)
/usr/include/c++/4.2/cstdlib:143: note: long int std::abs(long int)

4

That did not fix the problem.

Rats. Well, this doesn't repreoduce for me (w/ g++ 4.0.1), so I'm reduced
to guessing. The next thing I'd try is

  return new Val(abs(bro_int_t(val.int_val)), TYPE_COUNT);

but if that doesn't work, I'm not sure what next to try.

    Vern

5

Sadly, that did not work either. I'm afraid I'm not a programmer, so all I can do is follow your lead. For now I'll make that option is non-working and continue working on the update to the port.

If anyone on the list has the same version of gcc and can test this and find a resolution, please post it to the list. I'll include a patch in the port to fix it.

Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

6

When compiling with the --enable-int64 flag, the variable val.int_val is a ‘long long int’. It appears the abs function on your system is defined for ‘int’ and ‘long int’. You could probalby typecast the variable so that the compiler uses the ‘long int’ version. Though depending of the size of ‘long int’ on your system this could have an undesired effect. If ‘long int’ on your system is 64bits wide though you should be ok.

You can try:

return new Val(abs((long int)val.int_val), TYPE_COUNT);

The other concern here is that this is a one function fix and your going to run into this issue everytime you pass a ‘long long int’ to a function that has defines for just ‘int’ and ‘long int’.

If ‘long int’ is 64bits wide on your system, you might be better off editing the bro header file util.h so that you redefine int64.

typedef long long int int64;

would become

typedef long int int64;

// Joel

7

Thanks, Joel. This seems to point to a bigger problem. This software could be installed on any FreeBSD system, from an older OS to a brand new one, from i386 to amd to solaris. So, it's seems this is a situation that would call for an #ifdef, would it not?

I don't know the size of a long int on my system, but I'm almost certain that it won't be the same on *every* system.

Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

8

Here's what I have in my includes:

/usr/src/sys/i386/include/_types.h:typedef long long __int64_t;
/usr/src/sys/i386/include/_types.h:typedef unsigned long long __uint64_t;
/usr/src/sys/i386/include/_types.h:typedef long long __int64_t;
/usr/src/sys/i386/include/_types.h:typedef unsigned long long __uint64_t;

Fixing the function per your instructions allows the software to make successfully. I'm concerned, however, about your second point. If I change the define in util.h, will it break on some FreeBSD systems? I don't know.

According to the cvs repository, _inttypes.h hasn't been changed in almost six years on i386.
<http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/_inttypes.h>
It's been almost 5 years on amd64 and 5 years on ia64.

I guess I'm alright to redefine in util.h.

Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

9

That didn't work. I'll have to patch Val.cc.

Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

10

I didnt think about the port aspect(not much experience).
Definately not the way to maintain a build of somethign that would work across all OS’s
And in most cases there probably be a difference in bytes (4 vs 8) on most OS’s anyways.

An #ifdef would be the way to go, but my said typecasting would not be good for a port.
Looks like there are different functions for calculating absolute zero on different OS’s.

Check your headers for llabs.

This might be the way to go for portability

try swapping:
return new Val(abs(val.int_val), TYPE_COUNT);

for:
#ifdef USE_INT64
return new Val(llabs(val.int_val), TYPE_COUNT);
#else
return new Val(abs(val.int_val), TYPE_COUNT);
#endif

It may be better to define this function in a header but you can see if this works.

// Joel