[llvm-commits] [PATCH] Replace all uses of std::string* for errors with error_code in Support/MemoryBuffer.

Michael Spencer bigcheesegs at gmail.com
Thu Dec 9 07:21:13 PST 2010


On Thu, Dec 9, 2010 at 3:24 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Dec 7, 2010, at 1:23 PM, Michael Spencer wrote:
>
>> The two attached patches replace all uses of std::string* for error
>> handling with error_code in Support/MemoryBuffer and updates clients
>> to use them.
>
> Sounds good to me, please apply with some minor changes:
>
> +++ b/include/llvm/Support/MemoryBuffer.h
> @@ -16,7 +16,7 @@
>
>  #include "llvm/ADT/StringRef.h"
>  #include "llvm/Support/DataTypes.h"
> -#include <string>
> +#include "llvm/Support/system_error.h"
>
> Please extern system_error instead of #including it.

OK.

> +++ b/include/llvm/Support/system_error.h
> @@ -668,6 +668,11 @@ public:
>  const error_category& generic_category();
>  const error_category& system_category();
>
> +/// Get the error_category used for errno values from POSIX functions. This is
> +/// the same as the system_category on POISIX systems, but is the same as the
> +/// generic_category on Windows.
> +const error_category& posix_category();
>
> Space before the &, not after.

All the rest of the code is like this. It's from libc++ with minimal
changes to make it easier to share future changes.

> Aside from minor stuff, one thing strikes me as odd: the FS interfaces all return the errorcode as the result value, and the result as an "out" parameter.  I think this is a good pattern, and we should encourage it for clients as well.  What do you think about:
>
>  ...
>  static error_code getSTDIN(std::auto_ptr<MemoryBuffer> &Result);
>  ...
>
> Use of auto_ptr also self-documents that the client owns the result pointer.  What do you think?
>
> -Chris

I'd prefer OwningPtr, but I agree. It will take a lot longer to make
this change because it will require some refactoring of clients to
properly use the smart pointer, but I'll work on it.

- Michael Spencer




More information about the llvm-commits mailing list