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
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
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_C
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
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.
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
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
7 matches
Mail list logo
