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, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56250291936154a0 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: OS Bindings (was: Where is the elusive jump command?) Date: 2000/04/15 Message-ID: <8d9pkm$2k5$1@nnrp1.deja.com>#1/1 X-Deja-AN: 611492592 References: <38D771CA.D41AF9B5@port.ac.uk> <8bq7ku$mc8$1@nnrp1.deja.com> <38E0E723.C39C392@quadruscorp.com> <8brfm4$4uc$1@nnrp1.deja.com> <8brn4k$p6i$1@slb0.atl.mindspring.net> <8brrpj$i04$1@nnrp1.deja.com> <38E312F8.78883ACB@icn.siemens.de> <8c4rvf$d9k$1@nnrp1.deja.com> <2000Apr5.070127.1@eisner> <2000Apr6.081305.1@eisner> <8ci6vf$r5a$1@nnrp1.deja.com> <8ck638$krs3@ftp.kvaerner.com> <8cp23c$4gp$1@nnrp1.deja.com> <8csjs8$o2p3@ftp.kvaerner.com> <8d0su8$bqt$1@nnrp1.deja.com> <8d1ocu$5n31@ftp.kvaerner.com> <8d2dfo$28u$1@nnrp1.deja.com> <8d41rd$6622@ftp.kvaerner.com> X-Http-Proxy: 1.0 x43.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sat Apr 15 13:08:42 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-04-15T00:00:00+00:00 List-Id: In article <8d41rd$6622@ftp.kvaerner.com>, "Tarjei T. Jensen" wrote: > The modular semantics of a type like size_t in C is a side > effect. It is wron to blindly translate any unsinged type to a > modular type in Ada. The C designers used the unsigned type > because it was available and had the require range and not > because of its modular semantics. Actually I have seen quite a bit of C code that uses the type size_t for addressing computations (a not unreasonable choice) where wrap around semantics is just what you want. > Only a language lawyer would think that it would be sensible > for size_t to be modular type in Ada. Or someone who thinks it is a good idea to be completely interoperable with C :-) Actually it is you who are operating in language lawyer mode, and presuming to know the intent of the designers, and restrict programmers accordingly :-) > I think you will find it difficult to find many places in the > standard C libraries where the modular semantics of any > unsigned type is of importance or > where anything would fail if the type was not modular. Address computations using size_t are one of many examples. > The situation is most likely to be quite the oposite; that > errors or potential errors will be found which could have > cause programs to fail in mysterious > ways. I think that's EXACTLY wrong, what could cause mysterious failures is if the semantics of the Ada types that supposedly mirror the C types are subtly different, and the differences only show up in unusual cases. The point you make is a valid one with respect to the original design in C, it would have been nice in C to have unsigned types with underfined overflow conditions, rather than defined wrap around semantics. But given the choice that C designers made, I think it is really far more appropriate for Ada to copy these choices in providing analogous types in Ada than to decide to "improve" on the C design. When you are in the business of interfacing to a foreign language, you do not want to intefere with the interoperability of the interface by getting into the "that's terrible, we refuse to do things that way in Ada" mode. Indeed as I said above, it is language lawyers who make this mistake, not pragmatic folks :-) Sent via Deja.com http://www.deja.com/ Before you buy.