Once the overflow occurs, any attempt to handle it is not guaranteed to succeed.
True, but any attempt is better than no attempt.
You need to post all of your code
Probably best if I filter it a bit, so here's a further example......
Here's the basic error message, defined in progmem to save memory....
const prog_char ACC_ERR_977[] PROGMEM = "W - So far, <%ld> good leptons, and <%ld> pseudo gauge bosons.";
and here's where I use it to create a full error message for logging....
sprintf_P(_messBuff,ACC_ERR_977,_leptons,_pgBoson);
logging(_messBuff);
The logging() function then displays it on the screen, and/or writes to SD card.
If _messBuff is say 65 characters, then this works fine until the length of _leptons and _pgBoson exceeds a total of about 8 characters, at which point _messBuff gets busted.
Another example, this from a GPS project....
const prog_char GPS_ERR_366[] PROGMEM = "E - the latitude contains non-numeric values <%s>";
sprintf_P(_messBuff,GPS_ERR_366,_gpsBuff);
logging(_messBuff);
_gpsBuff is about 80 characters (normal maximum NMEA sentence length) but should normally only be holding 9 characters when processing latitude, however, if the GPS module has decided to generate some weird sh1t which it does occasionally the length of the PROGMEM string plus the length of whatevers in the gps buffer may exceed the length of _messBuffer.
Since the overflow issue first occurred I've done what I can to check the length of all the combined elements of the message before actually creating it, but I've used this technique in literally 100s of places so I added the snippet in my original posting as an extra safety net whilst I get the underlying issues fixed.
I guess what I'm really looking for is a function that will tell me how long the string created by sprintf_P() will be before I actually use it !
Cheers