Simple ADA/C Question

Simple ADA/C Question

[root]

Hello,

I am very new to ADA ( 3-4 days experience ) and I have a question that
probably has a simple answer.  As part of my learning experience, I wrote
a simple piece of code that requests the user to enter an integer and then
the integer is displayed.  My ADA code calls a C function, which requests
and then returns the integer.  The primary ADA task consists of a loop so
the I can go get as many integers as I want as long as I input 'y' when
prompted ( the default is no ).  This works fine as long as I enter an
integer. If I enter a real, the program exits as if I had hit the default.
What am I forgetting to check to prevent a real, or any unexpected value,
from having this effect?  TIA.

AE

Re: Simple ADA/C Question

[Bob Klungle]

Without the code any comment is a guess. However it sounds as though the
data type being interfaced to the C function is "type mytype is integer;"
or something like that. If the C function returns int, The Ada should give
you an exception and crash the program (unless you are capturing the
exception with something like:
exception
  when others => Null;
end;)
Either the C code has to check for invalid input or an exception handler
within the enclosing Ada function must handle type mismatches (it goes
without saying a real is not an int).

cheers...bob

root <root@vf700f.msfc.nasa.gov> wrote in article
<Pine.LNX.3.95.970225100418.10492A-100000@vf700f.msfc.nasa.gov>...
> Hello,
> 
> I am very new to ADA ( 3-4 days experience ) and I have a question that
> probably has a simple answer.  As part of my learning experience, I wrote
> a simple piece of code that requests the user to enter an integer and
then
> the integer is displayed.  My ADA code calls a C function, which requests
> and then returns the integer.  The primary ADA task consists of a loop so
> the I can go get as many integers as I want as long as I input 'y' when
> prompted ( the default is no ).  This works fine as long as I enter an
> integer. If I enter a real, the program exits as if I had hit the
default.
> What am I forgetting to check to prevent a real, or any unexpected value,
> from having this effect?  TIA.
> 
> AE
> 
> 
> 

Re: Simple ADA/C Question

[root]

On 26 Feb 1997, Bob Klungle wrote:

> Without the code any comment is a guess.

Sorry, I figured this to be such a simple oversight on my part that a code
example wasn't necessary.

> However it sounds as though the
> data type being interfaced to the C function is "type mytype is integer;"
> or something like that.

I am including the code that I think is applicable so as not to make this
post too long.

  function Do_C2 return INTEGER;

  package Int_IO is new Text_IO.Integer_IO( INTEGER );
  use Int_IO;

  Integer_To_Ada : INTEGER;

  function Do_C2 return INTEGER is

    Integer_In : INTEGER;

    function C_Integer_Input return INTEGER;
    pragma IMPORT( C, C_Integer_Input, "C_Integer_Input" );

  begin
    Integer_In := C_Integer_Input;
    New_Line;
    Put_Line( "Back again, the integer returned from the C function is "
);
    Put( Integer_In );
    New_Line;
    return( Integer_In );
  end Do_C2;

begin
  while To_Lower( Answer ) = 'y'
  loop
    Integer_To_Ada := Do_C2;
    New_Line;
    Put_Line( "the integer returned from the ADA function that called ");
    Put_Line( "the C function is " );
    Put( Integer_To_Ada );
    New_Line( 2 );
    Put( "do you want to run again ( y/n )? " );
    Get( Answer );
  end loop;

> If the C function returns int, The Ada should give
> you an exception and crash the program (unless you are capturing the
> exception with something like:
> exception
>   when others => Null;
> end;)

I'm not capturing any exception and I don't get any exception that crashes
the program.  Well, I guess since the program exits as if the default
condition was met, this is not an exception crash?  As you can tell, it is
not obvious to me that an exception has occurred :).  I'll go back and
read about exceptions and handling and try to figure this out.

> Either the C code has to check for invalid input or an exception handler
> within the enclosing Ada function must handle type mismatches (it goes
> without saying a real is not an int).

