[tor-bugs] #2046 [Tor Client]: Port Tor code for starting a background process to Windows

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Aug 30 23:11:30 UTC 2011


#2046: Port Tor code for starting a background process to Windows
------------------------+---------------------------------------------------
 Reporter:  sjmurdoch   |          Owner:  sjmurdoch         
     Type:  task        |         Status:  needs_review      
 Priority:  major       |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Client  |        Version:                    
 Keywords:              |         Parent:  #1983             
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by sjmurdoch):

 Replying to [comment:9 nickm]:
 > Looks good; merging!

 Thanks!

 > Minor issue we should fix:
 >  * I think the need_quotes check in format_commandline_argument might be
 inadequate: Shouldn't it also check for \ and " ?

 I believe not, because it is acceptable to escape \ and " outside of a
 quoted argument (as per http://msdn.microsoft.com/en-us/library/ms880421
 and list2cmdline in
 http://hg.python.org/cpython/file/3102951cc1ce/Lib/subprocess.py#l530).

 e.g.

 {{{
 C:\w\tor>src\tools\tor-fw-helper\tor-fw-helper.exe -T "foo bar" foo\bar
 foo\"bar
  foo\\\"bar
 ARG: 0: src\tools\tor-fw-helper\tor-fw-helper.exe
 ARG: 1: -T
 ARG: 2: foo bar
 ARG: 3: foo\bar
 ARG: 4: foo"bar
 ARG: 5: foo\"bar
 }}}

 > Thing we could fix later:
 >  * In format_commandline_argument(), it would be neat to skip the
 business of building a smartlist of char*, and just pre-allocate a
 guaranteed-to-be-long-enough string -- I think that strlen(arg)*2 + 3
 would be long enough, since each character in the input turns into at most
 2 characters in the output, and there are at most 3 characters of
 overhead: 1 for the nul-terminator, 2 for quotes.

 Yes, I was considering that. An alternative would be to have a smartlist
 of ranges within the string, since most of the time output strings will
 consist of contiguous areas of input string. That would however lead to
 rather tricky code, so I think your approach sounds good.

 > Let me know if you'd like me to open tickets for those.

 Yes please.

 > Stuff I tweaked:
 >  * I think the tor_join_cmdline() function and
 format_commandline_argument() functions ought to have "win" somewhere in
 their names.   (Fixed this.)
 >  * In documentation for tor_split_lines, we should refer to a NUL
 character.  NULL is a pointer.  (Pedantically, NUL is a null character,
 and null-terminated strings are also NUL-terminated, but never NULL-
 terminated.)  (Fixed this.)

 Thanks.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2046#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list