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

Groups > comp.lang.c > #58632 > unrolled thread

no stack

Back to article view | Back to comp.lang.c

Contents

  no stack fir <profesor.fir@gmail.com> - 2015-03-22 02:09 -0700
    Re: no stack wssimms@gmail.com - 2015-03-22 02:52 -0700
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:04 -0700
        Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 13:15 +0000
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:37 -0700
    Re: no stack Lőrinczy Zsigmond <nospam@for.me> - 2015-03-22 11:10 +0100
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:30 -0700
    Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:15 +0100
      Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:23 +0100
        Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:24 +0100
        Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:41 +0100
          Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-22 12:18 -0700
            Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 20:25 +0100
        Re: no stack Stephen Sprunk <stephen@sprunk.org> - 2015-03-23 12:17 -0500
        Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 13:22 -0400
    Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 11:13 +0000
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:29 -0700
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:33 -0700
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:39 -0700
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:46 -0700
        Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:16 +0000
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:25 -0700
            Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:59 +0000
              Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:15 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:39 +0100
                  Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 19:47 +0000
                    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:18 -0700
                      Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 11:21 +0000
                        Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 11:35 +0000
                        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:07 -0700
                          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:28 -0700
                          Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 14:56 +0000
                            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 08:13 -0700
                  Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:01 -0700
                    Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-23 13:14 +0100
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:30 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:15 +0100
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:49 -0700
    Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 12:37 +0100
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:06 -0700
        Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 13:23 +0100
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:48 -0700
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 08:51 -0700
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:39 -0700
              Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:54 -0700
        Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:45 +0100
          Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 14:20 +0000
            Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:43 +0100
            Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:09 -0700
              Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 20:38 +0000
                Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:54 -0700
                  Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:08 -0700
                    Re: no stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-23 12:07 +0000
                      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:13 -0700
                Re: no stack Kaz Kylheku <kaz@kylheku.com> - 2015-03-22 20:59 +0000
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:35 -0700
            Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 16:27 +0100
      Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:10 -0700
    Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 13:56 +0100
    Re: no stack John Bode <jfbode1029@gmail.com> - 2015-03-24 09:01 -0700
      Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-24 12:30 -0700
        Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 09:16 +0100
          Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 09:00 -0700
            Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:33 +0100
              Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-25 13:35 -0400
              Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:22 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 08:54 +0100
                  Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-26 08:48 -0700
                    Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 23:00 +0100
                  Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:15 -0700
                    Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-28 18:17 +0100
                      Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 12:36 -0700
                        Re: no stack Richard Damon <Richard@Damon-Family.org> - 2015-03-28 17:33 -0400
                      Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 08:04 -0700
                        Re: no stack David Brown <david.brown@hesbynett.no> - 2015-04-07 00:39 +0200
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-26 01:21 -0700
          Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-25 10:57 -0700
            Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:55 +0100

Page 4 of 4 — ← Prev page 1 2 3 [4]

#58868

John Bode <jfbode1029@gmail.com> writes:
[...]
> No.  Function arguments and block-scope variables have lifetimes limited to
> their enclosing scope; they should not be accessible outside of that scope.
>
> For example:
>
>     int *globalPtr;
>
>     void foo( void )
>     {
>       int a = 5;
>       ptr = &a;
>     }
>
>     void bar( void )
>     {
>       foo();
>       printf( "*ptr = %d\n", *ptr );
>       *ptr = 6;
>     }
>
> This *should* invoke undefined behavior; we're trying to read and update `a`
> outside of its lifetime.  If `a` is allocated statically in the
> same sense that `ptr` is allocated statically, how would you determine
> whether `a` is "live" or not?  You'd have to keep track of what scope you're
> in vs. what scope `a` belongs to.  

Quibble: Scope and lifetime are two distinct things.  Scope is a region
of program text in which an identifier is visible; lifetime is a
duration during program execution in which an object exists.

For local variables with automatic storage duration, the distinction can
*almost* be ignored; you can think of both scope and lifetime as
extending to the closing }.  But (a) the lifetime of a local object
begins at the beginning of the enclosing block, not at its declaration
(there are contrived cases where you can access the object within its
lifetime but outside its scope), and (b) if an object is declared in a
loop, then there's logically a distinct object for each iteration of the
loop (saving its address in one iteration and using that address to
access it in the next is undefined behavior, though it's likely to
"work").

More significantly, you can pass the address of a local object to
another function.  That other function is clearly outside the *scope* of
the object, but it can access it within its lifetime.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58903

