@clivepengelly,@fake-name,@technikadonis,@cmaglie is this a solution for the problem?
Anyone willing to test this?

I still stand that the current implementation is broken, and the correct option is to have printHEXalways emit a leading zero, but that's probably not a winning opinion at this point.

Really, this seems overcomplicated. Why not just have an alternative to theHEX (maybeACTUAL_HEX? or the less-accurateHEX_LEADINGZERO suggested in the bug report) parameter, rather then redefining a bunch of methods and changing their signatures?

@fake-name ,
I do support your opinion, I'm using HEX because I want it to be with leading zero..

BUT

HEX, DEC, etc. are a bunch of predefined values indicating the base of the value (e.g. HEX = 16)
This base is used as a divider for the value, so for each "letter" printed, the value is divided by the base.

adding a strange value for the base, like ACTUAL_HEX, will be a bit odd because it will be something like: 42 which is not a base value.

I added a OPTIONAL input value which defaults to PRINT_NOARG when not assigned.
if it IS assigned it checks if the given HEX value is smaller than 16, if so, it will add a leading zero.

With this solution, old scripts can still be used :)
I think that's the whole point.. they want it to be backward compatible.

HEX, DEC, etc. are a bunch of predefined values indicating the base of the value (e.g. HEX = 16)
This base is used as a divider for the value, so for each "letter" printed, the value is divided by the base.

So change that to an enum?

Also, gah, what terrible API design.

That's what my initial plan was BUT there may be some users that did actual write the base number and so.. It won't be backward compatible.

I know, it doesnt feel right for the HEX not printing the leading zero but this was once implemented and changing it would make a small group of arduino users unhappy ;)

That's what my initial plan was BUT there may be some users that did actual write the base number and so.. It won't be backward compatible.

That's not documented, and the documentation makes no statements aboutwhatHEX,DEC, etc... actuallycontain, so they're relying on undefined behaviournow. Their code is already broken, it just coincidentally works.

In fact the documentationexplicitly states:

An optional second parameter specifies the base (format) to use; permitted values are BIN (binary, or base 2), OCT (octal, or base 8), DEC (decimal, or base 10), HEX (hexadecimal, or base 16).

So passing anythingbutBIN,OCT,DEC orHEX is incorrect.

https://www.arduino.cc/en/Serial/Print
https://www.arduino.cc/en/Serial/Println

It's kind of documented...

Ah, it's kind of crappily documented onhttps://www.arduino.cc/en/Serial/Println, the contents of which actuallycontradicthttps://www.arduino.cc/en/Serial/Print (which I'm quoting literally above).
Well, except thatprintln() then says "has the same interface asprint(). so WTF?

Siiiiiiiigh, Arduino code in a nutshell.

True 👍

Anyways,print()'s documentation explicitly enumerates the valid values forformat whenval is integral, so I'm still sticking with just change the function offormat. If you really want to keep existing behaviour, just place the new enum values in the top bits offormat. If anyone is printing in > base 64, they're sufficiently nuts that I think we can ignore them.

It's horrible, yeah, but not any more so then the implementation it's papering over top of.

@facchinm any news on this?

Some ideas/opinions/thoughts:

1. Arduino'sprint() is meant as a simple printing function rather than a fully featured formatting one, so I'm not sure adding more arguments is a good idea.
2. For more advanced formatting specifications, I think usingprintf() is a better idea. SeeAdd function "printf" to AVR core class "print" #5938 which adds support forSerial.printf().
3. Back in the day I thought of including more fields in the format specifier, like

   #define WIDTH(x) ((x)<<8) // up to 127#define SIGN (1<<7) // include +/-#define ZERO_PAD (1<<6) // pad with zeros instead of spaces#define BASE(x) (x) // up to 36Serial.print(x, WIDTH(2) | ZERO_PAD | BASE(16));

   which would allow cramming multiple format specifiers on a single argument, thus being compatible with the proposal inVariadic print #5829.
4. Maybe it is a good idea to just print UNSIGNED integers (byte, word, unsigned long) as fixed width (zero-padded), and SIGNED integers (signed char, int, long) as regular numbers with a sign (e.g.Serial.print(-15,HEX) should print-F, notFFFFFFF1; seePrint negative numbers as negative numbers regardless of base #4535). This way, a simple conversion would be enough in most cases.

@retfie , if I remember correctly,HEX is defines as 16 (By default in the original arduino code)

All committers have signed the CLA.