https://bugzilla.novell.com/show_bug.cgi?id=298852 Matej Horvath changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |pbaudis@novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=298852#c2 --- Comment #2 from Robert Schiele 2007-09-26 19:38:17 MST --- Hello? Anyone there? I have checked now on a clean SLES10 installation and can confirm that the bug exists there as well. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=298852#c4 Robert Schiele changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #4 from Robert Schiele 2007-09-26 22:29:19 MST --- What you are telling here makes no sense for two reasons: 1. The documentation explicitly states HOST_NOT_FOUND as an error condition. Thus I would expect an error in that case. This can be found in both, the Linux man page and in IEEE Std 1003.1. 2. It is just not true that it has been like that all the time. SLES9, all RedHat/Fedora versions (even with the same version of glibc), all non-Linux systems I tried that have a similar function, and even SLES10 if you compile the same sample to a 32 bit application, behave different here. Thus if you wanted to hold your statement above _only_ 64 bit SLES10 would do it right --- which would mean that you needed to fix it for 32 bit SLES10 anyway. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=298852#c6 --- Comment #6 from Robert Schiele 2007-09-28 09:36:18 MST --- Some more information from my further investigation: There are three things to consider: 1. The return value if the function. 2. The value of the result parameter after the call. 3. The contents of the hostent struct. The documentation says: "Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r(). These return 0 on success and non-zero on error. The result of the call is now stored in the struct with address ret. After the call, *result will be NULL on error or point to the result on success." Thus according to the documentation you would expect that the return value is non-zero exactly when *result is NULL. Unfortunately this is not true on _all_ versions of glibc I tested. The return value of the method and the value of the result parameter behave in the same (according to the documentation incorrect) way on all versions of glibc I tested this (including RedHat distributions for reference). The difference between SLES10 (including all (open)SUSE distributions back to at least 9.3) and all other distributions (including SLES9) is that SLES10 returns an inconsistent data structure in that case where the other ones return a consistent one (though the data might not make real sense). Whereas returning an inconsistent data structure would be justified in the error case (since nobody wanted to access it then) it fails to indicate the error as described in the documentation. An obvious workaround is to check the return value _and_ the value of the result parameter before accessing any of the data structures. But I still think that either the implementation needs to be fixed to actually do what the documentation says or the documentation needs to be fixed to describe what actually happens. In the latter case it would be useful if the documentation explained why the return value of the function does indicate there is no error but the value of the result parameter contradicts this by indicating that there _is_ an error. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=298852#c8 --- Comment #8 from Marcus Meissner 2007-11-28 07:24:39 MST --- with this code: #include #include int main() { struct hostent serv_host; char hbuf[8192]; int herr = 0; int ret; struct hostent* hent_res = NULL; if ((ret=gethostbyname_r("nonexistenthost", &serv_host, hbuf, sizeof(hbuf), &hent_res, &herr))) { printf("ret=%d, herr=%d\n", ret, herr); return 1; } printf("%p, herr=%d\n", serv_host.h_addr_list, herr); return 0; } (all test on 10.3) x86 32bit with nscd has: meissner@westernhagen:~> ./xx 0xffe5f258, herr=1 meissner@westernhagen:~> ./xx 0xffdcd1c8, herr=1 random return values. ppc32 without nscd: meissner@grape:~> gcc -O2 -o xx xx.c -g -m32 meissner@grape:~> ./xx ret=110, herr=1 meissner@grape:~> gcc -O2 -o xx xx.c -g -m64 meissner@grape:~> ./xx ret=110, herr=1 meissner@grape:~> ppc32 with nscd: meissner@grape:~> gcc -O2 -o xx xx.c -g -m32 meissner@grape:~> ./xx (nil), herr=1 meissner@grape:~> gcc -O2 -o xx xx.c -g -m64 meissner@grape:~> ./xx (nil), herr=1 meissner@grape:~> I would talk to Mr. Drepper. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.