I did not put any checks in the C code, I would rather work this on the
ADA side in order to learn.  Thanx.

Re: Simple ADA/C Question

[John McCabe]

root <root@vf700f.msfc.nasa.gov> wrote:

>On 26 Feb 1997, Bob Klungle wrote:
>
>begin
>  while To_Lower( Answer ) = 'y'
>  loop
>    Integer_To_Ada := Do_C2;
>    New_Line;
>    Put_Line( "the integer returned from the ADA function that called ");
>    Put_Line( "the C function is " );
>    Put( Integer_To_Ada );
>    New_Line( 2 );
>    Put( "do you want to run again ( y/n )? " );
>    Get( Answer );
>  end loop;

<..snip..>

>I'm not capturing any exception and I don't get any exception that crashes
>the program.  Well, I guess since the program exits as if the default
>condition was met, this is not an exception crash?  As you can tell, it is
>not obvious to me that an exception has occurred :).  I'll go back and
>read about exceptions and handling and try to figure this out.

Since you didn't include all the code, I can't be sure whether this is
the answer or not and have to make some assumptions however..

It sounds to me like you're trying to read an integer input and
actually putting in a real e.g. 2.0. The input routine is finding the
"." of 2.0 and doesn't like it (you don't get "." in integers!)
therefore it abandons any further read leaving the input buffer with
the ".0" in it.

The next read (Get( Answer ); above) then reads in the character "."
and since it isn't a "y" the program terminates.

Therefore at some point you have to handle the input better, flushing
the input buffer if you detect a failure of some sort. In the C
function you have imported do you check for return values from the
input routines (e.g. scanf)? If not then you are probably seeing what
I've described here.

Good luck.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Simple ADA/C Question

[Stephen Leake]

Now we need the code for the C function C_Integer_Input. If it uses
scanf with %d (or any integer format), when you feed it a real (like
"123.45"), it will read "123", and leave ".45" still in the input
stream. Then when you run Ada.Text_IO.Get, you get "." in Answer, and
exit the loop.

One "solution" is to do Ada.Text_IO.Skip_Line after Do_C2; this will
throw away any unread characters (up to a line terminator).

-- 
- Stephe

Re: Simple ADA/C Question

[root]

On Wed, 26 Feb 1997, Stephen Leake wrote:

> Now we need the code for the C function C_Integer_Input. If it uses
> scanf with %d (or any integer format), when you feed it a real (like
> "123.45"), it will read "123", and leave ".45" still in the input
> stream. Then when you run Ada.Text_IO.Get, you get "." in Answer, and
> exit the loop.

Thanx, this is just what I am doing in C_Integer_Input ( scanf %d ).

> One "solution" is to do Ada.Text_IO.Skip_Line after Do_C2; this will
> throw away any unread characters (up to a line terminator).

I had looked for a way to flush the buffer ( e.g. fflush( stdin ) ), but
had not found one.  I'll try out the method shown.

> - Stephe

AE

Re: Simple ADA/C Question

[Robert Dewar]

Bob Klungle said

<<> If the C function returns int, The Ada should give
> you an exception and crash the program (unless you are capturing the
> exception with something like:
> exception
>   when others => Null;
> end;)>>


I have no idea what BOb is thinking of here. It is perfectly fine to
call a C function that returns an int, with the Ada function having
a return type of (type Myint is new Integer), if the representation of
int and Integer are the same, as is always true of GNAT, and likely
true of most other Ada 95 compilers.

Re: Simple ADA/C Question

[Keith Thompson]

In <dewar.856972571@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
> I have no idea what BOb is thinking of here. It is perfectly fine to
> call a C function that returns an int, with the Ada function having
> a return type of (type Myint is new Integer), if the representation of
> int and Integer are the same, as is always true of GNAT, and likely
> true of most other Ada 95 compilers.

