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

Groups > comp.lang.c > #18967

Re: addresses of variables

Show all headers | View raw

On 03/23/2012 02:47 PM, Jens Gustedt wrote:
> Am 03/23/2012 02:06 PM, schrieb James Kuyper:
>>> No. The other thread could know by some other magic when doing this
>>> if the thread here still is alive and thus the pointer is still
>>> valid. (E.g all threads might be serialized and the other thread can
>>> inspect a table of all running threads.)
>>
>> That's outside the scope of the C standard (unless there's some features
>> of the new threading library that I'm unfamiliar with - which is quite
>> possible). Therefore whether or not a given implementation can do the
>> optimization I'm talking about depends in part upon whether it provides
>> such mechanisms to make it invalid.
> 
> No it isn't outside the scope of the standard. Undefined behavior only
> occurs when some thread effectively accesses a pointer who's object's
> lifetime has ended.

Correct. Therefore, an implementation which provides, as a non-standard
extension, the ability to guarantee that such code will execute during
the object's lifetime, cannot use undefined behavior as an excuse to
perform the optimization I'm talking about. However, a fully conforming
implementation that provides no such mechanism CAN perform such an
optimization. To provide such a guarantee in a portable fashion would
require a re-write to the example code; it can't exist with the code as
written.

> BTW, again you don't need threads for such a discussion. Even without
> threads you can have execution of other parts of the program outside the
> usual control flow, e.g through a signal handler.

Sure - for instance, a fully portable way to do this by modifying the
function would be to create a volatile sig_atomic_type object visible
from both this function and the signal handler, initialized to 0, set to
1 after the call to printf(), and set back to 0 before the execution of
the return statement, and modified by no other part of the program. If
the function itself is never called by a signal handler, and if the
signal handler sees that the value of that object is 1, then it can
guarantee that it's executing it's own code during the lifetime of the
object pointed at by that pointer, and can therefore safely dereference
that pointer.
Under those circumstances, the implementation would be prohibited from
performing the kind of optimization I'm talking about.

At least, that would be the case if the restrictions on what you can do
with standard-defined behavior inside a signal handler weren't so severe
(I've not had time to see if they've relaxed those restriction in C2011
- but in C99 every method I can think of for getting the address that
was printed out by printf() into the signal handler's scope would have
had undefined behavior - for one thing, it would require fflush(stdout),
and then some interaction with the user through stdin, both of which
would violate the prohibition on calling standard library functions
(7.1.4p4 and footnote 188 of n1570.pdf).

The key point is that execution of the signal handler code during the
pointed-at object's lifetime must be guaranteed, not merely a
possibility. In the absence of something that forces the access through
the pointer to be sequenced between the start and the end of the
pointed-at object's lifetime, an implementation is free to optimize the
object's lifetime down to 0 seconds, giving such code exactly 0% chance
of executing during the non-existing time interval in which
dereferencing the address would have defined behavior.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 03:56 -0700
  Re: addresses of variables "BartC" <bc@freeuk.com> - 2012-03-18 11:18 +0000
  Re: addresses of variables jt@toerring.de (Jens Thoms Toerring) - 2012-03-18 11:18 +0000
  Re: addresses of variables pete <pfiland@mindspring.com> - 2012-03-18 07:30 -0500
    Re: addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 04:42 -0700
      Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-19 10:52 -0400
        Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-19 12:55 -0500
          Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 14:30 -0400
            Re: addresses of variables jacob navia <jacob@spamsink.net> - 2012-03-19 20:11 +0100
              Re: addresses of variables hoganlong@gmail.com - 2012-03-19 12:17 -0700
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 16:15 -0400
                Re: addresses of variables hoganlong@gmail.com - 2012-03-19 14:18 -0700
                Re: addresses of variables "io_x" <a@b.c.invalid> - 2012-03-19 23:26 +0100
            Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 03:52 -0500
              Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 06:00 -0400
                Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 16:47 -0500
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 18:37 -0400
                Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 17:58 -0500
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-21 20:24 -0400
                Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 23:53 -0500
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-22 06:22 -0400
                Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-22 12:01 -0400
                Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-24 16:09 -0500
                Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 13:41 +0100
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 09:06 -0400
                Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 19:47 +0100
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 16:04 -0400
                Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 00:19 +0100
                Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 22:20 -0400
                Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:39 +0100
            Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-20 20:02 +0100
              Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 15:18 -0400
                Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-21 21:37 +0100
          Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-20 11:52 -0400
            Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-21 11:04 -0400

csiph-web