Re: GNAT on WinXP: System.OS_Lib.Spawn raises Program_Error

[Martin <martin.dowie@btopenworld.com>]

On May 2, 9:39 pm, a...@anon.org (anon) wrote:
> Martin
>
> GNAT.OS_LIB existed in GNAT 3.15p  but since GNAT 2005 it have been
> moved to System.OS_LIB.  And the GNAT.OS_LIB just renames System.OS_LIB
> which makes this package a legacy for older projects and can be avoided for
> future use. It just causes more work for the compiler which increase the
> compile time.

Still there in the Win32 GPL 2008 edition.


> Plus, there are only 6 System files in the RM Ada standards:
>
>   0. System
>   1.   System.Address_To_Access_Conversions
>   2.   System.Machine_Code
>   3.   System.RPC
>   4.   System.Storage_Elements
>   5.   System.Storage_Pools
>
> All others System packages like all GNAT packages are non RM Ada
> standard package list. And any GNAT Ada programmer should know that.

You're assuming a level of knowledge that I don't find in the real
world.


> Adacore's annual or GNU quarterly update of GNAT is the Ada standard, for
> most people and schools, and very few programmers will use anything else.

I have no proof that 'very few programmers will use anything else' and
I suspect you don't either. I've used (professionally) 7 Ada compilers
that I can think of off the top of my head. And at least 1 more that
I've just on a personal level. That's not counting all the different
versions of each compiler separately.


> And any improvement that Adacore makes that is passed to GNU version will
> become to most programmers, additions to the Ada standards.  Just like a
> lot of programmers were using the Ada 2005 specs before they were approved
> in January, 2008.

GNAT extensions are not likely to become standard. Ada2005 specs were
_very_ likely to become standard.

Besides, I assume were all here in c.l.a. because we want to see
_more_ Ada in the world, so hopefully that means more people using all
Ada compilers and not just GNAT. We should be pointing out the 'right
thing to do' to all and let them make their minds up.


> Plus, "GNATLINK" uses "System.OS_LIB.spawn" to call the "gcc" compiler
> to compile the binder generated file.  If this was not OK, then why would
> Adacore or GNU use it?

Because AdaCore / GNU and certainly not going to port they're code to
a different compiler.


> And finally the RM allows the usages of additional System packages to be
> included in a standard.  System.OS_LIB is an "implementation-defined
> children of System" see, RM 13.7 (36),

The RM also allows the use of 'goto', are you advocating wide-spread
use of this facility too? Just because something is allowed does not
make it a 'good idea'.


> So you need to stop with the idea using non standard packages is a "bad
> idea". Plus, all that is needed is a few comments for future version of
> GNAT. And that because most programs written with GNAT will almost
> never be move from GNAT, so only updating comments are needed.

Sorry, that's just pants.

I just went though a porting exercise at work where a project was
looking to migrate from XD-Ada/68k to <some_other_Ada_product>/
PowerPC. One issue with XD-Ada based systems was that XD-Ada included
various non-standard extensions to package System - types of a known
size. This is the 2nd project I've seen that made _large_scale_ use of
these types throughout their code.

Perfectly avoidable (by defining types they know to match the size
required, perhaps even calling it 'Interfaces') or limiting the effect
by defining their own 'Project_System' package. The 1st option would
have involved 0 hours work the 2nd option a 2 minute job with minimal
source code files touched. In the end _dozens_ of files needed to be
modified and that incurs a lot more time (i.e. money) to check / re-
test.

Like I said - this is not the first time this has happened (and not
just with Ada - VC++ no hasn't come with <iostream.h>, only
<iostream>, since 2005 and I've seen projects which started post-98
when <iostream> was the standard header defined get bitten by this).

Cheers
-- Martin