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: 1014db,4c42ac518eba0bbe X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,4c42ac518eba0bbe X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,4c42ac518eba0bbe X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Coding for Obscurity Date: 1997/11/24 Message-ID: <347995B9.33264527@hso.link.com>#1/1 X-Deja-AN: 292184392 References: <343fbb5a.0@news.iprolink.ch> <34466EB4.3381@dynamite.com.au> <6275dt$agm$3@news.on> <344BCED0.2D51@dynamite.com.au> <62tpap$7gh$1@darla.visi.com> <3470EF6E.F74@lysator.liu.se> <64qsf0$ccc@dfw-ixnews11.ix.netcom.com> <3474BF28.2F9F@dynamite.com.au> <34741AAF.1C7@CWA.de> <65b6ns$kok$1@goanna.cs.rmit.edu.au> Organization: Hughes Training Inc. - Houston Operations Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-24T00:00:00+00:00 List-Id: Richard A. O'Keefe wrote: > = > Stephan Wilms writes: > >In detail: I would reqrite the first example like this: > = > > /* Sensible comment about what get's allocated. */ > > if ( to =3D=3D NULL ) > > { > > to =3D malloc( sizeof *to); > > if ( to =3D=3D NULL ) return NULL; > > } > = > I would be rather unhappy at _any_ of these being common in my C code. > One thing I would very much like to have in C is a '* __nonnull__' form= =2E > One thing I love about LC-Lint is that it distinguishes between > sometype *p; /* p should not be null */ > sometype */*@null@*/ q; /* q may or may not be null */ > = > The reason that I dislike the C fragment above is that when you are for= ced > to do manual memory management, you have to be absolutely clear about w= ho > `owns' a dynamically allocated object and who doesn't. This fragment > muddies that up. If you could specify in the interface that to _couldn= 't_ > be NULL on entry, then you wouldn't have to patch around the problem at= > run time. > = > By the way, I regard this as a defect in Ada as well. Ada was supposed= to > allow for garbage collection, but with the exception of a couple of rec= ent > Ada->JVM compilers, this hasn't happened. Since you _do_ have to do ma= nual > memory management in practice, it is a pity that the language doesn't p= rovide > more compile-time help for getting it right. Perhaps Ada 2007 could bo= rrow a > few ideas from LC-Lint. Yeah, I agree that Ada 83 was very weak in "helping" with memory management. And Ada 95 is somewhat better in this regards (i.e. providing access parameters eliminates many needs for access types). However, Ada 95 does provide the storage_pool scheme where I can build whatever memory management system I need to include whatever elaborate facilities I desire. I'm anxious to see what storage_pools become available as reuse components. Indeed, I've used simple storage_pools simply to guarantee certain pointers to heterogenous types are stored in consecutive memory. I can then send that memory block across an interface and eliminate all the normal code associate with staging the values into a message record for sending and extracting the values from a received message record. > -- > John =C6neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL. > Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok -- = Samuel T. Harris, Senior Engineer Hughes Training, Inc. - Houston Operations 2224 Bay Area Blvd. Houston, TX 77058-2099 "If you can make it, We can fake it!"