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

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

Question about struct initializers

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

Contents

  Question about struct initializers gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-17 20:48 +0000
    Re: Question about struct initializers bart <bc@freeuk.com> - 2026-08-17 22:21 +0100
      Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:46 +0800
    Re: Question about struct initializers bixbox <noreply@example.invalid> - 2026-08-17 23:23 +0200
      Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:47 +0800
      Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-18 10:39 +0200
    Re: Question about struct initializers scott@slp53.sl.home (Scott Lurndal) - 2026-08-17 21:44 +0000
      Re: Question about struct initializers Michael S <already5chosen@yahoo.com> - 2026-08-18 01:06 +0300
        Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-18 11:11 +0200
          Re: Question about struct initializers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-18 03:58 -0700
      Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-17 22:34 +0000
        Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:39 +0800
          Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-17 23:03 +0000
            Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 11:24 +0800
            Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-18 11:19 +0200
        Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-18 11:16 +0200
        Re: Question about struct initializers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:45 +0000
          Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-19 00:08 +0000
            Re: Question about struct initializers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-19 04:32 +0000
              Re: Question about struct initializers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-18 22:34 -0700
              Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-19 12:21 +0000
                Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-19 14:33 +0200
                  Re: Question about struct initializers scott@slp53.sl.home (Scott Lurndal) - 2026-08-19 14:53 +0000
                Re: Question about struct initializers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-19 23:29 +0000
                  Re: Question about struct initializers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-19 17:43 -0700
                    Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-20 09:56 +0000
                    Re: Question about struct initializers scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 14:53 +0000
                      Re: Question about struct initializers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-20 13:34 -0700
                        Re: Question about struct initializers scott@slp53.sl.home (Scott Lurndal) - 2026-08-20 21:00 +0000
                          Re: Question about struct initializers tTh <tth@none.invalid> - 2026-08-21 05:43 +0200
                            Re: Question about struct initializers scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 14:56 +0000
                      Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-22 00:31 +0800
                Re: Question about struct initializers gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-20 02:00 +0000
                  Why are you picking on Lawrence? (was: Re: Question about struct initializers) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 13:16 +0800
                    Re: Why are you picking on Lawrence? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:24 -0700
                  Re: Question about struct initializers richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-20 10:14 +0000
                    Re: Question about struct initializers gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-20 11:54 +0000
                  Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-20 13:37 +0200
                    Re: Question about struct initializers gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-20 11:53 +0000
                      Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-20 14:42 +0200
                      Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:26 -0700
                        Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-21 09:22 +0200
                          Compiler bugs (was: Re: Question about struct initializers) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-22 00:26 +0800
                          Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-21 12:20 -0700
                            Re: Question about struct initializers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-22 05:55 +0000
                            Re: Question about struct initializers David Brown <david.brown@hesbynett.no> - 2026-08-22 13:29 +0200
                              Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-22 14:16 -0700
                              Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-22 14:17 -0700
                              Re: Question about struct initializers Michael S <already5chosen@yahoo.com> - 2026-08-23 01:23 +0300
              Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-19 12:25 -0700
                Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:07 +0800
                  Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-19 13:17 -0700
                    Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:27 +0800
                      Re: Question about struct initializers "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-20 12:21 -0700
                        Fuck you, and fuck you too (was: Re: Question about struct initializers) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 12:51 +0800
                Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-20 04:10 +0800
          Re: Question about struct initializers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-18 17:13 -0700
      Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:45 +0800
    Re: Question about struct initializers Michael S <already5chosen@yahoo.com> - 2026-08-18 01:02 +0300
      Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:35 +0800
    Re: Question about struct initializers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-18 06:32 +0800

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

#401366

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.

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

#401390

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.

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

#401408 — Compiler bugs (was: Re: Question about struct initializers)

On 21/08/2026 3:22 PM, 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.
> 

Until we run into reality.  Compilers have bugs.  Did you know Sun's C++
compiler did not support single statement extern "C"?  I'll give you an
example,

   extern "C" int foo ;

would not compile.  However,

   extern "C" { int foo ; }

