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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ogicse!littlei!foxinsox.hf.intel.com!prune From: prune@foxinsox.hf.intel.com.ogi.edu Newsgroups: comp.lang.ada Subject: Re: Ada Constraints Message-ID: <1329@gandalf.littlei.UUCP> Date: 17 Aug 90 15:59:30 GMT References: <4CE1FEE5846FC025DB@icdc.llnl.gov> Sender: news@littlei.UUCP Reply-To: prune@foxinsox.hf.intel.com (Prune Wickart) Organization: Intel Corp., IMSO UNIX Development, Hillsboro, OR List-Id: In article <4CE1FEE5846FC025DB@icdc.llnl.gov> WILSON@AMSTEL.llnl.gov (One Heppy Heppy 'Ket') writes: > > How can I force range checks on data presented to my Ada program from a > foreign (viz., C) routine? > > Here's the problem. We have many Ada programs which receive many messages > from many C programs. These C programs occasionally (erroneously) send > messages with values not in the ranges defined by our interface, and hence not > in the ranges defined by the associated Ada datatypes. > > By the time Ada gets involved, the data is already loaded (by the non-Ada > network routines) into an Ada record-type variable. Our Ada compiler > (VAX Ada V1.5) sees no reason to perform any range checks, since it didn't do > the actual assignment which loaded the variable. Eventually the program > performs an array index based on a component of the record variable, and gets > an access violation, or worse, crashes a task, or who-knows-what. The way I read this, your design problem is that you lack the direct language tools to define the *true* interface. C only recognizes certain types, and sees no fault with the values it hands to the Ada routines. The Ada compiler trusts that the programmer has taken care of any inter- language issues, so that you effectively have an unchecked conversion from C to Ada. Your Ada compiler has a fairly intelligent optimizer, so you can't fool it simply by sticking a finger up your nose and doing a little dance. I recommend "properly" defining the interface from the Ada side. Don't try to fool the optimizer: if Digital upgrades it in 2.0, you could find yourself SOL the next time you build your message system. For illustration, I will assume that your input contains an integer subtype, an enumeration type, and a text message. max_error_number: constant integer := 150; type snafu_number is byte_integer range 0 .. max_error_number; type snafu_type is (no_problem, drain_clog, gfci_fault, incoming_missile, dirty_diaper, ); synopsis_limit: constant integer := 40; type snafu_string is string (1 .. synopsis_limit); type C_message is record -- This is what C sees error_number: byte_integer; error_class: byte_integer; error_text: string(1 .. 40); end; -- And now, the Ada side of the story: type Ada_message is record -- How Ada *wants* to see it numeric_code: snafu_number; error_type: snafu_type; synopsis: snafu_string; end; -- copy a C message into its Ada equivalent function convert_C_message_to_Ada_message (give: in C_message) return Ada_message is take: Ada_message; begin Ada_message.numeric_code := C_message.error_number; Ada_message.error_type := C_message.error_class; Ada_message.synopsis := C_message.error_text; exception -- handle range errors here to your heart's content end convert_C_message_to_Ada_message; This code can be added to your current system, in the Ada package that gets the information from the C routine. Simply feed a C_message to the C routine that is providing you with the input; then copy that to the Ada_message where you truly wanted the information. You've given the compiler all the information it can use about what the two records *really* contain, and it can optimize and/or in-line as it sees fit. I'm confident that the Digital compiler, like ours, will optimize out the redundant portions of the checks, and will make short work of what remains. -------------------------------------------------------------------------------- DISCLAIMER: Intel pays me well for the opinions it wants; the other stuff remains mine. Some of the latter is posted; it's worth what you paid for it. A buddhist nudist practices yoga bare. local backbone: tektronix myrddyn!prune@uunet.uu.net USA phone: (503) 696-4668 wickart@ijf2.hf.intel.com Copyright (C) 1990, William D. Wickart. All rights reserved.