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

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

initialization of local static variable

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

Contents

  initialization of local static variable "V.Subramanian, India" <subramanian100in@yahoo.com> - 2011-10-06 23:33 -0700
    Re: initialization of local static variable pete <pfiland@mindspring.com> - 2011-10-07 02:51 -0400
    Re: initialization of local static variable "BartC" <bc@freeuk.com> - 2011-10-07 10:44 +0100
    Re: initialization of local static variable China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-07 03:03 -0700
      Re: initialization of local static variable "BartC" <bc@freeuk.com> - 2011-10-07 11:33 +0100
        Re: initialization of local static variable jt@toerring.de (Jens Thoms Toerring) - 2011-10-07 11:11 +0000
          Re: initialization of local static variable "BartC" <bc@freeuk.com> - 2011-10-07 12:51 +0100
            Re: initialization of local static variable jt@toerring.de (Jens Thoms Toerring) - 2011-10-07 15:56 +0000
              Re: initialization of local static variable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-07 20:29 +0100
                Re: initialization of local static variable jacob navia <jacob@spamsink.net> - 2011-10-07 21:38 +0200
                  Re: initialization of local static variable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-07 21:16 +0100
                    Re: initialization of local static variable jacob navia <jacob@spamsink.net> - 2011-10-07 22:22 +0200
                      Re: initialization of local static variable jt@toerring.de (Jens Thoms Toerring) - 2011-10-07 22:25 +0000
                        Re: initialization of local static variable jacob navia <jacob@spamsink.net> - 2011-10-08 00:40 +0200
                          Re: initialization of local static variable Ian Collins <ian-news@hotmail.com> - 2011-10-08 11:56 +1300
                            Re: initialization of local static variable jacob navia <jacob@spamsink.net> - 2011-10-08 01:53 +0200
                              Re: initialization of local static variable Jens Gustedt <jens.gustedt@loria.fr> - 2011-10-09 23:04 +0200
                              Re: initialization of local static variable Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-10-10 11:54 -0500
                                Re: initialization of local static variable Ike Naar <ike@sverige.freeshell.org> - 2011-10-10 17:41 +0000
                                  Re: initialization of local static variable Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-10-10 17:35 -0500
                          Re: initialization of local static variable jt@toerring.de (Jens Thoms Toerring) - 2011-10-08 00:02 +0000
                            Re: initialization of local static variable "BartC" <bc@freeuk.com> - 2011-10-08 01:26 +0100
                              Re: initialization of local static variable "Philip Lantz" <prl@canterey.us> - 2011-10-08 03:01 -0700
                  Re: initialization of local static variable "BartC" <bc@freeuk.com> - 2011-10-07 21:42 +0100
                  Re: initialization of local static variable China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-07 16:25 -0700
                    Re: initialization of local static variable jacob navia <jacob@spamsink.net> - 2011-10-08 01:51 +0200
                      Re: initialization of local static variable China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-07 18:21 -0700
                  Re: initialization of local static variable Nobody <nobody@nowhere.com> - 2011-10-08 15:36 +0100
                    Re: initialization of local static variable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-08 22:06 +0100
                      Re: initialization of local static variable Nobody <nobody@nowhere.com> - 2011-10-09 05:35 +0100
                        Re: initialization of local static variable Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-09 09:25 +0100
                        Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-09 11:00 +0200
                          Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-09 10:56 -0700
                            Re: initialization of local static variable James Kuyper <jameskuyper@verizon.net> - 2011-10-09 14:30 -0400
                              Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-09 21:43 -0700
                            Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-10 19:08 +0200
                              Re: initialization of local static variable Geoff <geoff@invalid.invalid> - 2011-10-10 16:16 -0700
                                Re: initialization of local static variable Ike Naar <ike@iceland.freeshell.org> - 2011-10-10 23:22 +0000
                                Re: initialization of local static variable James Kuyper <jameskuyper@verizon.net> - 2011-10-10 20:40 -0400
                              Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-10 20:54 -0700
                                Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-11 18:45 +0200
                                  Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-11 18:51 +0200
                                    Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-11 18:52 -0700
                                      Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-12 08:49 +0200
                                  Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-11 19:48 +0200
                                    Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-11 21:25 -0700
                                      Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-12 08:48 +0200
                                        Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-12 08:54 +0200
                                          Re: initialization of local static variable pete <pfiland@mindspring.com> - 2011-10-12 20:55 -0400
                                  Re: initialization of local static variable Barry Schwarz <schwarzb@dqel.com> - 2011-10-11 18:52 -0700
                                Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-11 19:55 +0200
                                  Re: initialization of local static variable Keith Thompson <kst-u@mib.org> - 2011-10-11 11:24 -0700
                                    Re: initialization of local static variable Keith Thompson <kst-u@mib.org> - 2011-10-11 12:47 -0700
                                    Re: initialization of local static variable "io_x" <a@b.c.invalid> - 2011-10-12 08:49 +0200
              Re: initialization of local static variable Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 16:09 -0800
            Re: initialization of local static variable China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-07 16:06 -0700
              Re: initialization of local static variable Seebs <usenet-nospam@seebs.net> - 2011-10-12 22:25 +0000
                Re: initialization of local static variable "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-10-13 07:09 -0700
                  Re: initialization of local static variable Seebs <usenet-nospam@seebs.net> - 2011-10-17 17:21 +0000
                Re: initialization of local static variable Joe Wright <joewwright@comcast.net> - 2011-10-14 14:27 -0400
            Re: initialization of local static variable Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-08 00:03 -0400
              Re: initialization of local static variable China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-10-08 01:27 -0700
            Re: initialization of local static variable Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-08 00:08 -0400

