GNAT on WinXP: System.OS_Lib.Spawn raises Program_Error

GNAT on WinXP: System.OS_Lib.Spawn raises Program_Error

[daniel.wengelin]

Though not an Ada issue, really, someone here might have had the same
problem as I have had: I tried to make a small program start another
program using System.OS_Lib.Spawn. However, it raised Program_Error
and stated Exception_Access_Violation.

Any ideas why, and what to do about it?

/D

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

[Jeffrey R. Carter]

daniel.wengelin@home.se wrote:
> Though not an Ada issue, really, someone here might have had the same
> problem as I have had: I tried to make a small program start another
> program using System.OS_Lib.Spawn. However, it raised Program_Error
> and stated Exception_Access_Violation.
> 
> Any ideas why, and what to do about it?

Have you tried GNAT.OS_Lib.Spawn?

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

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

[anon]

First, in GNAT GPL 2008, GNAT.OS_LIB renames System.OS_LIB, so using 
GNAT.OS_LIB would be a waste of time.
Note: Spawn and Ada task can have problems. Should be avoided. Also, 
      in some case "spawn" is disabled.

Second, it would be helpful to give some code.

In the mean time, using the simple routine version it sounds like its your 
"Args" parameter in the call is not setup properly. Also you might try using 
the full path with the program name.


In <50d832b4-140d-4029-8d7c-9397115160ba@u8g2000yqn.googlegroups.com>, daniel.wengelin@home.se writes:
>
>Though not an Ada issue, really, someone here might have had the same
>problem as I have had: I tried to make a small program start another
>program using System.OS_Lib.Spawn. However, it raised Program_Error
>and stated Exception_Access_Violation.
>
>Any ideas why, and what to do about it?
>
>/D

Example of Spawn call

[anon]

with Ada.Text_IO ;
use  Ada.Text_IO ;

with GNAT.OS_Lib ;  -- Could be System.OS_Lib
use GNAT.OS_Lib ;

procedure test is

  Program_Name : String := "temp.exe" ;
  Args         : Argument_List_Access ;
  Success      : Boolean ;

begin -- test 

  -- Create argument list.

  Args := Argument_String_To_List ( " First -second 3" ) ;

  Spawn ( Program_Name, Args.all, Success ) ;
  if Success then
    Put_Line ( "Temp was Spawned Correctly" ) ;
  else
    Put_Line ( "ERROR: Spawn" ) ;
  end if ;
end test ;


--
-- Spawned program.  May require open/close calls for checking output
--
with Ada.Command_Line ;
use  Ada.Command_Line ;
with Ada.Text_IO ;
use  Ada.Text_IO ;

procedure temp is

begin
  for Index in 1 .. Argument_Count loop
    Put ( Index'img ) ;
    Put ( "  => " ) ;
    Put_Line ( Argument ( Index ) ) ;
  end loop ;
end temp ;



In <50d832b4-140d-4029-8d7c-9397115160ba@u8g2000yqn.googlegroups.com>, daniel.wengelin@home.se writes:
>
>Though not an Ada issue, really, someone here might have had the same
>problem as I have had: I tried to make a small program start another
>program using System.OS_Lib.Spawn. However, it raised Program_Error
>and stated Exception_Access_Violation.
>
>Any ideas why, and what to do about it?
>
>/D

Re: Example of Spawn call

[Hang]

On 5月1日, 下午11时28分, a...@anon.org (anon) wrote:
> with Ada.Text_IO ;
> use  Ada.Text_IO ;
>
> with GNAT.OS_Lib ;  -- Could be System.OS_Lib
> use GNAT.OS_Lib ;
>
> procedure test is
>
>   Program_Name : String := "temp.exe" ;
>   Args         : Argument_List_Access ;
>   Success      : Boolean ;
>
> begin -- test
>
>   -- Create argument list.
>
>   Args := Argument_String_To_List ( " First -second 3" ) ;
>
>   Spawn ( Program_Name, Args.all, Success ) ;
>   if Success then
>     Put_Line ( "Temp was Spawned Correctly" ) ;
>   else
>     Put_Line ( "ERROR: Spawn" ) ;
>   end if ;
> end test ;
>
> --
> -- Spawned program.  May require open/close calls for checking output
> --
> with Ada.Command_Line ;
> use  Ada.Command_Line ;
> with Ada.Text_IO ;
> use  Ada.Text_IO ;
>
> procedure temp is
>
> begin
>   for Index in 1 .. Argument_Count loop
>     Put ( Index'img ) ;
>     Put ( "  => " ) ;
>     Put_Line ( Argument ( Index ) ) ;
>   end loop ;
> end temp ;
>
> In <50d832b4-140d-4029-8d7c-939711516...@u8g2000yqn.googlegroups.com>, daniel.wenge...@home.se writes:
>
> >Though not an Ada issue, really, someone here might have had the same
> >problem as I have had: I tried to make a small program start another
> >program using System.OS_Lib.Spawn. However, it raised Program_Error
> >and stated Exception_Access_Violation.
>
> >Any ideas why, and what to do about it?
>
> >/D
>
>

I'm not seeing any problem:

C:\GNAT\Projects\test>test
 1  => First
 2  => -second
 3  => 3
Temp was Spawned Correctly

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

[Martin]

On May 2, 5:16 am, a...@anon.org (anon) wrote:
> First, in GNAT GPL 2008, GNAT.OS_LIB renames System.OS_LIB, so using
> GNAT.OS_LIB would be a waste of time.

Not entirely a waste, as using "GNAT.*" makes it explicit to anyone
reading the code that this is a non-standard package being used. Using
'System.OS_Lib' would give the erroneous impression to the casual
reader that only standard language defined packages are being used and
that there perhaps would be £0.00 cost to compile it up using a
different compiler.

Using non-standard extensions to standard units is generally a
_bad_idea_ but if it is unavoidable then it should be hidden in an
abstration layer that you have control over.

Cheers
-- Martin

Re: Example of Spawn call

[anon]

I am not the guy that ask for help. My example worked for the simple version 
of spawn.

I think the first guy "Daniel" who ask for help forgot to use the 
"Argument_String_To_List" routine to build the agument list.  Even if 
there is no arguments he should call "Argument_String_To_List"
and give it a null string ( "" ) to insure that the parameter is correct 
for the "spawn" call.



In <7cc6117d-689f-41ef-be05-882a7b5453a7@y34g2000prb.googlegroups.com>, Hang <xiehang@gmail.com> writes:
>On 5=D4=C21=C8=D5, =CF=C2=CE=E711=CA=B128=B7=D6, a...@anon.org (anon) wrote=
>:
>> with Ada.Text_IO ;
>> use  Ada.Text_IO ;
>>
>> with GNAT.OS_Lib ;  -- Could be System.OS_Lib
>> use GNAT.OS_Lib ;
>>
>> procedure test is
>>
>>   Program_Name : String :=3D "temp.exe" ;
>>   Args         : Argument_List_Access ;
>>   Success      : Boolean ;
>>
>> begin -- test
>>
>>   -- Create argument list.
>>
>>   Args :=3D Argument_String_To_List ( " First -second 3" ) ;
>>
>>   Spawn ( Program_Name, Args.all, Success ) ;
>>   if Success then
>>     Put_Line ( "Temp was Spawned Correctly" ) ;
>>   else
>>     Put_Line ( "ERROR: Spawn" ) ;
>>   end if ;
>> end test ;
>>
>> --
>> -- Spawned program.  May require open/close calls for checking output
>> --
>> with Ada.Command_Line ;
>> use  Ada.Command_Line ;
>> with Ada.Text_IO ;
>> use  Ada.Text_IO ;
>>
>> procedure temp is
>>
>> begin
>>   for Index in 1 .. Argument_Count loop
>>     Put ( Index'img ) ;
>>     Put ( "  =3D> " ) ;
>>     Put_Line ( Argument ( Index ) ) ;
>>   end loop ;
>> end temp ;
>>
>> In <50d832b4-140d-4029-8d7c-939711516...@u8g2000yqn.googlegroups.com>, da=
>niel.wenge...@home.se writes:
>>
>> >Though not an Ada issue, really, someone here might have had the same
>> >problem as I have had: I tried to make a small program start another
>> >program using System.OS_Lib.Spawn. However, it raised Program_Error
>> >and stated Exception_Access_Violation.
>>
>> >Any ideas why, and what to do about it?
>>
>> >/D
>>
>>
>
>I'm not seeing any problem:
>
>C:\GNAT\Projects\test>test
> 1  =3D> First
> 2  =3D> -second
> 3  =3D> 3
>Temp was Spawned Correctly
>

Re: Example of Spawn call

[sjw]

On May 2, 4:50 pm, Hang <xieh...@gmail.com> wrote:

> I'm not seeing any problem:
>
> C:\GNAT\Projects\test>test
>  1  => First
>  2  => -second
>  3  => 3
> Temp was Spawned Correctly

Aside from having to change Program_Name to just "temp", this worked
on Mac OS X (GCC 4.3.3). The behavior was subtly different:

$ ./test
 1  =>
 2  => First
 3  => -second
 4  => 3
Temp was Spawned Correctly
$

Would changing Program_Name to just "temp" also work on Windows?

Re: Example of Spawn call

[sjw]

On May 2, 8:38 pm, sjw <simon.j.wri...@mac.com> wrote:
> On May 2, 4:50 pm, Hang <xieh...@gmail.com> wrote:
>
> > I'm not seeing any problem:
>
> > C:\GNAT\Projects\test>test
> >  1  => First
> >  2  => -second
> >  3  => 3
> > Temp was Spawned Correctly
>
> Aside from having to change Program_Name to just "temp", this worked
> on Mac OS X (GCC 4.3.3). The behavior was subtly different:
>
> $ ./test
>  1  =>
>  2  => First
>  3  => -second
>  4  => 3
> Temp was Spawned Correctly
> $

Ah, it's the leading space in the arguments:

  Args := Argument_String_To_List ( " First -second 3" ) ;

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

[daniel.wengelin]

On 2 Maj, 06:16, a...@anon.org (anon) wrote:
> First, in GNAT GPL 2008, GNAT.OS_LIB renames System.OS_LIB, so using
> GNAT.OS_LIB would be a waste of time.
> Note: Spawn and Ada task can have problems. Should be avoided. Also,
>       in some case "spawn" is disabled.
>
> Second, it would be helpful to give some code.
>
> In the mean time, using the simple routine version it sounds like its your
> "Args" parameter in the call is not setup properly. Also you might try using
> the full path with the program name.
>
> In <50d832b4-140d-4029-8d7c-939711516...@u8g2000yqn.googlegroups.com>, daniel.wenge...@home.se writes:
>
> >Though not an Ada issue, really, someone here might have had the same
> >problem as I have had: I tried to make a small program start another
> >program using System.OS_Lib.Spawn. However, it raised Program_Error
> >and stated Exception_Access_Violation.
>
> >Any ideas why, and what to do about it?
>
> >/D
>
>

Thanks, fixing the Args sorted the problem out. I need to practice
more on the unconstrained string access array types 8-/
/D

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

[anon]

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.

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. 

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. 
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.

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? 

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),

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.



In <923b28dd-46ee-40cb-b13e-5f8860405f22@r36g2000vbr.googlegroups.com>, Martin <martin.dowie@btopenworld.com> writes:
>On May 2, 5:16=A0am, a...@anon.org (anon) wrote:
>> First, in GNAT GPL 2008, GNAT.OS_LIB renames System.OS_LIB, so using
>> GNAT.OS_LIB would be a waste of time.
>
>Not entirely a waste, as using "GNAT.*" makes it explicit to anyone
>reading the code that this is a non-standard package being used. Using
>'System.OS_Lib' would give the erroneous impression to the casual
>reader that only standard language defined packages are being used and
>that there perhaps would be =A30.00 cost to compile it up using a
>different compiler.
>
>Using non-standard extensions to standard units is generally a
>_bad_idea_ but if it is unavoidable then it should be hidden in an
>abstration layer that you have control over.
>
>Cheers
>-- Martin
>

Re: Example of Spawn call

[anon]

The first space in the argument list could be considered as a GNAT BUG 
because the routine "Argument_String_To_List" should truncate all leading 
and tailing spaces before processing the arguments list.

 Args :=3D Argument_String_To_List ( " First -second 3" ) ;

Because I did not try this but what would happen if you tried 

 Args :=3D Argument_String_To_List ( "   First   -second   3  " ) ;

As for the changing the name from "temp.exe" to "temp", must be done in 
Linux as well, but "Daniel" was asking for help with "Windows XP" which 
uses "temp.exe" in this example.


In <faad1a66-54f0-44dd-bdeb-54f430cd5384@x6g2000vbg.googlegroups.com>, sjw <simon.j.wright@mac.com> writes:
>On May 2, 8:38=A0pm, sjw <simon.j.wri...@mac.com> wrote:
>> On May 2, 4:50=A0pm, Hang <xieh...@gmail.com> wrote:
>>
>> > I'm not seeing any problem:
>>
>> > C:\GNAT\Projects\test>test
>> > =A01 =A0=3D> First
>> > =A02 =A0=3D> -second
>> > =A03 =A0=3D> 3
>> > Temp was Spawned Correctly
>>
>> Aside from having to change Program_Name to just "temp", this worked
>> on Mac OS X (GCC 4.3.3). The behavior was subtly different:
>>
>> $ ./test
>> =A01 =A0=3D>
>> =A02 =A0=3D> First
>> =A03 =A0=3D> -second
>> =A04 =A0=3D> 3
>> Temp was Spawned Correctly
>> $
>
>Ah, it's the leading space in the arguments:
>
>  Args :=3D Argument_String_To_List ( " First -second 3" ) ;
>

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

[Ed Falis]

On Sat, 02 May 2009 16:39:57 -0400, anon <anon@anon.org> wrote:

> 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.

You're wrong.  GNAT.OS_Lib is the intended interface for users (normally  
you will get a warning about using an implementation unit subject to  
unpredictable change if you use System.OS_Lib).  GNAT.OS_Lib is an  
implementation-defined unit provided to users.  That it is a renaming of  
System.OS_Lib is irrelevant (and also does not cause any noticable  
compilation overhead).

- Ed

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

[anon]

Ed.

If that was correct, then using "System.OS_LIB" would generated a 
compiler WARNING, but no error or warning is given. So, that package 
is usable as is.

Compiling overhead depends upon how many places packages are used.  
And some people count every cpu cycle. One wasted cycle may be too 
much, and it could cost someone life. I am talking about medical 
operations, such as pin-point radation treatements.



In <op.utbos0e85afhvo@naropa>, "Ed Falis" <falis@verizon.net> writes:
>On Sat, 02 May 2009 16:39:57 -0400, anon <anon@anon.org> wrote:
>
>> 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.
>
>You're wrong.  GNAT.OS_Lib is the intended interface for users (normally  
>you will get a warning about using an implementation unit subject to  
>unpredictable change if you use System.OS_Lib).  GNAT.OS_Lib is an  
>implementation-defined unit provided to users.  That it is a renaming of  
>System.OS_Lib is irrelevant (and also does not cause any noticable  
>compilation overhead).
>
>- Ed

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

