bss-name(push, "...") doesn't work without bss-name(pop)

[ghost]

This code:

#pragma bss-name(push, "MY_BSS")
unsigned char Variable;

produces this output:

.segment	"BSS"

_Variable:
	.res	1,$00

The segment is only changed when #pragma bss-name(pop) is used, as well.

However, other #pragma ...-name(push, "...")s work fine without a pop:

#pragma rodata-name(push, "MY_RODATA")
const unsigned char Variable = 0;

.segment	"RODATA"

.segment	"MY_RODATA"
_Variable:
	.byte	$00

(Also, the current behavior makes #pragma bss-name("MY_BSS") (without the push) useless since this one cannot be popped, but omitting a pop results in the pragma being ignored.)

[oliverschmidt]

From my perspective there are two issues (which might or might not be connected):

1. As described in detail by the OP #pragma bss-name(push, "<NAME>") has no effect if the corresponding #pragma bss-name(pop) is missing. I personally would consider this a minor issue.

2. As only hinted indirectly by the OP #pragma bss-name("<NAME>") seems to have no effect at all. I personally consider this a major issue.

[ghost]

1. As described in detail by the OP `#pragma bss-name(push, "<NAME>")` has no effect if the corresponding `#pragma bss-name(pop)` is missing. I personally would consider this a minor issue.

This is not a minor issue at all. I declare variables in a certain segment, but forget to pop the segment.
I would expect the compiler to either push my variables into the segment or to inform me that I forgot a pop.
But accepting the code as valid and ignoring the push completely is definitely as much of an issue as the second case. Both create behavior that the programmer didn't intend.

[oliverschmidt]

• I don't see the need that you agree with my assessment.
• "[...]but forget to pop[...]" implies a simple workaround: Don't forget it.
• This minor issue is a minor issue because it works correctly if used correctly as documented. The major issue is a major issue because it doesn't work correctly if used correctly as documented. Simple, isn't it?

[ghost]

O.k., last reply to this:

* "[...]but forget to pop[...]" implies a simple workaround: Don't forget it.

That's what a compiler is for, isn't it? To catch syntax issues.

If you mistype a variable and the C compiler assumes that this is a new variable, PHP-style, would you also say: "There's a simple workaround: Don't make typos"?

Or if you forget a closing bracket: Is it acceptable and a "minor issue" if the compiler still compiles the code and then simply throws out everything that happened after the opening bracket, only generating an error if you happen to call a function that was declared after the problematic opening bracket?

* This minor issue is a minor issue because it works correctly if used correctly as documented.

The fact that all the other ...-name(push, ...) pragmas work even without popping them, implies that the intention is that you don't have to pop it in the end.
There's nothing in the documentation that says that you must pop a push. The push is only so that the old value gets saved to the stack so that you can pop it back if you want to:

The value may later be restored by using the pop parameter with the #pragma.
[https://cc65.github.io/doc/cc65.htm]

"May", not "must".

Hence, a push without a pop being completely ignored is exactly 100% the same severance as the other pragma without the push.

[oliverschmidt]

Further posts like this will make me shut down the cc65 issue tracker altogether - be warned !

[polluks]

The weekend is coming, calm down...

[greg-king5]

It's a puzzling consequence of Pull Request #454. .segment commands for bss variables are issued only when the segment name changes. But, for some reason that I haven't found yet, the first change is recognized only if there is a second change.

#pragma bss-name("MY_BSS")  // has no effect yet
unsigned char Variable1;
unsigned char Variable2;
unsigned char Variable3;
#pragma bss-name("MY_BSS2")  // now the first one works as desired

[greg-king5]

I had forgotten that "#pragma bss-name()" changes the name of "the current bss segment" before cc65 writes its output files. If there was only one such pragma, and it sat in the C file before the first bss variable, then there was no name change when the Assembly source file was created. I fixed it by resetting the segment name back to the original "BSS" before writing the output.

Fixed in commit 644d623.