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

Created on 16 May 2019  路  8Comments  路  Source: cc65/cc65

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

bug

All 8 comments

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.

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.

  • 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?

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.

Was this page helpful?
0 / 5 - 0 ratings