67961 - AIX,OS/2: Call to "nsString::Find" matches more than one function

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Peter "jag" Annema]

I checked in this change to fix bustage on hotaix:

--- nsDocumentEncoder.cpp       2001/02/07 10:34:17     1.39
+++ nsDocumentEncoder.cpp       2001/02/07 12:50:27
@@ -1062,7 +1062,7 @@
       nsCOMPtr<nsIDOMElement> bodyElem = do_QueryInterface(selContent);
       nsAutoString wsVal;
       rv = bodyElem->GetAttribute(NS_LITERAL_STRING("white-space"), wsVal);
-      if (NS_SUCCEEDED(rv) && (kNotFound !=
wsVal.Find(NS_LITERAL_STRING("-moz-pre-wrap"))))
+      if (NS_SUCCEEDED(rv) && (kNotFound !=
wsVal.Find(NS_LITERAL_STRING("-moz-pre-wrap").get())))
       {
         mIsTextWidget = PR_TRUE;
         break;

Here's the error message:

nsDocumentEncoder.cpp
xlC_r -o nsDocumentEncoder.o -c -DOSTYPE=\"AIX4.3\" -DOJI -D_IMPL_NS_LAYOUT  
-I../../../dist/include -I../../../dist/include     
-I/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/../../events/src
-I/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/../../html/base/src
-I/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/../../html/style/src
-I/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/../../xul/base/src
-I/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/../../xul/content/src   
-qflag=w:w -DPIC  -DAIX -DAIX4_3 -Daix  -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT
-DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DMOZ_WIDGET_GTK=1
-DMOZ_ENABLE_XREMOTE=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DSTDC_HEADERS=1
-DHAVE_ST_BLKSIZE=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE_INT64_T=1
-DHAVE_INT64=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1
-DHAVE_CPP_2BYTE_WCHAR_T=1 -DHAVE_DIRENT_H=1 -DHAVE_MEMORY_H=1 -DH!
AVE_UNIST
D_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_SYS_VFS_H=1
-DHAVE_LIBC_R=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBC_R=1 -DHAVE_RANDOM=1
-DHAVE_QSORT=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1
-DHAVE_SNPRINTF=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STATVFS=1 -DHAVE_MEMMOVE=1
-DHAVE_USLEEP=1 -DHAVE_RINT=1 -DHAVE_GETTIMEOFDAY=1 -DGETTIMEOFDAY_TWO_ARGS=1
-DHAVE_DEV_ZERO=1 -DHAVE_IOS_BINARY=1 -DHAVE_IOS_BIN=1 -DHAVE_OSTREAM=1
-DNEEDS_bool=1 -DHAVE_CPP_SPECIALIZATION=1 -DNEED_CPP_UNUSED_IMPLEMENTATIONS=1
-DHAVE_CPP_TROUBLE_COMPARING_TO_ZERO=1 -DHAVE_I18N_LC_MESSAGES=1
-DMOZ_MAIL_NEWS=1 -DMOZ_ENDER_LITE=1 -DNS_MT_SUPPORTED=1 -DMOZ_PERF_METRICS=1
-DFORCE_BUILD_REFCNT_LOGGING=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_MATHML=1
-DMOZ_SVG=1 -DMOZ_BYPASS_PROFILE_AT_STARTUP=1 -DMOZ_DLL_SUFFIX=\".so\"
-DXP_UNIX=1 -DUNIX_ASYNC_DNS=1 -DHAVE_MOVEMAIL=1 -DJS_THREADSAFE=1 
/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/nsDocumentEncoder.cpp
"../../../dist/include/nsCppSharedAllocator.h", line 90.16: 1540-252: (W) The
destructor for "wchar_t" does not exist. The call is ignored.
"/builds/tinderbox/SeaMonkey/AIX_4.3_Depend/mozilla/layout/base/src/nsDocumentEncoder.cpp",
line 1065.55: 1540-071: (S) Call to "nsString::Find" matches more than one
function.

I assume AIX' NS_LITERAL_STRING is the NS_ConvertASCIItoUCS2 version and thus
Find could match both the nsString and the PRUnichar* versions of Find... I'm
not sure why it's complaining, hence this bug.

Comment 1

[Peter "jag" Annema]

The other option I considered was:

+      if (NS_SUCCEEDED(rv) && (kNotFound != wsVal.Find("-moz-pre-wrap")))

Not sure which one should be preferred, so I opted for the minimal change.

Shortly after I filed this bug OS/2 (VACPP) went red too:

nsDocumentEncoder.cpp
icc -FonsDocumentEncoder.o -c -DOSTYPE=\"OS21\" -DOJI -D_IMPL_NS_LAYOUT  
-I../../../dist/include -I../../../dist/include     
-IE:/OS2_4.00_Clobber/mozilla/layout/base/src/../../events/src
-IE:/OS2_4.00_Clobber/mozilla/layout/base/src/../../html/base/src
-IE:/OS2_4.00_Clobber/mozilla/layout/base/src/../../html/style/src
-IE:/OS2_4.00_Clobber/mozilla/layout/base/src/../../xul/base/src
-IE:/OS2_4.00_Clobber/mozilla/layout/base/src/../../xul/content/src       /Q
/qlibansi /Gd /Gm /Su4 /Mp /Tl-  -DDEBUG -DDEBUG_ -DTRACING /Ti+
-DMOZILLA_CLIENT -DX_DISPLAY_MISSING=1  -DNO_ANSI_KEYWORDS=1  -DOS2=4 
-D_X86_=1  -DXP_OS2_VACPP=1  -DTCPV40HDRS=1  -DNSCAP_DISABLE_DEBUG_PTR_TYPES=1 
-DSTDC_HEADERS=1  -DD_INO=d_ino  -DMOZ_DEFAULT_TOOLKIT=\"os2\"  -Dmode_t=int 
-Doff_t=long  -Dpid_t=int  -Dsize_t=unsigned  -Duid_t=int  -Dgid_t=int 
-D__size_t=1  -D__off_t=1  -DHAVE_CPP_2BYTE_WCHAR_T=1  -DHAVE_DIRENT_H=1 
-DHAVE_GETOPT_H=1  -DHAVE_MEMORY_H=1  -DHAVE_LIBM=1  -DMMAP_MISSES_WRITES=1 
-DHAVE_QS!
!
ORT=1  -D
HAVE_STRERROR=1  -DHAVE_MEMMOVE=1  -DHAVE_GETTIMEOFDAY=1 
-DGETTIMEOFDAY_TWO_ARGS=1  -DHAVE_VALLOC=1  -DHAVE_IOS_BINARY=1 
-DHAVE_IOS_BIN=1  -DHAVE_OSTREAM=1  -DNEEDS_bool=1  -DHAVE_CPP_SPECIALIZATION=1 
-DNEED_CPP_UNUSED_IMPLEMENTATIONS=1  -DHAVE_CPP_TROUBLE_COMPARING_TO_ZERO=1 
-DHAVE_I18N_LC_MESSAGES=1  -DMOZ_MAIL_NEWS=1  -DMOZ_ENDER_LITE=1 
-DNS_MT_SUPPORTED=1  -DMOZ_MONOLITHIC_TOOLKIT=1  -DUNIX_CRASH_ON_ASSERT=1 
-DDETECT_WEBSHELL_LEAKS=1  -DMOZ_USER_DIR=\".mozilla\" 
-DMOZ_BYPASS_PROFILE_AT_STARTUP=1  -DMOZ_DLL_SUFFIX=\".dll\"  -DXP_PC=1 
-DXP_OS2=1  -DBSD_SELECT=1  -DXP_OS2_FIX=1  -DJS_THREADSAFE=1  
E:/OS2_4.00_Clobber/mozilla/layout/base/src/nsDocumentEncoder.cpp
..\..\..\dist\include\nsCppSharedAllocator.h(90:16) : warning EDC3252: The
destructor for "wchar_t" does not exist. The call is ignored.
..\..\..\dist\include\nsCRT.h(238:9) : informational EDC3207: The previous
message applies to the definition of template "nsCppSharedAllocator<wchar_t>".
E:/OS2_4.00_Clobber/mozilla/layout/base/src/nsDocumentEncoder.cpp(1065:55) :
error EDC3071: Call to "nsString::Find" matches more than one function.
E:/OS2_4.00_Clobber/mozilla/layout/base/src/nsDocumentEncoder.cpp(1065:55) :
informational EDC3232: Call matches "nsString::Find(const
PRUnichar*,PRBool,PRInt32,PRInt32) const".
E:/OS2_4.00_Clobber/mozilla/layout/base/src/nsDocumentEncoder.cpp(1065:55) :
informational EDC3232: Call matches "nsString::Find(const
nsString&,PRBool,PRInt32,PRInt32) const".

