Bug 63220 - getnetbyname returned unexpected value
Summary: getnetbyname returned unexpected value
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-11 10:56 UTC by masanari iida
Modified: 2016-11-24 12:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-23 11:11:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 65056 ovirt-4.0 NEW net: remove default route before adding a new one 2016-10-03 09:04 UTC

Description masanari iida 2002-04-11 10:56:01 UTC
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:

Steps to Reproduce:

struct netent {

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

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.


Comment 1 Jakub Jelinek 2002-04-11 21:48:19 UTC
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.

Comment 2 masanari iida 2002-04-19 10:51:59 UTC

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.

           n_net: c0a80100
   inet_makeaddr: 0001a8c0

           n_net: 00c0a801
   inet_makeaddr: c0a80100

As I said, using glibc 2.2.2, same code do the job.
This is what I expected.


Comment 3 masanari iida 2002-04-19 10:53:13 UTC
Reopen this bug.
Thank you.

Comment 4 Jakub Jelinek 2002-04-22 10:25:05 UTC
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.

Comment 5 masanari iida 2002-04-23 11:11:28 UTC
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

Comment 6 Jakub Jelinek 2002-04-23 11:21:33 UTC
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.

Comment 7 masanari iida 2002-04-24 10:56:30 UTC
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@redhat.com>

        * nss/getent.c: Accept -s parameter to overwrite rules in
        nsswitch.conf.  Patch by Nalin Dahyabhai <nalin@redhat.com>.

>      * 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

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

Note You need to log in before you can comment on or make changes to this bug.