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

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

Static Arrays Inside Functions

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

Contents

  Static Arrays Inside Functions "F. Russell" <fr@random.info> - 2019-04-27 17:52 +0000
    Re: Static Arrays Inside Functions Bart <bc@freeuk.com> - 2019-04-27 19:03 +0100
      Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-27 13:14 -0700
        Re: Static Arrays Inside Functions David Brown <david.brown@hesbynett.no> - 2019-04-28 00:10 +0200
    Re: Static Arrays Inside Functions Siri Cruise <chine.bleu@yahoo.com> - 2019-04-27 13:40 -0700
    Re: Static Arrays Inside Functions nobody@example.org (Scott) - 2019-04-28 17:26 +0000
      Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-28 11:29 -0700
        Re: Static Arrays Inside Functions nobody@example.org (Scott) - 2019-04-29 01:17 +0000
          Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-28 20:09 -0700
          Re: Static Arrays Inside Functions "F. Russell" <fr@random.info> - 2019-04-29 10:33 +0000
            Re: Static Arrays Inside Functions Bart <bc@freeuk.com> - 2019-04-29 11:49 +0100
            Re: Static Arrays Inside Functions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-04-29 04:50 -0700
            Re: Static Arrays Inside Functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-29 17:36 +0100
            Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-29 15:24 -0700
        Re: Static Arrays Inside Functions Ike Naar <ike@iceland.freeshell.org> - 2019-04-29 05:50 +0000
          Re: Static Arrays Inside Functions Ike Naar <ike@iceland.freeshell.org> - 2019-04-29 05:51 +0000
          Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-29 00:04 -0700
            Re: Static Arrays Inside Functions Ike Naar <ike@iceland.freeshell.org> - 2019-04-29 15:06 +0000
      Re: Static Arrays Inside Functions Mateusz Viste <mateusz@wont.tell> - 2019-04-28 19:20 +0000
        Re: Static Arrays Inside Functions Keith Thompson <kst-u@mib.org> - 2019-04-28 13:50 -0700
    Re: Static Arrays Inside Functions James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-29 00:44 -0400

Page 1 of 2  [1] 2  Next page →

#143495 — Static Arrays Inside Functions

I need to include a lookup table, via an array, within a library function
that will be linked to other C programs:

double some_function(...)
{
static double[100] = {55.55, 66.66, ...}
...
}

I am not sure when this array will actually be initialized.

Will the array be initialized during compile time so that the
function code contains the values?

Or will the array be initialized during the first call to the function
and thereafter remain static?

[toc] | [next] | [standalone]

#143496

On 27/04/2019 18:52, F. Russell wrote:
> I need to include a lookup table, via an array, within a library function
> that will be linked to other C programs:
> 
> double some_function(...)
> {
> static double[100] = {55.55, 66.66, ...}
> ...
> }
> 
> I am not sure when this array will actually be initialized.
> 
> Will the array be initialized during compile time so that the
> function code contains the values?
> 
> Or will the array be initialized during the first call to the function
> and thereafter remain static?
> 

At compile-time.