On 24/03/15 20:30, Keith Thompson wrote:
> John Bode <jfbode1029@gmail.com> writes:
> [...]
>> No.  Function arguments and block-scope variables have lifetimes limited to
>> their enclosing scope; they should not be accessible outside of that scope.
>>
>> For example:
>>
>>     int *globalPtr;
>>
>>     void foo( void )
>>     {
>>       int a = 5;
>>       ptr = &a;
>>     }
>>
>>     void bar( void )
>>     {
>>       foo();
>>       printf( "*ptr = %d\n", *ptr );
>>       *ptr = 6;
>>     }
>>
>> This *should* invoke undefined behavior; we're trying to read and update `a`
>> outside of its lifetime.  If `a` is allocated statically in the
>> same sense that `ptr` is allocated statically, how would you determine
>> whether `a` is "live" or not?  You'd have to keep track of what scope you're
>> in vs. what scope `a` belongs to.  
> 
> Quibble: Scope and lifetime are two distinct things.  Scope is a region
> of program text in which an identifier is visible; lifetime is a
> duration during program execution in which an object exists.
> 
> For local variables with automatic storage duration, the distinction can
> *almost* be ignored; you can think of both scope and lifetime as
> extending to the closing }.  But (a) the lifetime of a local object
> begins at the beginning of the enclosing block, not at its declaration
> (there are contrived cases where you can access the object within its
> lifetime but outside its scope),

I am curious here - can you give an example of a legal way to access an
object within its lifetime and outside its scope, other than by passing
its address to an outside function (the function is not within the scope
of the local data, but it is run while the scope is still "active" in
the calling function)?  I don't imagine such contrived cases would be
useful in practice, but I can't think of any myself - so I wonder what
you are thinking of here.

> and (b) if an object is declared in a
> loop, then there's logically a distinct object for each iteration of the
> loop (saving its address in one iteration and using that address to
> access it in the next is undefined behavior, though it's likely to
> "work").
> 
> More significantly, you can pass the address of a local object to
> another function.  That other function is clearly outside the *scope* of
> the object, but it can access it within its lifetime.
> 
> [...]
> 

[toc] | [prev] | [next] | [standalone]

#58923

David Brown <david.brown@hesbynett.no> writes:

> On 24/03/15 20:30, Keith Thompson wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>> [...]
>>> No.  Function arguments and block-scope variables have lifetimes
>>> limited to their enclosing scope;  they should not be accessible
>>> outside of that scope.
>>>
>>> For example:
>>>
>>>     int *globalPtr;
>>>
>>>     void foo( void )
>>>     {
>>>       int a = 5;
>>>       ptr = &a;
>>>     }
>>>
>>>     void bar( void )
>>>     {
>>>       foo();
>>>       printf( "*ptr = %d\n", *ptr );
>>>       *ptr = 6;
>>>     }
>>>
>>> This *should* invoke undefined behavior;  we're trying to read and
>>> update `a` outside of its lifetime.  If `a` is allocated
>>> statically in the same sense that `ptr` is allocated statically,
>>> how would you determine whether `a` is "live" or not?  You'd have
>>> to keep track of what scope you're in vs. what scope `a` belongs
>>> to.
>>
>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>> region of program text in which an identifier is visible;  lifetime
>> is a duration during program execution in which an object exists.
>>
>> For local variables with automatic storage duration, the
>> distinction can *almost* be ignored;  you can think of both scope
>> and lifetime as extending to the closing }.  But (a) the lifetime
>> of a local object begins at the beginning of the enclosing block,
>> not at its declaration (there are contrived cases where you can
>> access the object within its lifetime but outside its scope),
>
> I am curious here - can you give an example of a legal way to
> access an object within its lifetime and outside its scope, other
> than by passing its address to an outside function [snip]

