and it has found an IP address.
But if ETH cable is not connected and it cannot get an IP address (e.g. via DHCP),
this function does not return an empty NUL terminated string.
Instead: it returns a NULL pointer.
But a NULL pointer is not allowed on strcpy() : it will crash and you will see the red "morse-code" LED.
Why does it give me a NULL pointer instead of a NUL terminated string?
You have to figure out on Arduino, mbed API "what works and what not".
(most of my time I waste my time to "understand" and debug the API)
The browsing in IDE does not work most of the time (no way to see hints, to go to definition or declaration). You have to figure out the hard way (trial and error).
A good programming practice is to check the returned value of your call (here your eth.get_ip_address(&ipAddr)) and not to just assume your parameter is set to anything special in case of error.
May be something like this
if (eth.get_ip_address(&ipAddr) == NSAPI_ERROR_OK) {
strcpy(KeepIPAddress, ipAddr.get_ip_address());
…
}
It’s also customary to check the validity of a pointer before using it in general, here you have a local instance of SocketAddress though, so not sure about the null pointer comment.
If the SocketAddress is not initialized, asking for the text representation of the IP address does not make sense and returning a nullptr is acceptable in my view
Sooooo.... You're complaining because you were too lazy to check what the get_ip_address() actually returned before trying to use it, and instead assumed it would work as you wanted it to? Then you further assumed strcpy would also work as you want it to, again without checking? You won't get far in programming with that approach. Do not assume things will work the way you want them to. Others will always have different ideas on how the functions they write should work. Returning NULL as an indication a function failed is a VERY common convention in c/c++, and has been for decades.
You are right, no reason to argue.
Just my concern that checking all the time for a NULL pointer, instead to assume it is a NUL terminated string - creates overhead.
I agree: if a function returns an error code - I had to verify it when called.
Oh yes, sure, this does the trick (I like it, even the performance is similar to)
if (ipAddr.get_ip_address())
strcpy(KeepIPAddress, ipAddr.get_ip_address());
else
KeepIPAddress[0] = '\0';
Actually, I do not like to call the same function twice.
Here it is OK, but when it comes to RTOS, "atomic actions" - the same function could return a different result on every call.
So, better coding style (for my feeling) is:
char *s;
s = ipAddr.get_ip_address();
if (s)
strcpy(KeepIPAddress, s);
else
KeepIPAddress[0] = '\0';
Conclusion for this "issue" (which is not a real one): I cannot make assumptions about API calls and returns. I had to check carefully all the possible conditions, e.g. returning a NULL ptr instead of a NUL-string.
When it is clearly to see in API documentation - it is obvious to handle properly.
If it is just an "assumption" what will happen - it will fail (maybe often not, just if this error happens). My mistake to "assume" how I would implement the API.
Your mistake is to not check the success of a call that is documented to provide feedback on success or not and assume you can safely use the parameter even when te call failed.