(Otherwise it wouldn't retain the same values on subsequent calls.)

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

#143498

Bart <bc@freeuk.com> writes:
> On 27/04/2019 18:52, F. Russell wrote:
>> I need to include a lookup table, via an array, within a library function
>> that will be linked to other C programs:
>> 
>> double some_function(...)
>> {
>> static double[100] = {55.55, 66.66, ...}

You forgot to provide a name for the array.

static double arr[100] = {55.55, 66.66, /* ... */};

The "static" keyword means that the object is created and initialized
once, during program startup.  Defining it inside a function means that
the name is visible only within the function, but the object exists and
can be accessed indirectly from anywhere (for example if the function
saves a pointer value).

>> ...
>> }
>> 
>> I am not sure when this array will actually be initialized.
>> 
>> Will the array be initialized during compile time so that the
>> function code contains the values?
>> 
>> Or will the array be initialized during the first call to the function
>> and thereafter remain static?
>
> At compile-time.

The compiler generates code that results, at run-time, in the
object being allocated and initialized before main() is invoked.
Typically a copy of the data will be included in the executable,
loaded at program startup along with the code.

> (Otherwise it wouldn't retain the same values on subsequent calls.)

In principle, the compiler could create an implicit flag so that
the initializion occurs exactly once, when the function is called
for the first time.  That would probably be conforming as long as
the visible behavior is the same, but I can't think of any good
reason to do it that way.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#143502

On 27/04/2019 22:14, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 27/04/2019 18:52, F. Russell wrote:
>>> I need to include a lookup table, via an array, within a library function
>>> that will be linked to other C programs:
>>>
>>> double some_function(...)
>>> {
>>> static double[100] = {55.55, 66.66, ...}
> 
> You forgot to provide a name for the array.
> 
> static double arr[100] = {55.55, 66.66, /* ... */};
> 
> The "static" keyword means that the object is created and initialized
> once, during program startup.  Defining it inside a function means that
> the name is visible only within the function, but the object exists and
> can be accessed indirectly from anywhere (for example if the function
> saves a pointer value).
> 
>>> ...
>>> }
>>>
>>> I am not sure when this array will actually be initialized.
>>>
>>> Will the array be initialized during compile time so that the
>>> function code contains the values?
>>>
>>> Or will the array be initialized during the first call to the function
>>> and thereafter remain static?
>>
>> At compile-time.
> 
> The compiler generates code that results, at run-time, in the
> object being allocated and initialized before main() is invoked.
> Typically a copy of the data will be included in the executable,
> loaded at program startup along with the code.
> 
>> (Otherwise it wouldn't retain the same values on subsequent calls.)
> 
> In principle, the compiler could create an implicit flag so that
> the initializion occurs exactly once, when the function is called
> for the first time.  That would probably be conforming as long as
> the visible behavior is the same, but I can't think of any good
> reason to do it that way.
> 

C++ handles function-local statics that way, but their initialisers 
don't need to be known at compile time as they do in C.  It is not as 
simple as just having a flag, since this needs to work even if the 
function is called from multiple threads at about the same time.

The only advantage you might have in C for initialising this way is if 
you had a function that might not be called at all during a run of the 
program, and a static variable that was so big the initialisation time 
was significant.  I doubt if that is common enough for compilers to 
handle it.

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

#143499

In article <qa24so02brf@news3.newsguy.com>, "F. Russell" <fr@random.info> 
wrote:

> I am not sure when this array will actually be initialized.

Suffice to say it will be initialised once, before any reference to it, and it 
will retain the initialised/last assigned values between function invocations.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
The first law of discordiamism: The more energy   This post         / \
to make order is nore energy made into entropy.   insults Islam.  Mohammed

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

#143512

On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:

>Will the array be initialized during compile time so that the
>function code contains the values?

Not to belabor the obvious related issue, but if you have *any*
initialized variable, where would you expect those initializing values
to be stored if not in the object code?

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

#143513

nobody@example.org (Scott) writes:
> On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:
>>Will the array be initialized during compile time so that the
>>function code contains the values?
>
> Not to belabor the obvious related issue, but if you have *any*
> initialized variable, where would you expect those initializing values
> to be stored if not in the object code?

    {
        int r = rand();
        time_t now = time(NULL);
    }

The initial values of r and now are not stored in the object code.
They're computed at run time.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#143518

On Sun, 28 Apr 2019 11:29:14 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>nobody@example.org (Scott) writes:
>> On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:
>>>Will the array be initialized during compile time so that the
>>>function code contains the values?
>>
>> Not to belabor the obvious related issue, but if you have *any*
>> initialized variable, where would you expect those initializing values
>> to be stored if not in the object code?
>
>    {
>        int r = rand();
>        time_t now = time(NULL);
>    }
>
>The initial values of r and now are not stored in the object code.
>They're computed at run time.

A fair point, but those aren't initializing *values*, are they? And
that's not quite what I was getting at in any case.

Most programmers would quickly intuit that object code must
necessarily contain all the information it needs for all of its
initializations. I was curious about the thinking behind the question
of whether the "code contains the values", wondering where that line
of thinking might lead.

You'll have to forgive me though. I've had a lot of IRL contact with
beginner programmers lately, and some of them have some truly baffling
notions.

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

#143519

nobody@example.org (Scott) writes:
> On Sun, 28 Apr 2019 11:29:14 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>>nobody@example.org (Scott) writes:
>>> On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:
>>>>Will the array be initialized during compile time so that the
>>>>function code contains the values?
>>>
>>> Not to belabor the obvious related issue, but if you have *any*
>>> initialized variable, where would you expect those initializing values
>>> to be stored if not in the object code?
>>
>>    {
>>        int r = rand();
>>        time_t now = time(NULL);
>>    }
>>
>>The initial values of r and now are not stored in the object code.
>>They're computed at run time.
>
> A fair point, but those aren't initializing *values*, are they? And
> that's not quite what I was getting at in any case.

I don't know what you mean.  Certainly the evalutions of the expressions
`rand()` and `time(NULL)` yield values, and those values are stored in
objects.

> Most programmers would quickly intuit that object code must
> necessarily contain all the information it needs for all of its
> initializations. I was curious about the thinking behind the question
> of whether the "code contains the values", wondering where that line
> of thinking might lead.

For a static object with an initializer, typically the object code will
contain something like a copy of the value that is to be stored in the
object.  The object code is of course generated at compile time.  The
value is copied into the object at load time (after the program starts
and before main() is entered).

For any object with an initializer, the compiler generates code that
results in the object being initialized during execution.  The
relationship between that code and the initial values can be very
straightforward or not.

> You'll have to forgive me though. I've had a lot of IRL contact with
> beginner programmers lately, and some of them have some truly baffling
> notions.

And I'm probably not saying anything you don't already know.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#143524

On Mon, 29 Apr 2019 01:17:21 +0000, Scott wrote:

> 
> Most programmers would quickly intuit that object code must
> necessarily contain all the information it needs for all of its
> initializations.
>

The C language requires more than just simple intuition.  Save
that for BASIC or even .NET.

Arrays in C, if not explicitly allocated with malloc(), are
placed on the stack.  But a static array within a function
has to stored differently and most likely that storage location
is the data segment of the final executable.  Does the linker
which joins the function object file with the final executable
include them in the data segment?

My question concerns whether or not these values are "ready to go"
at run time.  That is, upon a first call to the function, are
these values immediately accessible or is there an initial
setup required.  This may make a difference if the array is
very large.

An answer likely requires knowledge of, on GNU/Linux, the
ELF file format and the linker/loader process.

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

#143525

On 29/04/2019 11:33, F. Russell wrote:
> On Mon, 29 Apr 2019 01:17:21 +0000, Scott wrote:
> 
>>
>> Most programmers would quickly intuit that object code must
>> necessarily contain all the information it needs for all of its
>> initializations.
>>
> 
> The C language requires more than just simple intuition.  Save
> that for BASIC or even .NET.
> 
> Arrays in C, if not explicitly allocated with malloc(), are
> placed on the stack.  But a static array within a function
> has to stored differently and most likely that storage location
> is the data segment of the final executable.  Does the linker
> which joins the function object file with the final executable
> include them in the data segment?
> 
> My question concerns whether or not these values are "ready to go"
> at run time.  That is, upon a first call to the function, are
> these values immediately accessible or is there an initial
> setup required.  This may make a difference if the array is
> very large.
> 
> An answer likely requires knowledge of, on GNU/Linux, the
> ELF file format and the linker/loader process.
>


So, what answer are you looking for? The replies in the thread suggest 
that a compiler /could/ do just about anything, provided the end result 
in the program is the same.

But also that compilers /probably/ just write an object file with the 
static data already defined in a .data segment. Then no setup is 
required, and the data is ready to do'.

Here's an example similar to yours (not using doubles as the output for 
double confusingly represents floats as integer bit patterns):

     void somefunction(void) {
         static int table[] = {10,20,30,40,50,60};
     }

And here's the ASM output from a simple C compiler:

     segment   idata
     align     4
`somefunction.table.1:
     dd        10
     dd        20
     dd        30
     dd        40
     dd        50
     dd        60

     segment   code

`somefunction::          # start of the function code

That's one implementation. To find out what happens with any other, you 
will have to investigate each one.

What problem are you trying to solve?

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

#143526

On Monday, 29 April 2019 11:34:03 UTC+1, F. Russell  wrote:
> On Mon, 29 Apr 2019 01:17:21 +0000, Scott wrote:
> 
> > 
> > Most programmers would quickly intuit that object code must
> > necessarily contain all the information it needs for all of its
> > initializations.
> >
> 
> The C language requires more than just simple intuition.  Save
> that for BASIC or even .NET.
> 
> Arrays in C, if not explicitly allocated with malloc(), are
> placed on the stack.  But a static array within a function
> has to stored differently and most likely that storage location
> is the data segment of the final executable.  Does the linker
> which joins the function object file with the final executable
> include them in the data segment?
> 
> My question concerns whether or not these values are "ready to go"
> at run time.  That is, upon a first call to the function, are
> these values immediately accessible or is there an initial
> setup required.  This may make a difference if the array is
> very large.
> 
> An answer likely requires knowledge of, on GNU/Linux, the
> ELF file format and the linker/loader process.
>
C was designed so that the compiler would be easy to write. Thus there
is usually a simple mapping of C to an abstract machine code, and,
assuming that the code cannot be aggressively optimised, a programmer
who knows an assembly language should have a pretty good idea what
code will be generated.

In the case of a static array, you do need a bit more information. Clearly
the initial values will have to exist in the executable as literals. But
firstly, are the values modified or not, secondly, is RAM faster than
ROM, thirdly, does the system allow embedded literals to be modified
in place? These can all affect your answer.
However it is unlikely that if the initial literals are copied to a
RAM location before use, this will be done on first call of the function.
For on thing, that creates a chicken and egg problem because presumably
you need a flag to indicate whether the function has been called or not,
which itself is initialised to zero. It is likely that, on such a system,
there is a step on program launch which copies all the ROM data to RAM,
in one tight loop.
 

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

#143529

"F. Russell" <fr@random.info> writes:

> On Mon, 29 Apr 2019 01:17:21 +0000, Scott wrote:
>
>> 
>> Most programmers would quickly intuit that object code must
>> necessarily contain all the information it needs for all of its
>> initializations.
>>
>
> The C language requires more than just simple intuition.  Save
> that for BASIC or even .NET.
>
> Arrays in C, if not explicitly allocated with malloc(), are
> placed on the stack.

There is, in most implementations, a third "location" but the language
standard makes not mention of /where/ things are stored.  It cares only
about the storage duration of objects.

> But a static array within a function
> has to stored differently and most likely that storage location
> is the data segment of the final executable.

By the way, the fact that the static array is declared inside a function
will be, for most implementations, a red herring.  It could be taken
into account, but I've never used a C implementation where it was.

Objects in C (which includes arrays) have either automatic, allocated,
static or thread storage duration.  Arrays with automatic storage
duration will almost certainly be stored on the stack, but some machines
don't have "a stack" so they will have to be stored in some other way
that gives the right behaviour.

Objects with static storage duration will almost certainly be
represented directly in the executable, but those that are
zero-initialised are often given special treatment.  However, provided
the observable behaviour of the program is as the language mandates, the
implementation can do pretty much anything.  For example, it may
optimise the object away altogether!

<cut>
> My question concerns whether or not these values are "ready to go"
> at run time.  That is, upon a first call to the function, are
> these values immediately accessible or is there an initial
> setup required.  This may make a difference if the array is
> very large.

The problem is that the language specification does not say.  It is
almost inconceivable that the values will not be simply loaded when the
executable is read or mapped, but that's something the language makes no
comment on.

It seems likely that you are concerned that there may be a cost
difference between a static array declared at file scope (outside of all
functions) and one declared inside a function.  If that is the case,
don't worry.  Every implementation I've seen makes no distinction
between them (except of course for the scope of the name).

<cut>
-- 
Ben.

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

#143531

"F. Russell" <fr@random.info> writes:
> On Mon, 29 Apr 2019 01:17:21 +0000, Scott wrote:
>> Most programmers would quickly intuit that object code must
>> necessarily contain all the information it needs for all of its
>> initializations.
> 
> The C language requires more than just simple intuition.  Save
> that for BASIC or even .NET.
>
> Arrays in C, if not explicitly allocated with malloc(), are
> placed on the stack.  But a static array within a function
> has to stored differently and most likely that storage location
> is the data segment of the final executable.  Does the linker
> which joins the function object file with the final executable
> include them in the data segment?

That makes it sound like there's a default way to store array
objects.  There isn't.

A named array object defined outside any function, or defined
inside a function with the "static" keyword, has static storage
duration (it's created at program startup and exists until the
program terminates).  Any other named array object (defined inside
a function without "static") has automatic storage duration; its
lifetime ends at the end of the smallest block that encloses its
definition.  The latter is typically implemented via a "stack",
though the standard doesn't use that term.

A static object with an initialization typically has a bit-for-bit
copy in the executable file, and when the executable is loaded
during program startup, the memory region into which that copy is
loaded is the object.  A static object without an initialization is
initialized to zero; rather than wasting space in the executable
file with a bunch of zero bytes, it typically just specifies the
length; the runtime system takes care of creating and zeroing the
object during program startup.  None of this is specified by the
C standard, which only says how the program must behave.

(I'm glossing over the fact that "zero" for pointer and
floating-point types is not required to be all-bits-zero.  In most
implementations it is, and compilers are free to take advantage
of that.  In a hypothetical implementation where the null pointer
is represented as 0xFFFFFFFF, a static array of pointers with no
explicit initialization might require more work to set it up.)

> My question concerns whether or not these values are "ready to go"
> at run time.  That is, upon a first call to the function, are
> these values immediately accessible or is there an initial
> setup required.  This may make a difference if the array is
> very large.

If a function definition contains a static array definition, that
object will be "ready to go" before the function is ever called --
in principle, even before main() is called.  There may be an initial
setup, but it happens before any of your program code is executed.

> An answer likely requires knowledge of, on GNU/Linux, the
> ELF file format and the linker/loader process.

That knowledge is required if you want to know the details of how the
behavior is implemented, but the behavior itself is specified by the C
standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#143521

On 2019-04-28, Keith Thompson <kst-u@mib.org> wrote:
>     {
>         int r = rand();
>         time_t now = time(NULL);
>     }
>
> The initial values of r and now are not stored in the object code.
> They're computed at run time.

The subject is 'static arrays inside functions'.

  #include <stdlib.h>

  int main(void)
  {
    static int a[1] = {rand()};
    return 0;
  }

a.c:5:22: error: initializer element is not constant.

N12570:
6.7.9 Initialization
[...]
Constraints
[...]
4 All the expressions in an initializer for an object that has static or
  thread storage duration shall be constant expressions or string literals.

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

#143522

On 2019-04-29, Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2019-04-28, Keith Thompson <kst-u@mib.org> wrote:
>>     {
>>         int r = rand();
>>         time_t now = time(NULL);
>>     }
>>
>> The initial values of r and now are not stored in the object code.
>> They're computed at run time.
>
> The subject is 'static arrays inside functions'.
>
>   #include <stdlib.h>
>
>   int main(void)
>   {
>     static int a[1] = {rand()};
>     return 0;
>   }
>
> a.c:5:22: error: initializer element is not constant.
>
> N12570:

Typo, that should be N1570

> 6.7.9 Initialization
> [...]
> Constraints
> [...]
> 4 All the expressions in an initializer for an object that has static or
>   thread storage duration shall be constant expressions or string literals.

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

#143523

Ike Naar <ike@iceland.freeshell.org> writes:
> On 2019-04-28, Keith Thompson <kst-u@mib.org> wrote:
>>     {
>>         int r = rand();
>>         time_t now = time(NULL);
>>     }
>>
>> The initial values of r and now are not stored in the object code.
>> They're computed at run time.
>
> The subject is 'static arrays inside functions'.

Yes, I know that's the subject of the thread, but I was responding
to this statement:

    Not to belabor the obvious related issue, but if you have *any*
    initialized variable, where would you expect those initializing values
    to be stored if not in the object code?

(which you snipped).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#143528

On 2019-04-29, Keith Thompson <kst-u@mib.org> wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>> On 2019-04-28, Keith Thompson <kst-u@mib.org> wrote:
>>>     {
>>>         int r = rand();
>>>         time_t now = time(NULL);
>>>     }
>>>
>>> The initial values of r and now are not stored in the object code.
>>> They're computed at run time.
>>
>> The subject is 'static arrays inside functions'.
>
> Yes, I know that's the subject of the thread, but I was responding
> to this statement:
>
>     Not to belabor the obvious related issue, but if you have *any*
>     initialized variable, where would you expect those initializing values
>     to be stored if not in the object code?
>
> (which you snipped).

Ah, now I see. I took "*any* initialized variable" as "a variable (with
static duration) of any type, not just array type". You took it one step
further and also considered variables without static duration.

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

#143514

On Sun, 28 Apr 2019 17:26:27 +0000, Scott wrote:
> On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:
> 
>>Will the array be initialized during compile time so that the function
>>code contains the values?
> 
> Not to belabor the obvious related issue, but if you have *any*
> initialized variable, where would you expect those initializing values
> to be stored if not in the object code?

"easy" initializations could just as well be initialized by the compiler 
at run-time, when the program starts, instead of storing kilobytes of 
zero bytes or so inside the executable.

Mateusz

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

#143516

Mateusz Viste <mateusz@wont.tell> writes:
> On Sun, 28 Apr 2019 17:26:27 +0000, Scott wrote:
>> On 27 Apr 2019 17:52:24 GMT, "F. Russell" <fr@random.info> wrote:
>>>Will the array be initialized during compile time so that the function
>>>code contains the values?
>> 
>> Not to belabor the obvious related issue, but if you have *any*
>> initialized variable, where would you expect those initializing values
>> to be stored if not in the object code?
>
> "easy" initializations could just as well be initialized by the compiler 
> at run-time, when the program starts, instead of storing kilobytes of 
> zero bytes or so inside the executable.

Right.  Typically if you have these definitions at file scope:

    char zero[1024];
    char non_zero[1024] = { /* 1024 values here */ };

you'll have 1024 bytes of data in the object file holding the
initialized value for `non_zero`, and small amount of information
causing 1024 bytes to be allocated and zeroed for `zero`.

A small quibble: it's not "initialized by the compiler at run-time".
At run-time, the compiler is not running, and might not even exist
on the system.  The compiler generates code that causes allocation
and initialization to occur at load time and/or at run time.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web