Garance A Drosihn wrote:
As mentioned in pr bin/22965, I stumbled across a bug
in libc/gen/getcap.c when compiling it under other
platforms. The basic problem is some code which does:
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
I find
It turns out that the network stack gets really unhappy when you
trim an mbuf chain and leave the last mbuf with a negative length :-(
Ouch. 8)
Typically stack overruns lead to double faults (because there's no stack
on which to handle the fault) and a spontaneous reboot. This just
I'm pleased to announce first public release of IP Accounting Daemon (ipa).
Complete documentation and description of IP Accounting Daemon features is
availble on its manual pages. I can't describe all features in this mesage.
You can download IP Accounting Daemon from the following URL:
I know, that x86 is big endian architecture
but simple programm like this:
#include stdio.h
#include sys/param.h
main () {
/* Are we little or big endian? From HarbisonSteele. */
union
{
long l;
char c[sizeof (long)];
} u;
u.l = 1;
printf ("Little
Hi,
In src/release/texts/*/RELNOTES.TXT for 4.2R, HEAD and
4-stable branches:
|FreeBSD 4.x-RELEASE and 3.x-RELEASE CDs may be ordered on CDROM from:
|
|Walnut Creek CDROM
|4041 Pike Lane, Suite D
|Concord CA 94520
|1-800-786-9907, +1-925-674-0783,
I know, that x86 is big endian architecture
but simple programm like this:
#include stdio.h
#include sys/param.h
main () {
/* Are we little or big endian? From HarbisonSteele. */
union
{
long l;
char c[sizeof (long)];
} u;
u.l = 1;
printf
This program gets it wrong. When the last byte of a long is set after the long was
set to 1, we have a big endian architecture (the "little" end is at the 4th byte,
so the "big end" is at the 1st byte).
The x86 architecture _is_ little endian.
What?
on x86 long a =1
in memory is a 01 00
On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote:
This program gets it wrong. When the last byte of a long is set after the long was
set to 1, we have a big endian architecture (the "little" end is at the 4th byte,
so the "big end" is at the 1st byte).
The x86 architecture
On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote:
The x86 architecture _is_ little endian.
What?
on x86 long a =1
in memory is a 01 00 00 00
Lesser significant byte is first and most significant is last
That's the very little-endian.
per the Intel Pentium Processor Users Manual, section 1.3.1
"The Pentium processor is a "little endian" machine."
The program in question has the algorithm incorrect, a long in
little endian would look like: 0x01 0x00 0x00 0x00 the least
significant byte comes first in the memory space.
ÐÎ , 20 ÎÏÑ 2000, Peter Pentchev ÎÁÐÉÓÁÌ:
On Mon, Nov 20, 2000 at 05:47:47PM +0200, Alex Koshterek wrote:
This program gets it wrong. When the last byte of a long is set after the long
was
set to 1, we have a big endian architecture (the "little" end is at the 4th byte,
so the "big
On Mon, 20 Nov 2000, Alex Koshterek wrote:
I know, that x86 is big endian architecture
but simple programm like this:
#include stdio.h
#include sys/param.h
main () {
/* Are we little or big endian? From HarbisonSteele. */
union
{
long l;
char c[sizeof
Hi,
Once, someone told me that he had a patch for truss that allows it to
follow children, just like in Solaris (or strace -f in linux).
Does anyone have it?
--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]
To
I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS
(invalid system call) at the very beginning. Here is the kdump:
39525 ktrace RET ktrace 0
39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010)
39525 ktrace RET sigprocmask 0
39525 ktrace CALL
14 matches
Mail list logo