Page 1 of 4  [1] 2 3 4  Next page →

#11315 — initialization of local static variable

consider the following program x.c:
#include <stdlib.h>
#include <stdio.h>

char first[] = "test message";

void display(void)
{
        static char* p_first = first + 5;

        printf("%s\n", p_first);

        char second[] = "new message";
        static char* p_second = second + 4;

        printf("%s\n", p_second);

        return;
}

int main()
{
        display();

        return EXIT_SUCCESS;
}

When this program is compiled with
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
as
        gcc -std=c99 -pedantic -Wall -Wextra x.c
it generates the following error:
x.c: In function `display':
x.c:13: error: initializer element is not constant

The compiler accepts the initialization of the local static variable
'p_first' in 'display()' function. However the compiler reports error
for the initializtion of the local static variable 'p_second' in
'display()' function.

In the case of 'p_first', the array name 'first' decays into a pointer
to the first element and so in this case ALSO the memory address
stored in p_first will be known only at run-time(similar to that of
'p_second'). So why doesn't the compiler flag this as an error ?

Please clarify.

Thanks
V.Subramanian

[toc] | [next] | [standalone]

#11316

V.Subramanian, India wrote:
> 
> consider the following program x.c:
> #include <stdlib.h>
> #include <stdio.h>
> 
> char first[] = "test message";
> 
> void display(void)
> {
>         static char* p_first = first + 5;
> 
>         printf("%s\n", p_first);
> 
>         char second[] = "new message";
>         static char* p_second = second + 4;
> 
>         printf("%s\n", p_second);
> 
>         return;
> }
> 
> int main()
> {
>         display();
> 
>         return EXIT_SUCCESS;
> }
> 
> When this program is compiled with
> gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
> as
>         gcc -std=c99 -pedantic -Wall -Wextra x.c
> it generates the following error:
> x.c: In function `display':
> x.c:13: error: initializer element is not constant
> 
> The compiler accepts the initialization of the local static variable
> 'p_first' in 'display()' function. However the compiler reports error
> for the initializtion of the local static variable 'p_second' in
> 'display()' function.
> 
> In the case of 'p_first', the array name 'first' decays into a pointer
> to the first element and so in this case ALSO the memory address
> stored in p_first will be known only at run-time(similar to that of
> 'p_second'). So why doesn't the compiler flag this as an error ?
> 
> Please clarify.

ISO/IEC 9899
6.6 Constant expressions
9 An address constant is a null pointer, a pointer to an lvalue     
  designating an object of static storage duration, 
  or a pointer to a function designator; 
  it shall be created explicitly using the unary & operator 
  or an integer constant cast to pointer type, 
  or implicitly by the use of an expression of array or function type.

-- 
pete

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

#11318

"V.Subramanian, India" <subramanian100in@yahoo.com> wrote in message
news:16f1e150-05c8-4e30-a0e3-17aa3182f14d@d28g2000vby.googlegroups.com...

