Linux-Development-Sys Digest #125, Volume #7 Mon, 30 Aug 99 19:14:28 EDT
Contents:
(Root) ROM filesystem on Card ISA ("Manut")
Re: why not C++? (NF Stevens)
Re: why not C++? (Andomar)
Re: The optimization debate (was: why not C++?) (Paul D. Smith)
Normal User X shutdown (Thomas Gibson)
Question: Child Process I/O (Herng-Jeng Jou)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: Bazaar shadow password problem... (Aaron Slepecky)
Re: where i can get libXm? (Paul Kimoto)
Re: Kernel compile problem with (P)GCC 2.95 (Paul Kimoto)
Re: why not C++? (Kaz Kylheku)
Re: why not C++? (Phil Hunt)
Re: why not C++? (Assad Khan)
Re: TAO: the ultimate OS (SPAM THIS!!)
Re: why not C++? ("Mary Mest")
Re: why not C++? (Don Waugaman)
Re: why not C++? (Kaz Kylheku)
Re: Emulating network interfaces in user space (Dave Weis)
----------------------------------------------------------------------------
From: "Manut" <[EMAIL PROTECTED]>
Subject: (Root) ROM filesystem on Card ISA
Date: Mon, 30 Aug 1999 20:35:15 +0700
I want create ROM filesystem on ISA Card.
Who is Gide me?
thankx.
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 1999 18:33:26 GMT
[EMAIL PROTECTED] (Don Waugaman) wrote:
[snip]
>References also cannot be induced to point to NULL in a strictly-conforming
>program, which can eliminate a lot of checking of input conditions (or more
>practically, since most C routines don't check their input parameters
>anyway, can make the use of such routines much more reliable).
#include <cstdio>
char *GetAddress (char &c)
{
return &c;
}
int main (void)
{
char *p = NULL;
printf ("%p\n", GetAddress (*p));
return 0;
}
Which part of the this program is not strictly
conforming?
Norman
------------------------------
Date: Mon, 30 Aug 1999 21:06:31 +0200
From: Andomar <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
He means the pointer can't be null, like in:
void my_function( char** str ) { ... }
char **i_am_dumb = NULL;
my_function( i_am_dumb );
I.e., with references you can pass a NULL,
but never a NULL pointer.
The equivalent with references is:
void my_function( char*& str ) { ... }
You can see that you cannot fool the new
my_function into taking a NULL pointer.
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Date: 30 Aug 1999 13:36:39 -0400
Reply-To: [EMAIL PROTECTED]
%% "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]> writes:
>> I, myself, quite often use temporary pointers to walk through
>> arrays rather than incrementing a counter and using array indexing.
>> I actually do it because I find the code simpler to understand that
>> way, but it's probably faster, too.
sm> Last time I timed such code, I found out that it was actually
sm> slower because the pointer manipulation defeated the simple alias
sm> analysis and prevented some code reorganization, while the more
sm> straightforward array access was much better understood by the
sm> compiler (and automatically turned into a temp-pointer walking
sm> through the array).
As always, this will depend on the compiler. That's one of my main
points on this thread.
sm> If code is easier to understand for a programmer, it's probably
sm> also easier to understand for a compiler, leading to better code.
As I said, as a programmer I prefer the pointer walking method. It's
clearer to me, esp. in cases (not so rare) where the loop doesn't have a
trivial invariant or increment.
If I didn't prefer it, I wouldn't do it. That, after all, is another
one of my main points in this thread ;).
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Thomas Gibson <[EMAIL PROTECTED]>
Subject: Normal User X shutdown
Date: Mon, 30 Aug 1999 10:39:31 -0400
When running init level 4, what is the best way to allow a normal user
to perform a system shutdown ?
------------------------------
From: Herng-Jeng Jou <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Question: Child Process I/O
Date: Mon, 30 Aug 1999 15:03:17 -0500
Hi,
I need to write a program that launch a child process with a
command-line
program (which I only have binary, no source). My questions are related
to the I/O control
of the child process:
In the parent process, how do I determine when the child process has
done its number
crunching and is waiting for further input? Should I use /proc?
How do I determine whether there is still something in the output
buffer?
In a sense, I need an I/O facility similar to a debugger so the parent
process can talk to
the child program.
Could you suggest a document, book, or code example, ....? Thanks for
your help,
Jou
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 30 Aug 1999 20:22:00 GMT
In comp.os.misc Nix <$}xinix{[email protected]> wrote:
: [EMAIL PROTECTED] (Donal K. Fellows) writes:
:> We see a bunch of known hard/intractable problems.
: At least one (the `no viruses' constraint) requires either `no new code
: may be written for this system' or a realtime analysis system that must,
: to do its job *perfectly*, solve the halting problem.
false, imho.
this claim is based on the following program, which was
given in a mathematical journal as proof of the impossibility
of virus checking:
- call virus_check on program [y]. if answer
is Yes, virus, do nothing.
- if answer is no, not a virus, corrupt
the operating system.
now call virus_check on the above program. but we
have a double bind. it doesn't corrupt the operating
system is a virus, it does if it isn't. blah,blah,blah.
what this proof fails to consider is the concept
of a sandbox. an environment can be constructed such
that a program running in it is constrained to a
sandbox. concepts such as "corrupt operating system"
and "calling a function" are possibly barred from
definition within this sandbox.. i.e. they are not
possible.
moreover the proof supposes that a program that doesn't
actually do anything harmful in practice is not a virus.
but imho, any program that even has the code within it
"corrupt operating system" (which could be detected
by a virus checker) is potentially a virus. barring
it from execution leads to no harm, even if it wouldn't
actually corrupt the OS in practice. what is possibly
gained by allowing to run a program that can potentially
corrupt an operating system, but doesn't?
Q.E.D.
this is a pet peeve of mine that I plan to write a new
essay around. imho one of the fundamental problems with
computer science as it is practiced today is a very
poor/feeble/immature awareness of the concept of a
sandbox and its utterly crucial relevance to software
and hardware design.
------------------------------
From: Aaron Slepecky <[EMAIL PROTECTED]>
Subject: Re: Bazaar shadow password problem...
Date: Mon, 30 Aug 1999 20:31:03 GMT
so how would you go about fixing this problem? I may be having the same
problem?
Aaron
Alan Curry wrote:
>
> In article <745bb7$146$[EMAIL PROTECTED]>,
> H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> >Followup to: <[EMAIL PROTECTED]>
> >By author: Philip Edelbrock <[EMAIL PROTECTED]>
> >In newsgroup: comp.os.linux.development.system
>
> What program is it that generates this bizarre form of followup
attribution?
>
> >>
> >> I've got a series of machines running Linux. The oldest is running an
> >> installation of Slackware which uses shadow passwords, which handles
> >> email and some other services (nothing interactive). For some strange
> >> reason (out of no where) I can't log-on using telnet (into any
account)
> >> or via Netatalk, but I *can* ftp and use pop3 mail services (only
using
> >> the correct username/password). The /etc/passwd file has 'x's where
the
>
> >Sounds like in.telnetd was built without shadow password support.
>
> telnetd doesn't do authentication. It just calls /bin/login, which is
> supplied by the shadow package. Sounds to me like the shadow login has
been
> overwritten with a non-shadow one (you gotta watch out for that util-
linux
> package). If you can't log in to the text consoles either, that would
support
> my theory.
> --
> Alan Curry echo [EMAIL PROTECTED] | tr a-z n-
za-m
> The lbxproxy program has various options, all of which are optional.
> --
lbxproxy(1)
================== Posted via CNET Linux Help ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.misc
Subject: Re: where i can get libXm?
Date: 30 Aug 1999 16:34:07 -0500
Reply-To: [EMAIL PROTECTED]
[Posted and e-mailed.]
[This is not a c.o.l.d.system matter. Followups redirected.]
In article <pHyy3.79403$[EMAIL PROTECTED]>, tony lee wrote:
> when i install Cforge, i rpm it and it came out: libXm need by XXX
> i m wondering libXm is in which package and where i can download it?
This is Motif, right? You need to buy it, or try (to get by with)
Lesstif.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Kernel compile problem with (P)GCC 2.95
Date: 30 Aug 1999 16:37:40 -0500
Reply-To: [EMAIL PROTECTED]
In article <7qd0bo$qc3$[EMAIL PROTECTED]>, Peter Samuelson wrote:
> Are you sure gcc is getting the flag `-fno-strict-aliases'
> like gcc 2.95 needs? Recent (2.2.12 and 2.3.something) versions of the
> Makefile take care of this automatically but IIRC 2.2.9 does not.
This is probably not the problem here, but the flag is spelled
"-fno-strict-aliasing".
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 21:51:53 GMT
On 30 Aug 1999 13:16:37 -0700, Don Waugaman <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>NF Stevens <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Don Waugaman) wrote:
>
>[ snipped - null references not allowed, and I moved the question below
>to before the program for the sake of readability ]
>
>>Which part of the this program is not strictly
>>conforming?
>
>>#include <cstdio>
>
>>char *GetAddress (char &c)
>>{
>> return &c;
>>}
>
>>int main (void)
^^^^ that ANSI C syntactic kludge is not needed in C++
>>{
>> char *p = NULL;
>> printf ("%p\n", GetAddress (*p));
> ^^ deref'ing a NULL pointer
Another thing: the %p conversion specifier requires a void * type,
not char *.
>> return 0;
>>}
>
>This program dereferences a NULL pointer where I've noted above. It is
>legal by the standard for the compiler to pass the address from p through
>to create the reference parameter c because p cannot be NULL in a
>strictly conforming program - dereferencing a NULL pointer is undefined
>behavior and illegal in a strictly conforming program.
So the program isn't strictly conforming. Big deal? Strict conformance is
largely a theoretical notion. Note that in order to be strictly conforming, a
program must also meet all of the minimum implementation limits, and
must not make use of any extensions whatsoever. Most real-world applications
aren't strictly conforming.
The practical consideration is that compilers will not statically diagnose the
null pointer dereference. The program may not be strictly conforming, but it
is free of diagnosable constraint violation.
Most run-time systems won't catch it either, because the resulting
l-value is not written through.
The program clearly demonstrates that references can be misused, just like
pointers.
The only safety advantage of references is that they must be initialized:
int x;
int * const p; // okay, uninitialized pointer
int &r; // error, should be &r = x
However, the initialization can be abused to produce a bad reference, like the
initialization of the c parameter in the GetAddress function above.
And the ``no reseating'' property can be arrange in a pointer by
const qualification, so no advantage there in favor of references.
What about this?
int main()
{
int &p = new int;
delete &p;
// p continues to be used
p = 42;
}
Maybe null references are contrived, but using pointers as well as references
to objects that no longer exist is a real C++ problem that occurs in practice.
It's possible for functions to return references to local objects, or for
references to continue to exist after an object has been destroyed.
Thus, in the final analysis, C++ references can suffer from all of the same
errors that their pointer cousins fall victim to.
------------------------------
From: [EMAIL PROTECTED] (Phil Hunt)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Sun, 29 Aug 99 22:34:13 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
> My point was that he's added even more pointless and obscure things to C++
> such as reference variables. What the hells the point of those when you
> already have pointers? Also overloading the << and >> to produce a less
> powerfull (for most things) I/O system than *printf and *scanf and to
> produce confusing statements like "cout << 2 << 3". In general IMO
> operator overloading produces impossible to follow code and the syntax for
> declaring an overloaded operator is a joke as are other things such as
> class inheritance. Also why give constructor functions the same name as the
> class and make destructors have a tilda in front? Even worse the copy
> function is the same as the constructor except it takes an argument!
> Whats wrong with constructor() , destructor() and copy() for chrissake??
> I could go on but whats the point. C++ is a dogs dinner like I said before.
Since you feel like that, may I suggest you design something better.
--
Phil [EMAIL PROTECTED]
------------------------------
From: Assad Khan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 1999 18:44:27 -0400
Reply-To: [EMAIL PROTECTED]
In 1991 when Linus created Linux, ANSI C++ was in the works. Remember, before
the ANSI standard there were tons of different versions of C, and C++. ALso, if
you program in a language for so long, and write something good, why change to
a language you just used? I doubt Linus knows C++ or has the time (he compiled
himself without SMP :P). The last reason is that C is way more popular than
C++, so the # of developers who contribute to Linux may not know C++. Heh, even
C++ was writtin in C :P
Cocheese wrote:
> Dear Linux Community;
>
> There has been a puzzling question on my mind for some time. First, I
>
> admit i am no Linux Guru so this may be off the wall.
>
> *Why Is linux done primarily in the C programming language rather than
>
> C++?*
>
> Again I admit it would take a little extra work and put a minor set
>
> back in the evolution for a month or 2, but if C++ is so much faster,
>
> easier, and stable- WHY NOT?
>
> I have been a RH 6.0 user since the first week it was first released
>
> and since then i have loved it. I am struggling with it a bit but as i
>
> continue to learn this from an "other leading brand OS" and a full time
>
> programmer for a large company.
>
> There are many differences Between the two programming languages and
>
> there are huge advantages to C++.
>
> The downside is "linux has always been a C based Program so it will always
>
> be."
>
> *** BUT THEN AGAIN - ISN'T LINUX ALL ABOUT CHANGE? ***
>
> -Sincerely
>
> cocheese
>
> ------------------ Posted via CNET Linux Help ------------------
> http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (SPAM THIS!!)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 30 Aug 1999 18:00:51 -0300
On 30 Aug 1999 20:22:00 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]> puked this
up onto the newsgroups:
>In comp.os.misc Nix <$}xinix{[email protected]> wrote:
>: [EMAIL PROTECTED] (Donal K. Fellows) writes:
>:> We see a bunch of known hard/intractable problems.
>: At least one (the `no viruses' constraint) requires either `no new code
>: may be written for this system' or a realtime analysis system that must,
>: to do its job *perfectly*, solve the halting problem.
>false, imho.
>this claim is based on the following program, which was
>given in a mathematical journal as proof of the impossibility
>of virus checking:
>
>- call virus_check on program [y]. if answer
>is Yes, virus, do nothing.
>- if answer is no, not a virus, corrupt
>the operating system.
>now call virus_check on the above program. but we
>have a double bind. it doesn't corrupt the operating
>system is a virus, it does if it isn't. blah,blah,blah.
>what this proof fails to consider is the concept
>of a sandbox. an environment can be constructed such
>that a program running in it is constrained to a
>sandbox. concepts such as "corrupt operating system"
>and "calling a function" are possibly barred from
>definition within this sandbox.. i.e. they are not
>possible.
>
[snip]
>Q.E.D.
>this is a pet peeve of mine that I plan to write a new
>essay around. imho one of the fundamental problems with
>computer science as it is practiced today is a very
>poor/feeble/immature awareness of the concept of a
>sandbox and its utterly crucial relevance to software
>and hardware design.
Please explain this sandbox of yours in detail. What exactly would
a program be barred from doing? To keep a virus from infecting other
programs, you'd have to bar all programs from being able to open
any file, which would make it impossible to install new programs if
all programs were constrained to the sandbox.
To prevent filesystem corruption (which would ultimately cause OS
corruption), you'd have to make it completely impossible to directly
access a filesystem. This would create a problem for filesystem checkers.
You wouldn't be able to access a filesystem anyway because you have to
make it impossible to open a file! Of course, these are all blind
assumptions-- I don't actually know anything about this sandbox concept
of yours, which is why I am asking you to explain it in more detail.
--
If a man commits sedition in the middle of the
woods, and there are no cops around to arrest
him, is he still a criminal?
------------------------------
From: "Mary Mest" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: Mon, 30 Aug 1999 18:11:45 -0400
Reply-To: "Mary Mest" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> [EMAIL PROTECTED] (Michael Schuerig) wrote:
> >> For a man that had the opportunity to clean up the C syntax and make it
> >> more readable yet managed the impressive task of making it even more of
an
> >> dogs dinner than it already was, he really should have learnt his
lesson by
> >> now.
> >
> >You can bet that similarity to C was instrumental in the widespread
> >adoption of C++. If it were not to offer some kind of compatibility to
>
> I've no doubt it was.
>
> >existing C code, it wouldn't be nearly as widely used as it actually is.
> >There's a similar effect with Java.
>
> My point was that he's added even more pointless and obscure things to C++
> such as reference variables. What the hells the point of those when you
> already have pointers? Also overloading the << and >> to produce a less
> powerfull (for most things) I/O system than *printf and *scanf and to
> produce confusing statements like "cout << 2 << 3".
The purpose of overloading the << and >> operators was certainly not to
compete
with the printf and scanf family. If you're only using them to throw things
to cout or cin,
than you're certainly in no position to critique C++. The actual purpose of
those
operators is to allow any class the ability to define its own methods of
streaming itself
out. The fact that stdout(cout) and stdin(cin) are streams, and that int,
long, char* and
what not all have these operators defined was an afterthought that fit
nicely into the paradigm.
If you're not familiar with the concept of streams, well, then this
conversation is moot.
> In general IMO
> operator overloading produces impossible to follow code and the syntax for
> declaring an overloaded operator is a joke as are other things such as
> class inheritance. Also why give constructor functions the same name as
the
> class and make destructors have a tilda in front?
>Even worse the copy
> function is the same as the constructor except it takes an argument!
You can have a thousand constructors, each with arguments, that are not the
copy constructor. The difference is that the copy constructor takes a
reference to
a pre-constructed object. It's an object oriented language... at runtime,
you decide
how to construct yourself. Thats not a tough concept to grasp, is it?
> Whats wrong with constructor() , destructor() and copy() for chrissake??
So, you would rather have this, then:
MyClass* myInst = new constructor();
constructor? what constructor? who's constructor? This is where a
compiler tells
you that you're nuts... in any language.
> I could go on but whats the point. C++ is a dogs dinner like I said
before.
>
> >How long does someone have to be in industry so that you don't consider
> >them an "academic" in your derogatory sense? No, sorry, but the design
> >of C++ has above all been driven by practical concerns.
>
> Bullshit. The only practical part was building it on top of C. The rest of
> it was made up by stroustrop , probably with very little input from anyone
> who might have to use the language for real.
The plain fact that C++ is an ANSI language should tell you that many many
people have worked to make it what it has come to be.
>
> >About time to reconsider your preconceptions.
>
> I think not. Just because C++ is used by lots of people doesn't make it a
> good language syntactically anymore than billions of people buying Big
Macs
> makes the burger upmarket cuisine. Sure C++ has power but so what? So does
> assembler.
Lets not compare C++'s readibility with that of assembler. The only point
to be made,
and it is a valid point, is that, the deeper you go, or rather, the closer
you get to writing
true machine code, the more powerful your application will be. With that
said, it's almost
impossible to write an app in assembler that is worth a damn, considering
that it'll take you
so long to write/debug/test, that you could never even dream of meeting any
real-world
business deadlines, which is certainly not the case with C++.
Bottom line is this: C++ isn't a toy, its a tool, and sometimes tools are
complex and hard to
operate. If you have issues with the syntax, stick with Torbo Pascal. I
personally am glad
that C++ is the way it is.. if it were easy, everyone would be doing it, and
that makes for a
bloated marketplace for techies. We all know what that mean.
regards,
Kevin
>
> NJR
>
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 30 Aug 1999 13:16:37 -0700
In article <[EMAIL PROTECTED]>,
NF Stevens <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Don Waugaman) wrote:
[ snipped - null references not allowed, and I moved the question below
to before the program for the sake of readability ]
>Which part of the this program is not strictly
>conforming?
>#include <cstdio>
>char *GetAddress (char &c)
>{
> return &c;
>}
>int main (void)
>{
> char *p = NULL;
> printf ("%p\n", GetAddress (*p));
^^ deref'ing a NULL pointer
> return 0;
>}
This program dereferences a NULL pointer where I've noted above. It is
legal by the standard for the compiler to pass the address from p through
to create the reference parameter c because p cannot be NULL in a
strictly conforming program - dereferencing a NULL pointer is undefined
behavior and illegal in a strictly conforming program.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
I feel a lot more like I do now than I did a while ago.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Aug 1999 22:30:40 GMT
On Mon, 30 Aug 1999 18:11:45 -0400, Mary Mest <[EMAIL PROTECTED]> wrote:
>
>The actual purpose of those operators is to allow any class the ability to
>define its own methods of streaming itself out.
This is not possible. The << and >> operators take a stream object on the left.
This means that they must be the members of a stream class, or non-members. We
are talking about C++ right?
A non-brain-damaged design for C++ streams would put the stream objects
on the right, so that one could design object methods that accept the
stream, not the stream accepting the objects.
Of course, you can still do this, if you want, so the syntax becomes
my_object >> cout;
which is preferrable.
Then again, the ability itself is of little utility. I can't think of any use
for this other than debugging. If you want to know the state of object x,
just grab a lock, do cout << object, then unlock.
There is a use for object serialization (a.k.a. marshalling) but there
are interface compilers for that. You wouldn't want to implement RPC's
over streams. Or use flat text files as an object store.
>and stdin(cin) are streams, and that int, long, char* and what not all have
>these operators defined was an afterthought that fit nicely into the paradigm.
The afterthought was the overloading for arbitrary objects. That is why it's
awkward to do, with anti-object-oriented crap like non-member friend functions.
The original thought was to overload the stream for basic types,
since overloading the basic types isn't possible.
------------------------------
From: Dave Weis <[EMAIL PROTECTED]>
Subject: Re: Emulating network interfaces in user space
Date: Mon, 30 Aug 1999 08:27:20 -0500
Take a look at the source for diald, they do something like that.
Basically, you set up a pty with your program listening on it and the
point pppd/slip at that pty and you will get the packets that are routed
via the routes you make to the device.
djweis
On Mon, 30 Aug 1999, Phil Howard wrote:
> Is there a way to emulate a network interface in user process space?
> I would only car to implement IP on this interface. So it should
> get all IP packets routed out to that interface, and be able to put
> all IP packets that would "come in" in that interface. Also, ioctl
> would be done somehow. Does such a facility exist? Would it be
> very easy to do if not? The process would run as root.
>
> --
> Phil Howard KA9WGN
> [EMAIL PROTECTED] [EMAIL PROTECTED]
>
>
--
David Weis | 10520 New York Ave, Des Moines, IA 50322
[EMAIL PROTECTED] | Voice 515-278-0133 Ext 231
When they took the Fourth Amendment, I was quiet because I didn't deal drugs.
When they took the Sixth Amendment, I was quiet because I was innocent.
When they took the Second Amendment, I was quiet because I didn't own a gun.
Now they've taken the First Amendment and I can't say anything.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
