fixing compiler warnings

There are a couple of issues left that I'm not sure what to do with them....

[ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o
/Users/seth/bro/bro.git/src/main.cc: In function ‘int main(int, char**)’:
/Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ‘char*’

[ 70%] Building CXX object src/CMakeFiles/bro.dir/Sessions.cc.o
/Users/seth/bro/bro.git/src/Sessions.cc: In member function ‘void NetSessions::Internal(const char*, const pcap_pkthdr*, const u_char*)’:
/Users/seth/bro/bro.git/src/Sessions.cc:1357: warning: format not a string literal and no format arguments

If anyone would like to offer suggestions, I'm listening. :slight_smile:

  .Seth

There are a couple of issues left that I'm not sure what to do with them....

[ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o
/Users/seth/bro/bro.git/src/main.cc: In function ‘int main(int, char**)’:
/Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ‘char*’

int main(int argc, char *argv[])
might to the trick....

[ 70%] Building CXX object src/CMakeFiles/bro.dir/Sessions.cc.o
/Users/seth/bro/bro.git/src/Sessions.cc: In member function ‘void NetSessions::Internal(const char*, const pcap_pkthdr*, const u_char*)’:
/Users/seth/bro/bro.git/src/Sessions.cc:1357: warning: format not a string literal and no format arguments

-internal_error(msg);
+internal_error("%s", msg);

On a different note wrt to integer format string warnings: These
warnings tend to creep back in whenever you compile on a different
platform that has different integers widths. AFAIK the only way to get
really rid of them for good is to use the macros from inttypes.h
But that's already flagged for the integer types cleanup in ticket #319

cu
Gregor

Haven't looked at Seth's changes yet, but this is indeed the best
way to go about them.

Robin

[ 36%] Building CXX object src/CMakeFiles/bro.dir/main.cc.o
/Users/seth/bro/bro.git/src/main.cc: In function ‘int main(int, char**)’:
/Users/seth/bro/bro.git/src/main.cc:415: warning: deprecated conversion from string constant to ‘char*’

int main(int argc, char *argv[])
might to the trick....

That was my first inclination too, but the error isn't on that line. :slight_smile:

-internal_error(msg);
+internal_error("%s", msg);

Oh! Of course.

On a different note wrt to integer format string warnings: These
warnings tend to creep back in whenever you compile on a different
platform that has different integers widths. AFAIK the only way to get
really rid of them for good is to use the macros from inttypes.h
But that's already flagged for the integer types cleanup in ticket #319

I'm pretty clueless about the course of action that needs to happen for ticket #319. Could you give some guidance? Maybe I could go ahead and do it sometime if I knew what needs done.

  .Seth

Take a look at the libhilti code, "grep PRI
binpacpp/hilti/libhilti/*.c" will show some examples of using these
macros.

Robin

Basically the problem is that the uintXX_t and intXX_t types have to be
printed differently on different platforms (e.g., int64_t could be a %d
or %ld or %lld"). Using the macros gives you a portable way to specify
the format specifier.

So, you have to search the code for all instances were a fixed width
integer is printed (or formated) and change the format specifier to use
one of the macros.

However, I'm not sure whether it makes sense to do this before we check
whether we need to use 64 bit integers in some places. Since these
changes might require another set of updating format specifiers.

hth
gregor

Hmm. The error looks to be in this line:
    prefixes.append(""); // "" = "no prefix"
where prefixes is of type "name_list", which is defined in List.h as
PList(char). Thus the append's prototype is "char *". But it seems
converting a string literal to a "char *" now results in this warning
(the prototype would have to be a "const char*")......

I think the quickest hotfix would be

  prefixes.append(strdup(""));
(and add an #include <string.h>)

cu
gregor

I think it does. I would like to get rid of all compiler warnings
now, even if these will require more tweaking later.

Robin