Closed Bug 242704 Opened 20 years ago Closed 20 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: 20 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: