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

[Ben Langmuir]

> On Feb 9, 2015, at 1:03 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Mon, Feb 9, 2015 at 12:13 PM, Ben Langmuir <blangmuir at apple.com <mailto: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 <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.

Yikes.

> 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. ;]

Okay, I’ll forcibly null-terminate it, but won’t allow the errors.  Thanks for helping me figure this out :-)

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150209/fa1efeff/attachment.html>