would.  They completely forgot to thump their standard, back an the Sun
compiler team.  And by the time Oracle bought Sun, I had no indication
this had been fixed; and of course, the lawnmover that it is, I have no
way to know by now.

Of course, we can simply #define a buggy compiler as non-conformant, but
how does that help people running our code?  Especially if they build it
at home, and have no idea what's happening, or why it's not working?

But since this is not a group about executable binaries, I'll leave it
at that.


Happy finding compiler bugs!  How many did you find?
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401413

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.

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

#401421

On Fri, 21 Aug 2026 12:20:51 -0700, Chris M. Thomasson wrote:

> Shit. Well, still, I have a habit of trying to initialize
> everything. So, yes, I tend to write:
>
> static int g_a = 0;

I would say there is no harm in that. Shouldn’t any difference to
generated code.

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

#401424

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.

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

#401426

On 8/22/2026 4:29 AM, David Brown wrote:
> 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.

Indeed. It's just a habit I got into several decades ago.


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


:^) I wrote that because according to C std, I never needed to get into 
the habit of:

static int g_a = 0;

I could have left it as:

static int g_a;

sigh... So as the phrase goes.

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

#401427

On 8/22/2026 4:29 AM, David Brown wrote:
[...]

Fwiw, the last os used for embedded things I used was Quadros.

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

#401428

On Sat, 22 Aug 2026 13:29:42 +0200
David Brown <david.brown@hesbynett.no> wrote:

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

A cornerstone of existentialism?

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

#401330

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' };

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

#401333

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?

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401336

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?

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

#401337

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!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401364

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.

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

#401382 — Fuck you, and fuck you too (was: Re: Question about struct initializers)

On 21/08/2026 3:21 AM, Chris M. Thomasson wrote:
> 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.
> 
> 

No you don't.  "buf[4096]" lacks spaces around 4096.  It's much more
natural for humans to write

   char buf[ 4096 ] ;

because now you can see at a glance what the number is, and don't need
to copy and paste it into ChatGPT to read it aloud for you.

And "char buf[4096];" is I.D.E.-ism.  It's impossible to get I.D.Es.,
in my considerable experience, to not remove spaces inside ""s, []s, and
the like.  That's why ChatGPT, Copilot, Siri, and the like only ever
generate code without extraneous spaces for legibility purposes.[1]

So now I have conclusively proved that you 1) do not write your own
code, 2) never use a proper text editor like the pre-eminent T.E.C.O.,
Emacs -- GNU or otherwise --, or even V.I.M; 3) and always use a L.L.M.
to generate your code because you're too lasy to type.  Q.E.D.


So fuck you too!

[1] Yes, Dan Cross, I have this vocabulary, so fuck you.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401334

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 indicate this code came from
Copilot, or are you using ChatGPT to code for you these days?

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401317

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> 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?

Code in shared libraries wouldn't see local variables in main(),
but it might write to memory that's later used to store local
variables in main().  Think about a shared library's initialization
code calling a function that has its own local variables.  If main()
is guaranteed to be the first thing that's invoked, that stack space
is going to be "fresh" on the first invocation.  Shared libraries
can violate that assumption.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#401278

On 18/08/2026 5:44 AM, 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.

You fucking asshole!  You made the mistake of throwing insult my way, so
now I show you and all of comp.lang.c how utterly moronic you are.

You're an imbecile, nincompoop, and a troglodyte.


Go fucking read /21st Century C/ by Klemens, and don't dare write an-
other followup until you've learned it by heart, you fucking piece of
shit!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

#401272

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

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

#401276

On 18/08/2026 6:02 AM, Michael S wrote:
> 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.
>>
> 
> 

Thank you for thumping the standard correctly.  In my other followup I
gave a practical example of just that, using C99 and later syntax.

For some reason, I believe it was all the usual trolls, were trying to
upstage one another without actually knowing how C works, in their foll-
ow-ups.


Happy reading comp.lang.c!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

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

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

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

csiph-web