Re: doubt in USING POINTERS

From: Joe Wright (joewwright_at_comcast.net)
Date: 10/01/03 

Date: Wed, 1 Oct 2003 15:17:24 -0400

Wojtek Lerch <Wojtek_L@yahoo.ca> wrote in message
news:ca7e6477.0310011057.1ec1733@posting.google.com...
> kuyper@wizard.net (James Kuyper) wrote in message
news:<8b42afac.0310010654.1726a2ef@posting.google.com>...
> > "Wojtek Lerch" <Wojtek_L@yahoo.ca> wrote in message
news:<gBqeb.55229$3r1.3826@news02.bloor.is.net.cable.rogers.com>...
> > ...
> > > The standard says that trying to *access* it after the next
sequence point
> > > produces undefined behaviour, but that's not exactly the same as
saying that
> > > that's when its lifetime ends. In particular, I don't think it's
clear that
> > > the pointer to such an object becomes indeterminate at the next
sequence
> > > point.
> >
> > The purpose of the concept of "lifetime" is to describe the period
of
> > time during which the object can be accessed. I don't think you can
> > make that distinction.
>
> No, the purpose of the concept of "lifetime" is to describe the period
> of time *outside of which* you can't access the object and you can't
> even have a pointer to the object. *During* that period, accessing
> the object may or may not produce undefined behaviour, depending on
> numerous details of how you try to access it, what its contents are,
> whether restrict pointers to it exist, and so on. It's an important
> distinction: just because trying to access an object produces
> undefined behaviour for some reason, it doesn't mean that the object's
> lifetime has ended and any pointer that used to point to it is not a
> valid pointer any more. And 6.5.2.2p5 doesn't talk about the lifetime
> -- it's just one of the many places that talk about undefined
> behaviour.
>
> In short, when an object's lifetime ends is not determined by whether
> accessing the object produces undefined behaviour or not. It's
> determined by the object's storage duration (6.2.4p1). Trouble is,
> the C standard seems to have forgotten to define a type of storage
> duration suitable for those temporary objects returned by a function.
> If you assume that it must be one of the three defined storage
> durations, the pointer should stay valid until at least the end of the
> block, right?...

I think not. Functions return values, not objects. The concept of an
address of a value or of a member of a value is foreign to me. Assign
the value returned by the function to a suitable object and operate on
the object.

Relevant Pages

  • Re: doubt in USING POINTERS
    ... the purpose of the concept of "lifetime" is to describe the period ... even have a pointer to the object. ... the object may or may not produce undefined behaviour, ... duration suitable for those temporary objects returned by a function. ...
    (comp.lang.c)
  • Re: why do strcpy, strcat, & co return a pointer ?
    ... >>p is an array and not a pointer so p is being modified. ... but it is modified between two well defined sequence points: ... >one preceding the strcat call and the one preceding its return. ... >No undefined behaviour at all. ...
    (comp.lang.c)
  • Re: end of array
    ... You can make a pointer point to anything. ... arithmetic invokes undefined behaviour and anything can happen. ... I will probably get a segmentation fault or a memory fault. ... Just calculating a pointer like that can cause UB? ...
    (comp.lang.c)
  • Re: Rvalue of struct type
    ... the expression "funTest.a" yields an rvalue of type array of char, ... how can it be converted to pointer type when we can have pointer ... the next sequence point, or modifying it, results in undefined ...
    (comp.lang.c)
  • Re: system() without waiting
    ... Okay, "results in" undefined behaviour, then. ... In SUSv3 the execlpfunction has a prototype that ends with ", ... null pointer is a pointer that results from conversion of a null pointer ... null-terminated character strings. ...
    (comp.unix.programmer)