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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Gripe about Ada, rep specs that won't. Date: 1996/03/22 Message-ID: #1/1 X-Deja-AN: 143465231 references: <00001a73+00002504@msn.com> <4iq71v$cvr@news4.digex.net> <4isol4$dm7@ra.nrl.navy.mil> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-03-22T00:00:00+00:00 List-Id: In article <4isol4$dm7@ra.nrl.navy.mil>, Doug Rogers wrote: >dewar@cs.nyu.edu (Robert Dewar) wrote: >Well, that's quite a nice bit of high-road preaching from behind your >dais up there :-), but Ada does NOT protect you from those holes. >Regardless of the value of the discriminant, you can still access ANY >of the fields in a variant record. Well, here's some more preaching: No, you cannot access the fields from the wrong variant. A run-time check on the discriminant is done. Ada *does* protect you from that particular hole. Why do you believe otherwise? >... In fact, if I could rely on something >like Constraint_Error in those cases, I'd probably begrudgingly accept >the variant records of Ada. You can rely on a C_E, assuming your compiler works right. So please begrudgingly accept. ;-) You can also use pragma Unchecked_Union, a gnat-specific pragma that makes it more like a C union. (Not sure if this is in the current version of GNAT yet.) >..As it stands now, though, it just gets in >my way without providing any protection: I cannot set the discriminant, >and yet I can access another discriminant's fields. No... (By the way, I agree it can be an annoyance to have to do a whole-record assigmnent just to change the discrim -- I never had to do that in Pascal, which *also* did the same sort of checking...) >I'm using GNAT for prototyping. Here's my vote for packed types of all >sizes. I imagine that if you and enough others paid ACT for a support contract, they would implement it. I agree, it would be nice to have this support. Not quite nice enough to require in the Standard, though. >...Of course there's overhead. You have to keep track of each >index's bit position, not just its address. Tell me which has greater >cost, though, overhead in the compiler development or in the development >of each project that has to interface with embedded hardware? I've heard this argument before, and I don't buy it. Sure, the compiler is used by many, so adding features to a compiler might seem to benefit many (all the users) at the cost of a few (just the people who write the compiler). The problem is that adding features to a compiler causes it to be more buggy. More buggy for all users. It's not entirely clear what the tradeoff should be. But again, all it takes is money: if you have lots, or if you can gather a bunch of users who together have lots, you can get any compiler writer to do pretty much whatever you want. >... I've written my own version of >Sequential_Mixed_IO for GNAT, but since it uses System.File_IO and >various other Ada95-specific packages, I can't use -gnat83. System.File_IO is *not* Ada 95-specific. It is GNAT-specific. >Is there a way that I can make my package appear as if it were a >standard Ada83 package, even though it must do direct File_IO >operations? Surely only the *body* of your package depends on System.File_IO, so surely you can compile *most* of your code with the -gnat83 switch? - Bob