On Mon, Feb 9, 2015 at 12:13 PM, Ben Langmuir <[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 > 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. ;]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
