Move Parrot to C99 (subset)

Shane Calimlim shane at wayforward.com
Thu Dec 30 13:07:12 UTC 2010


I'm not a regular contributor and my opinion probably doesn't count
for a lot -- but, I suspect good MSVC support is worth the trouble.  A
lot of developers use it, and proper support for it would help draw
them in.  I've wanted to contribute to open source projects many
times, downloaded the source, realized what poor (if any) MSVC support
they had, and decided to spend my time elsewhere rather than going
through some convoluted ordeal to get the project to build -- possibly
breaking or complicating the build of my day job's projects in the
process.

Don't get me wrong, I appreciate the work you guys on linux/gcc do
very much.  We would both like to see these projects succeed, and
getting more contributors is an excellent way to improve the odds.  I
suspect there are a lot of devs in a similar situation as I am.  It's
been a long time dream of mine to maintain p5/parrot MSVC .sln's
ready-to-build, but unfortunately time just hasn't allowed for it.

On Thu, Dec 30, 2010 at 4:00 AM, Lucian Branescu
<lucian.branescu at gmail.com> wrote:
> 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">
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list