Move Parrot to C99 (subset)

Michael Hind mike.hind at gmail.com
Thu Dec 30 11:39:35 UTC 2010


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 <gp at zimt.uni-siegen.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20101230/69f9a13e/attachment.html>


More information about the parrot-dev mailing list