Avoidable, potential unsafety

[197g]

On Unix the function is potentially unsafe, depending on implementation choices made in the platform provided POSIX gethostname function. In particular its documentation (man page) reads:

If the null-terminated hostname is too large to fit, then the name is truncated, and no error is returned (but see NOTES below). POSIX.1-2001 says that if such truncation occurs, then it is unspecified whether the returned buffer includes a terminating null byte.

Although glibc and Linux will both never return a successful non-nullterminated result, Apples documentation even directly specifies this possibility (edit: but doesn't seem to allow it in practice, see below). The configuration is, however, much more generic than those specific systems.

It would be safer to append a single NULL-byte manually in any case.

[thomcc]

Apples documentation seems to specify that it returns an error code it the name is truncated, unless I'm misunderstanding you.

[197g]

The returned name is null-terminated, unless insufficient space is provided.

[ENAMETOOLONG] The current host name is longer [note by me: strictly] than namelen.

Host names are limited to {HOST_NAME_MAX} characters, not including the trailing null, currently 255.

These together I understand as: A 255 byte hostname may be returned successfully but is not null terminated.

[thomcc]

I have a mac, I'll try this with a hostname of 255.

[thomcc]

Literally can't make my hostname 255 bytes on mac, it truncates to 254 bytes.

Tried both the UI and via running sethostname as superuser.

[197g]

@jD91mZM2 Would you be able to offer any insight into whether or not this could affect Redox OS?

[jD91mZM2]

Relibc, our libc implementation, does not push a trailing NUL-byte in case of length reached. Either way, one should definitely not rely on the implementation differing from the specification :)

[197g]

Redox OS also not affected by any actual issue since relibc has a limit of 65 for the hostname.

[jD91mZM2]

Ah, well spotted!

[svartalf]

This issue was addressed in 350b1bc and covered with a bunch of tests, so I'm going to close it now; thanks, everyone!