Point #1:
The behavior of num2str is platform specific. On Windows machines (at least the ones I have used), num2str will truncate the display to the underlying accuracy of the number and pad 0's on the end if you request "too many" digits. On other platforms (I believe linux is one) you will get an exact conversion of the binary floating point bit pattern into decimal for as many digits as you request.
Point #2:
On those platforms that do print many more digits than 7 or 8, num2str is simply doing the exact binary floating point bit pattern conversion into decimal with no implied precision for those remaining digits in the sense you are talking about. Nothing "extra" is being passed around or retained in memory between function calls etc. It is always only a 32-bit floating point number. E.g., compare num2str(1) and num2str(1+eps). Those numbers are right next to each other in the IEEE double representation of floating point numbers. There is nothing inbetween them in this system. To see that try num2str(1+eps/2) and see what you get. A similar situation exists for the single precision numbers.
If you are on a computer that does not do the full conversion (e.g. Windows) you can use my num2strexact utility function from the FEX:
