@maidnl@pennam see alsomain...manchoz:ArduinoCore-mbed:rm_initCallback

@maidnl@pennam see alsomain...manchoz:ArduinoCore-mbed:rm_initCallback

@manchoz are you aware of this callback being used somewhere?

Thanks@manchoz, however your PR removes completely the callback and this would brake backward compatibility (in case someone used the callback), so I would prefer to keep the callback and just make it safe.
What do you think@pennam ?

@pennam@maidnl, there is no code referring to this callback. AFAIK, it is a leftover of the early stages of the ArduinoCore-mbed.@facchinm WDYT?

isn't already impossible to use the_initializerCallback() ?eth_if would never be anullptr because is always initialized here:

@pennam, I could be wrong, but here is my understanding:
you have 3 constructors of EthernetClass (1)EthernetClass(EthernetInterface *_if), (2)EthernetClass();, (3)EthernetClass(voidPrtFuncPtr _cb)._initializerCallback() (which is pointer to function) is initialized using constructor (3) and is not related to eth_if. I agree however on the fact that eth_if could not be nullptr ever, but just because you cannot call the constructor EthernetClass(nullptr) because of the conflict between (1) and (3).
This PR is needed in all cases since _initializeCallback is not properly initialized nor there is a check for its validity when is called.

@maidnl i was thinking if it makes any sense to keep the_initializerCallback() in the code:

• using ctor 3EthernetClass(voidPrtFuncPtr _cb); the_initializerCallback() is never called becauseeth_if is always different fromnullptr
• using ctor 2EthernetClass(); same story
• using ctor 1EthernetClass(EthernetInterface *_if) you can teoretically create an Ethernet object with a nulleth_if, but you can't configure the_initializerCallback() 😞

Let's go ahead and remove it. I don't see any use case for this feature.

👍 let's go for#900

superseded by#901