Comment 2

[Daniel Bratell]

What happens with 
NS_LITERAL_STRING("-moz-pre-wrap").get()
when 
NS_LITERAL_STRING("-moz-pre-wrap") is expanded to L"-moz-pre-wrap"?

Comment 3

[Joe Francis]

the ns_literal_string usage as a param to Find() was a mistake, though
apparently a harmless one on most platforms. The plain ascii param should be fine: 

+ if (NS_SUCCEEDED(rv) && (kNotFound != wsVal.Find("-moz-pre-wrap")))

Comment 4

[Peter "jag" Annema]

> What happens with 
> NS_LITERAL_STRING("-moz-pre-wrap").get()
> when 
> NS_LITERAL_STRING("-moz-pre-wrap") is expanded to L"-moz-pre-wrap"?

It's actually expanded to nsLiteralString(L"-moz-pre-wrap"), and there's a
.get() on nsLiteralString...

Comment 5

[Peter "jag" Annema]

jfrancis: I think that version is better since it doesn't require constructing a
nsLiteralString/nsAutoString... Wanna fix that next time you have to touch that
file? I'll leave this bug open to see if we can come up with a more general
solution to this problem.

Though, come to think of it, I think this problem will go away once we've
removed operator PRUnichar* on nsLiteralString and NS_ConvertASCIItoUCS2, and/or
when we force NS_LITERAL_STRING to expand to the same type.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

AIX and OS/2 both use the good form of NS_LITERAL_STRING, i.e.,
|nsLiteralString(L"...")|.  If vsVar is a 2-byte string, I would think
removing the NS_LITERAL_STRING would be slower, at least on platforms that
have a 2-byte unsigned wchar_t.  I really don't see where the ambiguity
comes from.

Also, I'm not sure what the intention of the code here is, but should you really
be doing a substring search rather than a simple equality test?  (I didn't even
know there was a "white-space" attribute.  I thought it was a CSS property...)

Comment 7

[Peter "jag" Annema]

I've searched on ".Find(" and found existing code with NS_ConvertASCIItoUCS2, so
my guess that that was causing the ambiguity doesn't seem to be the case, as
reinforced by David's statement that OS/2 and AIX use the
nsLiteralString(L"...") form.

hotaix just went green with the |.get()| patch, so I guess we'll have to look
for a way for nsLiteralString to be(come) a nsString...

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I wonder if |explicit| works correctly on these compilers.  If not, would
changing the type of the first parameter nsString::Find from a |const
nsString&| to a |const nsAReadableString&| help?  Otherwise I'm really
having trouble seeing where the ambiguity is.

Comment 9

[Peter "jag" Annema]

Here's pre-processor output I got from mkaply's local build:

if ((!((rv) & 0x80000000)) && (kNotFound !=
wsVal.Find(nsLiteralString(L"-moz-pre-wrap",
(sizeof(L"-moz-pre-wrap")/sizeof(wchar_t))-1))))

So how do you go from a nsLiteralString to a nsString... ?
Ignoring |explicit| is one way. Other options?

Comment 10

[Scott Collins]

now that you have to say |.get()| to get the raw pointer out of a literal
string, this ambiguity shouldn't be possible.