Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i" member of the struct got init'd to 0?
I've tested this under various conditions and it always seems to come up 0, so it seems pretty consistent.
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i" member of the struct got init'd to 0?
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i" >member of the struct got init'd to 0?
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the
"i" member of the struct got init'd to 0?
I've tested this under various conditions and it always seems to come
up 0, so it seems pretty consistent.
gazelle@shell.xmission.com (Kenny McCormack) writes:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that
the "i" member of the struct got init'd to 0?
Luck. The pages in the stack are zeroed by the operating system
before main() is invoked[*]. If this code were in a function called multiple times, then you will not be guaranteed that the 'i' field
will have any specific value.
[*] For security reasons.
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i" member of the struct got init'd to 0?
I've tested this under various conditions and it always seems to come up 0, so it seems pretty consistent.
The pages in the stack are zeroed by the operating system
before main() is invoked[*].
On Mon, 17 Aug 2026 20:48:21 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the
"i" member of the struct got init'd to 0?
Part of the language.
If automatic variable of struct type has an initializer then all
"named" fields that are not initialized explicitly are initialized to
zeros.
I've tested this under various conditions and it always seems to come
up 0, so it seems pretty consistent.
In article <PgLgS.12867$AH8e.9826@fx48.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
The pages in the stack are zeroed by the operating system
before main() is invoked[*].
On most systems they are cleared before the program is started, but
main() may not be the first thing to run; for example a dynamic
linker may load in shared libraries.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that local variables in main() would be zero.
-- Richard
gazelle@shell.xmission.com (Kenny McCormack) writes:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i"
member of the struct got init'd to 0?
Luck. The pages in the stack are zeroed by the operating system
before main() is invoked[*]. If this code were in a function called multiple times, then you will not be guaranteed that the 'i' field
will have any specific value.
[*] For security reasons.
On 17/08/2026 21:48, Kenny McCormack wrote:
Consider:
#include <stdio.h>
int main(void)
{
ÿÿÿÿ struct foo { char *name; int i; } foo = { "This is a test" };
ÿÿÿÿ printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i"
member of the struct got init'd to 0?
I've tested this under various conditions and it always seems to come
up 0,
so it seems pretty consistent.
I'm pretty sure it's part of the language. In general if you only
partially initialise an aggregate type, the remaining elements will be zeroed:
ÿ int A[10] = {1, 2};ÿÿÿÿÿÿÿÿÿÿÿ // inside a function
The last 8 elements will be zero. This is in contrast to this:
ÿ int B[10];
where the contents are undefined.
(Zeroing may or may not mean all-bits zero for floats, pointers, ints
with padding bits ... but I'm not getting into that.)
This test shows it better:
ÿ#include <stdio.h>
ÿ#include <string.h>
ÿint main() {
ÿÿÿÿ for (int i=0; i<10; ++i) {
ÿÿÿÿÿÿÿÿ int A[10] = {1, 2};
ÿÿÿÿÿÿÿÿ printf("%d %d\n", A[3], A[7]);
ÿÿÿÿÿÿÿÿ memset(A, 255, 40);
ÿÿÿÿ }
ÿ}
Output is consisently 0 0 on each loop, showing the uninitialised array elements are deliberately reset to zero each time around. Take out the initialisation, and they will be undefined first time around, then all 1s.
gazelle@shell.xmission.com (Kenny McCormack) writes:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i"
member of the struct got init'd to 0?
Are you building in debug mode? as far as I remember if I'm not wrong
debug mode initialize memory to zero or something.
bix
On 18/08/2026 6:34 AM, Richard Tobin wrote:
The pages in the stack are zeroed by the operating system
before main() is invoked[*].
On most systems they are cleared before the program is started, but
main() may not be the first thing to run; for example a dynamic
linker may load in shared libraries.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that local
variables in main() would be zero.
I can forgive that lapse in standard C knowledge, because you probably
didn't read mine nor Michael's followups before writing yours. But
now that you have, please update your C knowledge.
In article <K4MgS.476685$4Fu9.200541@fx05.ams4>,
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
On 18/08/2026 6:34 AM, Richard Tobin wrote:
The pages in the stack are zeroed by the operating system
before main() is invoked[*].
On most systems they are cleared before the program is started, but
main() may not be the first thing to run; for example a dynamic
linker may load in shared libraries.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that local
variables in main() would be zero.
I can forgive that lapse in standard C knowledge, because you probably
didn't read mine nor Michael's followups before writing yours. But
now that you have, please update your C knowledge.
I didn't make any statements about C. Please improve your reading comprehension.
gazelle@shell.xmission.com (Kenny McCormack) writes:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that the "i"
member of the struct got init'd to 0?
Are you building in debug mode? as far as I remember if I'm not wrong
debug mode initialize memory to zero or something.
On Mon, 17 Aug 2026 21:44:15 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
gazelle@shell.xmission.com (Kenny McCormack) writes:
Consider:
#include <stdio.h>
int main(void)
{
struct foo { char *name; int i; } foo = { "This is a test" };
printf("foo.name = '%s', foo.i = %d\n",foo.name,foo.i);
}
Running this generates the expected output of "This is a test" and 0.
But the question is: Is it part of the language or just luck that
the "i" member of the struct got init'd to 0?
Luck. The pages in the stack are zeroed by the operating system
before main() is invoked[*]. If this code were in a function called
multiple times, then you will not be guaranteed that the 'i' field
will have any specific value.
[*] For security reasons.
Before giving answer with such level of certainty it's recommended to
read the relevant document.
In article <PgLgS.12867$AH8e.9826@fx48.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
The pages in the stack are zeroed by the operating system
before main() is invoked[*].
On most systems they are cleared before the program is started, but
main() may not be the first thing to run; for example a dynamic
linker may load in shared libraries.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that local variables in main() would be zero.
In article <K4MgS.476685$4Fu9.200541@fx05.ams4>,
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
I didn't make any statements about C. Please improve your reading comprehension.
Indeed. The important paragraph is 6.7.9p21 in C11 (or 6.7.11p22 in
C23 - unfortunately many paragraph numbers changed a bit in C23):
"""
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage
duration.
"""
The text is basically the same from C89/C90 onwards - I have not
checked K&R.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that
local variables in main() would be zero.
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that
local variables in main() would be zero.
How would those shared libraries be seeing local variables in main(),
given that no part of main() has yet executed to pass any references
to them?
On Mon, 17 Aug 2026 22:34:32 -0000 (UTC), Richard Tobin wrote:
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that
local variables in main() would be zero.
How would those shared libraries be seeing local variables in main(),
given that no part of main() has yet executed to pass any references
to them?
In article <1162naf$26tip$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that
local variables in main() would be zero.
How would those shared libraries be seeing local variables in
main(), given that no part of main() has yet executed to pass any
references to them?
It wasn't the shared libraries themselves, but the dynamic linker
that loaded the shared libraries, though that's not important.
Running before main(), it used the stack for its own local
variables, with the result that when main() was called the stack was
no longer all zero.
On Wed, 19 Aug 2026 00:08:54 -0000 (UTC), Richard Tobin wrote:
In article <1162naf$26tip$4@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently) that
local variables in main() would be zero.
How would those shared libraries be seeing local variables in
main(), given that no part of main() has yet executed to pass any
references to them?
It wasn't the shared libraries themselves, but the dynamic linker
that loaded the shared libraries, though that's not important.
Running before main(), it used the stack for its own local
variables, with the result that when main() was called the stack was
no longer all zero.
Again, that doesn?t seem to make sense.
Checking my copy of K&R, section 1.10 ?External Variables and Scope?,
first of all it makes clear that variables local to main() are no
different to those in any other function:
The variables in `main`, such as `line`, `longest`, etc., are
private or local to `main`. Because they are declared within main,
no other function can have direct access to them. The same is true
of the variables in other functions; for example, the variable `i`
in `getline` is unrelated to the `i` in copy. Each local variable
in a function comes into existence only when the function is
called, and disappears when the function is exited. This is why
such variables are usually known as _automatic_ variables,
following terminology in other languages.
And then it says:
Because automatic variables come and go with function invocation,
they do not retain their values from one call to the next, and
must be explicitly set upon each entry. If they are not set, they
will contain garbage.
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
In article <1163bl5$2c1o2$1@dont-email.me>, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
Quite so.
I was responding to Scott's mistaken explanation of why the
trailing struct members are zero:
Luck. The pages in the stack are zeroed by the operating system
before main() is invoked
It's not luck, they're zero because they are in fact initialized, as
several people said. But Scott's explanation implies that even
uninitialized variables in main() are zero because of the operating
system zeroing the stack and main() being the first function to be
called. In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic
linker running before main().
On 19/08/2026 14:21, Richard Tobin wrote:
In article <1163bl5$2c1o2$1@dont-email.me>, Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
Quite so.
I was responding to Scott's mistaken explanation of why the
trailing struct members are zero:
Luck. The pages in the stack are zeroed by the operating system
before main() is invoked
It's not luck, they're zero because they are in fact initialized, as
several people said. But Scott's explanation implies that even
uninitialized variables in main() are zero because of the operating
system zeroing the stack and main() being the first function to be
called. In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic
linker running before main().
I think Scott was saying that uninitialised local variables often are
zero, at least for main(), rather than suggestion that they always are.
(And you are correct that some people make/made the assumption that they >were always zero, causing trouble later.)
Although he has not said as much himself, I expect that Scott replied >without reading the OP's post well enough, and jumped to the assumption
that it was talking about uninitialised local variables rather than
missing initialisers for an aggregate.
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
On 20/08/2026 3:25 AM, Chris M. Thomasson wrote:
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
The lack of spaces before and after 4096 implies this comes from
ChatGPT, or are you using Copilot now?
On 8/19/2026 1:07 PM, Johann 'Myrkraverk' Oskarsson wrote:
On 20/08/2026 3:25 AM, Chris M. Thomasson wrote:
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
The lack of spaces before and after 4096 implies this comes from
ChatGPT, or are you using Copilot now?
Huh? Are you a full blown moron, our just an idiot?
In the early days of C, this was often so, and some programs wrongly
depended on it. In some of those cases the mistake became apparent
when shared libraries were introduced, because of the dynamic linker
running before main().
On Wed, 19 Aug 2026 12:21:15 -0000 (UTC), Richard Tobin wrote:
In the early days of C, this was often so, and some programs wrongly
depended on it. In some of those cases the mistake became apparent
when shared libraries were introduced, because of the dynamic linker
running before main().
I still don?t understand the connection with dynamic linking.
In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic
linker running before main().
In article <116473r$hal8$1@artemis.inf.ed.ac.uk>,Why are you picking on Lawrence? The guy is a Python influencer, not a programmer, and now you are pretending he should know how binary code,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
...
In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic
linker running before main().
It would have been clearer (although it was certainly clear enough for
anyone with a triple digit IQ, but LDO seems not to have reached that
level) if this had been explained in terms of the introduction of the
I just did a quick experiment on Ubuntu with gcc, and found that
the same thing can happen with static libraries, using gcc's >`__attribute__((constructor))`. The discussion was about SunOS in
the mid 1980s, so things were likely different. I can imagine that,
in SunOS, dynamic linking was the only way for code to be executed
before main() is entered. Or perhaps it just became more common.
In article <116473r$hal8$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
...
In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic >>linker running before main().
It would have been clearer (although it was certainly clear enough for
anyone with a triple digit IQ, but LDO seems not to have reached that
level) if this had been explained in terms of the introduction of the
dynamic linker running before main() is called - rather than in terms of
the introduction of shared libs. Using the term "shared libraries" as a
proxy for "the dynamic linker" begat the possibility of confusion on the
part of careless readers.
And besides, it seems to me that even without either "shared libraries" or
a "dynamic linker", it has always been the case that non-main() code runs >before main is called. C is usually implemented as a bit of startup code >(often stored in crt0.lib or some such) that does stuff, then does a "call" >of "main". So that startup code could easily corrupt the (formerly
pristine) "stack".
In article <116473r$hal8$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
...
In the early days of C, this was often so, and some programs
wrongly depended on it. In some of those cases the mistake became
apparent when shared libraries were introduced, because of the dynamic
linker running before main().
It would have been clearer (although it was certainly clear enough for
anyone with a triple digit IQ, but LDO seems not to have reached that
level) if this had been explained in terms of the introduction of the
dynamic linker running before main() is called - rather than in terms of
the introduction of shared libs. Using the term "shared libraries" as a
proxy for "the dynamic linker" begat the possibility of confusion on the
part of careless readers.
And besides, it seems to me that even without either "shared libraries" or
a "dynamic linker", it has always been the case that non-main() code runs before main is called. C is usually implemented as a bit of startup code (often stored in crt0.lib or some such) that does stuff, then does a "call" of "main". So that startup code could easily corrupt the (formerly
pristine) "stack".
Note, incidentally, that "the s word" must always be enclosed in scare
quotes in this newsgroup.
(It's nice to see that your reputation as group cynic has not been
totally ruined by your clear, topical C question starting this thread!)
It certainly *could*, but as it happens in the common unix
implementations of the time it didn't. If you're interested, various
early versions of crt0.c can readily be found at www.tuhs.org. They
depend on very implementation-specific behaviour, notably declaring a
local struct variable that will happen to be at the location where the >operating system places pointers to the arguments and environment.
In article <1166ost$3dg4d$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not been
totally ruined by your clear, topical C question starting this thread!)
Heh heh. Well, somebody's got to do it.
This actually came up in real code that I was working on, and it seemed odd that it worked (*). Unless it was actually part of the language, as it now seems it is.
(*) Worked in the sense that it was always 0. Not that the code was
relying on that, of course.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
On Wed, 19 Aug 2026 12:21:15 -0000 (UTC), Richard Tobin wrote:
In the early days of C, this was often so, and some programs wrongly
depended on it. In some of those cases the mistake became apparent
when shared libraries were introduced, because of the dynamic linker
running before main().
I still don?t understand the connection with dynamic linking.
Oh? I thought it had been explained clearly enough, several times.
The idea is that dynamic linking introduced the possibility of
initialization code from dynamic libraries being invoked before
main() is called. I've already explained how this can clobber the
memory that's used for local variables when main() runs.
Without dynamic linking, main() is the first code that runs when
the program is executed. It allocates its local variables in memory
that's been zeroed by the OS.
On 20/08/2026 4:17 AM, Chris M. Thomasson wrote:
On 8/19/2026 1:07 PM, Johann 'Myrkraverk' Oskarsson wrote:
On 20/08/2026 3:25 AM, Chris M. Thomasson wrote:
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
The lack of spaces before and after 4096 implies this comes from
ChatGPT, or are you using Copilot now?
Huh? Are you a full blown moron, our just an idiot?
Thank you for confirming you never write your own code!
Happy assembly coding!
In article <1166ost$3dg4d$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not been
totally ruined by your clear, topical C question starting this thread!)
Heh heh. Well, somebody's got to do it.
This actually came up in real code that I was working on, and it seemed odd that it worked (*). Unless it was actually part of the language, as it now seems it is.
(*) Worked in the sense that it was always 0. Not that the code was
relying on that, of course.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Lawrence Dƒ??Oliveiro <ldo@nz.invalid> writes:
On Wed, 19 Aug 2026 12:21:15 -0000 (UTC), Richard Tobin wrote:
In the early days of C, this was often so, and some programs wrongly
depended on it. In some of those cases the mistake became apparent
when shared libraries were introduced, because of the dynamic linker
running before main().
I still donƒ??t understand the connection with dynamic linking.
Oh? I thought it had been explained clearly enough, several times.
The idea is that dynamic linking introduced the possibility of >>initialization code from dynamic libraries being invoked before
main() is called. I've already explained how this can clobber the
memory that's used for local variables when main() runs.
Without dynamic linking, main() is the first code that runs when
the program is executed. It allocates its local variables in memory
that's been zeroed by the OS.
Even without dynamic linking, the CRT (C Run-time) code will execute
before main() (often at a symbol called _start). I don't recall
any guarantee that the CRT code won't use the stack prior to invoking main.
scott@slp53.sl.home (Scott Lurndal) writes:
As for _start() calling main(), that wouldn't necessarily cause
an issue. There would be an issue only if some function is called
*and returns* before main() is entered.
The situation that started this subthread happened on SunOS in
the 1980s. Richard Tobin wrote:
When shared libraries were introduced in SunOS in the mid 1980s,
numerous programs including standard unix utilities had to be
corrected because they had assumed (probably inadvertently)
that local variables in main() would be zero.
Apparently the introduction of shared/dynamic libraries either
introduced the possibility of code being executed before main(),
or made it more likely.
/ Prior to starting up the program it must have a stack
/ initialized, the SLIC initialized, and its BSS cleared.
/
On 8/19/2026 1:27 PM, Johann 'Myrkraverk' Oskarsson wrote:
On 20/08/2026 4:17 AM, Chris M. Thomasson wrote:
On 8/19/2026 1:07 PM, Johann 'Myrkraverk' Oskarsson wrote:
On 20/08/2026 3:25 AM, Chris M. Thomasson wrote:
On 8/18/2026 9:32 PM, Lawrence D?Oliveiro wrote:
[...]
So there can be no assumption that the variables in main() are
initially zero, unless they are explicitly initialized that way.
char buf[4096];
vs
char buf[4096] = { '\0' };
The lack of spaces before and after 4096 implies this comes from
ChatGPT, or are you using Copilot now?
Huh? Are you a full blown moron, our just an idiot?
Thank you for confirming you never write your own code!
Sigh. I write all my own code. Its a shame that you as are you are. You should beware of the ai... Anyway, plonk.
On 8/20/2026 4:53 AM, Kenny McCormack wrote:
In article <1166ost$3dg4d$1@dont-email.me>,
David Brownÿ <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not been
totally ruined by your clear, topical C question starting this thread!)
Heh heh.ÿ Well, somebody's got to do it.
This actually came up in real code that I was working on, and it
seemed odd
that it worked (*).ÿ Unless it was actually part of the language, as
it now
seems it is.
(*) Worked in the sense that it was always 0.ÿ Not that the code was
relying on that, of course.
simply never assume that a in say:
int a;
equals zero. Its fairly simple.
On 8/20/26 23:00, Scott Lurndal wrote:
/ Prior to starting up the program it must have a stack
/ initialized, the SLIC initialized, and its BSS cleared.
/
What is the SLIC ?
On 20/08/2026 21:26, Chris M. Thomasson wrote:
On 8/20/2026 4:53 AM, Kenny McCormack wrote:
In article <1166ost$3dg4d$1@dont-email.me>,
David Brownÿ <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not beenHeh heh.ÿ Well, somebody's got to do it.
totally ruined by your clear, topical C question starting this thread!) >>>
This actually came up in real code that I was working on, and it
seemed odd
that it worked (*).ÿ Unless it was actually part of the language, as
it now
seems it is.
(*) Worked in the sense that it was always 0.ÿ Not that the code was
relying on that, of course.
simply never assume that a in say:
int a;
equals zero. Its fairly simple.
That only applies to non-static local variables.ÿ Program lifetime data
is always initialised.ÿ Code can happily rely on initialisation
happening as required by the rules of the C language.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
On Wed, 19 Aug 2026 12:21:15 -0000 (UTC), Richard Tobin wrote:
In the early days of C, this was often so, and some programs wrongly
depended on it. In some of those cases the mistake became apparent
when shared libraries were introduced, because of the dynamic linker
running before main().
I still don?t understand the connection with dynamic linking.
Oh? I thought it had been explained clearly enough, several times.
The idea is that dynamic linking introduced the possibility of
initialization code from dynamic libraries being invoked before
main() is called. I've already explained how this can clobber the
memory that's used for local variables when main() runs.
Without dynamic linking, main() is the first code that runs when
the program is executed. It allocates its local variables in memory
that's been zeroed by the OS.
Even without dynamic linking, the CRT (C Run-time) code will execute
before main() (often at a symbol called _start). I don't recall
any guarantee that the CRT code won't use the stack prior to invoking main.
On 20/08/2026 21:26, Chris M. Thomasson wrote:
On 8/20/2026 4:53 AM, Kenny McCormack wrote:
In article <1166ost$3dg4d$1@dont-email.me>,
David Brownÿ <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not beenHeh heh.ÿ Well, somebody's got to do it.
totally ruined by your clear, topical C question starting this thread!) >>>
This actually came up in real code that I was working on, and it
seemed odd
that it worked (*).ÿ Unless it was actually part of the language, as
it now
seems it is.
(*) Worked in the sense that it was always 0.ÿ Not that the code was
relying on that, of course.
simply never assume that a in say:
int a;
equals zero. Its fairly simple.
That only applies to non-static local variables.ÿ Program lifetime data
is always initialised.ÿ Code can happily rely on initialisation
happening as required by the rules of the C language.
Shit. Well, still, I have a habit of trying to initialize
everything. So, yes, I tend to write:
static int g_a = 0;
On 8/21/2026 12:22 AM, David Brown wrote:
On 20/08/2026 21:26, Chris M. Thomasson wrote:
On 8/20/2026 4:53 AM, Kenny McCormack wrote:
In article <1166ost$3dg4d$1@dont-email.me>,
David Brownÿ <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not been
totally ruined by your clear, topical C question starting this
thread!)
Heh heh.ÿ Well, somebody's got to do it.
This actually came up in real code that I was working on, and it
seemed odd
that it worked (*).ÿ Unless it was actually part of the language, as
it now
seems it is.
(*) Worked in the sense that it was always 0.ÿ Not that the code was
relying on that, of course.
simply never assume that a in say:
int a;
equals zero. Its fairly simple.
That only applies to non-static local variables.ÿ Program lifetime
data is always initialised.ÿ Code can happily rely on initialisation
happening as required by the rules of the C language.
Shit. Well, still, I have a habit of trying to initialize everything.
So, yes, I tend to write:
static int g_a = 0;
Shit happens.
On 21/08/2026 21:20, Chris M. Thomasson wrote:
On 8/21/2026 12:22 AM, David Brown wrote:
On 20/08/2026 21:26, Chris M. Thomasson wrote:
On 8/20/2026 4:53 AM, Kenny McCormack wrote:
In article <1166ost$3dg4d$1@dont-email.me>,
David Brownÿ <david.brown@hesbynett.no> wrote:
...
(It's nice to see that your reputation as group cynic has not been >>>>>> totally ruined by your clear, topical C question starting this
thread!)
Heh heh.ÿ Well, somebody's got to do it.
This actually came up in real code that I was working on, and it
seemed odd
that it worked (*).ÿ Unless it was actually part of the language,
as it now
seems it is.
(*) Worked in the sense that it was always 0.ÿ Not that the code was >>>>> relying on that, of course.
simply never assume that a in say:
int a;
equals zero. Its fairly simple.
That only applies to non-static local variables.ÿ Program lifetime
data is always initialised.ÿ Code can happily rely on initialisation
happening as required by the rules of the C language.
Shit. Well, still, I have a habit of trying to initialize everything.
So, yes, I tend to write:
static int g_a = 0;
Write that if you like - and if it makes code clearer, it can be a good thing.ÿ It is unlikely to be helpful to the reader to have an explicit
"0" initialiser, but it certainly could be if it is an enumeration
value, constexpr value, macro, or something else that is not obviously 0.
Contrary to Lawrence's answer, it typically /will/ make a difference to generated code - just one that is completely negligible in all but the smallest of embedded systems.ÿ In most of the toolchains I have used, "static int g;" goes in the ".bss" segment and gets zeroed as part of a loop, while "static int g = 0;" goes in the ".data" segment and is initialised by copying from a read-only segment of the executable.ÿ Thus
the explicit initialisation is marginally less efficient.
On the other hand, there are a few embedded toolchains (primarily those provided by Texas Instruments) which do not zero-initialise program
lifetime data that has no explicit initialisation - they do not clear
the ".bss" and "static int g;" variables before main().ÿ The misguided
fools at TI call this a "feature" leading to faster startup - users call
it a painful and deceptive flaw and non-conformity which has lead to countless problems and wasted debugging time.ÿ It has also lead some providers of portable embedded code to use explicit initialisation to 0
as you have done, giving less efficient code on platforms with more conforming tools.
Shit happens.
I get the impression that you don't understand what that phrase means.
You should stop using it - it makes no sense in the contexts you write it.
On 21/08/2026 21:20, Chris M. Thomasson wrote:
Shit happens.
I get the impression that you don't understand what that phrase
means. You should stop using it - it makes no sense in the contexts
you write it.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 9 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 245:21:35 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 83,782 |