errno is a less-than-wonderful mechanism, agreed.
But occasionally it's useful to preserve an errno value
"just in case" it holds something that might be useful.
The O.P.'s use case doesn't make much sense to me (if
the caller cares about a pre-existing errno value, the
caller should grab it before calling other functions)...
Indeed the caller could but I consider it The Right Thing
that a function which is going to use errno should only
modify it if something went wrong. I believe it makes
things overall more tidy. I actually believe that the
standard should specify that library functions should
only modify errno if something went wrong.
Consider the Unix specific readdir() For those not familiar
with it it returns successive directory entries on a Unix
system. You first open the directory with opendir() and
then you read the files by calling readdir() again and again.
readdir() will return a NULL pointer if it encounters an error
of if there are no more files to be read. So once readdir()
returns NULL the only way to tell if it was an error or the
end of the directory is to test the value of errno. This in
turns means that if you have a loop which is meant to read
all the directory entries then you have to set errno to 0
*every* time the loop gets repeated. On the other hand if it
was guaranteed that readdir() would only modify errno if
something went wrong and your loop only called readdir() then
you would only have to set errno to 0 once before entering
the loop.
This is as an example of why I feel that a function should
only modify errno if something went wrong. It's perhaps
a stylistic preference more than anything else but I do
prefer it.