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,56250291936154a0 X-Google-Attributes: gid103376,public From: "Tarjei T. Jensen" Subject: Re: OS Bindings (was: Where is the elusive jump command?) Date: 2000/04/15 Message-ID: <8d9ubm$62r7@ftp.kvaerner.com>#1/1 X-Deja-AN: 611521324 Content-Transfer-Encoding: 7bit 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> <8d9pkm$2k5$1@nnrp1.deja.com> Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Organization: Kv�rner Group IT Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-04-15T00:00:00+00:00 List-Id: Robert Dewar wrote >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. I'm quite certain that the only situation which would require modular semantics for a size_t would be if it were used in a hash function or encryption function. [This may not apply for someone who is writing a compiler or a loader.] There are two big probems with wraparound for size_t. One is that there may be a lot of strange stuff high up (perhaps above the stack). Not to mention the stack and the other is that around zero there may be problems as well. Both these things make wraparound semantics for size_t dangerous. I know the offsetof function which uses offsets from address zero to compute offsets in C. But that use does not require modular semantics for size_t. In the book that I have available offsetof is a macro defined as "#define offsetof(type, memb) ((size_t) &((type *)0)->memb)" There is no doubt that there is a lot of work done manipulating size_t, but I don't remember a seeing a single use which involved modular semantics. There might be the occational &, but that's it. I'm not convinced that these things would be something that an Ada programmer would find neccessary to do. In C these tricks may be neccessary, but in Ada much less so. That is after all why we have all the various attributes. >Address computations using size_t are one of many examples. If you are programming in C, you may have need to abuse the type, but in Ada??? Most of the information we would use size_t for are available as attributes. We might need to convert from bits to bytes, but that's it. Greetings,