Move Parrot to C99 (subset)

[Andrew Whitworth]

On Thu, Dec 30, 2010 at 6:39 AM, 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.

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
>