Compiling issues with libc 2.12

[naszta]

• What is the issue you have?
  Compile error.

• Please describe the steps to reproduce the issue. Can you provide a small but working code example?
  https://sourceware.org/bugzilla/show_bug.cgi?id=15366
  I have compile error in debug mode on this line:
  https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/conversions/to_chars.hpp#L754

• What is the expected behavior?
  Code should be compiled.

• And what is the actual behavior instead?
  It doesn't compile.

• Which compiler and operating system are you using? Is it a supported compiler?
  I'm on gcc 5.3 with C++14 with RH 6 compatible ABI
  (https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/ - RH 6)

• Did you use a released version of the library or the version from the develop branch?
  Both.

• If you experience a compilation error: can you compile and run the unit tests?
  __STDC_LIMIT_MACROS was added to the project and the issue has gone.

Possible fix:
#if !defined(NDEBUG) && !defined(__STDC_LIMIT_MACROS)
#define __STDC_LIMIT_MACROS
#endif
(may be with #pragma push_macro and #pragma pop_macro)
to
https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/conversions/to_chars.hpp#L2

[nickaein]

As have stated in your bugzilla link, this is more like a libc bug that has been fixed in newer versions. If switching to newer versions are off the table, can you use the workaround your proposed in your application?

Adding this workaround to the library code could be problematic. Defining __STDC_LIMIT_MACROS along with all macros with double underscores are reserved in C++ standard. Strictly speaking, defining a macro with double underscores is undefined behavior:

"Reserved" here means that the standard library headers #define or declare such identifiers for their internal needs, the compiler may predefine non-standard identifiers of that kind, and that name mangling algorithm may assume that some of these identifiers are not in use. If the programmer uses such identifiers, the behavior is undefined.

However, defining such macro inside an application that its code isn't going to spread in multiple place and referenced in various people could be probably safe and can be swept under the rug.

[garethsb]

A user of my library hit this with glibc 2.17 also. So far as I can tell, defining __STDC_LIMIT_MACROS is harmless.

More background here:
https://sourceware.org/ml/libc-alpha/2013-04/msg00598.html

[naszta]

I thought that adding a macro to the source would keep the issue locally. Older libc versions are widely used so it would be a big help for many developers. BTW: the best solution would be just simply use std::numeric_limits<type>::max() against macros.

[nickaein]

std::numeric_limits<T>::max() seems cleaner than macros. I've done some digging and it seems that it is defined for the basic arithmetic types and the standard has left the specialization of types like uint64_t optional and up to implementer. So to be pedantic, std::numeric_limits<uint64_t>::max() is not guaranteed to be available on a conforming C++11 compiler while INT64_MAX is.

In practice, it is very unlikely that an library implementer left these specializations out though.

[naszta]

We know the supported compilers. We could have issues with macros on the supported compilers while we know that numeric limits work nicely. I would go for numeric limits.

[nlohmann]

Any proposal how to proceed here?

[naszta]

I'm happy to create the change (from macro to numerical_limits). I wouldn't create, if it won't be merged. So are you okay with that solution?

[nlohmann]

Yes, please change to numeric_limits.

[naszta]

I create it till Friday.

[naszta]

#1514 is opened.

[nlohmann]

Closed by merging #1514.