Closed Bug 242704 Opened 21 years ago Closed 21 years ago

AIX debug build fails after recent AppendInt changes

Categories

(Core :: XPCOM, defect)

Other
AIX
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: pkwarren, Assigned: pkwarren)

Details

(Keywords: fixed1.7)

Attachments

(3 files)

AIX debug builds fail to build after the recent changes to AppendInt. The error occurs when compiling nsContentTestNode.cpp. I will attach a build log from a recent build.
Attached file Failing build log
Attached patch Patch v1Splinter Review
Assignee: string → pkw
Status: NEW → ASSIGNED
Comment on attachment 147743 [details] [diff] [review] Patch v1 I used the initial suggestion from Brendan in http://bugzilla.mozilla.org/show_bug.cgi?id=133801#c6.
Attachment #147743 - Flags: superreview?(darin)
Attachment #147743 - Flags: review?(darin)
I guess this is caused by the fact that we now have an AppendInt that takes a PRUint32 as well as the one that takes a PRInt32, and NS_PTR_TO_INT32 doesn't include a cast to specify the INT32 type.
Comment on attachment 147743 [details] [diff] [review] Patch v1 sr=darin requesting MOA=/r= from jst.
Attachment #147743 - Flags: superreview?(darin)
Attachment #147743 - Flags: superreview+
Attachment #147743 - Flags: review?(jst)
Attachment #147743 - Flags: review?(darin)
Comment on attachment 147743 [details] [diff] [review] Patch v1 aResult.Append(PRUnichar('@')); - aResult.AppendInt(NS_PTR_TO_INT32(aContent), 16); + AppendASCIItoUTF16(nsPrintfCString("%p", aContent), aResult); Wanna remove the first Append call, and make the format string to nsPrintfCString be "@%p"? r=jst
Attachment #147743 - Flags: review?(jst) → review+
hmm... i was just reminded of the fact that nsPrintfCString uses a 16 byte buffer by default. it uses PR_vsnprintf to write to that buffer, which means that a 64-bit address in hex will not entirely fit in the buffer. with the '@' character added, that means the address will be truncated to 14 hex characters. you can also use the other form of the nsPrintfCString constructor: nsPrintfCString(18, "@%p", aContent) this causes an 18 character, malloc'd buffer to be used instead.
Attached patch Patch v2Splinter Review
Patch that was checked in.
Comment on attachment 147751 [details] [diff] [review] Patch v2 sr=darin
Attachment #147751 - Flags: superreview+
Fix checked in. Checking in nsContentTestNode.cpp; /cvsroot/mozilla/content/xul/templates/src/nsContentTestNode.cpp,v <-- nsContentTestNode.cpp new revision: 1.16; previous revision: 1.15 done
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 147751 [details] [diff] [review] Patch v2 Requesting approval for a simple build break fix, which only affects debug builds.
Attachment #147751 - Flags: approval1.7?
Comment on attachment 147751 [details] [diff] [review] Patch v2 a=mkaply
Attachment #147751 - Flags: approval1.7? → approval1.7+
Checked into 1.7 branch. Checking in nsContentTestNode.cpp; /cvsroot/mozilla/content/xul/templates/src/nsContentTestNode.cpp,v <-- nsContentTestNode.cpp new revision: 1.14.14.1; previous revision: 1.14 done
Keywords: fixed1.7
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: