sdcc-user — Help and Discussion for SDCC users

Re: [Sdcc-user] What warnings would you want for array parameters

[Steve S. <ste...@gm...>]

On 12/2/25 13:22, erl...@gm... wrote:
> I get your point. Maybe some MISRA on/off og something like that could
> feasible. Whenever I do C, i check all warnings (and of course errors)
> based on the assumption that there should be no woarnings. MOst of them
> refer to some code construct that may need scrutinizing. Just my 2 cent

And even more, for some constructs that emit those warnings, most of
the time, they should be rewritten in a warning free manner.
For the very few occurence that it is by design, there should be
#pragma that can disable some warnings for a small code area.
That way we have the best of every side on the coin.

On Tue, Dec 2, 2025 at 7:56 PM Dave McGuire <mc...@ne...> wrote:
> I agree, and everything I write is compiled with -Wall too, but I
> think most people don't work that way.

And that's one of the reasons that rust feels much safer than C.
It's not only the language.
It's mostly that people are accepting warnings from the rust compiler
that they fight against in C.

Cheers
--
Steve Schnepp

Re: [Sdcc-user] What warnings would you want for array parameters

[Dave M. <mc...@ne...>]

On 12/2/25 13:22, erl...@gm... wrote:
>> > Anything the compiler can detect at compiletime should be either a > 
>> warning or an error.
>> > Coming from Ada, it seems weird that the compiler does not flag > 
>> everything it can detect at compile time. It saves so much debugging.
>>    The danger here is when the compiler flags things which aren't 
>> actually problems, which happens all the time in C.  Then warnings 
>> become annoying, then get turned off or ignored, which can cause real 
>> problems to get missed at compile time.
>>
>>    So, there is a balance to be struck here.
>
> I get your point. Maybe some MISRA on/off og something like that could 
> feasible. Whenever I do C, i check all warnings (and of course errors) 
> based on the assumption that there should be no woarnings. MOst of them 
> refer to some code construct that may need scrutinizing. Just my 2 cent

   I agree, and everything I write is compiled with -Wall too, but I 
think most people don't work that way.

              -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA

Re: [Sdcc-user] What warnings would you want for array parameters

[<erl...@gm...>]

On 01.12.2025 20.30, Dave McGuire <mc...@ne...> wrote:
> On 12/1/25 14:25, erl...@gm... wrote:
> > Anything the compiler can detect at compiletime should be either a 
> > warning or an error.
> > Coming from Ada, it seems weird that the compiler does not flag 
> > everything it can detect at compile time. It saves so much debugging.
>    The danger here is when the compiler flags things which aren't 
> actually problems, which happens all the time in C.  Then warnings 
> become annoying, then get turned off or ignored, which can cause real 
> problems to get missed at compile time.
> 
>    So, there is a balance to be struck here.
> 
>              -Dave
> 
> 
I get your point. Maybe some MISRA on/off og something like that could feasible. Whenever I do C, i check all warnings (and of course errors) based on the assumption that there should be no woarnings. MOst of them refer to some code construct that may need scrutinizing. 
Just my 2 cent
Erlo

Re: [Sdcc-user] What warnings would you want for array parameters

[Dave M. <mc...@ne...>]

On 12/1/25 14:25, erl...@gm... wrote:
> Anything the compiler can detect at compiletime should be either a 
> warning or an error.
> Coming from Ada, it seems weird that the compiler does not flag 
> everything it can detect at compile time. It saves so much debugging.
   The danger here is when the compiler flags things which aren't 
actually problems, which happens all the time in C.  Then warnings 
become annoying, then get turned off or ignored, which can cause real 
problems to get missed at compile time.

   So, there is a balance to be struck here.

             -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA

Re: [Sdcc-user] What warnings would you want for array parameters

[<erl...@gm...>]

On 26.11.2025 17.23, Philipp Klaus Krause <pk...@sp...> wrote:
> Formally, array parameters (without static) are no different from 
> pointer parameters. However, they have often been used to express the 
> intent of the parameter being an array of a certain size.
> 
> Do you have any preferences on what SDCC should do? Currently SDCC does 
> not warn (neither does clang), while GCC sometimes does:
> 
> 
> // Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds 
> test.c
> 
> void f(char a[4])
> {
>      a[4] = 7; // neither gcc nor clang warn
> }
> 
> void g(void)
> {
>      char a[3];
>      f(a); // gcc warns, clang doesn't.
>      f(0); // neither gcc nor clang warn
> }
> 
> 
> Would you like to see warnings in SDCC for any of these?
> 
> Philipp
> 
> 
> 
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 
Anything the compiler can detect at compiletime should be either a warning or an error.
Coming from Ada, it seems weird that the compiler does not flag everything it can detect at compile time. It saves so much debugging.

Erlo

Re: [Sdcc-user] [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-24 14:22:
> Am 24.11.25 um 13:54 schrieb Maarten Brock:
>> 
>> I would not qualify the stack as large for the mcs51 large & huge
>> memory models. Medium, large and huge do not place every variable in
>> the <= 248 bytes data memory, but still use it for itemps. So stack
>> space (= unallocated idata) remains very limited.
>> 
>> And when using --xstack the stack still is limited to 256 bytes pdata.
>> There is no stack implementation in xdata.
>> 
> […]
>> 
>> So my recommendation is to keep this behaviour for all targets with a
>> stack space of 256 bytes or less.
> 
> Except pdk, where despite the the stack being small, there is no point
> in omitting the promotion (and AFAIR pdk never omitted it). I'm not
> sufficiently familiar with ds390 to make changes there, so I guess for
> now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

For ds390 it would probably be OK to do the promotion as the stack space
is 1024 bytes there, IIRC.

Maarten

Re: [Sdcc-user] What warnings would you want for array parameters

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-26 17:23:
> Formally, array parameters (without static) are no different from
> pointer parameters. However, they have often been used to express the
> intent of the parameter being an array of a certain size.
> 
> Do you have any preferences on what SDCC should do? Currently SDCC
> does not warn (neither does clang), while GCC sometimes does:
> 
> 
> // Tested via gcc/clang -Wall -pedantic -Warray-parameter 
> -Warray-bounds test.c
> 
> void f(char a[4])
> {
> 	a[4] = 7; // neither gcc nor clang warn
> }
> 
> void g(void)
> {
> 	char a[3];
> 	f(a); // gcc warns, clang doesn't.
> 	f(0); // neither gcc nor clang warn
> }
> 
> 
> Would you like to see warnings in SDCC for any of these?
> 
> Philipp

I would like to see warnings for both cases.

Maarten

Re: [Sdcc-user] What warnings would you want for array parameters

[Wlodzimierz L. <wlo...@gm...>]

Agree, IMHO warning, in this case, is useful.

On Wed, Nov 26, 2025 at 5:51 PM Steve Schnepp <ste...@gm...> wrote:
>
> For me, more warnings is always better, as the lack if those is what makes C so much error prone.
>
> Any compile time check is worth a thousand runtime checks as it is mostly free.
>
> Cheers,
> --
> Steve Schnepp
>
> "A man is not dead while his name is still spoken."
>     -- T. Pratchett - Going Postal, Chapter 4 prologue
>
> On Wed, Nov 26, 2025, 17:24 Philipp Klaus Krause <pk...@sp...> wrote:
>>
>> Formally, array parameters (without static) are no different from
>> pointer parameters. However, they have often been used to express the
>> intent of the parameter being an array of a certain size.
>>
>> Do you have any preferences on what SDCC should do? Currently SDCC does
>> not warn (neither does clang), while GCC sometimes does:
>>
>>
>> // Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds
>> test.c
>>
>> void f(char a[4])
>> {
>>         a[4] = 7; // neither gcc nor clang warn
>> }
>>
>> void g(void)
>> {
>>         char a[3];
>>         f(a); // gcc warns, clang doesn't.
>>         f(0); // neither gcc nor clang warn
>> }
>>
>>
>> Would you like to see warnings in SDCC for any of these?
>>
>> Philipp
>>
>>
>>
>> _______________________________________________
>> Sdcc-user mailing list
>> Sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user



-- 
BR/Pozdrawiam. Wlodzimierz Lipert

Re: [Sdcc-user] What warnings would you want for array parameters

[Steve S. <ste...@gm...>]

For me, more warnings is always better, as the lack if those is what makes
C so much error prone.

Any compile time check is worth a thousand runtime checks as it is mostly
free.

Cheers,
--
Steve Schnepp

"A man is not dead while his name is still spoken."
    -- T. Pratchett - Going Postal, Chapter 4 prologue

On Wed, Nov 26, 2025, 17:24 Philipp Klaus Krause <pk...@sp...> wrote:

> Formally, array parameters (without static) are no different from
> pointer parameters. However, they have often been used to express the
> intent of the parameter being an array of a certain size.
>
> Do you have any preferences on what SDCC should do? Currently SDCC does
> not warn (neither does clang), while GCC sometimes does:
>
>
> // Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds
> test.c
>
> void f(char a[4])
> {
>         a[4] = 7; // neither gcc nor clang warn
> }
>
> void g(void)
> {
>         char a[3];
>         f(a); // gcc warns, clang doesn't.
>         f(0); // neither gcc nor clang warn
> }
>
>
> Would you like to see warnings in SDCC for any of these?
>
> Philipp
>
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

[Sdcc-user] What warnings would you want for array parameters

[Philipp K. K. <pk...@sp...>]

Formally, array parameters (without static) are no different from 
pointer parameters. However, they have often been used to express the 
intent of the parameter being an array of a certain size.

Do you have any preferences on what SDCC should do? Currently SDCC does 
not warn (neither does clang), while GCC sometimes does:


// Tested via gcc/clang -Wall -pedantic -Warray-parameter -Warray-bounds 
test.c

void f(char a[4])
{
	a[4] = 7; // neither gcc nor clang warn
}

void g(void)
{
	char a[3];
	f(a); // gcc warns, clang doesn't.
	f(0); // neither gcc nor clang warn
}


Would you like to see warnings in SDCC for any of these?

Philipp

Re: [Sdcc-user] [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Philipp K. K. <pk...@sp...>]

Am 24.11.25 um 13:54 schrieb Maarten Brock:
> 
> I would not qualify the stack as large for the mcs51 large & huge
> memory models. Medium, large and huge do not place every variable in
> the <= 248 bytes data memory, but still use it for itemps. So stack
> space (= unallocated idata) remains very limited.
> 
> And when using --xstack the stack still is limited to 256 bytes pdata.
> There is no stack implementation in xdata.
> 
[…]
> 
> So my recommendation is to keep this behaviour for all targets with a
> stack space of 256 bytes or less.
Except pdk, where despite the the stack being small, there is no point 
in omitting the promotion (and AFAIR pdk never omitted it). I'm not 
sufficiently familiar with ds390 to make changes there, so I guess for 
now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

Benedikt raised an interesting point regarding this: _BitInt does not 
undergo integer promotion, so by passing a _BitInt(8), one can pass a 
single byte variable argument that only uses one byte of the stack 
(except for pdk) in a standard-conforming way.

So once most users use at least C23, we can revisit this, since users do 
have a good alternative, and will then no longer have a need to omit 
promotion on char.

Philipp

Re: [Sdcc-user] [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-23 16:02:
> Currently, SDCC omits integer promotion of explictly typecast
> arguments passed as variable arguments. This is done only when the
> selected standard dialect is an SDCC variant, and the target is not a
> pdk port (see section 3.5.15 of the manual).
> 
> The feature allows to save a byte of stack space (and some code size /
> speed if pushing an 8-bit value is simpler than pushing a 16-bit one)
> when passing a char, bool or _BitInt as variable argument.
> 
> I'd like to remove support for this langauge extension from the stm8
> port, f8 port, the z80-related ports, hc08 and s08.
> 
> Rationale:
> 
> * The main benefit of the feature is saving a little bit of stack
> space. But stm8, f8, the z80-related ports, hc08, s08, and mcs51 (for
> the large and huge memory model) have a large stack (with the
> exception of some stm8 devices, the whole RAM can be used as stack).

I would not qualify the stack as large for the mcs51 large & huge
memory models. Medium, large and huge do not place every variable in
the <= 248 bytes data memory, but still use it for itemps. So stack
space (= unallocated idata) remains very limited.

And when using --xstack the stack still is limited to 256 bytes pdata.
There is no stack implementation in xdata.

> * Omitting the integer promotion violates the C standard, and could
> thus result in surprising behavior for the user. After all that cast
> is not necessarily explicitly written with intent to omit the
> promotion, the cast might come e.g. from a macro expansion.
> * The omission makes code compiled with the SDCC dialect incompatible
> with code compiled without the dialect. This results in silent
> breakage when there are calls between such code that pass explicitly
> cast variable arguments (AFAIK even if that happens within the same
> file, and there is a #pragma std_sdccXX / #pragma std_cXX in between).
> * stm8, f8, the z80-related ports, hc08, s08 do have instructions to
> efficiently push a 16-bit value onto the stack, so there is not much
> benefit in code size and speed.
> * For the z80-related ports, we do not have instructions to
> efficiently put a single 8-bit value on the stack, we instead need to
> push a 16-bit register or value, then adjust the stack pointer, so
> there typically is no or even a negative benenefit in code size and
> speed.
> 
> Philipp

So my recommendation is to keep this behaviour for all targets with a
stack space of 256 bytes or less.

Maarten

[Sdcc-user] No longer omitting the integer promotion on explicitly typecast arguments

[Philipp K. K. <pk...@sp...>]

Currently, SDCC omits integer promotion of explictly typecast arguments 
passed as variable arguments. This is done only when the selected 
standard dialect is an SDCC variant, and the target is not a pdk port 
(see section 3.5.15 of the manual).

The feature allows to save a byte of stack space (and some code size / 
speed if pushing an 8-bit value is simpler than pushing a 16-bit one) 
when passing a char, bool or _BitInt as variable argument.

I'd like to remove support for this langauge extension from the stm8 
port, f8 port, the z80-related ports, hc08 and s08.

Rationale:

* The main benefit of the feature is saving a little bit of stack space. 
But stm8, f8, the z80-related ports, hc08, s08, and mcs51 (for the large 
and huge memory model) have a large stack (with the exception of some 
stm8 devices, the whole RAM can be used as stack).
* Omitting the integer promotion violates the C standard, and could thus 
result in surprising behavior for the user. After all that cast is not 
necessarily explicitly written with intent to omit the promotion, the 
cast might come e.g. from a macro expansion.
* The omission makes code compiled with the SDCC dialect incompatible 
with code compiled without the dialect. This results in silent breakage 
when there are calls between such code that pass explicitly cast 
variable arguments (AFAIK even if that happens within the same file, and 
there is a #pragma std_sdccXX / #pragma std_cXX in between).
* stm8, f8, the z80-related ports, hc08, s08 do have instructions to 
efficiently push a 16-bit value onto the stack, so there is not much 
benefit in code size and speed.
* For the z80-related ports, we do not have instructions to efficiently 
put a single 8-bit value on the stack, we instead need to push a 16-bit 
register or value, then adjust the stack pointer, so there typically is 
no or even a negative benenefit in code size and speed.

Philipp

[Sdcc-user] Supporting parmeter forward declarations?

[Philipp K. K. <pk...@sp...>]

I am considering adding support for the most basic parameter forward 
declarations, a feature not in standard C.

Consider a parameter that is an array at least as long as the value of 
another parameter (via the C99 [static] syntax):

// OK, but some prefer the size to be the last argument.
void f(size_t i, char a[static i]);

// Not OK, size i is not known where it is used.
void f(char a[static i], size_t i);

// OK, but work for the definition only, and is not valid C23.
void f(a, i)
size_t i;
char a[static i];
{
}

// Parameter forward declaration.
void f(size_t i; char a[static i], size_t i);

IMO, parameter forward declarations are a reasonably simple feature to 
bring back support for something that C lost with K&R functions. They 
can help improve safety (making it possible to warn on passing an array 
that is too short).

I'm considering to support the most basic parameter forward declarations 
in SDCC: forward declaration of a single parameter of integer type.

Philipp

P.S.: Parameter forward declarations are quite controversial. Apple and 
large parts of the clang community are strongly opposed to this feature, 
so I don't think it will become part of a future C standard. Apple is 
pushing for an alternative approach instead:

// "dependent attributes" approach
void f(char a[static __counted_by(i)], size_t i);

The approach by Apple also applies outside of parameter declarations, 
but would substantially complicate parsing there. I don't see us 
implementing it anytime soon, and I am unsure if the proposal will be 
able to gather the necessary support to make it into the C standard.

GCC has supported parameter forward declarations since at least GCC 
3.0.1, 24 years ago. The "most basic parameter forward declarations" I 
want to support in SDCC are a subset of GCC parameter forward declarations.

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Maarten B. <sou...@ds...>]

Michael Hawkins schreef op 2025-11-15 23:33:
> Which raises a question in my mind. Are assemblers generally immune
> from this? Or are there things about assemblers that
> can also cause assembly to produce different binary when an assembler
> assembles from identical source? Because I have
> been using 8 bit assemblers for many years operating entirely under
> the assumption that, given the same source, every
> run would always produce the same binary. But, now I am wondering if
> that was ever a valid assumption. Or if it just
> happens to be the case, "most of the time".

Well, allocating uninitialized memory will do just that.
And if you then read and act upon the contents of that memory, you
should expect that different behaviour can occur.

Maarten

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Warner L. <im...@bs...>]

On Sat, Nov 15, 2025, 3:34 PM Michael Hawkins <mha...@gm...>
wrote:

> Which raises a question in my mind. Are assemblers generally immune from
> this? Or are there things about assemblers that
> can also cause assembly to produce different binary when an assembler
> assembles from identical source? Because I have
> been using 8 bit assemblers for many years operating entirely under the
> assumption that, given the same source, every
> run would always produce the same binary. But, now I am wondering if that
> was ever a valid assumption. Or if it just
> happens to be the case, "most of the time".
>

Generally, yes. They tend to be well worn so (a) no uninitialized variables
and (b) no need for randomized algorithms so the optimization pass
terminates. Plus 8-bit tends to be little more than a lookup table bolted
onto a simple parse.

Warner

-- 
> Michael A Hawkins
> Woodbury, CT 06798 USA
> Mobile: 203-550-5502
>
>
>
>
> On Sat, 2025-11-15 at 09:54 +0000, Alan Cox wrote:
> > That statement is actually incorrect.
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Michael H. <mha...@gm...>]

Which raises a question in my mind. Are assemblers generally immune from this? Or are there things about assemblers that
can also cause assembly to produce different binary when an assembler assembles from identical source? Because I have
been using 8 bit assemblers for many years operating entirely under the assumption that, given the same source, every
run would always produce the same binary. But, now I am wondering if that was ever a valid assumption. Or if it just
happens to be the case, "most of the time".

-- 
Michael A Hawkins
Woodbury, CT 06798 USA
Mobile: 203-550-5502




On Sat, 2025-11-15 at 09:54 +0000, Alan Cox wrote:
> That statement is actually incorrect.

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Alan C. <al...@et...>]

On Tue, 4 Nov 2025 10:33:33 +0100
"Eric Rullens" <go...@ds...> wrote:

> Hi Basil,
> 
> Yes, I have seen this as well. After compiling I always calculate a CRC over the entire binary, and this is not identical over compile cycles.
> 
> It has been some time since I investigated this, but Windows 10 (and 11) contain some memory protection features that are not present in Windows 7:
> 
> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/overview-of-threat-mitigations-in-windows-10#table-2
> 
> These should not influence "correct" programs, but I suspect SDCC somewhere uses uninitialized memory and/or pointers.
> 

That statement is actually incorrect. A perfectly correct C program can
compare pointers and behave differently depending whether an object is
allocated before or after another one. Memory randomisation and similar
effects can in turn change those orderings.

The classic example is lock ordering by memory address.

So whilst it might be an uninitialized value, or even deliberate
randomization there are a number of completely valid reasons around
stuff like tie breakers on sorting and so on that will also result in
behaviour varying.

Creating a program that behaves the same way under memory randomization
actually requires you follow some rigorous rules.

Alan

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Eric R. <go...@ds...>]

Yes, it definitely is the generated code that is changing.

Eric


> -----Original Message-----
> From: Wlodzimierz Lipert <wlo...@gm...>
> Sent: dinsdag 4 november 2025 15:13
> To: sdc...@li...
> Subject: Re: [Sdcc-user] Potential issues with non-deterministic compilation of
> 8051 code on W10/11?
> 
> Hi,
> 
> Are you sure its code which is chaning and not some path/timestamps etc?
> Can you try calculating checksum of CODE only?
> Check this function calc_fw_checksum, this is for stm8 but maybe you can impl.
> similar for 8051.
> https://github.com/wdl83/stm8s_relay_board_4x/blob/master/rtu_cmd.c#L35
> 
> On Tue, Nov 4, 2025 at 3:01 PM Philipp Klaus Krause <pk...@sp...> wrote:
> >
> > Am 04.11.25 um 10:33 schrieb Eric Rullens:
> > > Yes, I have seen this as well. After compiling I always calculate a
> > > CRC over the entire binary, and this is not identical over compile
> > > cycles.
> > >
> > > It has been some time since I investigated this, but Windows 10 (and
> > > 11) contain some memory protection features that are not present in
> > > Windows 7:
> > >
> > > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/
> > > windows-10/security/threat-protection/overview-of-threat-mitigations
> > > -
> > > in-windows-10#table-2
> > >
> > > These should not influence "correct" programs, but I suspect SDCC
> > > somewhere uses uninitialized memory and/or pointers.
> > >
> > > At the time I did not dig further in the problem, but if it helps I
> > > can check my notes again and recreate a test case.
> > >
> > > Eric
> > >
> >
> > If you can reproduce this in SDCC 4.5.0 or later: SDCC works mostly
> > function by function, so most SDCC issues can be reproduced within a
> > single function (basically take the affected progra, find the affected
> > function, and the check if compiling just that function (preceded by
> > any necessary declarations, macros and inline function definitions)
> > reproduces the issue - most times it does).
> > If you can find a not too big code sample to reproduce it, please open
> > a bug ticket.
> >
> > Philipp
> >
> >
> > _______________________________________________
> > Sdcc-user mailing list
> > Sdc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 
> 
> 
> --
> BR/Pozdrawiam. Wlodzimierz Lipert
> 
> 
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Eric R. <go...@ds...>]

Hi Philipp,

I did some testing using this main.c:

int sum(long a[], long b[]) __reentrant
{
  long f[1];

  f[0] = a[0] + b[0];

  return f[0] + b[0];
}

int main(void)
{
  long a = 1, b = 2;

  return sum(&a, &b);
}

Compiling with "sdcc --model-medium main.c".

Results for the following versions (all Windows binaries downloaded from SourceForge, 32-bit versions unless nothed otherwise), on a Windows 11 machine.

4.2.0-x64 gives *different* results on consecutive compile cycles.
4.3.0-x64 gives same results on consecutive compile cycles.
4.4.0 gives same results on consecutive compile cycles.
4.5.0 gives same results on consecutive compile cycles.
4.5.0-x64 gives same results on consecutive compile cycles.

The differences in the 4.2.0-x64 generated files, first few lines of the assembly listing:

Comparing files main.asm and MAIN.OLD.ASM
***** main.asm
;sloc0                     Allocated to stack - _bp +8
;sloc1                     Allocated to stack - _bp +1
;sloc2                     Allocated to stack - _bp +5
;------------------------------------------------------------
***** MAIN.OLD.ASM
;sloc0                     Allocated to stack - _bp +8
;sloc1                     Allocated to stack - _bp +4
;sloc2                     Allocated to stack - _bp +1
;------------------------------------------------------------
*****

With corresponding differences in the generated code further down the files.

To me this fits to what you described in the other email about https://sourceforge.net/p/sdcc/bugs/3772/.

So there is a problem in the (older version of the) boost library (perhaps uninitialized memory/pointer or so, perhaps giving different results with the Windows randomized memory address space layout randomization feature or so), and this seems to have been resolved with a newer version of the library.

In other words: depending on which boost version was used when SDCC was compiled, the bug could be present or not.

I do not know if it still is possible to check which boost versions were used for the mentioned SDCC packages, but other than that I would call this case closed?

 Eric


> -----Original Message-----
> From: Philipp Klaus Krause <pk...@sp...>
> Sent: dinsdag 4 november 2025 15:01
> To: sdc...@li...
> Subject: Re: [Sdcc-user] Potential issues with non-deterministic compilation of
> 8051 code on W10/11?
> 
> Am 04.11.25 um 10:33 schrieb Eric Rullens:
> > Yes, I have seen this as well. After compiling I always calculate a
> > CRC over the entire binary, and this is not identical over compile
> > cycles.
> >
> > It has been some time since I investigated this, but Windows 10 (and
> > 11) contain some memory protection features that are not present in
> > Windows 7:
> >
> > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/
> > windows-10/security/threat-protection/overview-of-threat-mitigations-
> > in-windows-10#table-2
> >
> > These should not influence "correct" programs, but I suspect SDCC
> > somewhere uses uninitialized memory and/or pointers.
> >
> > At the time I did not dig further in the problem, but if it helps I
> > can check my notes again and recreate a test case.
> >
> > Eric
> >
> 
> If you can reproduce this in SDCC 4.5.0 or later: SDCC works mostly function by
> function, so most SDCC issues can be reproduced within a single function
> (basically take the affected progra, find the affected function, and the check if
> compiling just that function (preceded by any necessary declarations, macros and
> inline function definitions) reproduces the issue - most times it does).
> If you can find a not too big code sample to reproduce it, please open a bug ticket.
> 
> Philipp
> 
> 
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Wlodzimierz L. <wlo...@gm...>]

Hi,

Are you sure its code which is chaning and not some path/timestamps etc?
Can you try calculating checksum of CODE only?
Check this function calc_fw_checksum, this is for stm8 but maybe you
can impl. similar for 8051.
https://github.com/wdl83/stm8s_relay_board_4x/blob/master/rtu_cmd.c#L35

On Tue, Nov 4, 2025 at 3:01 PM Philipp Klaus Krause <pk...@sp...> wrote:
>
> Am 04.11.25 um 10:33 schrieb Eric Rullens:
> > Yes, I have seen this as well. After compiling I always calculate a
> > CRC over the entire binary, and this is not identical over compile
> > cycles.
> >
> > It has been some time since I investigated this, but Windows 10 (and
> > 11) contain some memory protection features that are not present in
> > Windows 7:
> >
> > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/
> > windows-10/security/threat-protection/overview-of-threat-mitigations-
> > in-windows-10#table-2
> >
> > These should not influence "correct" programs, but I suspect SDCC
> > somewhere uses uninitialized memory and/or pointers.
> >
> > At the time I did not dig further in the problem, but if it helps I
> > can check my notes again and recreate a test case.
> >
> > Eric
> >
>
> If you can reproduce this in SDCC 4.5.0 or later: SDCC works mostly
> function by function, so most SDCC issues can be reproduced within a
> single function (basically take the affected progra, find the affected
> function, and the check if compiling just that function (preceded by
> any necessary declarations, macros and inline function definitions)
> reproduces the
> issue - most times it does).
> If you can find a not too big code sample to reproduce it, please open a
> bug ticket.
>
> Philipp
>
>
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user



