similar to: [LLVMdev] Style question: NULL or 0?

On Aug 17, 2011, at 4:41 PM, Jordy Rose wrote: > Hi, LLVM. I have a question I'd like to get put into the official style guidelines: do we prefer NULL or 0 for C++ objects? I've seen both throughout the code. > > Personally I prefer NULL, since it establishes that something is a pointer and not an integer (or integer-constructed object, but thankfully we avoid implicit

On Wed, Aug 17, 2011 at 4:41 PM, Jordy Rose <jediknil at belkadan.com> wrote: > But I think I read somewhere that 0 is more C++esque. I believe Stroustrup espoused this at one point (perhaps even on his website) on the basis that using NULL gives you a false sense of security - which isn't entirely true now that compilers (GCC & clang presumably) will warn you about using NULL

On Wed, Jun 3, 2015 at 12:21 AM, Nick Lewycky <nlewycky at google.com> wrote: > On 1 June 2015 at 07:20, Marshall Clow <mclow.lists at gmail.com> wrote: > >> This weekend, I got an email from Nuno Lopes informing me that UBSAN now >> paid attention to attribute(nonnull), and he was having some problems with >> it going off when using libc++. >> > >

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow wrote: > P.S. recent gcc (at least 4.8.x and later) make optimizations based on > this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL). BTW, this seems to be more an issue with glibc adding the tagging and not behavior of GCC itself. Joerg

This weekend, I got an email from Nuno Lopes informing me that UBSAN now paid attention to attribute(nonnull), and he was having some problems with it going off when using libc++. I did some investigation, and found that he was exactly right - there were places (deep inside the vector code, for example) which called std::memcpy(null, null, 0) - which is definitely UB. In an ideal world, our C

On Nov 6, 2012, at 2:19 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > Binutils and LLVM > > As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. I have summarized the information that I've gathered, and put it up

On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: > Author: hhinnant > Date: Fri Feb 14 15:09:01 2014 > New Revision: 201432 > > URL: http://llvm.org/viewvc/llvm-project?rev=201432&view=rev > Log: Remove myself as owner of libc++ > > Modified: > llvm/trunk/CODE_OWNERS.TXT > > Modified: llvm/trunk/CODE_OWNERS.TXT > URL:

Binutils and LLVM As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. As a start, I'd like to summarize the current status, and ask people for help updating the list. List taken from <http://www.gnu.org/software/binutils/>

In a discussion on IRC, Micheal was complaining about the semantics of StringSet, specifically how the iterators work. DannyB mentioned that we have a Trie class, so I decided to check it out. Lo and behold, I couldn't find _any_ uses of it, and when I deleted it from my system and did a clean rebuild, everything was fine. Looking at the log, the last substantial change to this class was in

As part of the work on C++17, WG21 released a series of "Technical Specifications", (TS) which added proposed new features to the standard library. These were all defined in the namespace 'std::experimental' (and namespaces inside of that). Then, much of these features were merged into the main standard, and became part of namespace 'std'. Libc++ now has two

So, I'm trying to use this file to look inside COFF files. Got the header. OK. Now I want to look at the sections. Look, there's a section iterator. I can use that! So, I write: for (llvm::object::section_iterator iter = Obj.begin_sections (); iter != Obj.end_sections(); ++iter ) and it doesn't compile. There's no ++ for section iterators. Apparently, you're supposed to

The file begins: > #ifndef LLVM_SUPPORT_WIN_COFF_H > #define LLVM_SUPPORT_WIN_COFF_H Why "WIN_COFF_H" - since this code is not windows-specific, as far as I can tell. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists at gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). --

The upcoming C++1z (probably C++17) standard will not contain several things - most notably auto_ptr. Soon, libc++ will not be providing auto_ptr by default when building in C++1z mode. You'll be able to get it back with a "-D_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" on your command line, or "#define _LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR" before including any libc++ header

On Mar 12, 2013, at 7:36 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Renato, > >> The test is initializing srand(1), so in theory, it shouldn't be different >> between compilers, since Clang is using the same libraries. > > If Clang and GCC disagree on the same source, same machine and with > the same libraries, that certainly is odd. But it

On Tue, Jan 12, 2016 at 10:27 PM, Yury Gribov via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > As for C++11, it has for e.g. srtd::sort: > > "Requires: operator< (for the version with no arguments) or comp (for the > version with a comparison argument) defines a strict weak ordering (25.4)." > > which also sounds like UB. Exactly correct. If your

<dynarray> was added to the C++14 standard, libc++ implemented it, and then it was removed. Now (from the standard’s point of view), it is in limbo. I would like to move it into std/experimental; to make it clear that it’s not a part of the standard. Any objections? Anyone using it? — Marshall

On Mon, Apr 10, 2017 at 1:22 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > As part of the work on C++17, WG21 released a series of "Technical > Specifications", (TS) which added proposed new features to the standard > library. These were all defined in the namespace 'std::experimental' (and > namespaces inside of that). > > Then, much of these

Delete it. =] Thanks. On Tue, Sep 4, 2012 at 9:53 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > In a discussion on IRC, Micheal was complaining about the semantics of > StringSet, specifically how the iterators work. > > DannyB mentioned that we have a Trie class, so I decided to check it out. > Lo and behold, I couldn't find _any_ uses of it, and when I deleted

Over the weekend I upgraded my system to Mac OS X 10.8, and now a clean cmake build fails. The error message: > Building C object runtime/libprofile/CMakeFiles/profile_rt-static.dir/CommonProfiling.c.o > cc1: error: unrecognized command line option "-Wcovered-switch-default" The configuration: > Mac OS X 10.8 > CMake 2.8.8 > LLVM tot > Apple clang version 4.0

On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner wrote: > Why should memset / memcpy be attribute nonnull? Is there standardese that > supports that? The generic entry text of the standard section. IMO this is a standard bug and someone should *please* get it fixed. It is ridiculous that zero sized operations are considered UB. Joerg