If you have a C function that returns an int, the corresponding Ada
function's return type should be Interfaces.C.int.  Yes, C's int and Ada's
Integer are usually the same size, but why take chances when the language
provides a type that's *guaranteed* to have the same representation?

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Simple ADA/C Question

[Robert Dewar]

Keith said

<<If you have a C function that returns an int, the corresponding Ada
function's return type should be Interfaces.C.int.  Yes, C's int and Ada's
Integer are usually the same size, but why take chances when the language
provides a type that's *guaranteed* to have the same representation?>>

I understand that position, but the trade off is between piles of annoying
conversions and much more straightforward code in some instances.

However, this was not the issue, Bob said that using int on the C side
and Integer on the Ada side definitely *will* cause problems, and this
is plain wrong!

Are there any compilers incidentally where int in C is not the same
as Integer in Ada? Certainly int = Integer on all GNAT compilers.
Hard to believe that anyone would deviate from this equivalence. Given
that the choice of what Integer means in Ada is definitely implementation
dependent, it seems foolish to make any other choice.

Re: Simple ADA/C Question

[Keith Thompson]

In <dewar.857350486@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
> I understand that position, but the trade off is between piles of annoying
> conversions and much more straightforward code in some instances.

Then define an imported function that returns Interfaces.C.int, and a
wrapper function that converts the result to Integer.  If you inline the
wrapper, there should be no runtime overhead as long as int and Integer
have the same representation.  Or overload unary "+" as a conversion
operator (yes, that convention is a bit controversial).

> However, this was not the issue, Bob said that using int on the C side
> and Integer on the Ada side definitely *will* cause problems, and this
> is plain wrong!

That's true.  I'd almost be happier if it were guaranteed to cause
problems.  The worst kind of bug is the one that doesn't show up until
years later.

> Are there any compilers incidentally where int in C is not the same
> as Integer in Ada? Certainly int = Integer on all GNAT compilers.
> Hard to believe that anyone would deviate from this equivalence. Given
> that the choice of what Integer means in Ada is definitely implementation
> dependent, it seems foolish to make any other choice.

I don't know, but with all the new 64-bit processors showing up,
presumably the C compiler implementers are facing a tradeoff between
backwards compatibility (32-bit int) and using the representation
that makes the most sense for the target machine (64-bit int).  I can
easily imagine two different C compilers (or even two different modes
of the same compiler) making the choice differently on the same system.
Has this actually happened?  I don't know.  Even if this isn't a problem
for 64-bit processors, who knows what will happen with the next generation
after that?

Whenever possible, I like to program in a way that won't cause future
maintenance programmers to curse my name.  8-)}

If you feel you must write code that assumes the same representation
for int and Integer, consider adding something like this:

   subtype Assertion is Boolean range True .. True;
   Integer_Same_Size : constant Assertion
      := Interfaces.C.int'Size = Standard.Integer'Size;

Then you'll at least get a warning if you try to port your software
to a system on which the assertion fails.  (I don't think the language
requires a warning, but I think all existing compilers will issue one.)

Or, if you want to get really fancy and guarantee catching it at compile
time, try this:

   Integer_Same_Size : constant Boolean
      := Interfaces.C.int'Size = Standard.Integer'Size;
   type Dummy(Discr: Boolean) is
      record
         case Discr is
            when False             => null;
            when Integer_Same_Size => null;	-- must be True
         end case;
      end record;

If the condition (which must be static) is false, the choices will
overlap, which is illegal.  Again, this shouldn't have any run-time
overhead.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Simple ADA/C Question

[Robert Dewar]

