r228613
> On Feb 9, 2015, at 1:23 PM, Ben Langmuir <[email protected]> wrote:
> 
> 
>> On Feb 9, 2015, at 1:03 PM, Chandler Carruth <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> On Mon, Feb 9, 2015 at 12:13 PM, Ben Langmuir <[email protected] 
>> <mailto:[email protected]>> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to