comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Interfacing Ada to Unix/execl var. arg. list function?
Date: 13 Oct 1994 08:22:05 -0400
Date: 1994-10-13T08:22:05-04:00	[thread overview]
Message-ID: <37j8pd$ovu@gnat.cs.nyu.edu> (raw)
In-Reply-To: 37ioh5$h9v@goanna.cs.rmit.oz.au

#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 :-)




  parent reply	other threads:[~1994-10-13 12:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-10-13  7:44 Interfacing Ada to Unix/execl var. arg. list function? Dale Stanbrough
1994-10-13  9:21 ` David Emery
1994-10-13 12:22 ` Robert Dewar [this message]
1994-10-13 17:37   ` Mark A Biggar
1994-10-13 18:46     ` Robert Dewar
1994-10-14 13:55   ` Norman H. Cohen
1994-10-13 13:31 ` Nicolas Courtel
1994-10-13 19:28 ` Tucker Taft
1994-10-14 13:55 ` Interfacing Ada to Unix/execl var ncohen
1994-10-17 18:18 ` Interfacing Ada to Unix/execl var. arg. li Bob Gilbert
1994-10-19  3:30   ` Interfacing Ada to Unix/execl var. arg. list function? Dale Stanbrough
1994-10-20 12:42     ` Interfacing Ada to Unix/execl var. arg Bob Gilbert
1994-10-20  4:18   ` Interfacing Ada to Unix/execl var. arg. li S M Ryan
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox