[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #7260 [Tor]: MinGW64 & -Werror -Werror

#7260: MinGW64 & -Werror -Werror
--------------------+-------------------------------------------------------
 Reporter:  yayooo  |          Owner:                    
     Type:  defect  |         Status:  needs_revision    
 Priority:  normal  |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor     |        Version:  Tor: 0.2.3.24-rc  
 Keywords:          |         Parent:                    
   Points:          |   Actualpoints:                    
--------------------+-------------------------------------------------------
Changes (by nickm):

  * status:  needs_review => needs_revision


Comment:

 The MinGW64.2.patch one looks almost okay.  It's not necessary to modify
 orconfig.h.in, though, since it should get automatically generated by
 autoheader.  But we probably *do* need corresponding changes in
 src/win32/orconfig.h, since the MSVC build (which uses it) doesn't use
 autoconf.  These problems seem like they could be good to fix in 0.2.3,
 ... I could use a second opinion from Roger/Weasel/Erinn/Andrea/everybody
 else on that one, though.  If not, alpha releases _are_ where we usually
 add support for more platforms.

 On the Werror.2.patch:
  * This one is complicated enough that it probably makes more sense for
 0.2.4... but hm. Some of the warnings that it fixes -- notably the socket
 printf one -- look as though they might mean invoking sprintf with too
 many arguments on Win64.  That is probably not safe.
  * I don't understand what the point is to making the autoconf tests all
 build with -Werror; autoconf shouldn't be passing any -W flags to the
 compiler while it's building.  In particular, it seems like a step
 backwards to have to clone AC_SEARCH_LIBS.  Do you know about --enable-
 gcc-warnings ?  You can invoke ./configure as "./configure --enable-gcc-
 warnings" and get Tor built with -Wextra -Werror and many more warnings.
  *  INTPTR_T_to_INT should probably use the same naming convention as the
 other printf stuff: look at how U64_PRINTF_ARG() works.  If we're calling
 it INTPTR_T_TO_INT, it needs to be a function or a macro that converts.
 If it has to be a type, then it should probably be INTPTR_PRINTF_TYPE or
 something.
  * In test_util.c , 1000000 is entirely too many bytes to be stack-
 allocating.
  * In src/test/tinytest_macros.h, intptr_t doesn't make much sense as a
 type.  int64_t would make more sense; so would intmax_t if we had it.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7260#comment:5>
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