Is MSVC support that important? I know other projects just gave up on it to save themselves the trouble.
On 30 December 2010 11:39, Michael Hind <[email protected]> wrote: > 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++ >> >> 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"> _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