Keith argues for always using the interfaces type. Fine, I understand the
argument, but there is no question that this leads to lots of extra code,
and many people avoid it, and I don't think that's so terrible (no worse
than using any other implementation dependent feature of a compiler. Probably
Keith likes to stay away from all such -- but many users are quite content
with adopting a style that is at least portable from GNAT to GNAT.


Keith suggests

<<   subtype Assertion is Boolean range True .. True;
   Integer_Same_Size : constant Assertion
      := Interfaces.C.int'Size = Standard.Integer'Size;
>>

Less writing, and guaranteed to not merely give a warning, but to be
illegal if the assumption is violated is:

   X : Integer := 1 / Boolean'Pos (Interfaces.C.int'Size = Integer'Size);


Note incidentally that Standard.Integer does not guarantee that you will
get the integer in standard, there is no way to do that in general!
So it is probably unnecssary pedantry.

As for Keith's guess that there could be C compilers that disagree on
int size, I doubt it. Keith are you aware of all the discussions going
on around C sizes on 64-bit machines?

In any case, a programmer who relies on int being the same as Integer is
certainly on safe ground with GNAT, and I suspect in practice with other
compilers too. There is a danger of excessive pedantry here, and I suspect
Keith is worrying about something that in fact will not be a problem in
practice. There are far more significant non-portabilities in porting of
C than this one (the whole business of records being passed by copy being
the most glaring!)

Re: Simple ADA/C Question

[John McCabe]

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

>Keith argues for always using the interfaces type. Fine, I understand the

All the guy wanted to know was what was wrong with his program!


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Simple ADA/C Question

[Anders Eliasson]

In article <331c6ca7.792732@news.demon.co.uk>, john@assen.demon.co.uk (John McCabe) wrote:
>dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
>>Keith argues for always using the interfaces type. Fine, I understand the
>
>All the guy wanted to know was what was wrong with his program!
>

God help me if I ever come up with a sophisticated question, I guess :).

eliasson@logan.msfc.nasa.gov

Re: Simple ADA/C Question

[Robert Dewar]

Jhn McCabe said

<<All the guy wanted to know was what was wrong with his progra,>>

Indeed, and the whole business of int vs Integer was a giant red herring,
since this obviously had nothing to do with his problem and was not in
fact a problem at all (except at a theoretical language lawyer level).
\x1a

Re: Simple ADA/C Question

[Keith Thompson]

