Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146641
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Indexing one past the end of array? |
| Date | 2019-10-06 07:40 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86bluu9buj.fsf@linuxsc.com> (permalink) |
| References | <gF6mF.2635984$c8w1.2556225@fx08.am4> <lnwodjvtkz.fsf@kst-u.example.com> <XE7mF.116042$zU2.62708@fx01.iad> |
Richard Damon <Richard@Damon-Family.org> writes: > On 10/5/19 4:13 PM, Keith Thompson wrote: > >> [..addressing past the end of an array..] >> >> For example, assume a system with 32-bit addresses and exactly 2**32 >> bytes of addressable memory. Assume an array object >> char buf[100]; >> is allocated starting at address 2**32-100. Then (buf+100) points just >> past the end of the array, and also just past the end of addressable >> memory. As long as evaluating (buf+100)-1 yields a valid pointer to >> buf[99], that's ok. (This is just an example. The standard doesn't >> assume this kind of mapping between addresses and integer values.) > > One possible issue you (or maybe it is the compier) can run into is that > buf + 100 must be > buf + 99. In you case above, buf + 100 would be > 2**32, which if addresses are treated as 32 bit numbers, wraps to zero > and thus the relationship doesn't hold. The Rationale mentions this issue and points out that there need be only one never-allocated byte at the end of memory (or of course a few more than one if alignment causes the second-to-last byte not to be usable). > an issue with segmented memory/pointers, with a segment > size of 2**16. In such an environment, you can't have both 2**16 byte > arrays and 16 bit pointers and full conforming, and practically, often > the 2**16 byte object is just defined to be not supported in a fully > conforming manner (I don't think it is actually required to be) In C90 hosted implementations were required to support objects of at least 32767 bytes. In C99 onwards (assuming it hasn't changed) hosted implementations are required to support objects of at least 65535 bytes (and the minimum value for SIZE_MAX is 65535). So segments of 2**16 bytes can still be conforming.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Indexing one past the end of array? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2019-10-06 04:02 +0800
Re: Indexing one past the end of array? Keith Thompson <kst-u@mib.org> - 2019-10-05 13:13 -0700
Re: Indexing one past the end of array? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-05 22:01 +0100
Re: Indexing one past the end of array? Keith Thompson <kst-u@mib.org> - 2019-10-05 14:35 -0700
Re: Indexing one past the end of array? Richard Damon <Richard@Damon-Family.org> - 2019-10-05 19:00 -0400
Re: Indexing one past the end of array? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 08:05 -0700
Re: Indexing one past the end of array? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 06:36 -0700
Re: Indexing one past the end of array? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-06 16:31 +0100
Re: Indexing one past the end of array? Richard Damon <Richard@Damon-Family.org> - 2019-10-05 17:10 -0400
Re: Indexing one past the end of array? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-06 07:40 -0700
Re: Indexing one past the end of array? Mateusz Viste <mateusz@wont.tell> - 2019-10-05 20:26 +0000
Re: Indexing one past the end of array? chad <cdalten@gmail.com> - 2019-10-05 16:55 -0700
Re: Indexing one past the end of array? "Oliver S." <Follow.Me@gmx.net> - 2019-10-06 15:50 +0200
Re: Indexing one past the end of array? "Oliver S." <Follow.Me@gmx.net> - 2019-10-06 17:04 +0200
Re: Indexing one past the end of array? scott@slp53.sl.home (Scott Lurndal) - 2019-10-07 13:32 +0000
Re: Indexing one past the end of array? "Oliver S." <Follow.Me@gmx.net> - 2019-10-07 17:23 +0200
csiph-web