Re: Gnat 3.13p: Command_Name RM A.15

Re: Gnat 3.13p: Command_Name RM A.15

[Schroeer, Joachim Dr.]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

Hallo Herr Grein,

ich habe auch ein kleines Paket, das ich innerhalb eines 
größeren Ada95 Projekts unter WinNT/98 zum Scannen der 
command-line benutzt habe. Es wurde bisher mit ObjectAda 
und GNAT eingesetzt und sollte auch auf anderen Plattformen 
laufen. Die function command_name dürfte Ihnen weiterhelfen.
Wenn Sie auch das Paket Portable.Standard haben wollen, 
das im Body benutzt wird, melden Sie sich bitte.

P.S. Eurocopter gehört doch zur EADS. Warum finde ich Ihren 
Namen dann nicht in unserer internen Mailing-Liste, wo doch 
die Kollegen von Daimler-Chrysler noch und die von der Casa 
schon zu sehen sind?

Beste Grüße
	J. Schröer


Dr.-Ing. Joachim Schröer
EADS Germany GmbH
Defense Electronics
Dept.: VEE22
Wörthstraße 85
D-89070 ULM
Telefon: +49 731 392 5993

Christoph Grein <christoph.grein@eurocopter.de> schrieb in im Newsbeitrag:
<mailman.979801451.11095.comp.lang.ada@ada.eu.org>...
> Thanks to all for their responses.
> 
> Randy Brukardt gave me a nice solution (it may not be applicable for all
cases, 
> but for me, it worked).
> 
> The original question was:
> 
> How do I get the full name of Ada.Command_Line.Command_Name? The result of

> Command_Name is implementation dependent.
> 
> Open the file with the name given by Command_Name, call the Name function
which 
> by A8.2(22) must return the full name, then close the file again:
> 
>   Open (File, in_file, Ada.Command_Line.Command_Name);
>   Full_Name := Name (File);  -- this is the idea only (careful, string
sizes)
>   Close (File);
> 
> OK, A8.2(22) actually says "should", but Randy confirmed that the ACATS
test for 
> the full name, so you can rely on this.
> 
> Christoph Grein
> 
> 


