Where are WiFi.macaddress() members/overload-members documented?

[orthogonaleety]

I am just beginning with arduino, and am so rusty at C++ that I might as well be a beginner.

Including <WiFi.h> , then thanks to the arduino IDE suggestions I was able to guess that WiFi.macaddress().c_string()returned a ':' delimited string of the return type of WiFi.macaddress(), but I am not happy that I was only able to guess this through experimentation and with the help of the impressive but still limited Arduino-ide.

[*] Where precisely are WiFi.macaddress() 's members/overload-members documented please? In particular c_string()?

If someone could please provide a 'precise' location of the relevant Espressif documentation, or even a section or anchor I would appreciate it. As I have almost certainly referred to it already, but blew right passed it, or missed its implications.

[*] Or coming at this from another angle, what would be the proper way of determining or the rationale behind 'reasonably' assuming that c_string() would be a suitable method please?

Many thanks.

[lbernstone]

The documentation is lacking, but in this case the header is quite clear. If you ask for WiFi.macAddress as a *uint8_t, you get an array of 8 bit numbers (presumably 12). If you ask for macAddress as a String, you get an Arduino String. Then you can take that String and turn it into a C-style char array with c_str().
example

[orthogonaleety]

Thankyou Ibernstone, I appreciate the responce.
However, as I said I might as well be a C++ beginner and the header is not at all clear. I cannot see anywhere in your linked WiFiSTA.h that it hints that c_string() will be overloaded for macaddress in particular, or for all uint8_t. This is I suspect because it does not.
By virtue of some mechanism that I do not understand it is also the case that c_string(), at least when passed to print, println, printf, does not actually 'effect' a plain c_string anyway, rather it provides a transform to 'dd:dd:dd:dd' (or presumably a c_sting pointer to such?) . Personally I don't like to see naming conventions used in such a way, c_string should always just supply a c_string of unit8_t, if a transform is to be made available that should be under another member name, but maybe convention encourages the former?

Anyway for completeness sake I think I was closer with my second question:
[*] Or coming at this from another angle, what would be the proper way of determining or the rationale behind 'reasonably' assuming that c_string() would be a suitable method please?[/i][/color]

To which the answer is that it may be commonly known that C++ strings may not readily work when passed to methods such as printf, and that instead they may expect an older style 'c string' for which c_string() is a/the standard method of obtaining.
So from there it follows that when working with macaddress it may support c_string().

How, on earth it is that it renders 'dd:dd:dd:dd' I've still no real idea, and haven't really looked into, but that wasn't my question I suppose.

Thanks all.

[lbernstone]

What you are talking about is buried in Arduino's print() class. This is a legacy from back when Arduino was running on 8k devices and didn't have a full stdlib available. My advice is to avoid this sort of short hand unless you are really thinking about backwards portability. Use the C- and C++ standard stuff. Use printf to do your string manipulation. The String class is handy, but it is not all that efficient and encourages people to pass objects around between functions.