__FILE__ and __LINE__

__FILE__ and __LINE__

[Carl G.M. Welman]

Dear all,

    I am looking for Ada equivalents for the C preprocessor macros
"__FILE__" and "__LINE__", which result in the source file name
(constant string) and the line number (integer) of the file/position
they are specified, respectively. As far as I know there are no
pragma's in Ada 95 or GNAT 3.x that do similar things. Maybe there are
other means to do the same ? Or is this impossible in Ada 95 ?

Regards, Carl.

Re: __FILE__ and __LINE__

[David C. Hoos, Sr.]

Hi Carl,

Although to my knowledge gnat does not do exactly what you're describing,
it does do what is needed for one of the mist frequent uses of __FILE__ and
__LINE__, i.e., identify the source code location of failed assertions.

The source code which follows gives an example of what can be done.

Two pragmas, Debug and Assert are enabled by the -gnata compiler switch. 
The Assert pragma causes the raising of an exception at the point of a
failed assertion.  The exception is raised with an exception message
consisting of the file name, followed by a colon, followed by the line
number.

The Ada95 exception occurrence facilities permit extraction of the
exception message in the exception handler.

The contrived example illustrates the features: 

---- begin example source code -----------------
with Ada.Exceptions;
with Ada.Text_IO;
with System.Assertions;
procedure Assert is
begin
   pragma Debug (Ada.Text_IO.Put_Line ("Debug message"));
   Ada.Text_IO.Put_Line ("About to make false assertion");
   begin
      pragma Assert (False);
      null;
   exception
      when E: System.Assertions.Assert_Failure =>
         Ada.Text_IO.Put_Line
           ("Assertion at " &
            Ada.Exceptions.Exception_Message (E) &
            " failed.");
   end;
   Ada.Text_IO.Put_Line ("After false assertion handled");
end Assert;
---- end example source code ----------
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Carl G.M. Welman <carl@nlr.nl> wrote in article
<5ia77f$go3@nlrgup.nlr.nl>...
> Dear all,
> 
>     I am looking for Ada equivalents for the C preprocessor macros
> "__FILE__" and "__LINE__", which result in the source file name
> (constant string) and the line number (integer) of the file/position
> they are specified, respectively. As far as I know there are no
> pragma's in Ada 95 or GNAT 3.x that do similar things. Maybe there are
> other means to do the same ? Or is this impossible in Ada 95 ?
> 
> Regards, Carl.
> 

Re: __FILE__ and __LINE__

[Robert Dewar]

<<    I am looking for Ada equivalents for the C preprocessor macros
"__FILE__" and "__LINE__", which result in the source file name
(constant string) and the line number (integer) of the file/position
they are specified, respectively. As far as I know there are no
pragma's in Ada 95 or GNAT 3.x that do similar things. Maybe there are
other means to do the same ? Or is this impossible in Ada 95 ?>>

There is no predefined way of doing this in Ada 95, and indeed it is highly
implementation dependent by definition (what is a "source file name"?)

It would be easy to implement an attribute (not a pragma, I don't see how
a pragma would work) that would provide this information, e.g.

Standard'Line
Standard'File

(applying attributes to Standard in such a case is an existing trick in
 GNAT for defining new attributes)

or you could, perhaps more cleanly, have two intrinsic functions in a 
library routine.

However, none of our customers has requested such a feature, so it is not
on our priority radar screen at the moment ....

Robert Dewar
Ada Core Technologies

Re: __FILE__ and __LINE__

[Carl G.M. Welman]

Robert Dewar wrote:
> ...
> It would be easy to implement an attribute (not a pragma, I don't see
> how a pragma would work) that would provide this information, e.g.
>     Standard'Line
>     Standard'File
> (applying attributes to Standard in such a case is an existing trick
> in GNAT for defining new attributes)
> ...

    You're right. Attributes are preferred (also from a user's point of
view). I've thought about Attributes for this job, but I couldn't find
appropriate Attributes. Furhermore, I couldn't figure out where they
should be Attributes of.

    I suppose that a small Ada preprocessor can also do the job. In
this case, other macros like __DATE__ and __TIME__ can also be
expanded. (There is no need to do this for the __STDC__ macro.)

Regards, Carl.

Re: __FILE__ and __LINE__

[Robert Dewar]

i<<    You're right. Attributes are preferred (also from a user's point of
view). I've thought about Attributes for this job, but I couldn't find
appropriate Attributes. Furhermore, I couldn't figure out where they
should be Attributes of.
>>

Actually, thinking about this more, I prefer a standard package to the
use of attributes:

  package Compile_Time_Info is
     function Time_Compiled return Calendar.Time;
     function Line_Number return Natural;
     function Source_File_Name return String;

     pragma Import (Intrinsic, Time_Compiled);
     pragma Import (Intrinsic, Line_Number);
     pragma Import (Intrinsic, Source_File_Name);

     etc ..
  end Compile_Time_Info;

This of course requrires compiler assistance (any solution to this problem
does), but this seems the cleanest approach. It would not be hard to 
implement in GNAT, but there are no plans to do so currently

Re: __FILE__ and __LINE__

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>It would be easy to implement an attribute (not a pragma, I don't see how
>a pragma would work) that would provide this information, e.g.
>
>Standard'Line
>Standard'File
>
>(applying attributes to Standard in such a case is an existing trick in
> GNAT for defining new attributes)

I must say that Standard'Foo seems to me to be a quite misleading name for
something that is in fact a non-standard language extension.
                            ^^^

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.