[-- Attachment #2: utilities-command_line.adb --]
[-- Type: application/octet-stream, Size: 3647 bytes --]

--                              -*- Mode: Ada -*-
-- Filename        : utilities-command_line.ads
-- Description     : Simplifies access on the command_line parameters 
--                   via key strings (options).
-- Author          : J. Schroeer
-- Created On      : 18. Feb. 1998
-- Last Modified By:
-- Last Modified On:
-- Update Count    : 1
-- Status          :

with Ada.Command_Line;
with Ada.Strings.Fixed;
with Ada.Strings.Unbounded;
with Portable.Operating_System;

package body Utilities.Command_Line is
  
  Dir_Sep : constant String  := Portable.Operating_System.Directory_Separator & "";
  ----------------------------------------------------------------------------
  function Argument(Key : in String) return String is
  begin
    for I in 1 .. Ada.Command_Line.Argument_Count - 1 loop
      if Key = Ada.Command_Line.Argument(I) then
        return Ada.Command_Line.Argument(I + 1);
      end if;
    end loop;
    return "";
  end Argument;
  ----------------------------------------------------------------------------
  function Argument(Key     : in String; 
                    Default : in String) return String is
                    
    Arg : constant String := Argument(Key);
  begin
    if Arg /= "" then
      return Arg;
    else
      return Default;
    end if;
  end Argument;
  ----------------------------------------------------------------------------                                 
  function Argument(Key     : in String; 
                    Default : in Float'Base) return Float'Base is
                    
    Arg : constant String := Argument(Key);
  begin
    if Arg /= "" then
      return Float'Value(Arg);
    else
      return Default;
    end if;
  end Argument;
  ----------------------------------------------------------------------------           
  function Argument(Key     : in String; 
                    Default : in Integer) return Integer is
                    
    Arg : constant String := Argument(Key);
  begin
    if Arg /= "" then
      return Integer'Value(Arg);
    else
      return Default;
    end if;
  end Argument;
  ----------------------------------------------------------------------------           
  function Has_Argument(Key : in String) return Boolean is
  begin
    for I in 1 .. Ada.Command_Line.Argument_Count loop
      if Key = Ada.Command_Line.Argument(I) then
        return True;
      end if;
    end loop;
    return False;
  end Has_Argument;
  ----------------------------------------------------------------------------
  function Command_Name(Full_Path : in Boolean := True) return String is
    Name : constant String := Ada.Command_Line.Command_Name;
  begin
    if Full_Path then
      return Name;
    else
      return Name(Ada.Strings.Fixed.Index(Source  => Name, 
												                  Pattern => Dir_Sep, 
												                  Going   => Ada.Strings.Backward) 
                  + 1 .. Name'Last);
    end if;
  end Command_Name;
  ----------------------------------------------------------------------------            
  function Total_Command_Line(Full_Path : in Boolean := True) return String is
    
    Cl : Ada.Strings.Unbounded.Unbounded_String := 
         Ada.Strings.Unbounded.Null_Unbounded_String;
    use type Ada.Strings.Unbounded.Unbounded_String;             
  begin
    for I in 1 .. Ada.Command_Line.Argument_Count loop
      Cl := Cl & " " & Ada.Command_Line.Argument(I);
    end loop;
    return Command_Name(Full_Path) & Ada.Strings.Unbounded.To_String(Cl);
  end Total_Command_Line;
  ----------------------------------------------------------------------------
end Utilities.Command_Line;  

[-- Attachment #3: utilities-command_line.ads --]
[-- Type: application/octet-stream, Size: 1948 bytes --]

--                              -*- Mode: Ada -*-
-- Filename        : utilities-command_line.ads
-- Description     : Simplifies access on the command_line parameters 
--                   via key strings (options).
-- Author          : J. Schroeer
-- Created On      : 18. Feb. 1998
-- Last Modified By:
-- Last Modified On:
-- Update Count    : 1
-- Status          :

package Utilities.Command_Line is

  -- All functions herein are case-sensitive for "key".

  function Argument(Key : in String) return String;

  -- Returns the argument on the command-line preceded by key if key is found,
  -- the empty string "" otherwise.
  --
  -- Example: If the main is called like
  --
  -- main -file filename -number 10
  --
  -- then argument("-file") = "filename", argument(key => "-number") = "10",
  -- argument("-FILE") = "".

  function Argument(Key     : in String;
                    Default : in String) return String;

  function Argument(Key     : in String;
                    Default : in Float'Base) return Float'Base;

  function Argument(Key     : in String;
                    Default : in Integer) return Integer;

  -- If has_argument(key) then return the string / float'value / integer'value 
  -- of the corresponding argument. 
  -- If not has_argument(key) then return the default.                  

  function Has_Argument(Key : in String) return Boolean;

  -- Returns true if key is an argument an the command_line, false otherwise.

  function Command_Name(Full_Path : in Boolean := True) return String;

  -- Returns ada.command_line.command_name if full_path.
  -- Returns ada.command_line.command_name without path when not full_path.
  -- ada.command_line.command_name is the full name of the Main-unit.

  function Total_Command_Line(Full_Path : in Boolean := True) return String;

  -- Returns the total command_line including command_name and all arguments
  -- separated by blanks.

end Utilities.Command_Line;

[-- Attachment #4: utilities.ads --]
[-- Type: application/octet-stream, Size: 362 bytes --]

--                              -*- Mode: Ada -*-
-- Filename        : utilities.ads
-- Description     : Parent package for Utilities
-- Author          : J. Schroeer
-- Created On      : Wed Mar 26 17:25:34 1997
-- Last Modified By:
-- Last Modified On: Wed Jul  2 13:41:50 1997
-- Update Count    : 2
-- Status          :

package Utilities is
end Utilities;

Re: Gnat 3.13p: Command_Name RM A.15

[Lutz Donnerhacke]

* Schroeer, Joachim Dr. wrote:
>ich habe auch ein kleines Paket, das ich innerhalb eines gr��eren Ada95
>Projekts unter WinNT/98 zum Scannen der command-line benutzt habe. Es
>wurde bisher mit ObjectAda und GNAT eingesetzt und sollte auch auf anderen
>Plattformen laufen. Die function command_name d�rfte Ihnen weiterhelfen.
>Wenn Sie auch das Paket Portable.Standard haben wollen, das im Body
>benutzt wird, melden Sie sich bitte.

I found a small package used by a larger Ada95 on NT/98 project to scan the
command line. It is tested with ObjectAda and GNAT and may work on other
platforms (sic!). Please have a look at the function command_name. If you
need the package Portable.Standard, please drop me an email.

>P.S. Eurocopter geh�rt doch zur EADS. Warum finde ich Ihren Namen dann
>nicht in unserer internen Mailing-Liste, wo doch die Kollegen von
>Daimler-Chrysler noch und die von der Casa schon zu sehen sind?

BTW: Eurocopter should be part of EDAS. Why is your name missing on your
internal mailing-lists, but your colleagues at Daimler-Chrysler are still
and those from Casa are already there?

[...]

Re: Gnat 3.13p: Command_Name RM A.15

[Christoph Grein]

Robert Dewar wrote:

> > Open the file with the name given by Command_Name, call the
> > Name function which
> > by A8.2(22) must return the full name, then close the file
> again:
> 
> This obviously does NOT work if the file is not in the current
> directory, which for an executable file is likely. Writing a
> program that only works if its executable is in the current
> directory is defintely very bad practice, so this "solution"
> cannot be recommended.

OK, I'm talking of Win98/NT only,where it works also for relative paths.

Call My_Executable, which is on drive C: at the relative path ..\X\
from drive E directory A:

E:\A> C:..\X\My_Executable

On Win98, Command_Name returns  C:\Full_Path\X\My_Executable.exe
on WinNT, it returns C:..\X\My_Executable

Open works with both strings (OK I have to first add the extension .exe if not 
present, and I know it must be .exe and nothing else), and Name returns the 
desired result: C:\Full_Path\X\My_Executable.exe

> There is no general way of getting the full path of the
> current executable if it is not availabel in arg(0), which
> is why this cannot be guaranteed.

I did not claim that this works on all conceivable OSs.

Christoph Grein

Re: Gnat 3.13p: Command_Name RM A.15

[Christoph Grein]

Thanks to all for their responses.

Randy Brukardt gave me a nice solution (it may not be applicable for all cases, 
but for me, it worked).

The original question was:

How do I get the full name of Ada.Command_Line.Command_Name? The result of 
Command_Name is implementation dependent.

Open the file with the name given by Command_Name, call the Name function which 
by A8.2(22) must return the full name, then close the file again:

  Open (File, in_file, Ada.Command_Line.Command_Name);
  Full_Name := Name (File);  -- this is the idea only (careful, string sizes)
  Close (File);

OK, A8.2(22) actually says "should", but Randy confirmed that the ACATS test for 
the full name, so you can rely on this.

Christoph Grein

Re: Gnat 3.13p: Command_Name RM A.15

[Larry Kilgallen]

In article <mailman.979801451.11095.comp.lang.ada@ada.eu.org>, Christoph Grein <christoph.grein@eurocopter.de> writes:
> Thanks to all for their responses.
> 
> Randy Brukardt gave me a nice solution (it may not be applicable for all cases, 
> but for me, it worked).
> 
> The original question was:
> 
> How do I get the full name of Ada.Command_Line.Command_Name? The result of 
> Command_Name is implementation dependent.
> 
> Open the file with the name given by Command_Name, call the Name function which 
> by A8.2(22) must return the full name, then close the file again:

Certainly you are correct that this may not be applicable for all cases.
The assumption that the implementation-dependent Command_Name bears any
relationship to a file name would seem to be fraught with peril.  I have
not used an Ada95 compiler on VMS, but I would expect something called
Command_Name to return the command I had typed, rather than the filename
of the executable image that implemented that command.  Some typical commands
and images they execute are:

	SET PASSWORD		SETP0.EXE
	SET CLASS		SETSHOCLASS.EXE
	SHOW CLASS		SETSHOCLASS.EXE
	SET HOST/HSC		HSCPAD.EXE
	SET HOST/RLOGIN		OPENVMS$RLOGIN.EXE
	SET DISPLAY		DECW$SETSHODIS.EXE

Those commands do not happen to be implemented in Ada, but they could be.

==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

The instances you cite probably aren't an issue to Ada because they don't execute an Ada program. However, you are right
about the Command_Name not necessarily returning the name of a file. If you had defined a logical for your executable,
there is no reason to think that the logical name would be parsed out to be the executable image filename. And if you did
try to translate it back to a filename, you'd be into system calls and thus decreasing your portability.

Still, as I pointed out in another post, perfect portability is nice, but not always essential. If your problem is simply
making the same source work on two specific platforms with only one pair of compilers, then you might get the job done
this way. Break those assumptions and you have no guarantee of portability. But to paraphrase a quote: "Portable Enough is
not nearly so wonderful a thing as Perfectly Portable, but its Portable Enough!" :-)

MDC

Larry Kilgallen wrote:

> ICertainly you are correct that this may not be applicable for all cases.
> The assumption that the implementation-dependent Command_Name bears any
> relationship to a file name would seem to be fraught with peril.  I have
> not used an Ada95 compiler on VMS, but I would expect something called
> Command_Name to return the command I had typed, rather than the filename
> of the executable image that implemented that command.  Some typical commands
> and images they execute are:

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Ted Dennison]

In article <NGeoaj90epLA@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> not used an Ada95 compiler on VMS, but I would expect something called
> Command_Name to return the command I had typed, rather than the
> filename of the executable image that implemented that command.  Some

That's right. Remember that the main use of this feature (in C programs
at least) is to redisplay the command's name in a "usage" statement,
with the proper paramers with which the command is supposed to be
invoked. It would be a little shocking for a user to type in
   somecommand --help

and be greeted with:
   q:/dira/dirb/dirc/dird/XYZ.exe arg1...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <mailman.979801451.11095.comp.lang.ada@ada.eu.org>,
  comp.lang.ada@ada.eu.org wrote:

> Randy Brukardt gave me a nice solution (it may not be
> applicable for all cases,  but for me, it worked).
>
> The original question was:
>
> Open the file with the name given by Command_Name, call the
> Name function which
> by A8.2(22) must return the full name, then close the file
again:

This obviously does NOT work if the file is not in the current
directory, which for an executable file is likely. Writing a
program that only works if its executable is in the current
directory is defintely very bad practice, so this "solution"
cannot be recommended.

There is no general way of getting the full path of the
current executable if it is not availabel in arg(0), which
is why this cannot be guaranteed.

This is an old old problem, nothing to do with Ada or GNAT!


Sent via Deja.com
http://www.deja.com/

Gnat 3.13p: Command_Name RM A.15

[Christoph Grein]

On win98 with Gnat3.13p, Ada.Command_Line.Command_Name always returns the full 
path, irrespective of the actual command line (executable only, relative or 
absolute path), whereas on winNT, only the string as entered on the command line 
is returned.

This different behaviour is annoying when trying to write portable code and you 
need the full path (including drive).

There are several Win32 flavours out there...

I know A.15 leaves this completely implementation defined,  there is not even an 
Implementation Advice as to how the string should look. But A.8.2(22) requires 
that Name return the full path (OK, it says "should"). So why is there the 
difference in the RM?

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

The problem you are having is due to the fact that command line behavior is
operating system dependent. The compiler has to ask the OS to give it the contents
of the command line because it can't get it for itself. (The command line is
determined before your compiled code is even up and running.)

So you're stuck with the problem that various flavors of Unix are going to parse
things on the command line before handing it to your program. WinXX is going to do
similar things, only differently from Unix. VMS behaves in its own way. None of
these OS's have ever agreed on how a command line should be treated, so there is no
portable way of dealing with it.

Note that this isn't something that the language can specify. It would be the same
problem in C/C++ or any other language.

You might try writing something that attempts to detect the type of system it is
running on and then parse the command line accordingly. Unfortunately, I know of no
*standard* way of doing that.

MDC

Christoph Grein wrote:

> On win98 with Gnat3.13p, Ada.Command_Line.Command_Name always returns the full
> path, irrespective of the actual command line (executable only, relative or
> absolute path), whereas on winNT, only the string as entered on the command line
> is returned.
>
> This different behaviour is annoying when trying to write portable code and you
> need the full path (including drive).

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


"Marin David Condic" <mcondic@mindspring.com> a �crit dans le message news: 3A64593A.380F3228@mindspring.com...
> You might try writing something that attempts to detect the type of system it is
> running on and then parse the command line accordingly. Unfortunately, I know of no
> *standard* way of doing that.
OS_Services (available from http://pro.wanadoo.fr/adalog/compo2.htm) does provide this functionnality (not perfect though), as well
as a function that returns the full executable path independently of the OS.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

This could be helpful. There are probably also compiler-vendor-supplied routines that might accomplish the same thing. The only
difficulty is that there is no *standard* way of doing it, hence no *portable* way of handling it. At least in the sense that you might
switch targets, but if you also switched compiler vendors, you would have to make some changes.

You do have System.System_Name available to you, but it is, of course, system/implementation dependent as to what the values will be.
So you can't write codes that said something to the effect:

case (System.Name) is
    when Sun_Unix => ... ;
    when Windows_NT => ... ;
    when ...
end case ;

I suppose it could be possible that the compiler vendors could agree on some set of enumerals and keep the list updated as new targets
emerge. That would enable code to be written that would get past the compiler. It just wouldn't do you any good if a specific system
wasn't supported. That naturally reduces product distinction and starts moving compilers more towards commodities, but there are
probably enough ways of distinguishing compilers that such an interoperability feature wouldn't harm the business.

MDC

Jean-Pierre Rosen wrote:

> "Marin David Condic" <mcondic@mindspring.com> a �crit dans le message news: 3A64593A.380F3228@mindspring.com...
> > You might try writing something that attempts to detect the type of system it is
> > running on and then parse the command line accordingly. Unfortunately, I know of no
> > *standard* way of doing that.
> OS_Services (available from http://pro.wanadoo.fr/adalog/compo2.htm) does provide this functionnality (not perfect though), as well
> as a function that returns the full executable path independently of the OS.
>
> --
> ---------------------------------------------------------
>            J-P. Rosen (Rosen.Adalog@wanadoo.fr)
> Visit Adalog's web site at http://pro.wanadoo.fr/adalog

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]


"Marin David Condic" <mcondic@mindspring.com> a �crit dans le message news: 3A659B05.4FA24A08@mindspring.com...
> You do have System.System_Name available to you, but it is, of course, system/implementation dependent as to what the values will
be.
> So you can't write codes that said something to the effect:
>
And it is specially unfortunate that in GNAT System_Name has the same single value, SYSTEM_NAME_GNAT, on all targets...

> I suppose it could be possible that the compiler vendors could agree on some set of enumerals and keep the list updated as new
targets
> emerge. That would enable code to be written that would get past the compiler. It just wouldn't do you any good if a specific
system
> wasn't supported. That naturally reduces product distinction and starts moving compilers more towards commodities, but there are
> probably enough ways of distinguishing compilers that such an interoperability feature wouldn't harm the business.
>
Note that it is the purpose of OS_Services to allow a common specification, with implementations that depend on the system. If this
(or a similar) package was provided by every vendor, it would solve the issue. This idea has been flying around for a while...

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <944r6m$f6d$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:

> And it is specially unfortunate that in GNAT System_Name has
> the same single value, SYSTEM_NAME_GNAT, on all targets...

As I said in the previous note, the idea that every copy of
System contains All possible values on all targets is fatally
flawed. It is really too bad that the definition was not

  System_Name : constant String := "impl dependent string";

Then we would just put the target identification string
there, this would be perfectly easy to do, but unfortunately
is not permitted!

Once again, it is perfectly easy to conditionalize code on
the basis of the target if you want to, but there is no system
independent way of doing this. Yes, it looks like System_Name
would help, but it is too broken.




Sent via Deja.com
http://www.deja.com/

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

O.K. I'll bite. You have a finite set of host/target platforms that you
support. Why couldn't there be an enumeration of them & have System_Name
= Linux_Pentium or System_Name = Windows_NT_Pentium?

A string makes the configuration management of the source a little
simpler in that if you add support for a new system, you don't have to
update the package System for each divergent path - just for the new
one. Granted, that is simpler, but in the case of GNAT, you have what? a
dozen paths or so? That's not that big a deal, is it? Life would be
nicer with a string, but can't an enumeration be made to work here?

I can see that it is an issue for those who have picked up the source
for GNAT and have started hacking away on their own. I'd guess the
answer there is "Tough Noogies!" You mess with the source, its up to you
to deal with it.

So outside of the standard, wouldn't it be possible for the compiler
writers to agree on a set of platforms they support and sort of maintain
a joint list of those systems? (There's only a few major players and
certainly enough forums in which to discuss it) If someone comes up with
a new implementation, they distribute the enumeration around, say once
every 6 months? I've had similar configuration management problems
wherein whenever someone released their system, I'd have to check out
and modify a dozen or so files in my system. (Table updates, etc.) It
was a nuisance, but never took more than a half a day to get done. If
the update is not too frequent, it didn't seem to be an issue.

MDC

Robert Dewar wrote:

> As I said in the previous note, the idea that every copy of
> System contains All possible values on all targets is fatally
> flawed. It is really too bad that the definition was not
>
>   System_Name : constant String := "impl dependent string";
>
> Then we would just put the target identification string
> there, this would be perfectly easy to do, but unfortunately
> is not permitted!

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <3A66EE38.5637FF37@acm.org>,
  Marin David Condic <mcondic.auntie.spam@acm.org> wrote:
> O.K. I'll bite. You have a finite set of host/target
> platforms that you support. Why couldn't there be an
> enumeration of them & have System_Name
> = Linux_Pentium or System_Name = Windows_NT_Pentium?


Because that means that every time we add a new target, we
invalidate all other targets, which is not acceptable.

Since the use of System_Name is compiler dependent in any
case, and since it is possible to write target dependent
code now in GNAT using compiler dependent approaches, the
use of System_Name in the manner you suggest gains nothing
in portability, and it does have very nasty consequences.



Sent via Deja.com
http://www.deja.com/

Re: Gnat 3.13p: Command_Name RM A.15

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]


"Robert Dewar" <robert_dewar@my-deja.com> a �crit dans le message news: 945ns0$7f7$1@nnrp1.deja.com...
> In article <944r6m$f6d$1@wanadoo.fr>,
>   "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> > And it is specially unfortunate that in GNAT System_Name has
> > the same single value, SYSTEM_NAME_GNAT, on all targets...
>
> As I said in the previous note, the idea that every copy of
> System contains All possible values on all targets is fatally
> flawed. It is really too bad that the definition was not
>
>   System_Name : constant String := "impl dependent string";
>
> Then we would just put the target identification string
> there, this would be perfectly easy to do, but unfortunately
> is not permitted!
>
This is an interesting idea. Since additions to System are permitted, maybe vendors could agree to add f.e.:
    Target_Name : constant string := <Whatever>;

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Gnat 3.13p: Command_Name RM A.15

[Florian Weimer]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> >   System_Name : constant String := "impl dependent string";
> >
> > Then we would just put the target identification string
> > there, this would be perfectly easy to do, but unfortunately
> > is not permitted!

> This is an interesting idea. Since additions to System are
> permitted, maybe vendors could agree to add f.e.: Target_Name :
> constant string := <Whatever>;

A function would be better in this case, I think.  A constant is just
too static (cf. the Win32c/Win32 issue).

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <3A659B05.4FA24A08@mindspring.com>,
  Marin David Condic <mcondic@mindspring.com> wrote:
> You do have System.System_Name available to you, but it is,
> of course, system/implementation dependent as to what the
> values will be.

Furthermore, it is fundamentally flawed, you cannot require
system to be changed in all ports whenever one port is added.
The proper design would be to have had a string.

Of course with GNAT there is no problem in conditionalizing
code for the target if you want to, but it is certainly not
portable to do so.

> I suppose it could be possible that the compiler vendors
> could agree on some set of enumerals and keep the list
> updated as new targets

Totally infeasible, this would require ALL vendors to change
ALL compilers if any vendor added a new target. You can't be
serious! Remember that the enumeration type has to list ALL
possibilities.

> That naturally reduces product distinction and starts moving
> compilers more towards commodities, but there are
> probably enough ways of distinguishing compilers that such an
> interoperability feature wouldn't harm the business.

Interoperability never harms business, you are looking for a
conspiracy theory here, when the fact of the matter is that
the design of System_Name is technically flawed beyond repair.



Sent via Deja.com
http://www.deja.com/

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

Robert Dewar wrote:

> I> I suppose it could be possible that the compiler vendors
> > could agree on some set of enumerals and keep the list
> > updated as new targets
>
> Totally infeasible, this would require ALL vendors to change
> ALL compilers if any vendor added a new target. You can't be
> serious! Remember that the enumeration type has to list ALL
> possibilities.
>

Well, within the confines of a given vendor's domain, there are a
limited set of targets, right? I'd not look at it as unworkable for that
vendor to enumerate all the targets they support. Theoretically, all the
combinations of host/target could be a massive number - but that's only
math. In reality it is a fairly small number.

By extrapolation, there are not really that many major players in the
Ada compiler market. Many of their host/target implementations overlap.
We are talking about, oh, say 100 or so possible enumerals? (In a
practical sense, probably a lot less) And consider that vendors are not
coming out with new hosts/targets every day, so there is a fair amount
of stability here. So if the vendors *wanted* to cooperate on this, I
just don't see it as impossible or even prohibitively expensive. They
aren't required to do this, but if they perceived some value in doing
so, I just don't see it as so big a problem that it couldn't be worked
out.

For example, if Aonix added two new machines to the list of supported
platforms & made that available in some way, ACT could decide to accept
the addition, reject it, or sit on it until a later date when it was
convenient to add it. Nobody can force a vendor to make an update they
don't want to make, right?



>
> > That naturally reduces product distinction and starts moving
> > compilers more towards commodities, but there are
> > probably enough ways of distinguishing compilers that such an
> > interoperability feature wouldn't harm the business.
>
> Interoperability never harms business, you are looking for a
> conspiracy theory here, when the fact of the matter is that
> the design of System_Name is technically flawed beyond repair.

Paranoia is just a kind of awareness. And awareness is just a form of
love. :-)

Actually, it would be an anti-conspiracy, or possibly "Free Enterprise",
but that's a side bar.

I was only looking at the fact that in most businesses, there is a
disadvantage to turning products into commodities. It reduces profit
margin. I don't think that fact is disputed by any economists. (There
are exceptions - the most often cited case is the casinos in Las Vegas
back around the 60's) To some extent, creating interoperability means
shifting the product towards being a commodity. Not being locked in to
one vendor means the consumer has more choices and can abandon one
vendor for another more easily, thus increasing competition and reducing
prices. Not a bad thing depending on which side of the table you are
sitting on. Cooperating on System_Name is a small thing, so I don't
think it impacts that situation much - as I observed.

Obviously, you are free to do whatever you think is right in the process
of implementing your compiler. If you think that the enumeration scheme
is totally unworkable, that's your judgement call to make. I'm of the
opinion that even though there are better schemes and it would be nice
if the standard allowed for that, that this is what we have and making
it work to some extent is not hopelessly impossible.

How would you feel about simply adding a string constant to the package
System? That could probably be done rather easily. System_Name remains
as is, but fades away in importance. A constant of the form:

Host_Target : constant String := "Alpha_VMS Alpha_VMS" ;

would probably sufice. Then the end user could parse the string for two
identifiers that tell him what he needs to know. It's downside is that
the end user doesn't necessarily know what other possibilities exist,
but in practical usage, it probably doesn't matter much. Could that be
added to the standard to make life easier for everyone?

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Stephen Leake]

Marin David Condic <mcondic@mindspring.com> writes:

> <snip>
> You might try writing something that attempts to detect the type of system it is
> running on and then parse the command line accordingly. Unfortunately, I know of no
> *standard* way of doing that.

System.System_Name should do the trick, but unfortunately, GNAT
_always_ returns SYSTEM_NAME_GNAT for this, no matter what system it
is on. I guess it's too hard to get it right? On problem would be that
the _same_ executable can run on several different systems, so some
sort of OS call would be required.

-- 
-- Stephe

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <u8zoagf9v.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:

> System.System_Name should do the trick

No, it cannot "do the trick" because it would imply that all
Ada compilers must know about all other Ada compilers. Even
within the GNAT world, it would mean that every GNAT port
must know about all other ports, i.e. that if we introduced
one port, then all other ports would have to be modified.
This is clearly impractical

> but unfortunately, GNAT
> _always_ returns SYSTEM_NAME_GNAT for this, no matter what
> system it is on.

But it is certainly possible to conditionalize GNAT code
depending on the system on which it is running (this is done
in the GNAT runtime).

Suppose that there *were* different SYSTEM_NAME values, it
would not help you write portable code, since the names would
still be tied to GNAT.




Sent via Deja.com
http://www.deja.com/

Re: Gnat 3.13p: Command_Name RM A.15

[Marin David Condic]

But at least you could take code developed on a Sun with GNAT and move
it to a PC with GNAT and account for the differences in how the two
platforms work. (File names, command line parameters, etc.) I've been in
this situation before and was very glad that GNAT worked so consistently
across both platforms. I may have had more trouble moving, say, from
GNAT/Unix to Aonix/PC, but that wasn't what I was doing. Having some way
to detect which platform I was on, may have helped me reduce the porting
issues even further.

Just because a thing isn't perfectly portable across all possible
compilers and platforms, doesn't mean it wouldn't be useful to have.

MDC

Robert Dewar wrote:

> Suppose that there *were* different SYSTEM_NAME values, it
> would not help you write portable code, since the names would
> still be tied to GNAT.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Gnat 3.13p: Command_Name RM A.15

[Robert Dewar]

In article <u8zoagf9v.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> System.System_Name should do the trick, but unfortunately,
GNAT
> _always_ returns SYSTEM_NAME_GNAT for this, no matter what
system it
> is on. I guess it's too hard to get it right? On problem
would be that
> the _same_ executable can run on several different systems,
so some
> sort of OS call would be required.


You can't do an OS call!!!!! This is a static constant that
you can access at compile time. That's the problem with this
feature, it is very broken.


Sent via Deja.com
http://www.deja.com/