bbbbbr

I stumbled across this issue recently, though in a slightly different form. It was with passing members of a struct that was a pointer. The things below make me wonder if this issue is specific to passing dereferenced pointer values with varargs. Context: typedef struct rtc_data_t { uint16_t day; uint8_t hour; uint8_t min; uint8_t sec; } rtc_data_t; rtc_data_t rtc; This produces output as if it is ignoring the casting to (uint8_t) and so every other %hd is zero instead of expected value printf("Day:...

HOME does have an explicit intended purpose which is not ambiguous, it is described in the SDCC manual: to locate code in a non-banked common area so it is always accessible. https://sdcc.sourceforge.net/doc/sdccman.pdf#subsubsection.4.1.3.2 Bankswitching -> Software Normally all functions you write end up in the segment CSEG. If you want a function explicitly to reside in the common area put it in segment HOME. This applies for instance to interrupt service routines as they should not be banked...

In addition to what Tony says, (in case it isn't mentioned in the discussion already) marking a function NONBANKED in a C source file allows that function to be placed in the non-banked HOME region regardless of whether that entire C source file has been assigned to a ROM bank (via the pragma). That makes such a function accessible regardless of which ROM bank is active (for gbdk at least, where HOME gets placed in a lower fixed-bank region). This is frequently used in GBDK. We are also using a patch...

In addition to what Tony says, (in case it isn't mentioned in the discussion already) marking a function NONBANKED in a C source file allows that function to be placed in the non-banked HOME region regardless of whether that entire C source file has been assigned to a ROM bank (via the pragma). That makes such a function accessible regardless of which ROM bank is active. This is frequently used in GBDK. We are also using a patch on the 6502 port for enabling that NONBANKED behavior on the NES co...

In addition to what Tony says, (in case it isn't mentioned in the discussion already) marking a function NONBANKED in a C source file allows that function to be placed in the non-banked HOME region regardless of whether that entire C source file has been assigned to a ROM bank (via the pragma). That makes such a function accessible regardless of which ROM bank is active. This is frequently used in GBDK. We are also using a patch on the 6502 port for enabling NONBANKED on the NES console.

sdasgb Fix N flag help to current behavior

Looks good. Confirming that the dependency check blocks the default boost 1.71.0 as expected on Ubuntu 20.04 and 22.04. Forcing install of boost 1.81 passes dependency checks and the resulting build does NOT crash when building the test.c example.

Thanks! Tested this out and it does appear to resolve the issue for path names with a space and 8.3 short name generation turned off. The recent build with the change does not error out under conditions where the old build does. For this comparison: -recent build is 15160 - old build is 14560