> char first[] = "test message";
>
> void display(void)
> {
>        static char* p_first = first + 5;
>
>        printf("%s\n", p_first);
>
>        char second[] = "new message";
>        static char* p_second = second + 4;
>
>        printf("%s\n", p_second);
>
>        return;
> }

> The compiler accepts the initialization of the local static variable
> 'p_first' in 'display()' function. However the compiler reports error
> for the initializtion of the local static variable 'p_second' in
> 'display()' function.

This is a funny one. My compiler (lccwin32) accepted this code with no
problem.

A couple of others including gcc gave the same error as yours.

There's no reason why that shouldn't work, other than perhaps something in
the language says it shouldn't. (Possibly, to do with the fact that the
declarations of 'second' and 'p_second' may not be in that order; p_second
could be created first.)

But you can get around it by separating the declaration of p_second, and 
it's initialisation, into two statements.

-- 
Bartc 

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

#11319

In article <16f1e150-05c8-4e30-a0e3-17aa3182f14d@d28g2000vby.googlegroups.com>,
 "V.Subramanian, India" <subramanian100in@yahoo.com> wrote:

> consider the following program x.c:
> #include <stdlib.h>
> #include <stdio.h>
> 
> char first[] = "test message";

The address of first is known when the program is loaded.

> 
> void display(void)
> {
>         static char* p_first = first + 5;

p_first is initialised when the program is loaded with address already known.


> 
>         printf("%s\n", p_first);
> 
>         char second[] = "new message";

The address of second is not known until display() is evaluated. second is 
allocated in auto storage and then the string "new message" is copied to it. 
Whilst the address of the string is known when the program is loaded, the 
address of the copy is not.

>         static char* p_second = second + 4;

p_second is initialised when the program is loaded with an address that will not 
be known until later and might change.

>         printf("%s\n", p_second);
> 
>         return;
> }

-- 
Celle est une langue.     |   With the nutty taste of wild hickory nuts.
C'est francais           /|\              I'm whoever you want me to be.
et tres, tres sexuel.    \|/         Annoying Usenet one post at a time.
- China Azul              |            At least I can stay in character.

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

#11320

"China Blue Corn Chips" <chine.bleu@yahoo.com> wrote in message
news:chine.bleu-1373B4.03030507102011@news.eternal-september.org...
> In article
> <16f1e150-05c8-4e30-a0e3-17aa3182f14d@d28g2000vby.googlegroups.com>,
> "V.Subramanian, India" <subramanian100in@yahoo.com> wrote:
>
>> consider the following program x.c:
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> char first[] = "test message";
>
> The address of first is known when the program is loaded.

The address of first, yes; it's contents are initially set to point to "test
message".

