Bug 63220 - getnetbyname returned unexpected value
getnetbyname returned unexpected value
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-11 06:56 EDT by masanari iida
Modified: 2007-04-18 12:41 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description masanari iida 2002-04-11 06:56:01 EDT
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,
Comment 1 Jakub Jelinek 2002-04-11 17:48:19 EDT
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 06:51:59 EDT
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,

Comment 3 masanari iida 2002-04-19 06:53:13 EDT
Reopen this bug.
Thank you.
Comment 4 Jakub Jelinek 2002-04-22 06:25:05 EDT
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 07:11:28 EDT
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 07:21:33 EDT
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 06:56:30 EDT
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@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
        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


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