[Hang]

On 5月2日, 下午1时31分, daniel.wenge...@home.se wrote:
> On 2 Maj, 06:16, a...@anon.org (anon) wrote:
>
>
>
> > First, in GNAT GPL 2008, GNAT.OS_LIB renames System.OS_LIB, so using
> > GNAT.OS_LIB would be a waste of time.
> > Note: Spawn and Ada task can have problems. Should be avoided. Also,
> >       in some case "spawn" is disabled.
>
> > Second, it would be helpful to give some code.
>
> > In the mean time, using the simple routine version it sounds like its your
> > "Args" parameter in the call is not setup properly. Also you might try using
> > the full path with the program name.
>
> > In <50d832b4-140d-4029-8d7c-939711516...@u8g2000yqn.googlegroups.com>, daniel.wenge...@home.se writes:
>
> > >Though not an Ada issue, really, someone here might have had the same
> > >problem as I have had: I tried to make a small program start another
> > >program using System.OS_Lib.Spawn. However, it raised Program_Error
> > >and stated Exception_Access_Violation.
>
> > >Any ideas why, and what to do about it?
>
> > >/D
>
> Thanks, fixing the Args sorted the problem out. I need to practice
> more on the unconstrained string access array types 8-/
> /D

Sorry for previous post - I was thinking the sample program was posted
by Daniel, I should have read things carefully.

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

