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

[Ben Langmuir]

r228613
> On Feb 9, 2015, at 1:23 PM, Ben Langmuir <blangmuir at apple.com> wrote:
> 
> 
>> On Feb 9, 2015, at 1:03 PM, Chandler Carruth <chandlerc at google.com <mailto: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
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

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