Re: [tor-bugs] #10845 [Tor bundles/installation]: Make libeay32.dll and ssleay32.dll visible to pluggable transports

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#10845: Make libeay32.dll and ssleay32.dll visible to pluggable transports
------------------------------------------+--------------------------
     Reporter:  dcf                       |      Owner:  erinn
         Type:  defect                    |     Status:  needs_review
     Priority:  normal                    |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:  tbb-3.5
Actual Points:                            |  Parent ID:  #9444
       Points:                            |
------------------------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:4 cypherpunks]:
 > len is DWORD, it's unsigned. len should be int.

 You are right. I didn't know DWORD was unsigned. Compiling with `-Wextra`
 shows:
 {{{
 RelativeLink.c: In function âGetSubdirectoryâ:
 RelativeLink.c:54:5: warning: comparison of unsigned expression < 0 is
 always false [-Wtype-limits]
 RelativeLink.c: In function âPrependToPathâ:
 RelativeLink.c:103:5: warning: comparison of unsigned expression < 0 is
 always false [-Wtype-limits]
 }}}

 > GetCurrentDirectory and GetEnvironmentVariable returns length of string
 not including nul-terminating character, but require output buffer with
 size including the null-terminating character.

 I had to check this again because the interface is confusing. When these
 functions ''fail'' because the buffer is too small, they return the number
 of needed characters ''including'' the null terminator; i.e., the number
 of tchars you need to pass to malloc. When they ''succeed'', they return
 the number of characters written ''not including'' the null terminator.
 [http://msdn.microsoft.com/en-
 us/library/windows/desktop/aa364934%28v=vs.85%29.aspx
 GetCurrentDirectory]:
   If the function succeeds, the return value specifies the number of
 characters that are written to the buffer, not including the terminating
 null character.
   If the function fails, the return value is zero. To get extended error
 information, call GetLastError.
   If the buffer that is pointed to by lpBuffer is not large enough, the
 return value specifies the required size of the buffer, in characters,
 including the null-terminating character.
 [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms683188%28v=vs.85%29.aspx
 GetEnvironmentVariable]:
   If the function succeeds, the return value is the number of characters
 stored in the buffer pointed to by lpBuffer, not including the terminating
 null character.
   If lpBuffer is not large enough to hold the data, the return value is
 the buffer size, in characters, required to hold the string and its
 terminating null character and the contents of lpBuffer are undefined.
   If the function fails, the return value is zero. If the specified
 environment variable was not found in the environment block, GetLastError
 returns ERROR_ENVVAR_NOT_FOUND.

 See http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms682009%28v=vs.85%29.aspx#example_2, where
 they pass the return value of GetEnvironmentVariable directly to malloc.

 I'd like to know whether the [http://msdn.microsoft.com/en-
 us/library/office/cc842072.aspx TCHAR] stuff looks right. I used
 [http://msdn.microsoft.com/en-
 us/library/windows/desktop/dd374074%28v=vs.85%29.aspx TEXT] on string
 literals, multiplied malloc arguments by sizeof(TCHAR), and used
 [http://msdn.microsoft.com/en-us/library/78zh94ax.aspx _tcslen] and
 [http://msdn.microsoft.com/en-us/library/2ts7cx93.aspx _sntprintf] in
 place of strlen and snprintf. I don't know whether the program is getting
 compiled in _UNICODE mode or not, or how to check that.

 I attached a new patch that uses int for len, adds a missing error check
 to the second calls to GetCurrentDirectory and GetEnvironmentVariable, and
 expresses the size of some memory allocations in a way that indicates what
 it going to be stored in them.

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