Linux-Development-Sys Digest #864, Volume #6 Wed, 23 Jun 99 09:14:07 EDT
Contents:
Re: gcc byte packing of inherited class data (Tom Lane)
Re: Semaphores don't compile, please help (Villy Kruse)
Re: PCI driver blues (Albrecht Dre�)
Does the cpu sleep??? (Albrecht Dre�)
Re: Difficulty in compiling kernel 2.2.10 (Wei-shi Tsai)
How to compile SMP driver( just -D__SMP__?) into RedHat 6.0 kernel? ("robert_c")
Re: using C++ for linux device drivers (Justin Vallon)
Re: using C++ for linux device drivers (Justin Vallon)
Re: using C++ for linux device drivers (Justin Vallon)
VCD filesystem (Dirk Farin)
How can I redirect kernel message to a file ? ("Soohyung Lee")
Sharing Sage on a linux server for terminals ("Peter King")
Re: Difficulty in compiling kernel 2.2.10 ([EMAIL PROTECTED])
TAO: evolution (Paolo Torelli)
Re: gcc byte packing of inherited class data (Erwin S. Andreasen)
----------------------------------------------------------------------------
From: Tom Lane <[EMAIL PROTECTED]>
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: 23 Jun 1999 01:35:06 -0400
Bruce Edge <[EMAIL PROTECTED]> writes:
> Without going into why I need a misaligned long after a char,
Real compilers (as opposed to Microsoft crap) won't let you do that,
period. Even if they are living on hardware that doesn't address-
fault on misaligned accesses, they won't let you commit that sin.
As a veteran of many portability problems, I can tell you that the
Only True Path is that a given struct declaration has a single
interpretation on a particular kind of hardware. *Anything* that
tries to alter that is spew of the devil, because it creates untold
potential for software incompatibilities of the worst kind (namely,
the kind that cause you to waste hours of work chasing "impossible"
bugs before you get that oh-no insight that it's not a code bug at
all, it's just that modules A and B have different ideas about the
layout of a struct that they supposedly share).
If you need a particular byte layout in memory, declare your structure
as a byte array and then write some routines to read/write it as
bytes. It may seem like a pain, but take my word for it: it beats
the alternative by a country mile.
regards, tom lane
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: Semaphores don't compile, please help
Date: 23 Jun 1999 11:21:41 +0200
In article <7korun$7e1$[EMAIL PROTECTED]>,
Stanislav Krasilovskiy <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I am trying to use the Linux semaphores as defined in <asm/semaphore.h>. Even
>though the functions "up," "down," and "down_interruptible" are explicitly
>defined in Assembler in the header file itself, the linker complains that
>it cannot find these functions. Could you please help me out?
These are for kernel modules only.
Look at /usr/include/sys/sem.h for user level semaphores.
Villy
------------------------------
From: [EMAIL PROTECTED] (Albrecht Dre�)
Subject: Re: PCI driver blues
Date: Wed, 23 Jun 1999 09:04:24 GMT
[Posted and mailed]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Danny Sung) writes:
[snip]
> at all.. (it's a board that uses AMCC's S9533, and I'm trying to read
[snip]
I wrote a driver for a board which uses the S5933 (it is a DSP motherboard
manufactured by Hunt Engineering). You can find the driver (currently only
for 2.0 kernels) at the SunSite archive (and mirrors) an the directory
pub/Linux/kernel/misc-cards, the file is called hepc3-0.9.0.tar.gz.
Hope this helps, Albrecht.
--
+-----------------------------------------------------------------------------+
| Dr.-Ing. Albrecht Dre\ss ---- |
| Max-Planck-Institut f\"ur Radioastronomie |\ / /o o\ |
| Abteilung f\"ur Infrarot-Interferometrie | \ / | / | |
| Auf dem H\"ugel 69 | \ | \ ---/ |
| D-53121 Bonn (Germany) ------------+------+------------------- |
| | / | |
| Phone (+49) 228 525 319 | / / |
| Fax (+49) 228 525 411 |/ / |
| Mail [EMAIL PROTECTED] |
+-------------- electrical engineers do it with less resistance --------------+
------------------------------
From: [EMAIL PROTECTED] (Albrecht Dre�)
Subject: Does the cpu sleep???
Date: Wed, 23 Jun 1999 09:27:07 GMT
Hi all,
I am currently writing a driver for a PCI card with AMCC's S5933 chip
and have problems with PCI Bus Mastering on motherboards with Intel's 440 chip-
sets. AMCC's support told me that the the reason was "the cpu going into a
sleep mode". Can anybody explain what this is? Any chance to avoid it, and
would it make any sense? (the driver works fine with other pci chipsets...)
Thanks, Albrecht.
--
+-----------------------------------------------------------------------------+
| Dr.-Ing. Albrecht Dre\ss ---- |
| Max-Planck-Institut f\"ur Radioastronomie |\ / /o o\ |
| Abteilung f\"ur Infrarot-Interferometrie | \ / | / | |
| Auf dem H\"ugel 69 | \ | \ ---/ |
| D-53121 Bonn (Germany) ------------+------+------------------- |
| | / | |
| Phone (+49) 228 525 319 | / / |
| Fax (+49) 228 525 411 |/ / |
| Mail [EMAIL PROTECTED] |
+-------------- electrical engineers do it with less resistance --------------+
------------------------------
From: Wei-shi Tsai <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Difficulty in compiling kernel 2.2.10
Date: Wed, 23 Jun 1999 06:06:44 GMT
I forgot to attach the error. Sorry.
make -C arch/i386/lib
make[1]: Entering directory `/usr/src/linux-2.0.35/arch/i386/lib'
make all_targets
make[2]: Entering directory `/usr/src/linux-2.0.35/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.0.35/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce
-m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c
-o checksum.o checksum.c
sum.c:200: redefinition of `csum_partial_copy'
checksum.c:105: `csum_partial_copy' previously defined here
{standard input}: Assembler messages:
{standard input}:185: Fatal error: Symbol csum_partial_copy already
defined.
make[2]: *** [checksum.o] Error 1
make[1]: *** [first_rule] Error 2
make: *** [_dir_arch/i386/lib] Error 2
--
Wei-shi Tsai
Cymbeline on #descent, Kahn, and ICQ(UIN:2801023)
The Lost Material Defender Page:
http://www.crosswinds.net/dallas/~perdita/index.html
MoonieCode(1.8.11):
SM:5+ F:sMe++>Mo+>:vZo<Bl+>:aLu+Ry+:pClR2 D:sMa<:vBe-Wi-> X:a0s|35d++
O:d+:s?:?o?:a--:h--- P:a+:s6:w-:f?:eBrD:hBkm:t-:cAs:y---:r+|
------------------------------
From: "robert_c" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: How to compile SMP driver( just -D__SMP__?) into RedHat 6.0 kernel?
Date: 22 Jun 1999 04:24:29 GMT
Could someone tell me about the following:
How to compile SMP driver ( just -D__SMP__ or need more options or __SMP__
can be igored?) into RedHat 6.0 kernel?
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 23 Jun 1999 00:58:21 -0400
Frank Sweetser <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>
> > Frank Sweetser <[EMAIL PROTECTED]> wrote:
> > >Justin Vallon <[EMAIL PROTECTED]> writes:
> > >> [EMAIL PROTECTED] (Alexander Viro) writes:
> > >> > In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> > >> > > I am working a sound driver for linux (I will probably use OSS).I
> > >> > >am planning to use C++, instead of C.
> > >>
> > >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> > >> void operator delete(void *p) { free(p); }
> > >
> > >...which is a higher-overhead version of
> > >
> > >#define new((x)) malloc((x))
> > >#define delete((x)) free((x))
> >
> > Frank, you are confused beyond salvation on this point.
> > Best drop it.
>
> exactly how am i confused? (honest question, i'm not trying to
> flame...) the only overhead to which i was referring is the
> overhead of calling a function that does nothing but call the
> function you really want. and yes, you do want to worry about that
> kind of optimization in the kernel code at times. note that this
> will not simply be inlined by the compiler in the case of the kernel
> unless you tell it to.
One point for effort. Don't resort to the pre-processor:
extern void *malloc(size_t s);
extern void free(void *p);
inline void *operator new(size_t s) { return malloc(s); }
inline void operator delete(void *p) { free(p); }
The problem with #defines is that you're confusion the two notions of
new and delete.
A *a = new A;
Is equivalent to:
A *a;
{
void *mem = ::operator new(sizeof(A)); // Get some memory
a = (A *) mem;
/* construct *a, naively with a->A() */
}
It is the second (get memory) ::opeartor new that I defined above.
This inline expansion happens behind-the-scenes, and after the
preprocessor has a stab at doing its worst.
[ I say naively because C++ has no direct way to construct an object.
You need to do it indirectly, via a dummy in-place operator new:
inline void *operator new(void *p) { return p; }
A *a;
{
void *mem = ::operator new(sizeof(A));
a = new(mem) A; /* new(void *) does nothing, then construct there */
}
> > >> Compile with -nostdinc++ -fno-exceptions.
> > >>
> > >> Static constructors may need a C++ link phase, or you could warn that
> > >> C++ static constructors will not be executed.
> > >
> > >don't forget about name mangling, call by reference, the whole
> > >private/public/protected mess...
> >
> > Name mangling is dealt with by 'extern "C"'.
>
> hrm... IIRC, there were some issues that came up with the last time this
> matter got hashed out regarding exporting symbols from C++ code - ie, going
> the other way. i may be misremembering, though...
extern "C" {
void f();
void public_init_function();
}
...insures that f and public_init_function are not mangled. Either way.
> > Call-by-reference is a non-issue; no kernel function or callback uses it.
>
> another feature of C++ that can't be used.
...unless you're talking about "internal" code. I can use
call-by-reference between C++ files. Of course, C knows nothing about
call-by-reference. I don't need everybody to love C++.
> > There is no such thing as a "private/public/protected" mess.
> > Those keywords have no effect on the emitted object code.
>
> another feature of C++ that can't be used.
But, I can use it.
/* x.c */
class Blah {
private:
int i;
public:
Blah();
};
void *InitializeDriver() {
return new Blah;
}
void DestroyDriver(void *driver) {
Blah *b = (Blah *) driver;
delete b;
}
> > That they are keywords at all might break some kernel headers.
>
> i guess my biggest point here is - once you take away all of the extra
> feautures that won't work or don't make sense in the kernel context, what
> advantages does C++ realy have for writing a kernel module?
Abstraction, virtual inheritance, published interfaces. I can provide
a low-cost C++ abstraction of a device driver:
You can provide a C++ virtual base class called DeviceDriver. If you
don't want to use C++, you don't have to. I can subclass
DeviceDriver, and I get open(), close(), etc, rather than writing a:
struct driver my_driver = {
my_open_function, my_close_function, my_read_function
};
You could say:
class MyDeviceDriver : public DeviceDriver {
public:
MyDeviceDriver();
virtual int open();
virtual int close();
virtual int read(offset_t src, void *dest, size_t count);
virtual int write(void *src, offset_t dest, size_t count);
};
void *BuildMyDevice() {
return new MyDeviceDriver;
}
Here's DeviceDriver:
struct driver glue_driver = { glue_open, glue_close, glue_read, glue_write };
int glue_open(void *driver_arg) {
DeviceDriver *dd = (DeviceDriver *) driver_arg;
return dd->open();
}
int glue_read(void *driver_arg, offset_t src, void *dest, size_t count) {
return ((DeviceDriver *) driver_arg)->read(src, dest, count);
}
glue_driver provide the functions for a device driver in the Linux
sense. The object (new MyDeviceDriver) would be a "driver arg" to the
low-level C++ to Linux device driver glue. Once *this is obtained,
the virtual functions are called, and you're in the C++ world. At
worst, this is one indirect function call (virtual function lookup
would cost one indirect function call).
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 23 Jun 1999 01:20:33 -0400
[EMAIL PROTECTED] writes:
> The main argument against C++ is still overhead. Even when you turn off
> many of the features, you still have overhead that is greater than C.
>
> Check out EROS, currently being discussed on linux-kernel. It is an OS
> that _was_ written in C++, and the author thinks this was a bad
> decision.
I can write a C program in C++, and it behaves in exactly the same
manner. Carefully add useful features, and you'll be optimizing.
Create a VMPage object that allocates a virtual memory page on
construction, and you're on the path to utter nonsense. Abstract a
tty driver with a virtual base class, and that would provide an
efficient interface and implementation.
Inlining is a strong reason to use C++. Macros don't typecheck their
parameters.
C++ just gives you a bigger gun to shoot yourself in the head.
You might not think twice about:
String s = String("Your name is ") + UserName + ".";
But, would you ever say:
const char *s1 = strdup("Your name is ");
const char *s2 = malloc(strlen(s1) + strlen(UserName) + 1);
strcpy(s2, s1);
strcat(s2, UserName);
const char *s3 = malloc(strlen(s2) + strlen(".") + 1);
strcpy(s3, s2);
strcat(s3, ".");
free(s1);
free(s2);
s = s3;
?
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 23 Jun 1999 01:04:23 -0400
Frank Sweetser <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Nathan Myers) writes:
>
> > Frank Sweetser <[EMAIL PROTECTED]> wrote:
> > >[EMAIL PROTECTED] (Nathan Myers) writes:
> > >> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> > >> >Justin Vallon <[EMAIL PROTECTED]> writes:
> > >> >> [EMAIL PROTECTED] (Alexander Viro) writes:
>
>
> > >> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> > >> >> void operator delete(void *p) { free(p); }
>
>
> this is what i was replying to. a version basically intended to look
> C++ish.
These are not C++-ish. There are completely reasonable
implementations of ::operator new and ::operator delete in terms of
the C memory allocator. Why do you require anything more complicated?
If malloc doesn't do a good job, then malloc should be re-written.
Add the inlines if you wish (probably reasonable).
> > >> >...which is a higher-overhead version of
> > >> >
> > >> >#define new((x)) malloc((x))
> > >> >#define delete((x)) free((x))
> > >>
> > >> Frank, you are confused beyond salvation on this point.
> > >> Best drop it.
> > >
> > >exactly how am i confused? (honest question, i'm not trying to flame...)
> >
> > The new operator in C++ is not (normally) called as a function,
> > so your macros would just break code. The argument to it is
> > a type, not a number, so it cannot be passed to malloc. It
> > calls a constructor. In allocation, it has different semantics
> > from malloc. Need I go on?
>
> how is my #define method any less broken than the function version to which
> i was replying? this was not intended to replace the real C++ new/delete
> operators, but rather to replace the C pseudo version that someone else
> posted.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Dirk Farin <[EMAIL PROTECTED]>
Subject: VCD filesystem
Date: Wed, 23 Jun 1999 12:05:01 +0200
Hi,
is there something like a video-CD (VCD) filesystem
for linux? When a VCD is mounted as ISO9660, everything
seems right at first, but isn't because of the different
sector size.
I know that a VCD can be read using the CDROMREADRAW
ioctl as the (commercial) 'mtv' player does.
Any information about URLs where to find more information
about the VCD format is welcome, too.
Greetings,
Dirk Farin
------------------------------
From: "Soohyung Lee" <[EMAIL PROTECTED]>
Subject: How can I redirect kernel message to a file ?
Date: Wed, 23 Jun 1999 16:01:54 +0900
I want to know the exact time of context switching between some tasks .
So, I added some printk functions in the kernel source for that purpose.
But, all the messages are output to the console .
I want to redirect these messages (by printk) to a file ( like redirection
of printf messages).
I don't want to know use /var/log/messages .
How can I do this ?
Can you help me ?
Thanks in advance ...
- Lee -
------------------------------
From: "Peter King" <[EMAIL PROTECTED]>
Subject: Sharing Sage on a linux server for terminals
Date: Thu, 17 Jun 1999 12:55:32 +0100
If I run Sage for dos multi user like Line100 on a linux server can mulitple
people run it from their win95 workstation through terminal emulation
software.
The reason I ask is that Sage Line100 tends to run the Sage.EXE from the
server and pull a 100MB database over the network constantly, hense my
customers network is dog slow.
To add to it they want their remote sites linking via a VPN router which is
obviously going to be impossible as these remote sites want to run the Sage
over the VPN.
Any suggestions.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Difficulty in compiling kernel 2.2.10
Date: Wed, 23 Jun 1999 11:25:26 GMT
Why are you compiling a 2.2.10 kernel in a directory lableled 2.0.35?
Perhaps a stale symbolic link?
Jim
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I forgot to attach the error. Sorry.
>
> make -C arch/i386/lib
> make[1]: Entering directory `/usr/src/linux-2.0.35/arch/i386/lib'
> make all_targets
> make[2]: Entering directory `/usr/src/linux-2.0.35/arch/i386/lib'
> gcc -D__KERNEL__ -I/usr/src/linux-2.0.35/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
-fno-strength-reduce
> -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586
-c
> -o checksum.o checksum.c
> sum.c:200: redefinition of `csum_partial_copy'
> checksum.c:105: `csum_partial_copy' previously defined here
> {standard input}: Assembler messages:
> {standard input}:185: Fatal error: Symbol csum_partial_copy already
> defined.
> make[2]: *** [checksum.o] Error 1
> make[1]: *** [first_rule] Error 2
> make: *** [_dir_arch/i386/lib] Error 2
>
> --
> Wei-shi Tsai
> Cymbeline on #descent, Kahn, and ICQ(UIN:2801023)
> The Lost Material Defender Page:
> http://www.crosswinds.net/dallas/~perdita/index.html
> MoonieCode(1.8.11):
> SM:5+ F:sMe++>Mo+>:vZo<Bl+>:aLu+Ry+:pClR2 D:sMa<:vBe-Wi-> X:a0s|35d++
> O:d+:s?:?o?:a--:h--- P:a+:s6:w-:f?:eBrD:hBkm:t-:cAs:y---:r+|
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: TAO: evolution
Date: Wed, 23 Jun 1999 14:28:28 +0200
Reply-To: [EMAIL PROTECTED]
"Vladimir Z. Nuri" wrote:
> : be discovered and corrected before being too late.
> "too late"?? imho there is all the time in the world.
"Too late" is finding a design flaw after implementing which requires
redesign and re-coding.
> and linux had many years to develop.
<chill> I hope you're not developing it like linux... it relies on
another's design, and if you look closely it's indeed a patchwork
> this is common in this thread & elsewhere: someone
> complaining about my or other's posts without citing anything
> specific. well my posts & others tend to be like rorschach tests, I've noticed.
Sorry for not knowing anything about this rorschach. About citing
anything specific, I already quoted a line in one of my previous
messages, and I'm not into searching your other messages for every line
you wrote. But let me tell you in most of your messages there were at
least one line where you flamed someone or tried to be unsympathetic.
You want quotes? here are some.
Mon, 10:59: "p.s. finally!! someone with some actual authority &
credentials to post to this thread, hahaha", as if others were kids
Mon, 10:53: "starting & feeding flamewars is just a trivial side-benefit
for me, hahaha!!", trying to be serious/costructive?
Sat, 10:19: "nothing personal, but are you an AI program? hehehe", "and
see that it exists, or can exist. ahhh but how rare they are indeed<g>",
how bothering. If you were trying to be sympathetic, ever heard of
smileys?
...and so on. I don't have time to keep searching, the lab is going to close
pretty soon and I' ought to be out of here hell fast. But it should give you
an idea.
> tedious & repetitive. and I'll respond with a bit
> of brashness in my response if the flameurs provoke it..
Yep, fire... I say, there are 3 ways to deal with fire: thorwing water on it,
throwing fuel on it, or sit aside cooking a neat beef waiting for the fire to
extinguish. I've gladly noticed you've moved to the third opportunity, but I
sadly have to notice you've kept fueling in the early stage. That's all.
> evolutionary strategy, "tit for tat". the only reason I am writing
> so much here, in regard to your typical nebulous criticism, is that
Gosh... I'll go fog then... :)
Sincerely, the impression I had is that you went too much "defect always", by
putting some fuel in every message, wether it was flame, comment or
suggestion. Gladly, you seem to have come to a better mood :)
> I take civility very seriously, and imho far more so than most
> in cyberspace!!
So do I.
> people are not helping or contributing so far solely because of my
> attitude problem. hahah pardon me while I ROFL.. plz reread the
not solely, but sure that did't help. I'm not discharging all responsabilities
over you. I'm just trying to say you went too far, and that caused harm.
> thread and reconsider your historical revisionism and naivete about
> human psychology embodied & fossilized in it like bugs in amber!!
_/`/`/|
_\/`/ |
__\/ |
|
//\OO/\\
> saying, "only the paranoid survive"<g> go ahead and criticise
> me because I don't back down, even in the face of widespread
> hostility!! I am working with memes that ultimately transcend
> popularity contests, although not in the short term.<g>
Should I? I never said to drop your work. Just to check your attitudes. That's
different.
Byez!
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
]All tied up, dried and forever I will stay dead to the world[
------------------------------
From: [EMAIL PROTECTED] (Erwin S. Andreasen)
Crossposted-To: gnu.gcc,gnu.g++,comp.os.linux.development
Subject: Re: gcc byte packing of inherited class data
Date: 23 Jun 1999 07:03:18 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 22 Jun 1999 18:27:42 +0000, Bruce Edge <[EMAIL PROTECTED]> wrote:
>I can't get gcc to pack this data:
>
>class a
>{
> char c;
>};
>
>class b
>{
> long l;
>};
>
>class c : public a, public b
>{
>
>};
For a simple setup like this, this worked here:
class A { public: char a; };
class B { public:long b __attribute__((packed)); };
class C : public A, public B {
};
int main() {
C c;
c.a = 42;
c.b = 0;
};
After c.b = 0, I run gdb:
(gdb) p sizeof(c)
$5 = 5
Dumping the memory:
(gdb) x/16b &c
0xbffff8d0: 0x2a 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0xbffff8d8: 0x00 0x00 0x00 0x00 0xca 0x84 0x04 0x08
And to be absolutely sure:
(gdb) set variable c.b=0x01010101
(gdb) x/16b &c
0xbffff8d0: 0x2a 0x01 0x01 0x01 0x01 0x00 0x00 0x00
0xbffff8d8: 0x00 0x00 0x00 0x00 0xca 0x84 0x04 0x08
It seems packed to me.
# g++ -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
SUSE 6.1, with glibc2.
--
==============================================================================
Erwin Andreasen Herlev, Denmark <[EMAIL PROTECTED]> UNIX System Programmer
<URL:http://www.andreasen.org> <*> (not speaking for) DDE
==============================================================================
------------------------------
** 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
******************************
