Move Parrot to C99 (subset)

[Lucian Branescu]

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 <mike.hind at gmail.com> 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 <gp at zimt.uni-siegen.de> 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">