From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311 Description of problem: using getnetbyname, n_net value became change after glibc-2.2.4-19. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Use getnetbyname() struct netent { n_net; } Use glibc 2.2.4-19 or 2.2.4-23 set example address 210.162.15 Actual Results: actual value n_net d2a29d00 (with 00) Expected Results: expected n_net d2a29d (without 00) Additional info: 2.1.3-15 without 00 2.2.2-10 without 00 2.2.4-19 with 00 2.2.4-24 with 00 Question Depend on the glibc version, the return value of n_net doesn't have "00" or have "00" Which one is correct result, with 00 or without? I would like to confirm this. If without 00 is expected value, I ask you to fix it. On HP-UX, without 00 is the return value. Regards,
This is what Ulrich Drepper, glibc maintainer, said about this: There is no standard governing this and what is there now is used somewhere else (cannot remember where I looked) and it makes a bit more sense. The old A, B, C, D net distinctions are not usable anymore and therefore this function is completely useless anyway. I'll just add that if you pass x->n_net through inet_makeaddr(x->n_net, 0); you'll get the same result both with old glibc, current glibc, HP-UX, BSD and whatever else.
Hello Thank you for the reply. Still I don't get about this. I would like to know the reason why the n_net return value has changed between 2.2.2 and 2.2.4. As you said, "there is no standard" about this, you may have the reason why you have changed the return value. This kind of change break the software compatibility so that you should announce about this change in the document such as Changelog. I have checked the inet_makeaddr(), but the return value of the Linux and HP-UX are different. Linux n_net: c0a80100 inet_makeaddr: 0001a8c0 HP-UX n_net: 00c0a801 inet_makeaddr: c0a80100 As I said, using glibc 2.2.2, same code do the job. This is what I expected. Regards,
Reopen this bug. Thank you.
The different return from inet_makeaddr is expected, its return value is in networking order and HP-UX is big endian while IA-32 linux little endian. ntohl(inet_makeaddr()) would give you host order.
Thank you for the answer. Still , I expect you to explain why you have changed the return value of the n_net betweeb 2.2.2 and 2.2.4. Even if it is not a bug, still I hope you put the fact that you have changed the format into the change log. These two are what I want. Thank you
It is in glibc ChangeLog. It was not me who did this change, though I cited above the change's author above on why he changed it.
Hi, I found following change log in /usr/share/doc/glibc-common-2.4.4/ChangeLog.gz If I am not mistaken, this is the part that I was looking for. Am I correct? 2001-09-22 Ulrich Drepper <drepper> * nss/getent.c: Accept -s parameter to overwrite rules in nsswitch.conf. Patch by Nalin Dahyabhai <nalin>. > * nss/nss_files/files-network.c (LINE_PARSER): Pad addr string > with as many ".0" as necessary to form a complete address > inet_network understands. * nss/getent.c: Various cleanups. Use simpler and fewer function calls. I think you should note the changes not only in the ChangeLog but also the www.redhat.com Errata page since this change break the compatibility. Anyway, I understood this is not a bug by accident but the chage. Thank you