Misc #20156
openC99 updates
Description
Now that we require Visual Studio 2015 and Oracle Developer Studio 12.5, we can do a couple of things to clean up:
- We should be able to remove our custom
stdbool.h
(added in VS2015 and Oracle SS 12.3) - Remove our usage of
__restrict
for Windows (added in VS2015) - Remove our custom
va_copy
(added in VS2015)
Just notating, a couple of things that we can use now:
- snprintf
- size_t printf format specifier (%z)
I'm happy to do this work, but I wanted to open this ticket in case there is something besides Visual Studio or Oracle Solaris Studio that I would have missed for one of our compilation targets. Are there any other targets that do not fully implement C99?
Updated by nobu (Nobuyoshi Nakada) 4 months ago
kddnewton (Kevin Newton) wrote:
Now that we require Visual Studio 2015 and Oracle Developer Studio 12.5, we can do a couple of things to clean up:
- We should be able to remove our custom
stdbool.h
(added in VS2015 and Oracle SS 12.3)
b75828fdfadaff6c5e09e42be32dff1216ed8fb1 says:
Fix compile error with Oracle Solaris Studio 12.4 on Solaris 10.
No problem with Oracle SS 12.5?
- Remove our usage of
__restrict
for Windows (added in VS2015)
_MSC_VER
1800 seems VS2013, so we might have been able to drop this condition already.
!if $(MSC_VER) >= 1800
#define restrict __restrict
!else
#define restrict /* not supported */
!endif
- Remove our custom
va_copy
(added in VS2015)
This is removed already?
Just notating, a couple of things that we can use now:
- snprintf
We use our custom snprintf
not only for old platforms, but also to avoid locales.
Updated by kddnewton (Kevin Newton) 4 months ago
I was going based on https://github.com/ruby/ruby/wiki/C99-Usage-Guidelines. Maybe this documentation needs to be updated.
b75828fdfadaff6c5e09e42be32dff1216ed8fb1 says:
Fix compile error with Oracle Solaris Studio 12.4 on Solaris 10.
No problem with Oracle SS 12.5?
The title of that commit is Support C89 if possible
. @ngoto (Naohisa Goto) was that necessary for actual C99 compilers or only to support old out-of-date compilers?
_MSC_VER 1800 seems VS2013, so we might have been able to drop this condition already.
Yes I think this is true.
We use our custom snprintf not only for old platforms, but also to avoid locales.
I see, thanks for the clarification.