[disclaimer: world's stupidest example]

    int
    foo(){
        int *p = 0;
      DUMB:
        if( p ) return *p;
        int x = 7;
        p = &x;
        goto DUMB;
    }

The expression '*p' accesses 'x' outside its scope but
within its lifetime.

[toc] | [prev] | [next] | [standalone]

#58925

On 25/03/15 17:00, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 24/03/15 20:30, Keith Thompson wrote:
>>> John Bode <jfbode1029@gmail.com> writes:
>>> [...]
>>>> No.  Function arguments and block-scope variables have lifetimes
>>>> limited to their enclosing scope;  they should not be accessible
>>>> outside of that scope.
>>>>
>>>> For example:
>>>>
>>>>     int *globalPtr;
>>>>
>>>>     void foo( void )
>>>>     {
>>>>       int a = 5;
>>>>       ptr = &a;
>>>>     }
>>>>
>>>>     void bar( void )
>>>>     {
>>>>       foo();
>>>>       printf( "*ptr = %d\n", *ptr );
>>>>       *ptr = 6;
>>>>     }
>>>>
>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>> statically in the same sense that `ptr` is allocated statically,
>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>> to.
>>>
>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>> region of program text in which an identifier is visible;  lifetime
>>> is a duration during program execution in which an object exists.
>>>
>>> For local variables with automatic storage duration, the
>>> distinction can *almost* be ignored;  you can think of both scope
>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>> of a local object begins at the beginning of the enclosing block,
>>> not at its declaration (there are contrived cases where you can
>>> access the object within its lifetime but outside its scope),
>>
>> I am curious here - can you give an example of a legal way to
>> access an object within its lifetime and outside its scope, other
>> than by passing its address to an outside function [snip]
> 
> [disclaimer: world's stupidest example]
> 
>     int
>     foo(){
>         int *p = 0;
>       DUMB:
>         if( p ) return *p;
>         int x = 7;
>         p = &x;
>         goto DUMB;
>     }
> 
> The expression '*p' accesses 'x' outside its scope but
> within its lifetime.
> 

And that's legal (i.e., defined behaviour)?

OK, I've learned something today - not necessarily something /useful/,
but still something new!

I had previously assumed that lifetimes of local variables begin and end
along with their scope (but obviously remain alive while temporarily
leaving scope to execute a function).

[toc] | [prev] | [next] | [standalone]

#58933

On 03/25/2015 12:33 PM, David Brown wrote:
...
> OK, I've learned something today - not necessarily something /useful/,
> but still something new!
> 
> I had previously assumed that lifetimes of local variables begin and end
> along with their scope (but obviously remain alive while temporarily
> leaving scope to execute a function).


"Structure, union, and enumeration tags ... Each enumeration constant
... Any other identifier has scope that begins just after the completion
of its declarator." (6.2.1p7)

"For [an object with automatic storage duration] ... its lifetime
extends from entry into the block with which it is associated until
execution of that block ends in any way." (6.2.4p6)

Therefore, the start of the scope and the start of the lifetime will
generally not coincide, though if you put all declarations of such
objects at the beginning of a block, the discrepancy between those
starts will be minimized (it still matters for initializers, which can
only refer to identifiers that are in scope).

[toc] | [prev] | [next] | [standalone]

#58982

David Brown <david.brown@hesbynett.no> writes:

> On 25/03/15 17:00, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 24/03/15 20:30, Keith Thompson wrote:
>>>> John Bode <jfbode1029@gmail.com> writes:
>>>> [...]
>>>>> No.  Function arguments and block-scope variables have lifetimes
>>>>> limited to their enclosing scope;  they should not be accessible
>>>>> outside of that scope.
>>>>>
>>>>> For example:
>>>>>
>>>>>     int *globalPtr;
>>>>>
>>>>>     void foo( void )
>>>>>     {
>>>>>       int a = 5;
>>>>>       ptr = &a;
>>>>>     }
>>>>>
>>>>>     void bar( void )
>>>>>     {
>>>>>       foo();
>>>>>       printf( "*ptr = %d\n", *ptr );
>>>>>       *ptr = 6;
>>>>>     }
>>>>>
>>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>>> statically in the same sense that `ptr` is allocated statically,
>>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>>> to.
>>>>
>>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>>> region of program text in which an identifier is visible;  lifetime
>>>> is a duration during program execution in which an object exists.
>>>>
>>>> For local variables with automatic storage duration, the
>>>> distinction can *almost* be ignored;  you can think of both scope
>>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>>> of a local object begins at the beginning of the enclosing block,
>>>> not at its declaration (there are contrived cases where you can
>>>> access the object within its lifetime but outside its scope),
>>>
>>> I am curious here - can you give an example of a legal way to
>>> access an object within its lifetime and outside its scope, other
>>> than by passing its address to an outside function [snip]
>>
>> [disclaimer: world's stupidest example]
>>
>>     int
>>     foo(){
>>         int *p = 0;
>>       DUMB:
>>         if( p ) return *p;
>>         int x = 7;
>>         p = &x;
>>         goto DUMB;
>>     }
>>
>> The expression '*p' accesses 'x' outside its scope but
>> within its lifetime.
>
> And that's legal (i.e., defined behaviour)?

Yes I'm pretty sure it is.  However I encourage you to get a copy
of the Standard and read through the relevant sections to double
check me -- exercises like this are good to go through every now
and then both to check other people and for your own benefit.
(This is assuming of course you think familiarity with the C
standard is a benefit. :)

[toc] | [prev] | [next] | [standalone]

#59007

On 26/03/15 00:22, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 25/03/15 17:00, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 24/03/15 20:30, Keith Thompson wrote:
>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>> [...]
>>>>>> No.  Function arguments and block-scope variables have lifetimes
>>>>>> limited to their enclosing scope;  they should not be accessible
>>>>>> outside of that scope.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>>     int *globalPtr;
>>>>>>
>>>>>>     void foo( void )
>>>>>>     {
>>>>>>       int a = 5;
>>>>>>       ptr = &a;
>>>>>>     }
>>>>>>
>>>>>>     void bar( void )
>>>>>>     {
>>>>>>       foo();
>>>>>>       printf( "*ptr = %d\n", *ptr );
>>>>>>       *ptr = 6;
>>>>>>     }
>>>>>>
>>>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>>>> statically in the same sense that `ptr` is allocated statically,
>>>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>>>> to.
>>>>>
>>>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>>>> region of program text in which an identifier is visible;  lifetime
>>>>> is a duration during program execution in which an object exists.
>>>>>
>>>>> For local variables with automatic storage duration, the
>>>>> distinction can *almost* be ignored;  you can think of both scope
>>>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>>>> of a local object begins at the beginning of the enclosing block,
>>>>> not at its declaration (there are contrived cases where you can
>>>>> access the object within its lifetime but outside its scope),
>>>>
>>>> I am curious here - can you give an example of a legal way to
>>>> access an object within its lifetime and outside its scope, other
>>>> than by passing its address to an outside function [snip]
>>>
>>> [disclaimer: world's stupidest example]
>>>
>>>     int
>>>     foo(){
>>>         int *p = 0;
>>>       DUMB:
>>>         if( p ) return *p;
>>>         int x = 7;
>>>         p = &x;
>>>         goto DUMB;
>>>     }
>>>
>>> The expression '*p' accesses 'x' outside its scope but
>>> within its lifetime.
>>
>> And that's legal (i.e., defined behaviour)?
> 
> Yes I'm pretty sure it is.  However I encourage you to get a copy
> of the Standard and read through the relevant sections to double
> check me -- exercises like this are good to go through every now
> and then both to check other people and for your own benefit.
> (This is assuming of course you think familiarity with the C
> standard is a benefit. :)
> 

I agree that familiarity with the standard is a good thing for some C
programmers, and I have read through N1570 (C11 draft) myself.  But I am
not sure that it is a useful document for most C programmers - generally
it is enough to have a solid understanding of the language, keep away
from "dangerous" parts, and have access to someone more knowledgeable if
the need arises.  (My co-workers would ask /me/ if they needed to know
technical details, and if I don't know the answer and can't find it
myself in the standards, I'd pass the question on to this group.)  For
most C programmers, I think studying the standards is a waste of time.

However, I /did/ re-read section 6.2.4 "Storage duration of objects",
and your example looks sound to me.  I also found n interesting
exception (in light of other threads in c.l.c. at the moment) is that
the storage lifetime of a VLA begins at its declaration, not at the
start of the block.

[toc] | [prev] | [next] | [standalone]

#59028

David Brown <david.brown@hesbynett.no> writes:
[...]
> However, I /did/ re-read section 6.2.4 "Storage duration of objects",
> and your example looks sound to me.  I also found n interesting
> exception (in light of other threads in c.l.c. at the moment) is that
> the storage lifetime of a VLA begins at its declaration, not at the
> start of the block.

It has to.  The size to be allocated cannot in general be known until
the declaration is reached.

    {
        // ...
        size_t len = some_computed_value;
        int vla[len];
        // ...
    }

The vla cannot be allocated at the start of the block because the value
of len isn't known yet.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59042

On 26/03/15 16:48, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> However, I /did/ re-read section 6.2.4 "Storage duration of objects",
>> and your example looks sound to me.  I also found n interesting
>> exception (in light of other threads in c.l.c. at the moment) is that
>> the storage lifetime of a VLA begins at its declaration, not at the
>> start of the block.
> 
> It has to.  The size to be allocated cannot in general be known until
> the declaration is reached.
> 

Yes, that is perfectly obvious.  However, since many posters in this
group pride themselves in their accuracy on the standards, I thought it
was worth mentioning as an exception to the general rule regarding
storage duration of local objects.

[toc] | [prev] | [next] | [standalone]

#59149

David Brown <david.brown@hesbynett.no> writes:

> On 26/03/15 00:22, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 25/03/15 17:00, Tim Rentsch wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 24/03/15 20:30, Keith Thompson wrote:
>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>> [...]
>>>>>>> No.  Function arguments and block-scope variables have lifetimes
>>>>>>> limited to their enclosing scope;  they should not be accessible
>>>>>>> outside of that scope.
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>>     int *globalPtr;
>>>>>>>
>>>>>>>     void foo( void )
>>>>>>>     {
>>>>>>>       int a = 5;
>>>>>>>       ptr = &a;
>>>>>>>     }
>>>>>>>
>>>>>>>     void bar( void )
>>>>>>>     {
>>>>>>>       foo();
>>>>>>>       printf( "*ptr = %d\n", *ptr );
>>>>>>>       *ptr = 6;
>>>>>>>     }
>>>>>>>
>>>>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>>>>> statically in the same sense that `ptr` is allocated statically,
>>>>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>>>>> to.
>>>>>>
>>>>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>>>>> region of program text in which an identifier is visible;  lifetime
>>>>>> is a duration during program execution in which an object exists.
>>>>>>
>>>>>> For local variables with automatic storage duration, the
>>>>>> distinction can *almost* be ignored;  you can think of both scope
>>>>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>>>>> of a local object begins at the beginning of the enclosing block,
>>>>>> not at its declaration (there are contrived cases where you can
>>>>>> access the object within its lifetime but outside its scope),
>>>>>
>>>>> I am curious here - can you give an example of a legal way to
>>>>> access an object within its lifetime and outside its scope, other
>>>>> than by passing its address to an outside function [snip]
>>>>
>>>> [disclaimer: world's stupidest example]
>>>>
>>>>     int
>>>>     foo(){
>>>>         int *p = 0;
>>>>       DUMB:
>>>>         if( p ) return *p;
>>>>         int x = 7;
>>>>         p = &x;
>>>>         goto DUMB;
>>>>     }
>>>>
>>>> The expression '*p' accesses 'x' outside its scope but
>>>> within its lifetime.
>>>
>>> And that's legal (i.e., defined behaviour)?
>>
>> Yes I'm pretty sure it is.  However I encourage you to get a copy
>> of the Standard and read through the relevant sections to double
>> check me -- exercises like this are good to go through every now
>> and then both to check other people and for your own benefit.
>> (This is assuming of course you think familiarity with the C
>> standard is a benefit. :)
>
> I agree that familiarity with the standard is a good thing for
> some C programmers, and I have read through N1570 (C11 draft)
> myself.  But I am not sure that it is a useful document for most C
> programmers [...]  [snip elaboration]

Right, for most C programmers it isn't.  But that's why for people
like you it is, since you are likely to be looked to as a source
for authoritative (and correct!) information.

> However, I /did/ re-read section 6.2.4 "Storage duration of
> objects", and your example looks sound to me.  I also found n
> interesting exception (in light of other threads in c.l.c. at
> the moment) is that the storage lifetime of a VLA begins at its
> declaration, not at the start of the block.

Yes, and that exception can be important, because it may not be
immediately obvious that a declared array is a VLA rather than a
fixed-size array.

[toc] | [prev] | [next] | [standalone]

#59155

On 28/03/15 17:15, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 26/03/15 00:22, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 25/03/15 17:00, Tim Rentsch wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 24/03/15 20:30, Keith Thompson wrote:
>>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>> [...]
>>>>>>>> No.  Function arguments and block-scope variables have lifetimes
>>>>>>>> limited to their enclosing scope;  they should not be accessible
>>>>>>>> outside of that scope.
>>>>>>>>
>>>>>>>> For example:
>>>>>>>>
>>>>>>>>      int *globalPtr;
>>>>>>>>
>>>>>>>>      void foo( void )
>>>>>>>>      {
>>>>>>>>        int a = 5;
>>>>>>>>        ptr = &a;
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      void bar( void )
>>>>>>>>      {
>>>>>>>>        foo();
>>>>>>>>        printf( "*ptr = %d\n", *ptr );
>>>>>>>>        *ptr = 6;
>>>>>>>>      }
>>>>>>>>
>>>>>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>>>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>>>>>> statically in the same sense that `ptr` is allocated statically,
>>>>>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>>>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>>>>>> to.
>>>>>>>
>>>>>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>>>>>> region of program text in which an identifier is visible;  lifetime
>>>>>>> is a duration during program execution in which an object exists.
>>>>>>>
>>>>>>> For local variables with automatic storage duration, the
>>>>>>> distinction can *almost* be ignored;  you can think of both scope
>>>>>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>>>>>> of a local object begins at the beginning of the enclosing block,
>>>>>>> not at its declaration (there are contrived cases where you can
>>>>>>> access the object within its lifetime but outside its scope),
>>>>>>
>>>>>> I am curious here - can you give an example of a legal way to
>>>>>> access an object within its lifetime and outside its scope, other
>>>>>> than by passing its address to an outside function [snip]
>>>>>
>>>>> [disclaimer: world's stupidest example]
>>>>>
>>>>>      int
>>>>>      foo(){
>>>>>          int *p = 0;
>>>>>        DUMB:
>>>>>          if( p ) return *p;
>>>>>          int x = 7;
>>>>>          p = &x;
>>>>>          goto DUMB;
>>>>>      }
>>>>>
>>>>> The expression '*p' accesses 'x' outside its scope but
>>>>> within its lifetime.
>>>>
>>>> And that's legal (i.e., defined behaviour)?
>>>
>>> Yes I'm pretty sure it is.  However I encourage you to get a copy
>>> of the Standard and read through the relevant sections to double
>>> check me -- exercises like this are good to go through every now
>>> and then both to check other people and for your own benefit.
>>> (This is assuming of course you think familiarity with the C
>>> standard is a benefit. :)
>>
>> I agree that familiarity with the standard is a good thing for
>> some C programmers, and I have read through N1570 (C11 draft)
>> myself.  But I am not sure that it is a useful document for most C
>> programmers [...]  [snip elaboration]
>
> Right, for most C programmers it isn't.  But that's why for people
> like you it is, since you are likely to be looked to as a source
> for authoritative (and correct!) information.
>
>> However, I /did/ re-read section 6.2.4 "Storage duration of
>> objects", and your example looks sound to me.  I also found n
>> interesting exception (in light of other threads in c.l.c. at
>> the moment) is that the storage lifetime of a VLA begins at its
>> declaration, not at the start of the block.
>
> Yes, and that exception can be important, because it may not be
> immediately obvious that a declared array is a VLA rather than a
> fixed-size array.
>

No, that exception is /not/ important - because code that uses a 
variable within its lifetime but outside its scope (except, of course, 
via function calls within the scope) is /bad/ and /wrong/ code, even if 
it happens to be legal, and happens to work.  If asked about such code, 
I wouldn't even bother trying to figure out if the array was a VLA or a 
fixed size array - it would be immediately rejected anyway.

There are lots of cases where the rules of C are clearly defined (or 
implementation-defined, which should be equally clear in the compiler 
documentation), but the rules should not matter in well-written code. 
(Yes, "well-written" is not a defined term - it means "code that /I/ 
think is well written :-).  For instance, if anyone thinks they need to 
know if a plain char is signed or unsigned, they have written (or plan 
to write) bad code.

[toc] | [prev] | [next] | [standalone]

#59157

On Saturday, March 28, 2015 at 5:17:50 PM UTC, David Brown wrote:
> 
> There are lots of cases where the rules of C are clearly defined (or 
> implementation-defined, which should be equally clear in the compiler 
> documentation), but the rules should not matter in well-written code. 
> (Yes, "well-written" is not a defined term - it means "code that /I/ 
> think is well written :-).  For instance, if anyone thinks they need to 
> know if a plain char is signed or unsigned, they have written (or plan 
> to write) bad code.
>
Sometimes it's reasonable to take a histogram or provide a look-up
table for al character values. For example you're writing a Huffman compressor for text. The method becomes very dicey if chars are 16
bit, and impossible if they are 32 bit, but is fine for extended
ascii, which is often all you need to support.
Of course you can just cast the char to unsigned, which is the 
better solution. 

[toc] | [prev] | [next] | [standalone]

#59165

On 3/28/15 3:36 PM, Malcolm McLean wrote:
> On Saturday, March 28, 2015 at 5:17:50 PM UTC, David Brown wrote:
> >
> > There are lots of cases where the rules of C are clearly defined (or
> > implementation-defined, which should be equally clear in the compiler
> > documentation), but the rules should not matter in well-written code.
> > (Yes, "well-written" is not a defined term - it means "code that /I/
> > think is well written :-).  For instance, if anyone thinks they need to
> > know if a plain char is signed or unsigned, they have written (or plan
> > to write) bad code.
> >
> Sometimes it's reasonable to take a histogram or provide a look-up
> table for al character values. For example you're writing a Huffman 
> compressor for text. The method becomes very dicey if chars are 16
> bit, and impossible if they are 32 bit, but is fine for extended
> ascii, which is often all you need to support.
> Of course you can just cast the char to unsigned, which is the
> better solution.
>
Actually, for modern processors 16 bits into a histogram isn't that bad, 
in fact it comes close to fitting inside the typical cache.

For 32 bit characters, you may be able to do the brute force method on a 
64 bit machine. If you are thinking of 32 bits as the full Unicode 
character set it becomes a lot more manageable, since the highest value 
for a character is 0x10FFFF so the table is actually possible for a 32 
bit processor. For "practical" examples, you could break the table into 
pages, where the upper bits determine what page and the lower bits where 
on the page, and only allocate pages if there exists something in that 
page, and you will likely find that most of the pages will never be hit 
(especially if you prepare to handle the full 32 bits) on most practical 
text samples, especially as character values above 0x00FFFF are very rare.

[toc] | [prev] | [next] | [standalone]

#59283

David Brown <david.brown@hesbynett.no> writes:

> On 28/03/15 17:15, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 26/03/15 00:22, Tim Rentsch wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 25/03/15 17:00, Tim Rentsch wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>
>>>>>>> On 24/03/15 20:30, Keith Thompson wrote:
>>>>>>>> John Bode <jfbode1029@gmail.com> writes:
>>>>>>>> [...]
>>>>>>>>> No.  Function arguments and block-scope variables have lifetimes
>>>>>>>>> limited to their enclosing scope;  they should not be accessible
>>>>>>>>> outside of that scope.
>>>>>>>>>
>>>>>>>>> For example:
>>>>>>>>>
>>>>>>>>>      int *globalPtr;
>>>>>>>>>
>>>>>>>>>      void foo( void )
>>>>>>>>>      {
>>>>>>>>>        int a = 5;
>>>>>>>>>        ptr = &a;
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      void bar( void )
>>>>>>>>>      {
>>>>>>>>>        foo();
>>>>>>>>>        printf( "*ptr = %d\n", *ptr );
>>>>>>>>>        *ptr = 6;
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>> This *should* invoke undefined behavior;  we're trying to read and
>>>>>>>>> update `a` outside of its lifetime.  If `a` is allocated
>>>>>>>>> statically in the same sense that `ptr` is allocated statically,
>>>>>>>>> how would you determine whether `a` is "live" or not?  You'd have
>>>>>>>>> to keep track of what scope you're in vs. what scope `a` belongs
>>>>>>>>> to.
>>>>>>>>
>>>>>>>> Quibble:  Scope and lifetime are two distinct things.  Scope is a
>>>>>>>> region of program text in which an identifier is visible;  lifetime
>>>>>>>> is a duration during program execution in which an object exists.
>>>>>>>>
>>>>>>>> For local variables with automatic storage duration, the
>>>>>>>> distinction can *almost* be ignored;  you can think of both scope
>>>>>>>> and lifetime as extending to the closing }.  But (a) the lifetime
>>>>>>>> of a local object begins at the beginning of the enclosing block,
>>>>>>>> not at its declaration (there are contrived cases where you can
>>>>>>>> access the object within its lifetime but outside its scope),
>>>>>>>
>>>>>>> I am curious here - can you give an example of a legal way to
>>>>>>> access an object within its lifetime and outside its scope, other
>>>>>>> than by passing its address to an outside function [snip]
>>>>>>
>>>>>> [disclaimer: world's stupidest example]
>>>>>>
>>>>>>      int
>>>>>>      foo(){
>>>>>>          int *p = 0;
>>>>>>        DUMB:
>>>>>>          if( p ) return *p;
>>>>>>          int x = 7;
>>>>>>          p = &x;
>>>>>>          goto DUMB;
>>>>>>      }
>>>>>>
>>>>>> The expression '*p' accesses 'x' outside its scope but
>>>>>> within its lifetime.
>>>>>
>>>>> And that's legal (i.e., defined behaviour)?
>>>>
>>>> Yes I'm pretty sure it is.  However I encourage you to get a copy
>>>> of the Standard and read through the relevant sections to double
>>>> check me -- exercises like this are good to go through every now
>>>> and then both to check other people and for your own benefit.
>>>> (This is assuming of course you think familiarity with the C
>>>> standard is a benefit. :)
>>>
>>> I agree that familiarity with the standard is a good thing for
>>> some C programmers, and I have read through N1570 (C11 draft)
>>> myself.  But I am not sure that it is a useful document for most C
>>> programmers [...]  [snip elaboration]
>>
>> Right, for most C programmers it isn't.  But that's why for people
>> like you it is, since you are likely to be looked to as a source
>> for authoritative (and correct!) information.
>>
>>> However, I /did/ re-read section 6.2.4 "Storage duration of
>>> objects", and your example looks sound to me.  I also found n
>>> interesting exception (in light of other threads in c.l.c.  at
>>> the moment) is that the storage lifetime of a VLA begins at its
>>> declaration, not at the start of the block.
>>
>> Yes, and that exception can be important, because it may not be
>> immediately obvious that a declared array is a VLA rather than a
>> fixed-size array.
>
> No, that exception is /not/ important - because code that uses a
> variable within its lifetime but outside its scope (except, of
> course, via function calls within the scope) is /bad/ and /wrong/
> code, [snip elaboration]

You misundertood my point.  It's important to know about to be
trusted as an authority on what the language semantics are more
generally.  Knowing about semantic glitches like this, in addition
to being useful for strengthening your arguments against using a
particular pattern (rather than just emotionally labelling it
"bad" and "wrong"), should raise your listeners' confidence as to
your understanding of general language semantics (as it should,
since continually reading up on various and sundry backwaters of
the Standard will improve your understanding of those parts that
are more mainstream).

[toc] | [prev] | [next] | [standalone]

#59718

On 30/03/15 17:04, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 28/03/15 17:15, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 26/03/15 00:22, Tim Rentsch wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
<snip>
>>>> However, I /did/ re-read section 6.2.4 "Storage duration of
>>>> objects", and your example looks sound to me.  I also found n
>>>> interesting exception (in light of other threads in c.l.c.  at
>>>> the moment) is that the storage lifetime of a VLA begins at its
>>>> declaration, not at the start of the block.
>>>
>>> Yes, and that exception can be important, because it may not be
>>> immediately obvious that a declared array is a VLA rather than a
>>> fixed-size array.
>>
>> No, that exception is /not/ important - because code that uses a
>> variable within its lifetime but outside its scope (except, of
>> course, via function calls within the scope) is /bad/ and /wrong/
>> code, [snip elaboration]
>
> You misundertood my point.  It's important to know about to be
> trusted as an authority on what the language semantics are more
> generally.  Knowing about semantic glitches like this, in addition
> to being useful for strengthening your arguments against using a
> particular pattern (rather than just emotionally labelling it
> "bad" and "wrong"), should raise your listeners' confidence as to
> your understanding of general language semantics (as it should,
> since continually reading up on various and sundry backwaters of
> the Standard will improve your understanding of those parts that
> are more mainstream).
>

OK - you mean that knowing about the exception is important, rather than 
the exception itself?  I can agree with you there.

[toc] | [prev] | [next] | [standalone]

#59009

W dniu czwartek, 26 marca 2015 00:22:30 UTC+1 użytkownik Tim Rentsch napisał:
> (This is assuming of course you think familiarity with the C
> standard is a benefit. :)

I think its harm (Im joking a little, but not quite) (Im joking again, [though as i said in another thread as some say that optimistation is a waste of time for me optimisation cmpared to studying standard topics is much less waste of time, studying standart that is a waste - but noble waste] - At all, talking on c when you already know this is a waste.. 

((it would be really fine to talk something new and usefull: my favourite would be, "gpu kernel c advanced magic", or something that can turn your focus to code something brand new and terrific and make you rich and famous ;y (im a bit joking but a bit of money could be needed for health care and things )

[toc] | [prev] | [next] | [standalone]

#58939

David Brown <david.brown@hesbynett.no> writes:
> On 24/03/15 20:30, Keith Thompson wrote:
[...]
>> Quibble: Scope and lifetime are two distinct things.  Scope is a region
>> of program text in which an identifier is visible; lifetime is a
>> duration during program execution in which an object exists.
>> 
>> For local variables with automatic storage duration, the distinction can
>> *almost* be ignored; you can think of both scope and lifetime as
>> extending to the closing }.  But (a) the lifetime of a local object
>> begins at the beginning of the enclosing block, not at its declaration
>> (there are contrived cases where you can access the object within its
>> lifetime but outside its scope),
>
> I am curious here - can you give an example of a legal way to access an
> object within its lifetime and outside its scope, other than by passing
> its address to an outside function (the function is not within the scope
> of the local data, but it is run while the scope is still "active" in
> the calling function)?  I don't imagine such contrived cases would be
> useful in practice, but I can't think of any myself - so I wonder what
> you are thinking of here.

#include <stdio.h>
#include <stdbool.h>

int main(void) {
    bool first_time = true;
    TOP:;
    int *ptr;
    if (!first_time) printf("*ptr = %d\n", *ptr);
    int i = 42;
    ptr = &i;
    if (first_time) {
        first_time = false;
        goto TOP;
    }
}

The lifetime of `i` begins on entry to the block that makes up the body
of `main`, and ends on reaching the closing `}`.  The scope of `i`
extends from its declaration to the closing `}`.  The printf call is
outside the scope of `i`, so it can't refer to `i` by name -- but the
object `i` exists and it can access that object via `ptr`, which was
previously set to point to `i`.

(You could try to do something similar with a loop, but the lifetime of
`i` would be restricted to the body of the loop, and `*ptr` would refer
to a different object on the second iteration -- though it would
probably "work".)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58965

On 25/03/15 18:57, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 24/03/15 20:30, Keith Thompson wrote:
> [...]
>>> Quibble: Scope and lifetime are two distinct things.  Scope is a region
>>> of program text in which an identifier is visible; lifetime is a
>>> duration during program execution in which an object exists.
>>>
>>> For local variables with automatic storage duration, the distinction can
>>> *almost* be ignored; you can think of both scope and lifetime as
>>> extending to the closing }.  But (a) the lifetime of a local object
>>> begins at the beginning of the enclosing block, not at its declaration
>>> (there are contrived cases where you can access the object within its
>>> lifetime but outside its scope),
>>
>> I am curious here - can you give an example of a legal way to access an
>> object within its lifetime and outside its scope, other than by passing
>> its address to an outside function (the function is not within the scope
>> of the local data, but it is run while the scope is still "active" in
>> the calling function)?  I don't imagine such contrived cases would be
>> useful in practice, but I can't think of any myself - so I wonder what
>> you are thinking of here.
>
> #include <stdio.h>
> #include <stdbool.h>
>
> int main(void) {
>      bool first_time = true;
>      TOP:;
>      int *ptr;
>      if (!first_time) printf("*ptr = %d\n", *ptr);
>      int i = 42;
>      ptr = &i;
>      if (first_time) {
>          first_time = false;
>          goto TOP;
>      }
> }
>
> The lifetime of `i` begins on entry to the block that makes up the body
> of `main`, and ends on reaching the closing `}`.  The scope of `i`
> extends from its declaration to the closing `}`.  The printf call is
> outside the scope of `i`, so it can't refer to `i` by name -- but the
> object `i` exists and it can access that object via `ptr`, which was
> previously set to point to `i`.
>
> (You could try to do something similar with a loop, but the lifetime of
> `i` would be restricted to the body of the loop, and `*ptr` would refer
> to a different object on the second iteration -- though it would
> probably "work".)
>

That's pretty much the same as Tim's example - and I know see what you 
meant.

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web