comp.lang.ada Google Group

Re: Common exception handling

2008-08-29T15:31:03Z

Well, I do often post silly things without smileys and assume everyone
is astute enough to figure out that I was trying to be funny. But I
wasn't being funny here. Although the above looks somewhat ugly, I
can imagine that a solution of this sort may be entirely appropriate
in some cases. Suppose, for example, that the common code isn't just

Re: Common exception handling

2008-08-29T08:32:18Z

Surely you missed a smiley off this suggestion!!! :-)
== Martin

Re: Possible compiler bug with this simple program

2008-08-29T07:41:17Z

...
Even if the workaround using "in 0 .. n - 1" works on a given
compiler and machine, according to Randy this depends on
non-standard (ie. generally unportable) features of the compiler.
For example, Randy mentioned that Tucker's compiler would give the
x-array "maximum bounds", which in this case seems to mean

Re: Failure integrating .NET GPL version of GNAT into Visual Studio 2005

2008-08-29T06:03:07Z

Thanks Rob. I didn't ask the original question but had the same problem.
After adjusting the paths in the fix it worked for me.
Rgds
Paul

Re: Possible compiler bug with this simple program

2008-08-28T21:29:41Z

Thanks, Randy. This is useful.
Superficially, in my situation, it appears that GNAT 4.3.0 on OS X PPC
supports it and GNAT 4.3.1-2 on Debian lenny on Intel duo does not
support it. I suppose there could be an element of dumb luck of GNAT
is not supposed to support it and it just happens to work on OS X. On

Re: Possible compiler bug with this simple program

2008-08-28T21:16:21Z

Thanks, everybody, for the comments.
As for the second problem ( in 0 .. n - 1 loop versus for i in x'range
loop), my main concern (since I have a workaround--the first form) is
that the compiler allows the second form at all. It looks like a
situation where a simple syntactically correct program bombs.

Re: Possible compiler bug with this simple program

2008-08-28T21:08:42Z

On Aug 28, 12:56 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
And that would look something like this?
for Long_Float'Alignment use 64;
for Real_Vector'Alignment use ???;
Jerry

Re: Possible compiler bug with this simple program

2008-08-28T21:01:35Z

...
This is the subject of AI05-0002-1. (It was carried over from the Ada 95.)
[Now, I have to go look this one up because I don't remember anything about
what we decided...] Ah, yes:
"We do not require support for C convention interfacing pragmas for
unconstrained
array objects, unconstrained array function results, and most unconstrained

Re: Possible compiler bug with this simple program

2008-08-28T15:56:12Z

Or, perhaps, declare a subtype:
subtype Constrained_Real_Vector is Real_Vector (0 ..
Integer'Last);
and use the subtype as the parameter type in mapform19 and your access-
to-procedure type.
-- Adam

Re: Possible compiler bug with this simple program

2008-08-28T15:54:15Z

On Aug 28, 1:03 am, Niklas Holsti <niklas.hol...@tidorum.invalid >
wrote:
Yes, good point. For an unconstrained array parameter like X, the
compiler doesn't need to know what X'Last is in order to access
elements of the array---but it does need to know X'First. (X'Last is
needed for range checking but not for actually accessing elements.)

Re: OpenToken (was: Status of ayacc and aflex?)

2008-08-28T13:38:30Z

Are your fixes included in the latest release from Ted Dennison? If
not, could you please submit your patches in a bug report on the
Debian bug tracking system? That way they will benefit anyone who
cares about OpenToken, and they can be integrated in Debian. For
instructions on how to report bugs, see [link]. The

Anyone using gnat-gps 4.3~2008.08.09 in Debian unstable or Ubuntu?

2008-08-28T13:30:14Z

If so please contact me, I need input from you.

Re: Possible compiler bug with this simple program

2008-08-28T08:03:43Z

I suspect that one problem is using the C convention to pass a
parameter that is of an unconstrained array type, see below.
...
...
So Real_Vector is an unconstrained array type. According to RM
B.3(70), the C convention passes only a single pointer to the first
element of the array, so the 'Range attribute will not be available

Re: Possible compiler bug with this simple program

2008-08-28T07:56:36Z

I cannot test your program now but it seems to me that perhaps you
should specify the alignment of the arrays and Long_Floats. Also, it
might be a good idea to double-check that on the Intel Core 2, the
long floats are really 64 bits and not 80 bits wide. It could be that
the compiler got that wrong but I doubt it.

Possible compiler bug with this simple program

2008-08-28T07:28:29Z

The following is a program which emulates the structure of a binding
to a bunch of C code (but there is no C code included here--it is all
Ada). This structure exhibits a behavior which I think might be a
compiler error but could be the result of incorrect declarations when
running on certain machines.