Re: Be more lenient with the NS_LITERAL_CSTRING macro

[jwwang]

We have NS_NAMED_LITERAL_CSTRING which seems to be a better and safer 
alternative for literal strings. And we should avoid using nsLiteralCString 
directly to avoid the pitfall described by James.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Be more lenient with the NS_LITERAL_CSTRING macro

[James Cheng]

Once you defined

NS_LITERAL_CSTRING(s) as
static_cast(nsLiteralCString(s))

const char kSomeData[] = {5,5,6,6}; which is no a literal string  can be
passed to the constructor [1].

Non-null terminated data may cause some unexpected behavior.

[1]
https://dxr.mozilla.org/mozilla-central/source/xpcom/string/nsTLiteralString.h#32

2016-08-12 11:16 GMT+08:00 <jww...@mozilla.com>:

> For
> static constexpr auto& kSomeStrLiteral = "hello world";
> NS_LITERAL_CSTRING(kSomeStrLiteral) is not allowed.
>
> However, we can have
> auto s1 = nsLiteralCString("hello world");
> auto s2 = nsLiteralCString(kSomeStrLiteral);
>
> I wonder why didn't we define NS_LITERAL_CSTRING(s) as
> static_cast(nsLiteralCString(s))
> ?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Be more lenient with the NS_LITERAL_CSTRING macro

[jwwang]

For
static constexpr auto& kSomeStrLiteral = "hello world";
NS_LITERAL_CSTRING(kSomeStrLiteral) is not allowed.

However, we can have
auto s1 = nsLiteralCString("hello world");
auto s2 = nsLiteralCString(kSomeStrLiteral);

I wonder why didn't we define NS_LITERAL_CSTRING(s) as
static_cast(nsLiteralCString(s))
?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_LITERAL_CSTRING

[Neil]

FYI The patch to make NS_LITERAL_CSTRING only work with string literals 
(and preprocessor macros that expand to string literals) has now been 
merged to mozilla-central.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_LITERAL_CSTRING

[Neil]

Ehsan Akhgari wrote:


On 2015-04-27 6:29 AM, Neil wrote:

I found the following in-tree examples, none of which would have 
worked with NS_LITERAL_STRING:


These are terrible!


But what should we replace them with?

  1. Change all of those static const char arrays back into #define
  2. Invent a new wrapper for static const char arrays
 (NS_TERMINATED_ARRAY?). Would such a string be marked as sharable?
  3. Something else?

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NS_LITERAL_CSTRING

[Neil]

NS_LITERAL_STRING, as its name suggests, only ever gets used on string 
literals, or macros that expand to string literals.


NS_LITERAL_CSTRING gets (ab?)used in all sorts of ways. Should we be 
consistent and require NS_LITERAL_CSTRING to be used on string literals? 
I found the following in-tree examples, none of which would have worked 
with NS_LITERAL_STRING:


static const char f00[] = f00;
F001(NS_LITERAL_CSTRING(f00));
NS_NAMED_LITERAL_CSTRING(f002, NS_LITERAL_CSTRING(F00));
templatesize_t N
void F003(const char (f00)[N])
{
 F003(NS_LITERAL_CSTRING(f00));
}
F004(NS_LITERAL_CSTRING(F00) + NS_LITERAL_CSTRING(f00));
NS_ConvertASCIItoUTF16 f005(NS_LITERAL_CSTRING(f00));
NS_NAMED_LITERAL_CSTRING(f006, f00);
f007.Assign(NS_LITERAL_CSTRING(f00));

When I tried enforcing string literals the compilers also tripped up 
over this line but it might be because of the way macros are expanded:

nsCString f008 = NS_LITERAL_CSTRING(__FUNCTION__);

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_LITERAL_CSTRING

[Ehsan Akhgari]

On 2015-04-27 6:29 AM, Neil wrote:

NS_LITERAL_STRING, as its name suggests, only ever gets used on string
literals, or macros that expand to string literals.

NS_LITERAL_CSTRING gets (ab?)used in all sorts of ways. Should we be
consistent and require NS_LITERAL_CSTRING to be used on string literals?


I would say yes.


I found the following in-tree examples, none of which would have worked
with NS_LITERAL_STRING:


These are terrible!


When I tried enforcing string literals the compilers also tripped up
over this line but it might be because of the way macros are expanded:
nsCString f008 = NS_LITERAL_CSTRING(__FUNCTION__);


That's because __FUNCTION__ doesn't get handled by the preprocessor! 
The compilers typically cannot replace it with a string sooner than the 
semantic analysis phase since they need to, well, know what function 
it's used in.  :-)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform