> On Feb 9, 2015, at 1:03 PM, Chandler Carruth <[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
