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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c50f57c0c29b391b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!wn12feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail From: Dave Thompson Newsgroups: comp.lang.ada Subject: Re: memory management Message-ID: <120qa1d035eklbq382nqkgk31equh0141c@4ax.com> References: <1131064.rs72P29t4t@yahoo.com> <1226363.QsRZW1KHie@linux1.krischik.com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 13 Jun 2005 04:01:26 GMT NNTP-Posting-Host: 12.76.7.179 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1118635286 12.76.7.179 (Mon, 13 Jun 2005 04:01:26 GMT) NNTP-Posting-Date: Mon, 13 Jun 2005 04:01:26 GMT Organization: AT&T Worldnet Xref: g2news1.google.com comp.lang.ada:11304 Date: 2005-06-13T04:01:26+00:00 List-Id: On Thu, 2 Jun 2005 18:41:07 -0700, "Steve" wrote: > While some C/C++ compilers may have checked array bounds, I'm not so sure it > complies with a standard. I don't have a copy of the standard available to > check. > It definitely does. Accessing out of declared bounds of an array is undefined behavior (equivalent to erroneous in Ada) and is not required to work in any particular or bounded way and also not required to be diagnosed -- but diagnosis is permitted if the implementation (implementor) wants to. But, and an important but, all bytes of an object's storage can standardly be accessed as an array of character. Precisely, they can all be _addressed_ with any flavor character pointer, and can be fetched as unsigned char; signed char, and plain char if an implementation chooses to make it signed, can at least in theory have 'trap representations' fetching of which is undefined. In practice this isn't done for integer types, mostly only floating-point (NaNs etc.) and very occasionally pointers. If you want them, C99 (9899) and C++ (14882) are available from ANSI webstore.ansi.org in PDF for personal use for USD 18 (each) by credit card (some people have reported trouble with non-USD cards). The ANSI terms include an indemnification clause that some fairly respected regulars on comp.{lang,std}.c feel is too broad; judge for yourself. INCITS (former X3) also has their own store, or used to. Or C99 with TC1 and Rationale is reliably reported to be published in traditional book form by Wiley with BSI as ISBN 0470845732, also C++ as 0470846747. TC1,2 are free-beer at ANSI. Or, the last public draft of C99 is free-beer 'next door' to WG9 at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/ and earlier drafts and other committee documents up 1 or 2. Although not identical to the adopted standard, the differences are mostly minor and obscure -- one does come up every few months or so in discussions on comp.lang.c -- and the draft is also in .txt and PS. C90 was AFAIK published by (or under) ANSI only in the expensive scanned form (about USD 200) and even that has disappeared now, although there was the Schildt version if you can find it used (as I did) and ignore the less-than-worthless annotations. There were claims about a year ago that BSI had been convinced to re-publish C90 on the basis that it is a specific (nonsuperseded) normative reference for C++, even though no longer for C; I never found it there myself. ANSI does show DIN and AS versions. > I do know that it is a common C idiom to describe a structure something > like: > Which would not work if array bounds were checked. > This is called the 'struct hack', see 2.6 in the C FAQ at the usual places and http://www.eskimo.com/~scs/C-faq/top.html . (In fact on searching to check something I discovered it's even indexed in C99 under 'struct hack' although that isn't in the body!) It does work on all or at least nearly all implementations precisely because they don't check, but it is officially undefined behavior -- explicitly (re)stated for C90 by (the response to) Defect Report 051, see at the website above. (DR#s below 200 are C90; above C99.) However, precisely because it is often useful, C99 adds a specific syntax for it called 'Flexible Array Member', which is to declare the last member (component) of a struct as an array with _no_ specified bound, and that type can then legally be used to access suitable actual objects of any size. This also avoids the ugly and easily forgotten adjustment of the length computation by one; other than that it is actually implemented the same as the 'hack'. AFAICS the restrictions on allocating FAM-structs mean that you _could_ put in dope to check them, but I don't know any implementation that does. > I have heard of tools that will do array bounds checking with C, that give > some way of describing the above example, but I don't think it is really > part of the C/C++ standard. > It is permitted, but not required and not expected or demanded or even (mostly?) wanted by (C) users and hence not done. And since C uses pointers all over the place, in particular all array accesses and 'by reference' parameters at least formally use pointers, the cost of checking pointers tends to occur 'everywhere' or at least more places than needed in more disciplined languages including Ada, which further discourages C implementors from providing it or already largely unenthustiastic users from requesting it. Note that even the not-widely-enough-used 'memory debugging' or specifically 'malloc debugging' tools often check only that accesses are within an entire allocated object, not necessarily within an array within that object (as a struct field or a multidim array 'row'). Of course where the whole object is the array this doesn't matter. - David.Thompson1 at worldnet.att.net