Can we assume C99?

[Cantor, Scott]

I don't know what the baseline has been for the code base, is C99 a reasonable requirement?

I need SIZE_MAX to fix some bounds checking errors, just need to know if I need to waste time on an autoconf test for it.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-***@xerces.apache.org
For additional commands, e-mail: c-dev-***@xerces.apache.org

[Roger Leigh]

Visual Studio had somewhat lacking C99 support, so it might be problematic for older versions.
Could we not use std::numeric_limits instead?  It should work everywhere, and should be better supported than C99?

Regards,Roger


Roger Leigh
-------- Original message --------From: "Cantor, Scott" <***@osu.edu> Date: 06/07/2017 16:04 (GMT+00:00) To: c-***@xerces.apache.org Subject: Can we assume C99?
I don't know what the baseline has been for the code base, is C99 a reasonable requirement?

I need SIZE_MAX to fix some bounds checking errors, just need to know if I need to waste time on an autoconf test for it.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-***@xerces.apache.org
For additional commands, e-mail: c-dev-***@xerces.apache.org

[Cantor, Scott]

Post by Roger Leigh
Visual Studio had somewhat lacking C99 support, so it might be problematic
for older versions.

It's not missing SIZE_MAX though, AFAIK, so Windows isn't really much of a concern there.

Post by Roger Leigh
Could we not use std::numeric_limits instead? It should work everywhere,
and should be better supported than C99?

Possibly, I'm not as familiar with it. If we're referring to size_t in the code, which we are, I wanted to be consistent with that. I checked in this change for now so I could patch a bug in Base64.cpp, and it's indirecting via XERCES_SIZE_MAX, so it's easy enough to change, though hard to test.

I think your cmake check around some of this may be slightly off. It was including stdint.h but if you do that in C++, you don't get the MAX macros unless you define another macro apparently. I don't get cstdint usable on Linux without C++11, so it's falling into the stdint.h part, and I had to alter your cmake version to make that work.

-- Scott