-- 
BR/Pozdrawiam. Wlodzimierz Lipert

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Philipp K. K. <pk...@sp...>]

Am 04.11.25 um 10:33 schrieb Eric Rullens:
> Yes, I have seen this as well. After compiling I always calculate a
> CRC over the entire binary, and this is not identical over compile
> cycles.
> 
> It has been some time since I investigated this, but Windows 10 (and
> 11) contain some memory protection features that are not present in
> Windows 7:
> 
> https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/
> windows-10/security/threat-protection/overview-of-threat-mitigations-
> in-windows-10#table-2
> 
> These should not influence "correct" programs, but I suspect SDCC
> somewhere uses uninitialized memory and/or pointers.
> 
> At the time I did not dig further in the problem, but if it helps I
> can check my notes again and recreate a test case.
> 
> Eric
> 

If you can reproduce this in SDCC 4.5.0 or later: SDCC works mostly
function by function, so most SDCC issues can be reproduced within a
single function (basically take the affected progra, find the affected
function, and the check if compiling just that function (preceded by
any necessary declarations, macros and inline function definitions) 
reproduces the
issue - most times it does).
If you can find a not too big code sample to reproduce it, please open a
bug ticket.

Philipp

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Philipp K. K. <pk...@sp...>]

Am 04.11.25 um 00:13 schrieb Basil Hussain:

> Link to thread:
> https://www.eevblog.com/forum/microcontrollers/w10-sdcc-4-2-0-generates- 
> unpredictable-results-but-with-w7-all-is-fine/
> 
> Details about the situation are not forthcoming, but some of the 
> apparent facts seem to be:
> 
> - Same SDCC binaries (of v4.2.0) are being run on W7 and W10.
> - Behaviour doesn't change if SDCC executables are set to run in W7 
> compatibility mode.
> - Code size inconsistency appears to be due to differing register 
> allocations each time, which causes different code to be generated.
> 
> […]
> 
> Anyone with any thoughts on this? Perhaps a latent bug in SDCC revealed 
> by a subtle difference in behaviour of W10/11 versus W7? I know Philipp 
> has occasionally posted on EEVblog forums in the past, so perhaps he 
> could engage there?

 From the information there, I cannot track down the issue.

However, from that thread, the sdcc_diff.txt indicates that the 
difference is in the allocation of variables on the stack. That happens 
in src/SDCCsalloc.hpp. It was affected by 
https://sourceforge.net/p/sdcc/bugs/3772/, which was a  bug in the boost 
library, which might be able to cause the issues discussed.

Philipp