[Martin]

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

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

[sjw]

On May 2, 11:01 pm, "Ed Falis" <fa...@verizon.net> wrote:
> On Sat, 02 May 2009 16:39:57 -0400, anon <a...@anon.org> wrote:
> > 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.
>
> You're wrong.  GNAT.OS_Lib is the intended interface for users (normally  
> you will get a warning about using an implementation unit subject to  
> unpredictable change if you use System.OS_Lib).  GNAT.OS_Lib is an  
> implementation-defined unit provided to users.  That it is a renaming of  
> System.OS_Lib is irrelevant (and also does not cause any noticable  
> compilation overhead).

With GCC 4.3.3 on Mac OS X,

$ gnatmake -f -gnatwaL test
gcc -c -gnatwaL test.adb
test.adb:7:03: warning: "Program_Name" is not modified, could be
declared constant
gnatbind -x test.ali
gnatlink test.ali
gnatlink: warning: executable name "test" may conflict with shell
command

So no warning about implementation-defined units there (I have seen
them, though).

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

[Ed Falis]

On Sat, 02 May 2009 19:20:05 -0400, anon <anon@anon.org> wrote:

> Ed.
>
> If that was correct, then using "System.OS_LIB" would generated a
> compiler WARNING, but no error or warning is given. So, that package
> is usable as is.

