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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#11371

jacob navia <jacob@spamsink.net> 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 could be completely wrong here since I don't have your compiler
installed and thus have to rely on BartC's descriptions. But if
he's correct and I understanding his descriptions correctly a static
variable with a constant expression initializer is initialized only
once, while one with a non-constant expression initializer is set
again each time the function is called. If this is true then I
would think things might become confusing: what actually is a "con-
stant expression" can be a bit difficult to see (I have to admit
that even after a number of years using C I'm still not always
100% certain and may like to rely on the compiler to point out
the errors of my way;-)

Your

> double sqrt2_over_2 = sqrt(2)/2;

is a nice example. At the first glance, this is as constant a
value as they get, no doubts about that from a mathematical point
of view. So one would rather likely expect the compiler to "under-
stand" that I mean the quite constant value of 0.70710678... But
then the compiler might not know if I'm going to do something sneaky
like linking against a different libm where the result of sqrt(2)
is something different from 1.41421345... And thus it can't be 100%
sure it's dealing with a constant and will consider it (against
all common sense) to be an initialization with a non-constant
value.

So my point is that while the above looks like a very constant
expression and thus a user may reasonably expect it to be one,
it actually isn't one. And when you make the behaviour of a
static variable depend on what it was initialized with you might
end up with some confusion for the unsuspecting users. Consider
a function like this

double bar( void ) {
    static double sqrt2_over_2 = sqrt( 2 ) / 2;
    if ( sqrt2_over_2 == sqrt( 2 ) / 2 )
        return sqrt2_over_2;
    return sqrt2_over_2 = 42.0;
}

What I'm going to get on the first and the second invocation
(please disregard problems with floating point comparisons for
equality for the sake of the example)? Is it an initialization
with a constant value or isn't it? What is an unsuspecting
user going to expect?

Of course, all this is only relevant if the description given
by BartC is correct.

> 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.

I'm not sure what you mean with the "once" stuff - but I personally
wouldn't expect to have a static variable having set its value more
than once - ever. I.e. for

long int foo_s( ) {
    static long int r = random( );
    return r;
}

I would expect to get the same value returned each time while
with

long int foo_a( ) {
    long int r = random( );
    return r;
}

I'd expect a different value on each invocation.

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

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

#11372

"Jens Thoms Toerring" <jt@toerring.de> wrote in message 
news:9f9i99Ff4oU1@mid.uni-berlin.de...
> jacob navia <jacob@spamsink.net> wrote:

>> 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 could be completely wrong here since I don't have your compiler
> installed and thus have to rely on BartC's descriptions. But if
> he's correct and I understanding his descriptions correctly a static
> variable with a constant expression initializer is initialized only
> once, while one with a non-constant expression initializer is set
> again each time the function is called. If this is true then I
> would think things might become confusing: what actually is a "con-
> stant expression" can be a bit difficult to see

It really requires two different symbols:

 '='      to mean dynamic assignment
 '=='   (perhaps) to mean one-time initialisation

The trouble is the current usage in C uses '=' for both meanings. That might 
be OK if 'static' only ever means a one-time initialisation. But trying to 
extend the way initialisation for statics is done causes some confusion when 
just the one symbol is used for both ways.

And having a separate rule for 'constant' and 'non-constant' is not really 
workable either for the reasons you've stated. And suppose you *did* want to 
initialise multiple times with a constant?

-- 
Bartc 

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

#11389

On Fri, 07 Oct 2011 17:26:31 -0700, BartC <bc@freeuk.com> wrote:

> It really requires two different symbols:
>
>  '='      to mean dynamic assignment
>  '=='   (perhaps) to mean one-time initialisation
>
> The trouble is the current usage in C uses '=' for both meanings.

C does have different syntax to mean dynamic assignment vs. one-time
initialization. They do both use the '=' symbol, but they are easily
distinguished, both by the compiler and the programmer.

My 2 cents worth:
I definitely do not think that extending initialization of statics to
allow non-constant expressions should also imply that they should be
"initialized" more than once; that would completely ignore the concept
of "initialization".

