>2017-10-30 19:19 GMT+01:00 Kris Maglione :
>
>> Our static analysis tools are pretty good at catching a lot of lambda
>> capture bugs at this point, though. I'd be much less comfortable using them
>> if they weren't.
>>
>> It's probably worth considering whether we need to write static analysis
>>
2017-10-30 19:19 GMT+01:00 Kris Maglione :
> Our static analysis tools are pretty good at catching a lot of lambda
> capture bugs at this point, though. I'd be much less comfortable using them
> if they weren't.
>
> It's probably worth considering whether we need to write static analysis
> tools f
On 10/30/2017 10:03 PM, Kris Maglione wrote:
On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:
Okay, this is half the argument. The second half would be:
- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more l
On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:
Okay, this is half the argument. The second half would be:
- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on t
On Mon, Oct 30, 2017 at 11:04:10AM -0400, Boris Zbarsky wrote:
On 10/30/17 10:52 AM, Simon Sapin wrote:
How do new language features lead to security bugs?
By making unsafe behaviors easier or more tempting.
For example:
[&]() { /* stuff */ }
is a huge footgun in a language without a borrow
Okay, this is half the argument. The second half would be:
- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.
- Is ranged-for more prone to iterator invalidati
On 10/30/2017 04:52 PM, Simon Sapin wrote:
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just bec
On 10/30/17 10:52 AM, Simon Sapin wrote:
How do new language features lead to security bugs?
By making unsafe behaviors easier or more tempting.
For example:
[&]() { /* stuff */ }
is a huge footgun in a language without a borrow checker. You _could_
still do something like that before lam
I don't know about C++14 specifically, but a good example is C++17's
std::string_view, which allows an implicit cast from std::string&& and can
very easily lead to UAF:
https://github.com/isocpp/CppCoreGuidelines/issues/1038
Alex
On Mon, Oct 30, 2017 at 10:52 AM, Simon Sapin wrote:
> On 30/10/1
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features
And let's be careful with the new C++ features, pretty please.
We managed to not be careful when we started to use auto, or ranged-for or
lambdas.
I'd prefer to not fix more security critical bugs or memory leaks just because
of fancy hip and cool
language features ;)
-Olli
On 10/30/2017 05
How will this affect the matrix of specific C++ features we can use?
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
(At the moment I'm dying for generic lambdas, which are C++14. I'd been
using std::function as a workaround, but I also need control over the
allocation policy, w
This has reached mozilla-central and nightlies are now being built with
VS2017.
The clang-cl builds (which still rely on a VS package for link.exe, among
other things) remain on VS2015 while I work out some issues in clang-cl's
path detection. All other Windows jobs have moved to VS2017.
While I'
On Fri, Oct 27, 2017 at 12:03 AM, Xidorn Quan wrote:
> On Thu, Oct 26, 2017, at 12:24 PM, Ted Mielczarek wrote:
>> On the other hand, it's easier to
>> justify dropping support if VS is the last compiler holding us back from
>> being able to use new C++ features.
>
> FWIW, it's not at the moment.
On Thu, Oct 26, 2017, at 12:24 PM, Ted Mielczarek wrote:
> On the other hand, it's easier to
> justify dropping support if VS is the last compiler holding us back from
> being able to use new C++ features.
FWIW, it's not at the moment. Currently we are really only blocked on
GCC for new C++ featur
On 2017-10-26 12:19 PM, Ryan VanderMeulen wrote:
On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they
are not needed anymore?
Our compiler toolchains are determin
On 10/26/2017 10:14 AM, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
Our compiler toolchains are determined with in-tree configs nowadays, so
this change wo
It would be great to get these speed gains for 58, hot on the heels of the
57 release.
My plan is this: if I can get this landed by Monday, that still leaves two
weeks in the cycle. Based on my positive experience thus far with this
compiler (this update has been much more smooth than past ones),
Agreed, changing compilers of an already-released ESR isn't a good idea.
You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
using
On 26/10/2017 15:14, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
Yes, IMO.
Whether or not we're "locked" in any technical sense, I think we should
proba
Are we locked into using the same compiler for the ESR updates? In
other words, do we need to keep VS2015 for ESR52 builds until they are
not needed anymore?
On 26-Oct-17 3:31, Sylvestre Ledru wrote:
Hello,
On 25/10/2017 23:48, David Major wrote:
I'm planning to move production Windows bui
Hello,
On 25/10/2017 23:48, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
In which version are you planning to land this change?
As we are close to the end of the 58 cycle in nightly, it would be great
to wait for 59.
Thanks,
Sylvestre
On Wed, Oct 25, 2017, at 05:48 PM, David Major wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
Thanks for doing the work on this!
> VS2017 has optimizer improvements that produce faster code. I've seen
> 3-6%
> improvement on Speedometer. There is als
I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.
VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visua
24 matches
Mail list logo