B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[��Y]�][��X��ܚX�P\��\˘\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

[Roger Leigh]

Post by Cantor, Scott

Post by Roger Leigh
Visual Studio had somewhat lacking C99 support, so it might be problematic
for older versions.

It's not missing SIZE_MAX though, AFAIK, so Windows isn't really much of a concern there.

OK, that's good news.

Post by Cantor, Scott

Post by Roger Leigh
Could we not use std::numeric_limits instead? It should work everywhere,
and should be better supported than C99?

Possibly, I'm not as familiar with it. If we're referring to size_t in the code, which we are, I wanted to be consistent with that. I checked in this change for now so I could patch a bug in Base64.cpp, and it's indirecting via XERCES_SIZE_MAX, so it's easy enough to change, though hard to test.

http://en.cppreference.com/w/cpp/types/numeric_limits

Should be as simple as:

#include <limits>

std::numeric_limits<size_t>::min()
std::numeric_limits<size_t>::max()

std::numeric_limits<ssize_t>::min()
std::numeric_limits<ssize_t>::max()

Limits are defined for all the standard integer types.

Post by Cantor, Scott
I think your cmake check around some of this may be slightly off. It was including stdint.h but if you do that in C++, you don't get the MAX macros unless you define another macro apparently. I don't get cstdint usable on Linux without C++11, so it's falling into the stdint.h part, and I had to alter your cmake version to make that work.

Interesting, I'll certainly take a look. I'm afraid I'm away until next
Wednesday, so I won't be able to do anything until then.


Regards,
Roger

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-***@xerces.apache.org
For additional commands, e-mail: c-dev-***@xerces.apache.org

[Cantor, Scott]

Post by Roger Leigh
Interesting, I'll certainly take a look. I'm afraid I'm away until next
Wednesday, so I won't be able to do anything until then.

If you want to check it, this is what I had to use on the autoconf side:

#if defined(__cplusplus) && XERCES_HAVE_CSTDINT
# include <cstdint>
#elif XERCES_HAVE_STDINT_H
# if defined(__cplusplus)
# define __STDC_LIMIT_MACROS
# endif
# include <stdint.h>
#endif

Yours drops into the first bit so it didn't ever have to try and depend on stdint.h, but if you ever had to depend on that, the __STDC_LIMIT_MACROS defintion is required by the C99 standard if you want the limit macros defined in stdint.h when C++ is used.

Of course, your point about using numeric_limits is probably valid, but I don't know precisely when/where that might be unsupported.

-- Scott


Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���â2�FWb�V�7V'67&�&T�W&6W2�6�R��&pФf�"FF�F����6����G2�R�

[Cantor, Scott]

Are you using C++11 in the cmake CI builds on Linux? Just curious...it seems to be detecting cstdint there but my autoconf test didn't due to that flag not being enabled.

I don't think we have an autoconf check for it, so there's nothing to enable it if the compiler supports it.

-- Scott

Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���â2�FWb�V�7V'67&�&T�W&6W2�6�R��&pФf�"FF�F����6����G2�R�

[Roger Leigh]

Post by Cantor, Scott
Are you using C++11 in the cmake CI builds on Linux? Just curious...it seems to be detecting cstdint there but my autoconf test didn't due to that flag not being enabled.

Yes. It's the

set(CMAKE_CXX_STANDARD 14)

line. This tries to use C++14, then if it fails it will fall back to
C++11 and C++98. So it basically puts the compiler into the highest
mode it can, and then we perform the feature tests with the compiler in
that mode. The <cstdint> checks will fail if the compiler isn't in a
suitable mode, and it will fall back to the other types.

Post by Cantor, Scott
I don't think we have an autoconf check for it, so there's nothing to enable it if the compiler supports it.

I wrote the Autoconf AC_PROG_CXX support for C++11 back in 2013
(http://www.spinics.net/lists/ac/msg11596.html) but it appears not to
have made it into a stable release yet. It might be possible to take a
copy of the macro from Autoconf CVS. (This was before I discovered CMake!)


Regards,
Roger

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-***@xerces.apache.org
For additional commands, e-mail: c-dev-***@xerces.apache.org

[Cantor, Scott]

Post by Roger Leigh
I wrote the Autoconf AC_PROG_CXX support for C++11 back in 2013
(http://www.spinics.net/lists/ac/msg11596.html) but it appears not to
have made it into a stable release yet. It might be possible to take a
copy of the macro from Autoconf CVS. (This was before I discovered CMake!)

Seems like it might be worth it, I'll take a look. It would be simpler to compare outcomes with the cmake builds at least.

-- Scott


Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���â2�FWb�V�7V'67&�&T�W&6W2�6�R��&pФf�"FF�F����6����G2�R�

[Boris Kolpackov]

Post by Cantor, Scott
I don't know what the baseline has been for the code base, is C99 a reasonable requirement?
I need SIZE_MAX to fix some bounds checking errors, just need to know
if I need to waste time on an autoconf test for it.

My experience has been that supporting a standard (like C99 or C++98)
is pretty pointless, especially for things like C++11 and beyond: most
compilers these days only support a subset of their features. Your case
is a good example: VC is not C99-compliant but has SIZE_MAX. When it
comes to C++, VC supports features from 14 and 17 while not being fully
C++11-compliant.

So what we found works much better is to define a set of compilers and
their versions that we support -- any feature supported by all of them
is fair play.

Perhaps we should do something like this for Xerces-C++, especially if
we plan to start migrating to C++11. In fact, this will be a great aid
to gradual migration since we can just start using new features if they
are available in all the supported compilers.

Boris

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-***@xerces.apache.org
For additional commands, e-mail: c-dev-***@xerces.apache.org

[Cantor, Scott]

Post by Boris Kolpackov
Perhaps we should do something like this for Xerces-C++, especially if
we plan to start migrating to C++11. In fact, this will be a great aid
to gradual migration since we can just start using new features if they
are available in all the supported compilers.

It's certainly workable for me but I only support a fairly limited set myself so it's hard for me to say what others might need, or be able to avoid problems, unless Travis or similar tool exists to verify the build, or we have volunteers I guess.

-- Scott


Т���������������������������������������������������������������������ХF�V�7V'67&�&R�R���â2�FWb�V�7V'67&�&T�W&6W2�6�R��&pФf�"FF�F����6����G2�R