If you want to assign a value to a static variable, use assignment!
Don't try to use initialization for a role it doesn't have.

Of course, as others have pointed out, Jacob is free to implement
this extension in the way that he thinks is most useful to his
users. This is just my opinion. I would also encourage the generation
of a warning message for this construct, unless the user explicitly
enables the feature.

Philip

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

#11351

"jacob navia" <jacob@spamsink.net> wrote in message
news:j6nkfh$3tt$1@speranza.aioe.org...
> 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?

Actually there seems to be an inconsistency with how lccwin32 handles this:

int a=1901;

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

Here, the initialisation of b seems to be done on each entry to the
function. But here:

int a=1901;

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

the initialisation of b is only done once; it doesn't get reset to 1234 on
each call.

So there is ambiguity about the construct:

  static int b = X;

which may be executed once, or N times, depending on the nature of X (or
more accurately, zero on N times).

-- 
Bartc 

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

#11364

In article <j6nkfh$3tt$1@speranza.aioe.org>, jacob navia <jacob@spamsink.net> 
wrote:

> 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?

What does it mean? Does it mean initalise the static exactly once before the 
first dynamic reference? Or does it mean initialise on every call? If the 
latter, what does that do to auto-initialising function that require a flag be 
initialised once (static bool firstcall = true)?

Allowing only initialise at load to a constant simplifies the loader and 
provides enough power to implement the other kinds of initialisation.

#define once(statement) do { \
        static bool onceflag = true; \
        if (onceflag) {onceflag = false; {statement;}} \
} while(0)

#define reinitialiseEachCall(variable,value) variable; variable=(value)

static int perfect = 6; /*simple constant initialisation*/
static double pi; once(pi = 2*atan(1));
static int reinitialiseEachCall(b, a);

-- 
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]

#11368

Le 08/10/11 01:25, China Blue Corn Chips a écrit :
> In article<j6nkfh$3tt$1@speranza.aioe.org>, jacob navia<jacob@spamsink.net>
> wrote:
>>
>> 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?
>
> What does it mean? Does it mean initalise the static exactly once before the
> first dynamic reference?

no

> Or does it mean initialise on every call?

Yes, as I have it now.

> If the
> latter, what does that do to auto-initialising function that require a flag be
> initialised once (static bool firstcall = true)?
>

That is an initialization with a compile time constant and the old
rules apply.

> Allowing only initialise at load to a constant simplifies the loader and
> provides enough power to implement the other kinds of initialisation.
>
> #define once(statement) do { \
>          static bool onceflag = true; \
>          if (onceflag) {onceflag = false; {statement;}} \
> } while(0)
>

This remains valid

> #define reinitialiseEachCall(variable,value) variable; variable=(value)
>

That also :-)

> static int perfect = 6; /*simple constant initialisation*/
> static double pi; once(pi = 2*atan(1));
> static int reinitialiseEachCall(b, a);
>

That will not work at the top level (global)

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

#11374

In article <j6o39a$678$1@speranza.aioe.org>, jacob navia <jacob@spamsink.net> 
wrote:

> That is an initialization with a compile time constant and the old
> rules apply.

Is atan(1) a constant or not? Do you really want two incompatiable semantics 
based on solely on whether I remember what is a constant expression?

> > static int perfect = 6; /*simple constant initialisation*/
> > static double pi; once(pi = 2*atan(1));
> > static int reinitialiseEachCall(b, a);
> >
> 
> That will not work at the top level (global)

#define pi (pi_())
double pi_(void) {static double pi; once(pi=2*atan(1)); return pi;}

-- 
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]

#11396

On Fri, 07 Oct 2011 21:38:28 +0200, jacob navia wrote:

>> 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?

Because it should report an error. The programmer is trying to do
something that isn't meaningful; the compiler should ideally try to warn
them, rather than (metaphorically) sniggering to itself, opening the
popcorn, and watching the programmer try to figure it out on their own.

> 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...

You're expecting too much from the programmer. E.g. assuming that they
actually understand the difference between initialisation and assignment.
Given how long you've been here, you really should know better.

