Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #112091

Re: Arrays sorting!!

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>

Show all headers | View raw


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


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