I totally agree with this. One of the problems I have having in configure is that OpenGL on Ubuntu 10.10 uses a lot of long long types and consequently displays errors as there are no compatible types in parrot. I know there has been discussion to move this out, but it needs resolution.
I don't know if MSVC allows C++ type comments (//) (it should of course, but who knows), but that is a minor issue. As I understand it, MSVC is the main reason we have not moved to the C99 standard long ago, so yes any subset that it understands, should be incorporated. I don't know if any other C compilers that are needed to build parrot are restricted to C89, Sun/Oracle? - can anyone clarify this. Cheers, Michael (mikehh) On 30 December 2010 09:33, Gerd Pokorra <[email protected]> wrote: > I think the most C99 standards will work on all PLATFORMS where Parrot > is used. > > 1++ > > > -- Gerd > > > Am Donnerstag, den 30.12.2010, 03:11 +0100 schrieb Andrew Whitworth: > > Parrot makes extensive use of the function snprintf for buffer-safe > > string writes. Unfortunately, snprintf is part of the C99 standard and > > officially Parrot uses C89 only. The workaround that Parrot uses is to > > #define the identifier snprintf to the function Parrot_secret_snprintf > > in src/misc.c. Unfortunately Parrot_secret_snprintf is functionally > > identical to sprintf, not snprintf. Even though we call > > "snprintf(...)", on some systems it uses Parrot_secret_snprintf, which > > does not do bounds checking and may corrupt memory. > > > > On 64-bit windows systems with MSVC, we need to define INTVAL to "long > > long" to get a 64-bit value. Unfortunately, the data type "long long" > > (and associated machinery like the standard library functions strtoll, > > etc) are C99 only. This causes known problems in IMCC on certain > > systems where we cannot use 64-bit numeric literals because IMCC uses > > strtol instead of strtoll on those systems. > > > > I would like to start the discussion about Parrot moving to C99. I > > think there is a lot of benefit to such a move, not just the two > > things I mentioned above. > > > > Of course, some systems like MSVC do not implement the complete C99 > > standard, and there's no reason we need to use all of it. I'm > > perfectly happy using the subset of C99 that is supported by MSVC. We > > already use the subset of C89 that C++ compilers support, because we > > are always careful to build on g++ even though it's more strict than a > > C89 compiler is in some cases. There's no reason we can't continue to > > use a highly portable subset of C99 that includes the features we > > already use or want to use. > > > > MSVC does have support for snprintf and long long. I suggest we make > > those things "official" parts of our repertoire, and require them in > > all supported platforms. > > > > As chromatic once said "HELLO FROM THE 21ST CENTURY PLEASE JOIN US THE > > WATER IS FINE" > > > > --Andrew Whitworth > > > > --Andrew Whitworth > > _______________________________________________ > > http://lists.parrot.org/mailman/listinfo/parrot-dev > > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Michael H. Hind Cell: +44 (0) 7877 224 745
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
