[llvm-dev] Quality of LLVM headers

Paweł Bylica via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 20 12:16:29 PDT 2016


On Mon, Jun 20, 2016, 21:07 Justin Bogner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev
> wrote:
> >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote:
> >>
> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev
> wrote:
> >> > > Hi LLVM,
> >> > >
> >> > > I want to complain a bit about the quality of the code included in
> the
> >> > > public LLVM headers. For projects that depend on LLVM is really
> hard to
> >> > > just include LLVM headers not to trigger tons of warnings.
> >> > >
> >> > > Moreover, the is this issue that you have to define
> __STDC_LIMIT_MACROS
> >> > and
> >> > > __STDC_CONSTANT_MACROS everywhere just to include single
> DataTypes.h.
> >> > > Strangely, it seems to be required only when compiling with clang,
> not
> >> > with
> >> > > GCC.
> >> > >
> >> > > Can we do anything to improve the situation?
> >> > >
> >> > > I have just one idea, to add unittests that only include public
> headers
> >> > > with higher compiler restrictions than for LLVM code in .cpp files.
> >> >
> >> > Get a system with C++11 compliant system headers.
> >> >
> >>
> >> What do you mean exactly? How is this related?
> >
> > __STDC_LIMIT_MACROS and co are requirements by C99 superseded by C++11.
> > If your system headers correctly implement C++11, you don't need them.
>
> Apparently DataTypes.h does the following:
>
>   #if !defined(__STDC_LIMIT_MACROS)
>   # error "Must #define __STDC_LIMIT_MACROS before #including
> Support/DataTypes.h"
>   #endif
>
> I'm guessing this is what Paweł is talking about. Maybe this is an
> obsolete check from before we required a C++11 compliant host compiler?
>

Exactly. This is required to have macros like ULONG_MAX available in
DataTypes.h. I wander if that requirement can be replaced with something
less intrusive for projects depending on LLVM.

I can work on changes, but need at least a clue that has a chance to be
accepted.

_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160620/7fbc4b59/attachment.html>


More information about the llvm-dev mailing list