[ 
https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966506#comment-16966506
 ] 

Alberto Massari commented on XERCESC-2179:
------------------------------------------

The definition for RegQueryValueExA 
([https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexa)]
 uses LPDWORD, but DWORD is defined as "unsigned long" 
([https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types)]

 
|*DWORD*|A 32-bit unsigned integer. The range is 0 through 4294967295 decimal.
 This type is declared in IntSafe.h as follows:
 {{typedef unsigned long DWORD;}}|

 

So, there should be no difference between an unsigned long and a DWORD.

As for the changes that add a +1 to some string lengths, the size of the buffer 
is set to 1024, and it should be big enough to hold any possible encoding name; 
in other cases the data to be read is a number, so the NULL terminator would 
not be added.

Are you targeting a non-desktop version of Windows? I don't see how that code 
could fail

> access violation in win32transservice.cpp with 64 bit compile
> -------------------------------------------------------------
>
>                 Key: XERCESC-2179
>                 URL: https://issues.apache.org/jira/browse/XERCESC-2179
>             Project: Xerces-C++
>          Issue Type: Bug
>          Components: DOM
>    Affects Versions: 3.2.2
>            Reporter: martin goodall
>            Assignee: Alberto Massari
>            Priority: Blocker
>             Fix For: 3.2.3
>
>         Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Reply via email to