Bug 40758 - WIN64, apr_vformatter(..) cannot handle 64bit pointers without APR_VOID_P_IS_QUAD flag enabled
Summary: WIN64, apr_vformatter(..) cannot handle 64bit pointers without APR_VOID_P_IS_...
Status: VERIFIED FIXED
Alias: None
Product: APR
Classification: Unclassified
Component: APR (show other bugs)
Version: HEAD
Hardware: All Windows Server 2003
: P3 major (vote)
Target Milestone: ---
Assignee: Apache Portable Runtime bugs mailinglist
URL: http://www.apachelounge.com/forum/vie...
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2006-10-15 20:30 UTC by Philip Soeberg
Modified: 2007-07-02 17:44 UTC (History)
0 users


Attachments
change unknown macro (905 bytes, patch)
2007-04-27 07:32 UTC, Davi Arnaut 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Soeberg 2006-10-15 20:30:56 UTC 
Unless /D APR_VOID_P_IS_QUAD is explicitly defined when compiling libapr, the
apr_vformatter(..) function in apr_snprintf.c is unable to handle %p pointer
conversions. This is unfortunate if any formatting remains after the conversion
(e.g. %s%p%s or similar). If formatting remains, the next iteration will most
likely crash due to incomplete increment of data pointer.

I have been unable to find any correlation between WIN64 and APR_VOID_P_IS_QUAD
in the makefiles or anywhere else. In fact, the only place I found
APR_VOID_P_IS_QUAD is in apr_snprintf.c.

The hunt for the bug is described here:
http://www.apachelounge.com/forum/viewtopic.php?t=926
Comment 1 Davi Arnaut 2007-04-27 07:31:38 UTC 
APR_VOID_P_IS_QUAD is not defined anywhere and the usual way is
using APR_SIZEOF_VOIDP. Patch follows.
Comment 2 Davi Arnaut 2007-04-27 07:32:18 UTC 
Created attachment 20060 [details]
change unknown macro
Comment 3 William A. Rowe Jr. 2007-05-31 15:00:04 UTC 
Committed, thanks!