On Thu, Dec 30, 2010 at 6:39 AM, 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.
MSVC, as far as I am aware, supports snprintf, long long (strtoll, strtoull, etc) and // comments. I don't necessarily think that we should allow // comments as a stylistic thing, but the other features should be fine to use. suncc and most other C compilers I can think of all allow these same things. --Andrew Whitworth >> >> 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