Just because something is possible, that doesn't mean that it's a good
idea. E.g. if you're writing a text editor, it's quite simple to add
an option to allow tab stops to be set at something other than every eight
columns. Dealing with the consequences of such a feature is a) somewhat
less simple and b) Somebody Else's Problem (TM).

More generally, any kind of extension creates a risk of "Embrace, Extend,
Extinguish", even if that wasn't the original intention. In some cases,
the drawbacks may be outweighed by the utility. This doesn't appear to be
such a case.

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

#11412

Nobody <nobody@nowhere.com> writes:

> On Fri, 07 Oct 2011 21:38:28 +0200, jacob navia wrote:
>
>>> 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?
>
> Because it should report an error. The programmer is trying to do
> something that isn't meaningful; the compiler should ideally try to warn
> them, rather than (metaphorically) sniggering to itself, opening the
> popcorn, and watching the programmer try to figure it out on their
> own.

What's no meaningful about it?  I agree that the actual meaning that
Jacob has chosen is odd (and I think, in retrospect, he does too) but
the idea of permitting new ways to initialise a static object is not, to
me, inherently meaningless.

<snip stuff the I largely agree with>
-- 
Ben.

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

#11428

On Sat, 08 Oct 2011 22:06:00 +0100, Ben Bacarisse wrote:

