Re: inet string functions

[jjohnstn <jjohnstn at redhat dot com>]

On Wed, 28 Jun 2006, Shaun Jackman wrote:

> On 6/28/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
> > Are such net functions generally useful to platforms that don't have
> > inet_addr and friends or is this something that Cygwin and RTEMS would
> > want to share?
> 
> These functions are useful to me because creating a libgloss for an
> arbitrary system call interface, such as Linux, is straight forward,
> whereas adding functions that are best provided by libc is more
> difficult.
>

If we cordone out these functions as optional directories like we do
for other optional functions then it shouldn't harm anything.
 
> > I continue to stress that if you add arm support to libc/sys/arm, such
> > functions are automatically provided and you don't have a piece-meal
> > solution that only supports an arbitrary subset of applications.  We
> > already have the EL/IX standard.
> 
> I'm not sure I understand. Did you perhaps mean libc/sys/linux/machine/arm?
>
Yes.
 
> i386-pc-linux-newlib is a little odd in that it requires both Linux
> headers and GNU libc headers to compile. I prefer arm-elf
> (gloss-linux) because it stands on its own.
>

This is something we need to work on.  I would like to make 
newlib independent as possible.  Adding an additional 
platform like arm would definitely go a long way to getting this work 
done.
 
> For a function that is system independent, such as inet_addr, I see no
> reason why this function should have been added to a system specific
> directory, sys/linux in this case, rather than a generic directory
> that all targets can share.
> 

You have to remember where newlib sits in the scheme of things.   It's 
root is an ANSI C Library (note the ANSI and not POSIX) for embedded 
platforms.  Glibc has been the C Library for native platforms with 
full-fledged POSIX support.  There are many embedded platforms that don't 
even have file systems. 

-- Jeff J.