r228601 - Update r228592 for when gethostname() returns an error

[Chandler Carruth]

On Mon, Feb 9, 2015 at 12:13 PM, Ben Langmuir <blangmuir at apple.com> wrote:

> Date: Mon Feb  9 14:13:11 2015
> New Revision: 228601
>
> URL: http://llvm.org/viewvc/llvm-project?rev=228601&view=rev
> Log:
> Update r228592 for when gethostname() returns an error
>
> If gethostname() is not successful, just skip adding the hostname to the
> module hash.  And don't bother setting hostname[255] = 0, since if
> gethostname() is successful, it will be null-terminated already (and if
> it's not successful we don't read the string now.
>

Sadly, I think this still isn't enough to be pedantically correct.

The relevant specs allow for a gethostname to not return an error even when
truncation occurs, and do not require null termination when truncation
occurs. Linux (glibc at least) returns an error and set errno to either
EINVAL or ENAMETOOLONG. SUS and POSIX don't really seem to allow this to
fail...

I think the "best" approach here is:

if (gethostname(...) == 0 || errno == ENAMETOOLONG || errno == EINVAL) {
  hostname[sizeof(hostname) - 1] = 0;
  hash_combine(...);
}

But I'm fine if you refuse to handle ENAMETOOLONG or EINVAL, and just null
terminate the thing forcibly and only use it when it returns a non-error. I
don't believe it is possible for you to reach the error on Linux because
the kernel doesn't provide 256 bytes for the hostname anyways. ;]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150209/a9d90c55/attachment.html>