>>
>> void display(void)
>> {
>>         static char* p_first = first + 5;
>
> p_first is initialised when the program is loaded with address already
> known.

But 'first' refers to it's contents, not it's address. The contents might
have changed (point to another string) by the time display() gets called. 
(I'm assuming p_first is re-initialised on each entry to the function.)

-- 
Bartc 

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

#11321

BartC <bc@freeuk.com> wrote:

> "China Blue Corn Chips" <chine.bleu@yahoo.com> wrote in message
> news:chine.bleu-1373B4.03030507102011@news.eternal-september.org...
> > In article
> > <16f1e150-05c8-4e30-a0e3-17aa3182f14d@d28g2000vby.googlegroups.com>,
> > "V.Subramanian, India" <subramanian100in@yahoo.com> wrote:
> >
> >> consider the following program x.c:
> >> #include <stdlib.h>
> >> #include <stdio.h>
> >>
> >> char first[] = "test message";
> >
> > The address of first is known when the program is loaded.

> The address of first, yes; it's contents are initially set to point to "test
> message".

I guess that you overlooked that 'first' isn't a pointer but
an array (which would explain most of what you wrote in the
following). Thus memory for it is made available and initia-
lized (to "test message") when the program is loaded. Its
address is, of course, known at that point in time.

> >> void display(void)
> >> {
> >>         static char* p_first = first + 5;
> >
> > p_first is initialised when the program is loaded with address already
> > known.

> But 'first' refers to it's contents, not it's address.

'first + 5' evaluates to the address of (the first element of)
'first, incremented by 5 - there's nothing refering to the con-
tent of 'first'. Since 'first is an array (not a pointer) we've
got the common conversion of an array to a pointer to its first
element when the array is used where a value is required.

> The contents might
> have changed (point to another string) by the time display() gets called. 

The content of the array 'first' could have changed, yes, but it
will still have the same address.

> (I'm assuming p_first is re-initialised on each entry to the function.)

No, 'p_first', being a static variable, is initialized exactly
once when the program is loaded - at least that's how I would
tend to interpret 3.1.2.4 in C89:

     An object declared with external or internal linkage, or with the
  storage-class specifier static has static storage duration.  For such
  an object, storage is reserved and its stored value is initialized
  only once, prior to program startup.

                                   Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#11322

"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:9f852eF700U1@mid.uni-berlin.de...
> BartC <bc@freeuk.com> wrote:
>
>> "China Blue Corn Chips" <chine.bleu@yahoo.com> wrote in message
>> > "V.Subramanian, India" <subramanian100in@yahoo.com> wrote:

>> >> char first[] = "test message";
>> >
>> > The address of first is known when the program is loaded.
>
>> The address of first, yes; it's contents are initially set to point to
>> "test
>> message".
>
> I guess that you overlooked that 'first' isn't a pointer but
> an array (which would explain most of what you wrote in the
> following). Thus memory for it is made available and initia-
> lized (to "test message") when the program is loaded. Its
> address is, of course, known at that point in time.

Oh, OK.

>> (I'm assuming p_first is re-initialised on each entry to the function.)
>
> No, 'p_first', being a static variable, is initialized exactly
> once when the program is loaded - at least that's how I would
> tend to interpret 3.1.2.4 in C89:

I tried this:

int a=1901;

void testfn(void) {
  static int b=a;
  printf("A, B = %d, %d\n",a,b);
}

- int main(void) {
-  testfn();
-  a=2901;
-  testfn();
- }

[hyphens added to avoid weird formatting issues in Windows Mail]

Which worked as expected, with lccwin32 compiler (b is assigned the value 
of a on each entry to the function).

On other, presumably more compliant compilers, this initialisation of b 
wasn't allowed. However the behaviour allowed by lccwin32 is more 
intuitive and more useful. (There is nothing after all to stop you writing:

  static int b; b=a;

which would have the same effect. So why not the convenience of having it 
all in one statement?)

-- 
Bartc 

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

#11330

BartC <bc@freeuk.com> wrote:
> >> (I'm assuming p_first is re-initialised on each entry to the function.)
> >
> > No, 'p_first', being a static variable, is initialized exactly
> > once when the program is loaded - at least that's how I would
> > tend to interpret 3.1.2.4 in C89:

> I tried this:

> int a=1901;

> void testfn(void) {
>   static int b=a;
>   printf("A, B = %d, %d\n",a,b);
> }

> - int main(void) {
> -  testfn();
> -  a=2901;
> -  testfn();
> - }

> [hyphens added to avoid weird formatting issues in Windows Mail]

> Which worked as expected, with lccwin32 compiler (b is assigned the value 
> of a on each entry to the function).

That, for me, would be absolutely unexpected since then the
'static' qualifier on 'b' would have no effect at all, it
would behave exactly the same as if you would have written

    int b = a;

> On other, presumably more compliant compilers, this initialisation of b 
> wasn't allowed.
>
> However the behaviour allowed by lccwin32 is more 
> intuitive and more useful. (There is nothing after all to stop you writing:

>   static int b; b=a;

> which would have the same effect. So why not the convenience of having it 
> all in one statement?)

As I said, I would be rather surprised by this behaviou since I'm
used to rely on static variables to be initialized once and then
never again. Thus for me

   static int b = a;

(which doesn't work as long a isn't a constant expression) and

   static int b;
   b = a;

are two rather different things. If 'a' is a constant expression
then 'b' should be set once to it the first time the function is
called and then retain any value it has at the end of the func-
tion.

Consider for example code like this you will find quite often:

void foo( ) {
    static int is_uninitialized = 1;
    if ( ! is_uninitialized ) {
         initialize_something( );
         is_uninitialized = 0;
    }
    ...
}

Rather obviously, 'is_uninitialized' is meant to ensure that
initialize_something() is called only once, the first time the
function is called. Having it re-initialized to 1 every time
the function is called would break a lot of existing code...

But then the lccwin32 compiler allows something that isn't
defined by the standard (initialization with a non-constant
expression) and for that situation it could bend the rules
in whatever way it wants - it's on its own to define what
the further consequences are. It's not intuitive to me what
it seems to be doing but then that's of litte importantance;-)

                             Regards. Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#11341

jt@toerring.de (Jens Thoms Toerring) writes:

> BartC <bc@freeuk.com> wrote:
<snip>
>> I tried this:
>
>> int a=1901;
>
>> void testfn(void) {
>>   static int b=a;
>>   printf("A, B = %d, %d\n",a,b);
>> }
>
>> - int main(void) {
>> -  testfn();
>> -  a=2901;
>> -  testfn();
>> - }
>
>> [hyphens added to avoid weird formatting issues in Windows Mail]
>
>> Which worked as expected, with lccwin32 compiler (b is assigned the value 
>> of a on each entry to the function).
>
> That, for me, would be absolutely unexpected since then the
> 'static' qualifier on 'b' would have no effect at all, it
> would behave exactly the same as if you would have written
>
>     int b = a;

Not exactly the same.  In the case of static b, it's address could be
passed out of the function and would be valid even after the function's
return.

By the way I agree with the "unexpected" part.  Despite this being an
extension, I'd expect only one initialisation.  By the way, even a
function call is permitted as the initialiser.

<snip>
-- 
Ben.

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

#11343

Le 07/10/11 21:29, Ben Bacarisse a écrit :
> By the way I agree with the "unexpected" part.  Despite this being an
> extension, I'd expect only one initialisation.  By the way, even a
> function call is permitted as the initialiser.
>

Well, why shouldn't be possible?

I don't see any reason. The compiler can do it, the language
looks the same, why shouldn't I do it?

Besides the obvious (the standard doesn't like it) is there
any reason not to do it?

Now, it *could* be said that it would be unexpected because
static initializations are done at load time but obviously
the intention of the programmer here can't be that since
there is no way a function can be called at load time...

Are there any other reasons why it should not work?

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

#11346

jacob navia <jacob@spamsink.net> writes:

> Le 07/10/11 21:29, Ben Bacarisse a écrit :
>> By the way I agree with the "unexpected" part.  Despite this being an
>> extension, I'd expect only one initialisation.  By the way, even a
>> function call is permitted as the initialiser.
>
> Well, why shouldn't be possible?
>
> I don't see any reason. The compiler can do it, the language
> looks the same, why shouldn't I do it?
>
> Besides the obvious (the standard doesn't like it) is there
> any reason not to do it?
>
> Now, it *could* be said that it would be unexpected because
> static initializations are done at load time but obviously
> the intention of the programmer here can't be that since
> there is no way a function can be called at load time...

The programmer may simply expect the initialisation to be done "early"
(as it is in C++).  Whenever it get done, I'd expect the function to be
called only once.  That, for me, is the "unexpected" part.

> Are there any other reasons why it should not work?

No, you define what it means, so it is bound to work.  Do you think it
is useful?

-- 
Ben.

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

#11347

Le 07/10/11 22:16, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 07/10/11 21:29, Ben Bacarisse a écrit :

[snip]

>
> The programmer may simply expect the initialisation to be done "early"
> (as it is in C++).  Whenever it get done, I'd expect the function to be
> called only once.  That, for me, is the "unexpected" part.
>

Yes, I agree that this handling of static is not coherent with the
other handling of statics in other parts of the language.

I see that you have a point here.

>> Are there any other reasons why it should not work?
>
> No, you define what it means, so it is bound to work.  Do you think it
> is useful?
>

I think it makes the language more coherent. See the question of the
original poster. He was surprised that it doesn't work, and
intuitively, you expect it to work.

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

#11354

jacob navia <jacob@spamsink.net> wrote:
> Le 07/10/11 22:16, Ben Bacarisse a écrit :
> > jacob navia<jacob@spamsink.net>  writes:
> >
> >> Le 07/10/11 21:29, Ben Bacarisse a écrit :

> [snip]

> > The programmer may simply expect the initialisation to be done "early"
> > (as it is in C++).  Whenever it get done, I'd expect the function to be
> > called only once.  That, for me, is the "unexpected" part.

> Yes, I agree that this handling of static is not coherent with the
> other handling of statics in other parts of the language.

> I see that you have a point here.

> >> Are there any other reasons why it should not work?
> >
> > No, you define what it means, so it is bound to work.  Do you think it
> > is useful?

> I think it makes the language more coherent. See the question of the
> original poster. He was surprised that it doesn't work, and
> intuitively, you expect it to work.

I think there are different things to consider here. First of all,
not restricting the initialization of a static variable to a con-
stant expression may have some benefits (but not being a compiler
writer and thus not having to ponder all possible consequences I
might overlook a number of hairy corner cases).

The other point is having a static variable initialized more than
once. That's something I find rather disturbing - I learned to
expect a static variable to be initialized once (may it be while
loading the program or when the function it's defined in is called
for the first time seems to me to be less crucial), but having it
change its value afterwards due to the initialization again and
again is something I wouldn't have considered to be a possibility.

As far as I can see there's a double "personality" to a static
variable. One is that it can be returned from a function (the
part of 'static' I hadn't considered but Ben pointed out a few
posts up-thread). The other is the part about "it's initialized
once and then keeps its value across function invocations". That
these two meanings overlap is probably due to the way static va-
riables are typically implemented (i.e. actually somewhere as
some global memory entity, initialized at the momemt they are
set up, just not made visible to the programmer when it's de=
fined within a function).

Your approach seems to concentrate on the "I can return it from
a function", dropping the "it's initialized only once" part of
it - with, as far as I have understood BartC's posts, still ma-
king a difference depending on how it was initialized. I.e. if
it was initialized with a constant expression it behaves as a
"standard" static variable (initialized only once), otherwise it
follows some other rules.

I don't want to argue if this is wrong - you write the compiler
and thus you define what happens - but, at least to me, it does
not make things easier to understand or seems to be more cohe-
rent since I now also have to consider how a static variable is
initialized in order to figure out how it will behave.

                            Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#11359

Le 08/10/11 00:25, Jens Thoms Toerring a écrit :
>
> I don't want to argue if this is wrong - you write the compiler
> and thus you define what happens - but, at least to me, it does
> not make things easier to understand or seems to be more cohe-
> rent since I now also have to consider how a static variable is
> initialized in order to figure out how it will behave.
>

Obviously if it is initialized with a constant expression the simple
rule applies as before: it is initialized once by the linker before
the program is loaded

If the expression is not constant it will be initialized when the
program executes the initialization statement (it can't be otherwise
since it is NOT a constant expression)

I see this as very easy to understand but I could be wrong since
I program in C since a long time and can't go back to my beginner
years to verify that it looks coherent to a beginner)

Now, I have a problem with the "once" that Ben pointed out. Should
I generate code that initializes that ONCE?

For instance I could generate code that tests a memory location to see
if the variable is initialized or not and skip the initialization
if it is initialized already.

The whole thing comes down to the existence of an initialization
procedures (like the C++ constructors) that would allow us to
write:

double sqrt2_over_2 = sqrt(2)/2;
int main(void)
{
	printf("%g\n",sqrt2_over_2);
}

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

#11360

On 10/ 8/11 11:40 AM, jacob navia wrote:
> Le 08/10/11 00:25, Jens Thoms Toerring a écrit :
>>
>> I don't want to argue if this is wrong - you write the compiler
>> and thus you define what happens - but, at least to me, it does
>> not make things easier to understand or seems to be more cohe-
>> rent since I now also have to consider how a static variable is
>> initialized in order to figure out how it will behave.
>>
>
> Obviously if it is initialized with a constant expression the simple
> rule applies as before: it is initialized once by the linker before
> the program is loaded
>
> If the expression is not constant it will be initialized when the
> program executes the initialization statement (it can't be otherwise
> since it is NOT a constant expression)
>
> I see this as very easy to understand but I could be wrong since
> I program in C since a long time and can't go back to my beginner
> years to verify that it looks coherent to a beginner)
>
> Now, I have a problem with the "once" that Ben pointed out. Should
> I generate code that initializes that ONCE?
>
> For instance I could generate code that tests a memory location to see
> if the variable is initialized or not and skip the initialization
> if it is initialized already.

You probably should do something along those lines, that's how C++ does 
it.  In C++ a function scope static variable is initialised once the 
first time the function is called.  You can use a hidden regular file 
scope static variable (which will be zero initialised) for the test.

> The whole thing comes down to the existence of an initialization
> procedures (like the C++ constructors) that would allow us to
> write:
>
> double sqrt2_over_2 = sqrt(2)/2;
> int main(void)
> {
> 	printf("%g\n",sqrt2_over_2);
> }

In C++, file scope static variables are initialised before main is 
called, so you could create a hidden function called on entry to main to 
get the same effect.

If you are adding C++ like extensions, checking and following the C++ 
rules would be a good idea.  You would be gaining the benefit of the 
work done for the C++ standard.

-- 
Ian Collins

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

#11369

Le 08/10/11 00:56, Ian Collins a écrit :
>
> In C++, file scope static variables are initialised before main is
> called, so you could create a hidden function called on entry to main to
> get the same effect.
>
> If you are adding C++ like extensions, checking and following the C++
> rules would be a good idea. You would be gaining the benefit of the work
> done for the C++ standard.
>

Yes, you are right. I think that is a heavy argument in favor of doing
it just once.

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

#11456

Hi,

Am 10/08/2011 01:53 AM, schrieb jacob navia:
> Le 08/10/11 00:56, Ian Collins a écrit :
>>
>> In C++, file scope static variables are initialised before main is
>> called, so you could create a hidden function called on entry to main to
>> get the same effect.
>>
>> If you are adding C++ like extensions, checking and following the C++
>> rules would be a good idea. You would be gaining the benefit of the work
>> done for the C++ standard.
>>
> 
> Yes, you are right. I think that is a heavy argument in favor of doing
> it just once.

Another argument of doing it like C++ is that it really enhances the
semantics of static variables. The way you currently seem to have it can
be easily emulated in standard C. Just use a definition without
initialization that is followed by an assigment.

Having "once initialized" static variables are a real advantage if this
is guaranteed to be thread safe (in some former version of C++ that I
had to deal with it wasn't). And it also plays well if you declare the
variable "const".

Jens

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

#11467

jacob navia <jacob@spamsink.net> wrote:
> Le 08/10/11 00:56, Ian Collins a ?crit :
>>
>> In C++, file scope static variables are initialised before main is
>> called, so you could create a hidden function called on entry to main to
>> get the same effect.
>>
>> If you are adding C++ like extensions, checking and following the C++
>> rules would be a good idea. You would be gaining the benefit of the work
>> done for the C++ standard.
> 
> Yes, you are right. I think that is a heavy argument in favor of doing
> it just once.

This can be surprisingly complicated in the presence of threads.  This
is what g++ has to do:

double pi()
{
  static const int p = 4 * atan (1);
  return p;
}

pi():
	subq	$8, %rsp
	cmpb	$0, guard variable for pi()::p(%rip)
	jne	.L2
	movl	guard variable for pi()::p, %edi
	call	__cxa_guard_acquire
	testl	%eax, %eax
	je	.L2
	movsd	.LC0(%rip), %xmm0
	call	atan
	mulsd	.LC1(%rip), %xmm0
	cvttsd2si	%xmm0, %eax
	movl	%eax, pi()::p(%rip)
	movl	guard variable for pi()::p, %edi
	call	__cxa_guard_release
.L2:
	cvtsi2sd	pi()::p(%rip), %xmm0
	addq	$8, %rsp
	ret

	.local	guard variable for pi()::p
	.comm	guard variable for pi()::p,8,8
	.local	pi()::p
	.comm	pi()::p,4,4

Andrew.

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

#11469

On 2011-10-10, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> This can be surprisingly complicated in the presence of threads.  This
> is what g++ has to do:
>
> double pi()
> {
>   static const int p = 4 * atan (1);

int p ? Are you in the "pi equals three" camp?

>   return p;
> }

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

#11486

Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2011-10-10, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> This can be surprisingly complicated in the presence of threads.  This
>> is what g++ has to do:
>>
>> double pi()
>> {
>>   static const int p = 4 * atan (1);
> 
> int p ? Are you in the "pi equals three" camp?

LOL!  Ya got me there.  I guess I could claim to be some kind of
biblical literalist, but I don't think that would fly.  :-)

Andrew.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web