Bug 55892 - hostent structure not available without DNS package
hostent structure not available without DNS package
Product: eCos
Classification: Retired
Component: Patches and contributions (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jesper Skov
Jonathan Larmour
Depends On:
  Show dependency treegraph
Reported: 2001-11-08 08:52 EST by Andrew Lunn
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-20 12:05:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for the problem (5.62 KB, patch)
2001-11-08 08:58 EST, Andrew Lunn
no flags Details | Diff
So you mean this..... (3.95 KB, text/plain)
2001-11-30 11:42 EST, Andrew Lunn
no flags Details
It's close enough for me to snaffle and adjust into the sources :-). Here's what I checked in. (1.37 KB, patch)
2001-11-30 11:56 EST, Jonathan Larmour
no flags Details | Diff

  None (edit)
Description Andrew Lunn 2001-11-08 08:52:30 EST
Description of Problem:

Applications which use the BSD interface assume that the structure hostent
and the functions gethostbyname & gethostbyaddr exist. In versions before
1.5.2-final this structure was always provided along with dummy
implementations which returned NULL (A valid result). 

With 1.5.2-final the DNS client code i contributed was added. The
definition of hostent was moved into the DNS package and the stub functions
removed. It is now a requirement that any code wanting to use hostent must
use the DNS code, when in fact the dummy functions may be sufficient. 

It would be better if that when the DNS package is not provided the dummy
functions are implemented along with the hostent structure definition. The
attached patch does this. 

Version-Release number of selected component (if applicable): 1.5.2-final

How Reproducible:

Add the OpenSSL package to the repository. (Jifl has it). Compile this
package without adding the DNS package. The compilation will fail when
hostent is used.

Additional Information:

The DNS code uses CDL interfaces. Is it possible to provide a default
implementation of an interface if no other interface has been defined? If
so this patch could be cleaned up. The dummy functions etc would be put
into the default interface implementation rather than use the current
#ifdef stuff i used. If someone can point me towards an example of this i
will clean up the patch.
Comment 1 Andrew Lunn 2001-11-08 08:58:16 EST
Created attachment 36841 [details]
Patch for the problem
Comment 2 Jesper Skov 2001-11-08 09:48:03 EST
I don't have the POSIX standard here, and I don't remember where Jifl
keeps the PDF edition. The standard contains a list of what functions
can be expected to be available when a certain header is included. I
want to avoid breaking that by making a subset available.

If your code works with the suggested patch, it doesn't check the
error value when NULL is returned. But someone else's code might and
would want h_errno and the appropriate error definitions to be
available - also when they don't want the actual DNS implementation

So I'm uncomfortable with the suggested patch, because it's little
more than a band aid for the OpenSSH code. Or at least, I'm thinking
of it as such until we can see what the POSIX standard have to say on
the subject.

However, as suggested in the Bug text, it is possible to provide
alternative implementations. You could clone the existing DNS package
into a new CYGPKG_NS_DNS_DUMMY package which doesn't contain any code,
but provides the definitions.

I have to suggest that as the best short-term fix (or simply including
the DNS package). When Jifl gets back we can discuss alternatives, as
he has a much better grasp of the impact this would have. 

But I doubt we'd want to provide dummy implementations of various
packages, simply because there'd be a gazillion of those. And anyone
preferring to have dummy functions over changing the application (or
other packages code) always have the option of adding dummy packages

But let's see what Jifl has to say when he comes back.

Comment 3 Jonathan Larmour 2001-11-30 10:07:20 EST
I think Andrew's general approach is alright. Some flexibility is required with
respect to the standards because the standards don't assume configurable
systems: they instead take an all-or-nothing approach.

But I wouldn't like there to be a separate dummy package around, nor even need
there be a .c/cxx file - instead define the dummy gethostyname and gethostbyaddr
functions that return NULL as static inlines isoinfra's netdb.h.

And I'm trying to avoid C++ comments in "standard" headers so that in future we
can move to allow people compiling with -ansi/-pedantic.

Sorry it's taken me a while to get to this - I've had quite a lot of things on
my plate for end of quarter (today!).
Comment 4 Andrew Lunn 2001-11-30 11:42:38 EST
Created attachment 39185 [details]
So you mean this.....
Comment 5 Jonathan Larmour 2001-11-30 11:56:36 EST
Created attachment 39186 [details]
It's close enough for me to snaffle and adjust into the sources :-). Here's what I checked in.
Comment 6 Alex Schuilenburg 2003-06-20 12:05:26 EDT
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=55892

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