>>> Besides the obvious (the standard doesn't like it) is there
>>> any reason not to do it?
>>
>> Because it should report an error. The programmer is trying to do
>> something that isn't meaningful; the compiler should ideally try to warn
>> them, rather than (metaphorically) sniggering to itself, opening the
>> popcorn, and watching the programmer try to figure it out on their
>> own.
> 
> What's no meaningful about it?  I agree that the actual meaning that
> Jacob has chosen is odd (and I think, in retrospect, he does too) but
> the idea of permitting new ways to initialise a static object is not, to
> me, inherently meaningless.

An initialisation is not an assignment. An initialisation sets the *initial*
value of the object at the point that it comes into existence. For a
static object, that point is program start, before main() is entered. At
that point, no automatic variables exist, so initialising a static object
from an automatic variable is meaningless.

An assignment sets the value of the object at the point that the
assignment statement was executed. But an initialisation isn't a
statement, and isn't "executed". For automatic variables, the distinction
is largely academic, but it's quite significant for static variables.

Sure, you can create a language where this is meaningful, but such a
language differs from C in a rather fundamental way.

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

#11433

Nobody <nobody@nowhere.com> writes:

> On Sat, 08 Oct 2011 22:06:00 +0100, Ben Bacarisse wrote:
>
>>>> Besides the obvious (the standard doesn't like it) is there
>>>> any reason not to do it?
>>>
>>> Because it should report an error. The programmer is trying to do
>>> something that isn't meaningful; the compiler should ideally try to warn
>>> them, rather than (metaphorically) sniggering to itself, opening the
>>> popcorn, and watching the programmer try to figure it out on their
>>> own.
>> 
>> What's no meaningful about it?  I agree that the actual meaning that
>> Jacob has chosen is odd (and I think, in retrospect, he does too) but
>> the idea of permitting new ways to initialise a static object is not, to
>> me, inherently meaningless.
>
> An initialisation is not an assignment. An initialisation sets the *initial*
> value of the object at the point that it comes into existence. For a
> static object, that point is program start, before main() is entered. At
> that point, no automatic variables exist, so initialising a static object
> from an automatic variable is meaningless.

That was not the original example.  I was going to say I did not spot
the change to talking about an automatic variable, but I just had a
quick look and this sub-thread seems to be all about the original
code!

> An assignment sets the value of the object at the point that the
> assignment statement was executed. But an initialisation isn't a
> statement, and isn't "executed". For automatic variables, the distinction
> is largely academic, but it's quite significant for static variables.

Nit (not germane to the point)...  Initialisations can be executed (at
least that a good way to think of some of them) and it really does
matter for automatic variables.  If int i = f(x) + g(y); is not executed
it can't mean anything useful.

> Sure, you can create a language where this is meaningful, but such a
> language differs from C in a rather fundamental way.

Given that you are talking about initialising a static with an automatic
variable, I am having trouble imagining it in any language!

To me, the crucial differences between initialisation and assignment are
(a) initialisation works for non-assignable objects (like const vars)
and (b) it happens once at the start of the object's lifetime.  Any
change to the value after that is some form of assignment.  I like to
think of both as being executed (even for static objects) -- but that's
just for simplicity of exposition.

-- 
Ben.

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

#11434

"Nobody" <nobody@nowhere.com> ha scritto nel messaggio
news:pan.2011.10.09.04.35.30.760000@nowhere.com...
> On Sat, 08 Oct 2011 22:06:00 +0100, Ben Bacarisse wrote:
>
>>>> Besides the obvious (the standard doesn't like it) is there
>>>> any reason not to do it?
>>>
>>> Because it should report an error. The programmer is trying to do
>>> something that isn't meaningful; the compiler should ideally try to warn
>>> them, rather than (metaphorically) sniggering to itself, opening the
>>> popcorn, and watching the programmer try to figure it out on their
>>> own.
>>
>> What's no meaningful about it?  I agree that the actual meaning that
>> Jacob has chosen is odd (and I think, in retrospect, he does too) but
>> the idea of permitting new ways to initialise a static object is not, to
>> me, inherently meaningless.
>
> An initialisation is not an assignment. An initialisation sets the *initial*
> value of the object at the point that it comes into existence.

so this for a is not 'a' initialization:

void  f(void){int  a;  ....}

because no one sets "the *initial* value to"  'a'
even if f() is called

> For a
> static object, that point is program start, before main() is entered. At
> that point, no automatic variables exist, so initialising a static object
> from an automatic variable is meaningless.

> An assignment sets the value of the object at the point that the
> assignment statement was executed.

so this below, for 'a', is initialzation of one assignment?

void  f(void){int  a=3;  ....}

i think one initialization

> But an initialisation isn't a
> statement, and isn't "executed". For automatic variables, the distinction
> is largely academic, but it's quite significant for static variables.
>
> Sure, you can create a language where this is meaningful, but such a
> language differs from C in a rather fundamental way.
>

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

#11452

On Sun, 9 Oct 2011 11:00:30 +0200, "io_x" <a@b.c.invalid> wrote:

snip

>so this for a is not 'a' initialization:
>
>void  f(void){int  a;  ....}
>
>because no one sets "the *initial* value to"  'a'
>even if f() is called

It is not an initialization because initialization requires an
assignment expression which is clearly not present (6.7.8).

snip

>so this below, for 'a', is initialzation of one assignment?
>
>void  f(void){int  a=3;  ....}
>
>i think one initialization

Is this legal C90/C99 or is it something added to the new draft>

-- 
Remove del for email

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

#11453

On 10/09/2011 01:56 PM, Barry Schwarz wrote:
> On Sun, 9 Oct 2011 11:00:30 +0200, "io_x" <a@b.c.invalid> wrote:
...
>> void  f(void){int  a=3;  ....}
...
> Is this legal C90/C99 or is it something added to the new draft>

I think you may have been confused by the whitespace (or lack thereof).
The only non-C feature is ...., representing the missing rest of the
body of the function. Here's the same, with a little extra white space:

    void f(void)
    {
        int a = 3;
        ....
    }
-- 
James Kuyper

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

#11463

On Sun, 09 Oct 2011 14:30:06 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 10/09/2011 01:56 PM, Barry Schwarz wrote:
>> On Sun, 9 Oct 2011 11:00:30 +0200, "io_x" <a@b.c.invalid> wrote:
>...
>>> void  f(void){int  a=3;  ....}
>...
>> Is this legal C90/C99 or is it something added to the new draft>
>
>I think you may have been confused by the whitespace (or lack thereof).
>The only non-C feature is ...., representing the missing rest of the
>body of the function. Here's the same, with a little extra white space:
>
>    void f(void)
>    {
>        int a = 3;
>        ....
>    }
Yup.  I managed to simultaneously skip over the (void) and replace the
{ with (.  Gotta learn to read slower.

-- 
Remove del for email

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

#11468

"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio 
news:von397t5o2d6tg0r9utiv49is6k7vukl9v@4ax.com...
> On Sun, 9 Oct 2011 11:00:30 +0200, "io_x" <a@b.c.invalid> wrote:
>
> snip
>
>>so this for a is not 'a' initialization:
>>
>>void  f(void){int  a;  ....}
>>
>>because no one sets "the *initial* value to"  'a'
>>even if f() is called
>
> It is not an initialization because initialization requires an
> assignment expression which is clearly not present (6.7.8).

so for you the global variable  "vii"
...
static int vii;
...
is not initilizated...
for me it is initializated to 0 even if there is no "vii=number;"

> snip
>
>>so this below, for 'a', is initialzation of one assignment?
>>
>>void  f(void){int  a=3;  ....}
>>
>>i think one initialization
>
> Is this legal C90/C99 or is it something added to the new draft>
>
> -- 
> Remove del for email 

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

#11488

On Mon, 10 Oct 2011 19:08:56 +0200, "io_x" <a@b.c.invalid> wrote:

>so for you the global variable  "vii"
>...
>static int vii;
>...
>is not initilizated...
>for me it is initializated to 0 even if there is no "vii=number;"

This behavior depends on the target environment and whether it is a
debug build, release build or the optimization level when it was
compiled. It can also depend on whether the application is being run
in a debugger or not. There is no guarantee that a variable that is
not explicitly initialized will have any particular value when
accessed. You cannot depend on this behavior. A programmer who does is
in for some unpleasant surprises.

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

#11490

On 2011-10-10, Geoff <geoff@invalid.invalid> wrote:
> On Mon, 10 Oct 2011 19:08:56 +0200, "io_x" <a@b.c.invalid> wrote:
>
>>so for you the global variable  "vii"
>>...
>>static int vii;
>>...
>>is not initilizated...
>>for me it is initializated to 0 even if there is no "vii=number;"
>
> This behavior depends on the target environment and whether it is a
> debug build, release build or the optimization level when it was
> compiled. It can also depend on whether the application is being run
> in a debugger or not. There is no guarantee that a variable that is
> not explicitly initialized will have any particular value when
> accessed. You cannot depend on this behavior. A programmer who does is
> in for some unpleasant surprises.

A static variable that is not explicitly initialized is guaranteed
to be initialized to zero.

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

#11495

On 10/10/2011 07:16 PM, Geoff wrote:
> On Mon, 10 Oct 2011 19:08:56 +0200, "io_x" <a@b.c.invalid> wrote:
...
>> static int vii;
...
> ... There is no guarantee that a variable that is
> not explicitly initialized will have any particular value when
> accessed.

Yes, there is, in section 6.7.8p10:
> If an object that has static storage duration is not initialized explicitly,
> then:
> — if it has pointer type, it is initialized to a null pointer;
> — if it has arithmetic type, it is initialized to (positive or unsigned) zero;
> — if it is an aggregate, every member is initialized (recursively) according to these rules;
> — if it is a union, the first named member is initialized (recursively) according to these
> rules.
-- 
James Kuyper

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

#11496

On Mon, 10 Oct 2011 19:08:56 +0200, "io_x" <a@b.c.invalid> wrote:

>
>"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio 
>news:von397t5o2d6tg0r9utiv49is6k7vukl9v@4ax.com...
>> On Sun, 9 Oct 2011 11:00:30 +0200, "io_x" <a@b.c.invalid> wrote:
>>
>> snip
>>
>>>so this for a is not 'a' initialization:
>>>
>>>void  f(void){int  a;  ....}
>>>
>>>because no one sets "the *initial* value to"  'a'
>>>even if f() is called
>>
>> It is not an initialization because initialization requires an
>> assignment expression which is clearly not present (6.7.8).
>
>so for you the global variable  "vii"
>...
>static int vii;
>...
>is not initilizated...
>for me it is initializated to 0 even if there is no "vii=number;"

I'm sorry; I didn't realize you wanted to play language lawyer.  In
that case, I have to ask: what difference does it make if vii is
global or has block scope?

-- 
Remove del for email

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

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

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

csiph-web