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.)
From my perspective there are two issues (which might or might not be connected):
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.
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.
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.
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.
Further posts like this will make me shut down the cc65 issue tracker altogether - be warned !
The weekend is coming, calm down...
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
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 644d623d314f0c6fa62b6ca3031ae8c658c803fc.