> Keith argues for always using the interfaces type. Fine, I understand the
> argument, but there is no question that this leads to lots of extra code,
> and many people avoid it, and I don't think that's so terrible (no worse
> than using any other implementation dependent feature of a compiler. Probably
> Keith likes to stay away from all such -- but many users are quite content
> with adopting a style that is at least portable from GNAT to GNAT.

I would hope that users would remember that GNAT isn't the only Ada
compiler out there.  (See my signature.)

No, I don't know of any Aonix or other compiler for which Integer and
Interfaces.C.int have different representations, but then I'm not very
familiar with our Intel products.

> Keith suggests
>  
> <<   subtype Assertion is Boolean range True .. True;
>    Integer_Same_Size : constant Assertion
>       := Interfaces.C.int'Size = Standard.Integer'Size;
> >>
>  
> Less writing, and guaranteed to not merely give a warning, but to be
> illegal if the assumption is violated is:
>  
>    X : Integer := 1 / Boolean'Pos (Interfaces.C.int'Size = Integer'Size);

Hmm.  I find the "Assertion" version easier to read, but to each his own.

In your example, I'd make X a named number rather than an Integer
variable, to make it clearer that the expression is static and therefore
illegal if it raises an exception.  The rules for static expressions
are tricky enough that it's worth being more explicit.

> Note incidentally that Standard.Integer does not guarantee that you will
> get the integer in standard, there is no way to do that in general!
> So it is probably unnecssary pedantry.

My intent was to make it explicit that this is the predefined type
Integer.  No biggie.

> As for Keith's guess that there could be C compilers that disagree on
> int size, I doubt it. Keith are you aware of all the discussions going
> on around C sizes on 64-bit machines?

I've heard a little about the discussions, but I don't remember the
details.  In any case, code that implicitly assumes that Interfaces.C.int
and Integer have the same representation not only requires that they
have the same representation, but that the reader of the code *knows*
that they have the same representation.

So, Robert, would you argue that Interfaces.C.int is unnecessary, and
that code should always assume that int and Integer are the same size?
If not, when is it appropriate to use Interfaces.C.int?

In another article, john@assen.demon.co.uk (John McCabe) wrote:
> All the guy wanted to know was what was wrong with his program!

Yes, and that was answered a while ago.  Now the discussion has gone on
to other things.  Such is Usenet.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"Humor is such a subjective thing." -- Cartagia

Re: Simple ADA/C Question

[Larry Kilgallen]

In article <E6LzEL.Hp0@thomsoft.com>, kst@sd.aonix.com (Keith Thompson) writes:

> No, I don't know of any Aonix or other compiler for which Integer and
> Interfaces.C.int have different representations, but then I'm not very
> familiar with our Intel products.

I would hope Aonix would look to supporting additional platforms in
future years, and there is always the possibility that on one of them
a dominent C compiler could have a different integer size than was
appropriate for ObjectAda (I boldly use that name claiming that
Aonix has more than used up their quota of name changes for the
lifetime of the Ada95 standard :-).

	< from Robert Dewar >

>> As for Keith's guess that there could be C compilers that disagree on
>> int size, I doubt it. Keith are you aware of all the discussions going
>> on around C sizes on 64-bit machines?

The fact that a C compiler is dominant may be less related to whether
it supports the rumored forthcoming consensus and more related to
whether it has the Microsoft brand.

Larry Kilgallen

Re: Simple ADA/C Question

[Robert Dewar]

Larry said

<<I would hope Aonix would look to supporting additional platforms in
future years, and there is always the possibility that on one of them
a dominent C compiler could have a different integer size than was
appropriate for ObjectAda>>

Well it's always possible, and is equally possible in the case of GNAT.
Looking at all current platforms, I don't see any where this possibility
is likely to arise (as you know GNAT is on 30-40 platforms now, so we have
looked at this issue on a pretty wide range of platforms).

We have found one platform, VMS, on which are standard decision to make
the Long_Integer type in Ada match long in C, is not appropriate. On VMS
type long in C is 32-bits, but we have two conflicting rquirements here,
one to be compatible with C in the normal GNAT style, and the other to
be compatible with DEC Ada 83. In DEC Ada 83, type Long_Integer is
64-bits, and we decided that this compatibility consideration wins out,
so Long_Integer /= long in the VMS version of GNAT.

However int is still the same as Integer, and I am still willing to bet
that it is very unlikely that any compiler will make any other choice
in the forseeable future. Too much user code depends on this identify
(and just in case you feel like blaming GNAT, the code I am talking
about is millions of lines of legacy Ada 83 code, written long before
GNAT existed!)

Re: Simple ADA/C Question

[Robert Dewar]

Keith said

<<Hmm.  I find the "Assertion" version easier to read, but to each his own.>>

    Maybe, but my form is guaranteed to give an error message, the assert
    form is not even guaranteed to give a warning (which would in any csae
    be overlooked if warnings were suppressed)

<<In your example, I'd make X a named number rather than an Integer
variable, to make it clearer that the expression is static and therefore
illegal if it raises an exception.  The rules for static expressions
are tricky enough that it's worth being more explicit.>>

    No point in encouraging the (I think unwarranted) viewpoint that the
    rules about static expressions are complex by unnecessary concessions
    to some imagined confusion.
     
           1 / 0

    is an illegal expression. It is illegal quite independent of the
    context in which it occurs, and Ada 95 programmers should understand
    this point clearly!

<<Actually here might be a nice form of the assertion:>>

    Check_Int_Size :
      Compile_Time_Assert := Require / (int'size = Integer'Size);

<<So, Robert, would you argue that Interfaces.C.int is unnecessary, and
that code should always assume that int and Integer are the same size?>>

    Of course not! Arguing that you can sometimes use X instead of Y has
    nothing to do with arguing that Y should never be used! 

<<If not, when is it appropriate to use Interfaces.C.int?>>

    If you are writing a text book, or if you want to be really fanatical
    about being portable to arbitrary unknown compilers in the future (in
    practice, I suspect that a decision to make int /= Integer would break
    so much code that it might be quite unwise :-) 

    P.S. All Aonix products have int'size = integer'size

    Note: Integer has a special place in Ada 95 because of its use in
    type String, so it is hard to get away from completely!

Re: Simple ADA/C Question

[Robert Dewar]

AE asks

<<I am very new to ADA ( 3-4 days experience ) and I have a question that
probably has a simple answer.  As part of my learning experience, I wrote
a simple piece of code that requests the user to enter an integer and then
the integer is displayed.  My ADA code calls a C function, which requests
and then returns the integer.  The primary ADA task consists of a loop so
the I can go get as many integers as I want as long as I input 'y' when
prompted ( the default is no ).  This works fine as long as I enter an
integer. If I enter a real, the program exits as if I had hit the default.
What am I forgetting to check to prevent a real, or any unexpected value,
from having this effect?  TIA.>>

your design is defective, to accept any character other than y as a
terminating character is a bad idea. In this case, the character read
is the period (if you input 21.35, the get of an integer will read only
the 21), and your program is working exactly as you intend (only though
I don't think you exactly intended this effect :-)

Re: Simple ADA/C Question

[root]

On 27 Feb 1997, Robert Dewar wrote:

> 
> your design is defective, to accept any character other than y as a
> terminating character is a bad idea. In this case, the character read
> is the period (if you input 21.35, the get of an integer will read only
> the 21), and your program is working exactly as you intend (only though
> I don't think you exactly intended this effect :-)
> 

Design, we don't need no stinkin design :).  I am simply learning ADA and
ADA to C interfacing and am not focusing on proper and robust designs yet.
Next week I will develop my new heart pump controller using embedded ADA
with a touch of C and THEN I'll pay attention to design, maybe :).

address e-mail replies to:
eliasson@logan.msfc.nasa.gov

Re: Simple ADA/C Question

[root]

On 27 Feb 1997, Robert Dewar wrote:

<snip>

BTW, humor aside, your point was duly noted.

address e-mail replies to:
eliasson@logan.msfc.nasa.gov

Re: Simple ADA/C Question

[Robert I. Eachus]

In article <dewar.857350486@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > Are there any compilers incidentally where int in C is not the
  > same as Integer in Ada? Certainly int = Integer on all GNAT
  > compilers.  Hard to believe that anyone would deviate from this
  > equivalence. Given that the choice of what Integer means in Ada is
  > definitely implementation dependent, it seems foolish to make any
  > other choice.

   Yes, and there is not much you can do about it...in the PC
environment for example there are C compilers with 16-bit ints, with
32-bits and compilers where the user gets to choose.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Simple ADA/C Question

[Robert Dewar]

Robert Eachus says

<<   Yes, and there is not much you can do about it...in the PC
environment for example there are C compilers with 16-bit ints, with
32-bits and compilers where the user gets to choose.>>

Sorry, that's too vague, please point me to a SPECIFIC Ada 95 compiler
that you can get today, where int and Integer are different.
I am not asking for theory, my question was a pragmatic one.
P.S. no use looking in GNAT, where Integer = int by definition,
and there are not many other Ada 95 compilers for the PC to look at!

Re: Simple ADA/C Question

[Jon S Anthony]

In article <dewar.857486486@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Keith suggests
> 
> <<   subtype Assertion is Boolean range True .. True;
>    Integer_Same_Size : constant Assertion
>       := Interfaces.C.int'Size = Standard.Integer'Size;
> >>
> 
> Less writing, and guaranteed to not merely give a warning, but to be
> illegal if the assumption is violated is:

You at compile time - surely at runtime (assuming no pragma supress or
some such) this will raise CE if violated.

> 
>    X : Integer := 1 / Boolean'Pos (Interfaces.C.int'Size = Integer'Size);

OK.  But it is significantly less clear as well.


> As for Keith's guess that there could be C compilers that disagree on
> int size, I doubt it. Keith are you aware of all the discussions going
> on around C sizes on 64-bit machines?

This certainly _was_ a problem a few years ago.  In a previous
existence, I had to deal with it in a port to AlphaAXP.


> compilers too. There is a danger of excessive pedantry here, and I suspect
> Keith is worrying about something that in fact will not be a problem in

I'm with Keith.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Simple ADA/C Question

[Robert Dewar]

Jon said

<<> Less writing, and guaranteed to not merely give a warning, but to be
> illegal if the assumption is violated is:

You at compile time - surely at runtime (assuming no pragma supress or
some such) this will raise CE if violated.

>
>    X : Integer := 1 / Boolean'Pos (Interfaces.C.int'Size = Integer'Size);

OK.  But it is significantly less clear as well.>>

Robert replies. I am not sure what that sentence means, since it does not
quite parse, but if you are saying that my statement may raise CE at run
time, that is wrong, it is definitely staticaly illegal at compile time.

As for it being unclear, of course a comment would clarify the intent,

something like:

    --  Cause illegality (division by zero) if int size /= integer size

and then I think it would be clear enough1

Re: Simple ADA/C Question

[Jon S Anthony]

In article <dewar.857703307@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon said
> 
> <<> Less writing, and guaranteed to not merely give a warning, but to be
> > illegal if the assumption is violated is:
> 
> You at compile time - surely at runtime (assuming no pragma supress or
> some such) this will raise CE if violated.
> 
> >
> >    X : Integer := 1 / Boolean'Pos (Interfaces.C.int'Size = Integer'Size);
> 
> OK.  But it is significantly less clear as well.>>
> 
> Robert replies. I am not sure what that sentence means, since it does not
> quite parse, but if you are saying that my statement may raise CE at run
> time, that is wrong, it is definitely staticaly illegal at compile time.

You're right it has at least one typo (insert "mean" after the first
"You") and even after that is fixed it is still unclear, because I
goofed up the contextual quotes as well.

What I meant to say was,

"You mean Keith's 'assertion' version won't give an error at compile
time - surely at runtime (assuming no pragma supress or some such)
this will raise CE if violated".


> As for it being unclear, of course a comment would clarify the intent,
> 
> something like:
> 
>     --  Cause illegality (division by zero) if int size /= integer size
> 
> and then I think it would be clear enough1

Perhaps, but now you have even more writing - not less.  And you can
always forget comments, "the road to Hell is paved with ..."

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Simple ADA/C Question

[Robert Dewar]

Jon said

<<"You mean Keith's 'assertion' version won't give an error at compile
time - surely at runtime (assuming no pragma supress or some such)
this will raise CE if violated".>>

Yes, but in such a case I feel it is *extremely* important to generate
the diagnostic at compile time rather than at runtime. A constraint error
may cause all sorts of peculiar effects (by silently terminating a task,
or by being caught by a when others exception handler).

Re: Simple ADA/C Question

[Larry Kilgallen]

In article <dewar.857783465@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jon said
> 
> <<"You mean Keith's 'assertion' version won't give an error at compile
> time - surely at runtime (assuming no pragma supress or some such)
> this will raise CE if violated".>>
> 
> Yes, but in such a case I feel it is *extremely* important to generate
> the diagnostic at compile time rather than at runtime.

For my money, one of the major advantages of Ada is the effect
of detecting more errors at compile time and fewer at run time.
Run-time detection raises the testing requirements to even less
achievable levels.

Larry Kilgallen

Re: Simple ADA/C Question

[Robert Dewar]

Jon says

<<Perhaps, but now you have even more writing - not less.  And you can
always forget comments, "the road to Hell is paved with ...">>

Given that the message was to me, I think it is wrong, since the "you"
equals me! I can never forget comments (ask my students and everyone
else whom I bug mercilessly on comments :-)