After the landing of bug 104651 there are a bunch of null-termination assertions about the dependent string usage when using the history window.
16 years ago
Comment on attachment 57125 [details] [diff] [review] patch r=jag
Fix checked in 2001-11-10 17:27 PDT.
yo.. you've broken the symmetry of tokenPair and made the "AgeInDays" comparison almost totally unreadable - can you make them both nsDependentSingleFragmentCSubstring please?
+ const char* startPtr = (const char*)yarn.mYarn_Buf; + rv = gRDFService->GetResource( + nsCAutoString(Substring(startPtr, startPtr+yarn.mYarn_Fill)).get(), + getter_AddRefs(resource)); This is also totally unreadable. Can't we do something to declare the Substring further above the GetResource call? is the nsCAutoString still necessary, with Substring()
> yo.. you've broken the symmetry of tokenPair and made the "AgeInDays" comparison > almost totally unreadable - can you make them both > nsDependentSingleFragmentCSubstring please? Not easily, since nsASingleFragmentString doesn't have .get(), for good reason. I guess I could throw str.BeginReading(iter) all over the place, but I'd rather not. I had really wanted to avoid using our string classes at all here, since this code doesn't really get along with them. > This is also totally unreadable. Can't we do something to declare the > Substring further above the GetResource call? is the nsCAutoString still > necessary, with Substring() OK, I could split it out.
Oh, and that nsCAutoString is being used as PromiseFlatCString. It may well be faster until bug 109572 is fixed.
Comment on attachment 57403 [details] [diff] [review] additional patch r=jag
Comment on attachment 57403 [details] [diff] [review] additional patch thanks.. makes that code much more readable. sr=alecf
Now I'm just curious: + const nsASingleFragmentCString& tokenName = + Substring(token->tokenName, token->tokenName + token->tokenNameLength); How exactly does this work? It looks like a temporary is created by Substring() and a reference is stored by tokenName.. but doesn't the temporary go away almost immediately, leaving tokenName pointing to possibly-freed memory? Just curious how this string magic does its thing...
The reference keeps the object alive for the scope of the reference itself.
Checked in 2001-11-11 12:37 PDT.
neat, learn something new every day. Thanks guys.
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]