From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,130283ad9c6c2e69
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-13 09:45:35 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody
From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Interfacing Ada to Unix/execl var. arg. list function?
Date: 13 Oct 1994 08:22:05 -0400
Organization: Courant Institute of Mathematical Sciences
Message-ID: <37j8pd$ovu@gnat.cs.nyu.edu>
References: <37ioh5$h9v@goanna.cs.rmit.oz.au>
NNTP-Posting-Host: gnat.cs.nyu.edu
Date: 1994-10-13T08:22:05-04:00
List-Id: <comp.lang.ada>

#2 won't work because attributes can only be applied to names (i.e. it is
a simple case of a syntax error). GNAT does indeed give a confusing
error message:

     6.    v := "abc"'access;
                     |
        >>> binary operator expected

LRM references aren't the issue here, since GNAT would merely point to
some syntax rule about binary operators which would not be the slightest
help. The important thing about error messages is that they have to guess
right what you did wrong. What is happening here is that GNAT has parsed a
primary (the string literal) that cannot possibly be a name, so it doesn't
even consider the possibility of an attribute, and then it flails around
for what might appear.

Clearly what is needed is a decent error message, something like:

     6.    v := "abc"'access;
                |
        >>> attribute prefix must be a name

The RM reference if one was given would simply point to the syntax rule
for attributes showing that the prefix of an attribute must be a name,
so would not add much.

Unless the compiler correctly guesses what you had in mind, no amount of
extra explanation of what it THINKS is the error will help, in fact it will
simply confuse further.

Anyway, I have put this error case on my list of things to look at, and
I would really appreciate if more people would send in cases like this
where GNAT does a poor job of giving error messages -- we can only
improve this if we see examples. I collect/fix my own errors, but I am
disappointed I don't get more complaints/suggestions in this area
-- I guess people have grown accustomed to poor error messages in Ada
compilers -- let's fix that!

Back to the problem at hand. The proper solution is

   execv (pathname, strings_array'(new string'("a"), new string'("bc"), ....))

For problem #2, it is indeed a glitch that to declare a null array
constant you have to provide a junk initialization value for all the
values, except of course there AREN'T any values, so that's a bit
annoying. Of course again you don't need a separate junk variable:

    null_arg_list : constant string_array := (1..0 => new string'(""));

will do fine.

Note: pointers to aggregates certainly make sense at the implementation
level, and at that level we have something called a reference which can
be applied to any expression to get a pointer to that expression. It
would be easy enough to provide this as an extension to Ada, but GNAT
is not (yet) in the language extension business :-)