Re: [Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Eric R. <go...@ds...>]

Hi Basil,

Yes, I have seen this as well. After compiling I always calculate a CRC over the entire binary, and this is not identical over compile cycles.

It has been some time since I investigated this, but Windows 10 (and 11) contain some memory protection features that are not present in Windows 7:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/overview-of-threat-mitigations-in-windows-10#table-2

These should not influence "correct" programs, but I suspect SDCC somewhere uses uninitialized memory and/or pointers.

At the time I did not dig further in the problem, but if it helps I can check my notes again and recreate a test case.

 Eric


> -----Original Message-----
> From: Basil Hussain <ba...@st...>
> Sent: dinsdag 4 november 2025 00:13
> To: SDCC User Mailing List <sdc...@li...>
> Subject: [Sdcc-user] Potential issues with non-deterministic compilation of 8051
> code on W10/11?
> 
> Hi all,
> 
> This is not a problem I am personally experiencing, but I am writing to see if any
> other SDCC users/devs have any opinion on what is going on here.
> 
> On the EEVblog forums, there is thread recently started by a user who claims that
> ever since he moved his SDCC development environment from Windows 7 to
> Windows 10, his 8051 code base (for an EFM8) no longer compiles
> deterministically, which apparently causes the resultant firmware image size to
> be too large. He claims that when running the same compilation multiple times
> back-to-back on W10, the code size varies every time, but on W7 it does not.
> 
> Link to thread:
> https://www.eevblog.com/forum/microcontrollers/w10-sdcc-4-2-0-generates-
> unpredictable-results-but-with-w7-all-is-fine/
> 
> Details about the situation are not forthcoming, but some of the apparent facts
> seem to be:
> 
> - Same SDCC binaries (of v4.2.0) are being run on W7 and W10.
> - Behaviour doesn't change if SDCC executables are set to run in W7 compatibility
> mode.
> - Code size inconsistency appears to be due to differing register allocations each
> time, which causes different code to be generated.
> 
> Said user currently doesn't want to consider this might be a problem with SDCC,
> try the latest SDCC release, nor engage in any of the support avenues for SDCC
> (i.e. mailing lists or SF tickets), and seems to be spiralling off into wild theories
> alleging flawed memory allocation processes on Windows 10/11, and that now all
> his software is "untrustworthy". :-/
> 
> Anyone with any thoughts on this? Perhaps a latent bug in SDCC revealed by a
> subtle difference in behaviour of W10/11 versus W7? I know Philipp has
> occasionally posted on EEVblog forums in the past, so perhaps he could engage
> there?
> 
> Regards,
> Basil Hussain
> 
> 
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user

[Sdcc-user] Potential issues with non-deterministic compilation of 8051 code on W10/11?

[Basil H. <ba...@st...>]

Hi all,

This is not a problem I am personally experiencing, but I am writing to 
see if any other SDCC users/devs have any opinion on what is going on here.

On the EEVblog forums, there is thread recently started by a user who 
claims that ever since he moved his SDCC development environment from 
Windows 7 to Windows 10, his 8051 code base (for an EFM8) no longer 
compiles deterministically, which apparently causes the resultant 
firmware image size to be too large. He claims that when running the 
same compilation multiple times back-to-back on W10, the code size 
varies every time, but on W7 it does not.

Link to thread:
https://www.eevblog.com/forum/microcontrollers/w10-sdcc-4-2-0-generates-unpredictable-results-but-with-w7-all-is-fine/

Details about the situation are not forthcoming, but some of the 
apparent facts seem to be:

- Same SDCC binaries (of v4.2.0) are being run on W7 and W10.
- Behaviour doesn't change if SDCC executables are set to run in W7 
compatibility mode.
- Code size inconsistency appears to be due to differing register 
allocations each time, which causes different code to be generated.

Said user currently doesn't want to consider this might be a problem 
with SDCC, try the latest SDCC release, nor engage in any of the support 
avenues for SDCC (i.e. mailing lists or SF tickets), and seems to be 
spiralling off into wild theories alleging flawed memory allocation 
processes on Windows 10/11, and that now all his software is 
"untrustworthy". :-/

Anyone with any thoughts on this? Perhaps a latent bug in SDCC revealed 
by a subtle difference in behaviour of W10/11 versus W7? I know Philipp 
has occasionally posted on EEVblog forums in the past, so perhaps he 
could engage there?

Regards,
Basil Hussain