Ah, I see.  The unit does not get a warning because its interface is  
"fixed" for use by the renaming.  Still, the current header comments  
contain:

--  Note: this package is in the System hierarchy so that it can be  
directly
--  be used by other predefined packages. User access to this package is  
via
--  a renaming of this package in GNAT.OS_Lib (file g-os_lib.ads).

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

[Ed Falis]

On Sun, 03 May 2009 06:33:18 -0400, sjw <simon.j.wright@mac.com> wrote:

> So no warning about implementation-defined units there (I have seen
> them, though

Yep, counterintuitive but so.

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

[anon]

General comments should be taken with a gain of salt.  If you check, most of 
the GNAT packages and programs, you will see 100s of comments that are not 
valid or useful. Like, "Is this correct" or "need comment here". Then other 
places where comments could be useful there is only code. 

What is needed is another documentation file, called may be "GNAT extension 
to Ada 2005 specification", where the documentation would explain the extra 
packages with each package routine, and including the package limitations, 
if any.

The following example show that the "System.OS.LIB" could be set as a 
non-portable internal system file that generates warning and forces a 
programmer to use "GNAT.OS_LIB".  But in Ada 2005 version, Adacore 
decided not too. Which allows the programmer to choose to use 
"GNAT.OS_LIB" (Ada 95 specs) or "System.OS_LIB" (Ada 2005 specs). Just 
like some programmers choose to use "Text_IO" instead of "Ada.Text_IO", 
or "Unchecked_Conversion" instead of "Ada.Unchecked_Conversion".  


The following two/three files will show how to bypass the non-portable 
error. We all know that the attribute Image is an internal routine and if 
you include those files that contains those routine the compiler will 
generate a non-portable compiler warning. But if you rename those system 
files you can access those routines with no generated warnings after 
compiling the renaming file.

-- compiler order
gnat compile Img_Bool 
gnat make test1



--
-- Test1.ads
--
with Ada.Text_IO ;
use  Ada.Text_IO ;

--                  System file that defines Image routine for Boolean
--                  "Image" attribute and will give a non-portable 
--                  warning message, if use 
-- with System.Img_Bool ;
-- use  System.Img_Bool ;


--                  package that refined system file System.Img_Bool
--                  No warning or error message, if pre-compiled 
--                  version is used.
with Img_Bool ;
use  Img_Bool ;

procedure test1 is

  Success      : Boolean := True ;

begin -- test1 

  Put ( "Image Value of 'Success' := " ) ;
  Put ( Image_Boolean ( Success ) ) ;
  New_Line ( 2 ) ;

  Put_Line ( "Built-in Image Value of 'Success' := " 
             & Boolean'Image ( Success ) ) ;
end test1 ;



--
-- Img_Bool.ads : Rename internal GNAT package "System.Img_Bool"
--                Compiling this file like most packages that include 
--                GNAT internal system files will generate a warning. 
--                With or without the body file.
-- 
--                Using this file after it has been compiled will 
--                prevent the compiler from generating a non-portable
--                warning message and gives direct access to a GNAT
--                internal system file routine.
--
with System.Img_Bool ;

package Img_Bool renames System.Img_Bool ;


--
-- Img_Bool.adb : Not really needed.  Used just to match the
--                design of "GNAT.OS_LIB", under Ada 2005.
--
--                Do not use, if compiling pre GNAT 2005.
--
pragma No_Body ;


In <op.utcvihzv5afhvo@naropa>, "Ed Falis" <falis@verizon.net> writes:
>On Sat, 02 May 2009 19:20:05 -0400, anon <anon@anon.org> wrote:
>
>> Ed.
>>
>> If that was correct, then using "System.OS_LIB" would generated a
>> compiler WARNING, but no error or warning is given. So, that package
>> is usable as is.
>
>Ah, I see.  The unit does not get a warning because its interface is  
>"fixed" for use by the renaming.  Still, the current header comments  
>contain:
>
>--  Note: this package is in the System hierarchy so that it can be  
>directly
>--  be used by other predefined packages. User access to this package is  
>via
>--  a renaming of this package in GNAT.OS_Lib (file g-os_lib.ads).

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

[Ed Falis]

On Sun, 03 May 2009 20:22:14 -0400, anon <anon@anon.org> wrote:
> General comments should be taken with a gain of salt.  If you check,  
> most of
> the GNAT packages and programs, you will see 100s of comments that are  
> not
> valid or useful. Like, "Is this correct" or "need comment here". Then  
> other
> places where comments could be useful there is only code.

None of us are perfect, eh?  There is an ongoing process of improving  
comments.  The one I quoted is not ambiguous.  But you're correct that I  
was wrong about the warning being generated in this case.

>
> What is needed is another documentation file, called may be "GNAT  
> extension
> to Ada 2005 specification", where the documentation would explain the  
> extra
> packages with each package routine, and including the package  
> limitations,
> if any.

It's called the GNAT Reference Manual, which does not document  
System.OS_Lib as part of the GNAT public library.  Generally, it refers to  
the source specifications for details.

>
> The following example show that the "System.OS.LIB" could be set as a
> non-portable internal system file that generates warning and forces a
> programmer to use "GNAT.OS_LIB".  But in Ada 2005 version, Adacore
> decided not too. Which allows the programmer to choose to use
> "GNAT.OS_LIB" (Ada 95 specs) or "System.OS_LIB" (Ada 2005 specs). Just
> like some programmers choose to use "Text_IO" instead of "Ada.Text_IO",
> or "Unchecked_Conversion" instead of "Ada.Unchecked_Conversion".

The unqualified names of the standard library packages are "deprecated"  
but retained for backward compatibility.  As far as System.OS_Lib goes,  
I'll be asking tomorrow why we allow its use without generating a  
warning.  Seems like an oversight to me rather than a decision, but as you  
point out in your example, this lack of a warning appears to be related to  
package renamings.

- Ed

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

[Robert A Duff]

sjw <simon.j.wright@mac.com> writes:

> $ gnatmake -f -gnatwaL test
> gcc -c -gnatwaL test.adb
> test.adb:7:03: warning: "Program_Name" is not modified, could be
> declared constant
> gnatbind -x test.ali
> gnatlink test.ali
> gnatlink: warning: executable name "test" may conflict with shell
> command
>
> So no warning about implementation-defined units there (I have seen
> them, though).

That's a bug.  GNAT should warn on "with System.OS_Lib;",
but not warn on "with GNAT.OS_Lib;".  The idea is that
if you mention GNAT.<something>, you _know_ you are using
a GNAT-specific package.

The purpose of these renamings is to avoid namespace pollution.
You could have your own user-defined package called GNAT -- perhaps
it was written in Ada 83 days, before GNAT even existed.  Not likely,
but GNAT is a perfectly legal name for a user-defined package.
So we don't want the Ada runtimes to "with GNAT.OS_Lib;" -- instead,
they "with System.OS_Lib;".

- Bob

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

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message 
news:xc2Ll.188618$4m1.82760@bgtnsc05-news.ops.worldnet.att.net...
...
 Just like a
> lot of programmers were using the Ada 2005 specs before they were approved
> in January, 2008.

For the record, Ada "2005" (really Amendment 1 to Ada 95) was published by 
ISO (that's the last step of the standardization process) in March 2007. 
That's why the official designation of Amendment 1 is "ISO/IEC 8652:1995/AMD 
1:2007(E)". The "(E)" means English, the "2007" is the year of publication.

                  Randy.

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

[anon]

Actually, Adacore stated in March 2007, "Ada 2005, ISO/IEC 8652, was 
formally formally approved by ISO SC22/WG9 on January 24, 2007". Also, 
Adacore stated that they would be the first to use Ada 2005 spec in GNAT 
Pro. But, other than may be GNAT PRO license users, the official Ada GPL 
version using Ada 2005 specs was not generally available until May 4, 2008. 
Note: GNAT GPL 2007 (released in summer 2007) still defaulted to Ada 95 
specs.

URL Ref. : http://www.adacore.com/2007/03/07/gnat-pro-601/
           http://libre.adacore.com  -- 2007/2008 releases

But even with a typo my comment is still valid, Adacore started to insert 
Ada 2005 specs into its GPL version before January 24, 2007 and a lot of 
programmers were using Ada 2005 features, before they were approved.



In <gtnvri$2gg$1@munin.nbi.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
>"anon" <anon@anon.org> wrote in message 
>news:xc2Ll.188618$4m1.82760@bgtnsc05-news.ops.worldnet.att.net...
>....
> Just like a
>> lot of programmers were using the Ada 2005 specs before they were approved
>> in January, 2008.
>
>For the record, Ada "2005" (really Amendment 1 to Ada 95) was published by 
>ISO (that's the last step of the standardization process) in March 2007. 
>That's why the official designation of Amendment 1 is "ISO/IEC 8652:1995/AMD 
>1:2007(E)". The "(E)" means English, the "2007" is the year of publication.
>
>                  Randy.
>
>

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

[Martin]

On May 5, 3:43 am, a...@anon.org (anon) wrote:
> Actually, Adacore stated in March 2007, "Ada 2005, ISO/IEC 8652, was
> formally formally approved by ISO SC22/WG9 on January 24, 2007". Also,

"Actually" couldn't both be true?

RB states that the standard was 'published' in March 2007, AdaCore
stated 'agreed' in January 2007.

The wheels of standardization grind slowly...


> Adacore stated that they would be the first to use Ada 2005 spec in GNAT
> Pro. But, other than may be GNAT PRO license users, the official Ada GPL
> version using Ada 2005 specs was not generally available until May 4, 2008.
> Note: GNAT GPL 2007 (released in summer 2007) still defaulted to Ada 95
> specs.
>
> URL Ref. :http://www.adacore.com/2007/03/07/gnat-pro-601/
>            http://libre.adacore.com -- 2007/2008 releases
>
> But even with a typo my comment is still valid, Adacore started to insert
> Ada 2005 specs into its GPL version before January 24, 2007 and a lot of
> programmers were using Ada 2005 features, before they were approved.

And they were available on my webpage long before that (last updated
2004) but marked as for the forthcoming Ada0Y standard.

But 'so what?' - anyone using them (either mine or AdaCore's) would be
well aware they were on potentially non-portable ground. It's a
decision for them, as to where that's a problem for them or not. For
me, I wouldn't use them professionally on anything needing to be
released but would consider them for 'utility' programs if they were
going to save me time.

Also, define "a lot of" - certainly not the vast majority of
professional users, who will either a) not be using GNAT; or b) using
a specific version defined by a project at conception and quite
possibly never updated - that happens a lot.

Cheers
-- Martin

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

[Randy Brukardt]

Martin is correct, both are true. The JTC1 ballot closed in January 2007. 
But a standards aren't official until they're published, and that can take a 
while (for Corrigendum 1, it took nearly a year).

In any case, if Anon had originally said January 2007, I wouldn't have said 
anything, but since he said January 2008 (which is off by a year using any 
rule), I felt I needed to correct it for future readers.

                                  Randy.

"Martin" <martin.dowie@btopenworld.com> wrote in message 
news:02d45d5d-1543-4b65-90e0-b5b82eed048c@b1g2000vbc.googlegroups.com...
On May 5, 3:43 am, a...@anon.org (anon) wrote:
> Actually, Adacore stated in March 2007, "Ada 2005, ISO/IEC 8652, was
> formally formally approved by ISO SC22/WG9 on January 24, 2007". Also,

"Actually" couldn't both be true?

RB states that the standard was 'published' in March 2007, AdaCore
stated 'agreed' in January 2007.

The wheels of standardization grind slowly...


> Adacore stated that they would be the first to use Ada 2005 spec in GNAT
> Pro. But, other than may be GNAT PRO license users, the official Ada GPL
> version using Ada 2005 specs was not generally available until May 4, 
> 2008.
> Note: GNAT GPL 2007 (released in summer 2007) still defaulted to Ada 95
> specs.
>
> URL Ref. :http://www.adacore.com/2007/03/07/gnat-pro-601/
> http://libre.adacore.com -- 2007/2008 releases
>
> But even with a typo my comment is still valid, Adacore started to insert
> Ada 2005 specs into its GPL version before January 24, 2007 and a lot of
> programmers were using Ada 2005 features, before they were approved.

And they were available on my webpage long before that (last updated
2004) but marked as for the forthcoming Ada0Y standard.

But 'so what?' - anyone using them (either mine or AdaCore's) would be
well aware they were on potentially non-portable ground. It's a
decision for them, as to where that's a problem for them or not. For
me, I wouldn't use them professionally on anything needing to be
released but would consider them for 'utility' programs if they were
going to save me time.

Also, define "a lot of" - certainly not the vast majority of
professional users, who will either a) not be using GNAT; or b) using
a specific version defined by a project at conception and quite
possibly never updated - that happens a lot.

Cheers
-- Martin