Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: New to the group Date: Mon, 02 Nov 2015 02:34:34 -0500 Organization: Aioe.org NNTP Server Lines: 68 Message-ID: References: <97f1036b-2ca0-488f-a630-566994f8e58d@googlegroups.com> <-9udnUrFSOV8WJHLnZ2dnUU7-N-dnZ2d@supernews.com> <6bba1447-e1fe-42dd-8972-8f3c9837ad5c@googlegroups.com> <877fn4amxg.fsf@jester.gateway.sonic.net> <1d793bd7rhaq6vblplj5da2jaukilaire2@4ax.com> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:43083 On Sat, 31 Oct 2015 06:54:26 -0400, David Thompson wrote: > On Fri, 02 Oct 2015 20:44:49 -0400, "Rod Pemberton" > wrote: >> On Fri, 02 Oct 2015 19:08:27 -0400, Paul Rubin wrote: >> >> > Yes. Think of a subscript error in a C program. The C standard says >> > what happens when a subscript is in range, but says nothing about what's >> > supposed to happen when it's out of range. Traditionally in C, that's >> > an unsafe operation and anything can happen. >> >> (nitpick ...) >> >> It defines access one past the end of certain arrays as valid, >> e.g., to detect nul '\0' at the end of string. But, yes, in >> general, access outside the scope of valid C objects is >> undefined or implementation defined. >> > People often treat the \0 as "after" the string, although the C > standards define the term string to include the (first) \0 and then > repeatedly talk about strings, characters, and character sequences > "including the terminating null" or "not including ...". > s/null/nul/ NUL is a character for ASCII and EBCDIC. C redefines the NUL character to be as large as the size of the C byte which can be larger in bits than the size of a C character. This was to allow for finding 16-bit NULs quickly on word sized machines when the character size is 8-bits or 9-bits, etc. > However, everyone agrees the \0 is in the *array* that the string is > stored in. [...] Yes. It's referred to as "after" the string because of the declared length of the string does not include the NUL character. > C also allows calculating the address of, but *not* accessing, the > fictional element that would be just after the array &a[n] or a+n . I know of no bounds checks or range checks for C that would prohibit accessing anything at any address. Accessing anything outside the scope of a valid C object is "undefined behavior" or implementation defined behavior, such as for a pointer to a memory mapped device. In fact, the ability to access just prior to an "array" or just after the end of an array is used by malloc() on many implementations since malloc() typically creates a header struct just prior to the allocated memory. > This means (on most implementations) an array can't be allocated > exactly at the end of the address space, or the end of a segment when > real segments are used, which the compiler can usually avoid easily. Here, I think you may be refering to a C object larger than a C byte in size crossing a segment boundary, perhaps causing a access violation such as a page fault, etc. This has nothing to do with C, but entirely with the platform. Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.