IRC channel logs
2025-03-01.log
back to list of logs
<crupest>The aid of removing MAXHOSTNAMELEN in Neal's xgethostname seems to rely on a glibc extension that gethostname will set errno to ENAMETOOLONG when buffer is not big enough. POSIX does not specifies that. Maybe we should at least add a platform macro guard? <crupest>I found a lot of path-related function in POSIX is not really nice to dynamic buffer allocation. Because they behave differently in this situation. I can't know whether it is the buffer small or there is other errno. <youpi>perhaps just test if the length of the returned name is equal to the size <crupest>readlink is OK. But gethostname returns only 0 and -1 <crupest>In POSIX "No errors are defined." for gethostname <crupest>"Host names are limited to {HOST_NAME_MAX} bytes." <crupest>But I remember hostname has a specification on what format is valid of it. <crupest>Whatever, I'll just detect if it is glibc and guard with it. For other platforms, do whatever they want. <youpi>you can use the same implementation in both cases <crupest>It returns only 0 or -1. No errno. And "except that if namelen is an insufficient length to hold the host name, then the returned name shall be truncated and it is unspecified whether the returned name is null-terminated" <crupest>Being strict to the standard, I don't think there is a way to test length. <crupest>I'll also check the glibc implementation. <crupest>Ah. Both glibc and musl are using uname to implement gethostname <crupest>And utsname.nodename has a fixed length of _UTSNAME_NODENAME_LENGTH, aka 65 on every platforms. So I guess use the value from sysconf should be good enough. <crupest>Can't believe PAM uses different indent styles together in source files. Some use tab. Some use spaces. Some use both... <crupest>youpi: You are right. They even use hard-coded 100 as hostname buffer size. <crupest>Have to stop today. The PAM *_MAX problem is real-real-really tough.