- User Since
- Dec 27 2014, 8:52 PM (159 w, 4 d)
Thu, Jan 4
Tue, Jan 2
@weimingz: Since your platform supports srand(0), is it possible to look at how your platform implements srand(0) and "inline" that implementation into random_device? That seems like it would be more in keeping with the other ifdefs in this file.
Dec 16 2017
I keep seeing patches go by for other targets where they're just implementing random_device for their target. It doesn't *have* to be based on an actual /dev/urandom. You can see all the other options under #ifdefs in this file: getentropy, /dev/random, nacl_secure_random, arc4random, rand_s,... If you're on a target that doesn't have any of these, then IMO the appropriate patch would be one of
Dec 13 2017
Nov 16 2017
Oct 9 2017
I'm also much out of my depth here, but I'm skeptical. You're changing the comments in the code from essentially saying "This workaround helps people with broken code" to essentially saying "This indispensable functionality helps people like me who use dlopen()." Are you 100% sure that you're not just a person with broken code?
Sep 18 2017
Sep 17 2017
Sep 13 2017
Sep 12 2017
Sep 11 2017
TODO.txt says "future should use <atomic> for synchronization." I would have interpreted this as meaning that the line
Aug 8 2017
Aug 3 2017
I've updated D35863 to be actually correct AFAICT from my local testing; but I'm not sure what's the most appropriate way to get "fancy allocator" tests into libcxx's test suite. The way I did it locally is here:
Basically, I conditionally replace "test_allocator.h" with "test_fancy_allocator.h", and then re-run all the existing tests. "test_fancy_allocator" uses fancy pointers that carry with them a "payload" of the allocated size n, and then in a.deallocate(p,n) we assert that p.payload()==n. A bunch of list tests fail this assertion before this patch, and none fail after this patch.
Jul 28 2017
But if I'm overseeing reasons to issue a warning in this case, we could add an analogue of -Wshadow-uncaptured-local for this case. WDYT?
Jul 25 2017
Jul 18 2017
If the goal is fine-grained control over the heuristics for compiling switch statements, perhaps one should enumerate all the possible ways to lower switch statements --- jump-tables, lookup-tables, if-trees, if-chains, (more?) --- and add a separate flag for each of them.
...Although I'm not sure what purpose there'd really be in saying "This switch statement *must* be compiled into an if-else tree" or "this one *must* be a lookup table"; couldn't that end up being a pessimization one day, as the optimizer gets smarter?
Jun 26 2017
Mar 27 2017
Mar 10 2017
I notice that the Standard implies that std::unique_ptr<T> will work only with *object types* T, and yet the "object" wording is missing from shared_ptr.
Jan 11 2017
Jan 10 2017
Dec 29 2016
Dec 26 2016
PVS-Studio implements tons of checks of this variety. See e.g.
They don't have a catchy name for the category either, but perhaps "suspicious-" or "copypaste-" would do.
Dec 16 2016
The provided example (typoing "i" for "j") sounds like the sort of thing that PVS-Studio catches; maybe see what wording they use for that kind of mistake? Without investigating, I would suggest "cut-and-paste-error" or "likely-typo".
Dec 15 2016
LGTM. I wonder if rsmith is happy with the exact semantics of "shouldUseUndefinedBehaviorReturnOptimization"... but that seems like a tiny nit that's fixable post-commit anyway.
Nov 28 2016
Sep 8 2016
Jul 19 2016
May 5 2016
It seems like this proposed diagnostic and fixit, statistically speaking, is *never* correct.
In the cases where there is a code issue to be corrected, the diagnosable issue really seems to involve dataflow analysis:
Apr 15 2016
I would like to see a new version of http://reviews.llvm.org/D19105 with all the "1-bit-bitfield" diffs removed.
Right now, it's hard to see that there's *anything* in D19105 that's not a miscorrection of a 1-bit bitfield.
Apr 16 2015
Dec 28 2014
Dec 27 2014
Commented on a test. The functional change is way out of my league.
Also consider adding a "three-pass" test case similar to