Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #112091
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Arrays sorting!! |
| Date | 2017-06-12 23:39 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <ohn1fl$shg$1@dont-email.me> (permalink) |
| References | (2 earlier) <BRv%A.173442$6r7.45165@fx34.am4> <U4w%A.40744$9M.16883@fx18.am4> <6681ba5c-0f02-40f2-9381-13c254b01843@googlegroups.com> <ohmpff$vch$1@dont-email.me> <0827527d-7e65-47e8-8571-c16b0335ebee@googlegroups.com> |
On 12/06/17 23:00, supercat@casperkitty.com wrote: > On Monday, June 12, 2017 at 2:22:57 PM UTC-5, David Brown wrote: >> On 12/06/17 16:36, supercat wrote: >>> Under C11, if an automatic-duration object is not initialized but its address >>> is taken, and if the type is one without any trap representations, conforming >>> implementations are required to ensure that reading the variable will yield >>> some (possibly arbitrary) value of that type. >>> >> >> 6.7.9 (Initialization): >> >> "If an object that has automatic storage duration is not initialized >> explicitly, its value is indeterminate." >> >> >> Annex J.2 has a list of undefined behaviour, including: >> >> "the value of an object with automatic storage duration is used while it >> is indeterminate (6.2.4, 6.7.9, 6.8)." >> >> To me, that sounds like using the value of an uninitialised automatic >> storage object, before it has been written, is undefined behaviour. >> This appears to be the case whether you read it directly, or if you take >> a pointer and read through that. >> >> Can you give the reference in C11 for your interpretation of something >> different? > > The descriptions in Annex J2 are sometimes over-generalized, listing things > which will *often*, though not always, invoke UB. > It seems to me to be pretty clear: "The behavior is undefined in the following circumstances:". It lists things that whose behaviour is not defined by the C standard. It is quite possible that some cases have their behaviour defined in other places (like implementation documentation) - just not defined in the C standard. > See section 6.3.2.1: > > - If the lvalue designates an object of automatic storage duration > that could have been declared with the register storage class (never > had its address taken), and that object is uninitialized (not declared > with an initializer and no assignment to it has been performed prior > to use), the behavior is undefined. How do you get from that to the idea that if you have taken its address, then reading the uninitialised object gives a value of that type? That paragraph says /nothing/ about what happens when you read from an uninitialised object whose address has been taken. Nothing else in 6.3.2.1 says so either. There is no definition of the behaviour - therefore, the behaviour is undefined just as surely as if the standards said so explicitly (see section 4). > > Given "int arr[60]", the expression arr[i] is defined as taking the address > of arr (as an int*), adding i, and then dereferencing the resulting pointer. > > If the type of the array had trap representations, then accessing an > Indeterminate Value of that type would yield Undefined Behavior regardless > of the object's storage duration, but the vast minority of implementations > specify that "int" has no trap representations. >
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Arrays sorting!! Christopher <info@invalid.invalid> - 2017-06-12 04:55 +0100
Re: Arrays sorting!! luser droog <luser.droog@gmail.com> - 2017-06-11 21:30 -0700
Re: Arrays sorting!! bartc <bc@freeuk.com> - 2017-06-12 13:32 +0100
Re: Arrays sorting!! bartc <bc@freeuk.com> - 2017-06-12 13:48 +0100
Re: Arrays sorting!! supercat@casperkitty.com - 2017-06-12 07:36 -0700
Re: Arrays sorting!! David Brown <david.brown@hesbynett.no> - 2017-06-12 21:22 +0200
Re: Arrays sorting!! supercat@casperkitty.com - 2017-06-12 14:00 -0700
Re: Arrays sorting!! David Brown <david.brown@hesbynett.no> - 2017-06-12 23:39 +0200
Re: Arrays sorting!! "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 18:47 -0400
Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 12:03 +0100
Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 20:23 +0800
Re: Arrays sorting!! mark.bluemel@gmail.com - 2017-06-12 07:32 -0700
Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 23:06 +0800
Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 16:08 +0100
Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-12 23:11 +0800
Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 16:46 +0100
Re: Arrays sorting!! "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-13 17:49 +0800
Re: Arrays sorting!! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 15:57 +0100
Re: Arrays sorting!! Real Troll <Real.Troll@Trolls.com> - 2017-06-12 16:55 -0400
csiph-web