Re: fclose vs ferror (from libc/getcap)
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 surprising that the above works under FreeBSD.
(not only that, it seems to work OK under several other
OS's too). The fclose is supposed to throw away the
stream, but the ferror (apparently) still works with
that pointer.
The PR includes a patch for getcap.c (which is just to
use the result from fclose to determine if an error
occurred), but I also wonder if we should do something
so that this combination would ALWAYS fail. It seems
to me that fclose should clear out whatever fields that
ferror is using for sanity-checking, and ferror should
always return an errno of 'bad parameter', or something
like that.
Or is there some reason that we DO want ferror to work
on streams which have already been closed?
Bear in mind that ferror is one of a number of stdio functions that
are often implemented as macros. For instance: ferror and (say)
getc might look like this:
#define ferror(f) ((f)-fl _FERR)
#define getc(f) ((f)-p (f)-xr ? *(f)-p++ : fgetc(f))
Given the intentionally minimalist way those functions are written,
to do any consistent and obligatory sanity-checking on (FILE *) would
cause a big change in the actual code generated, and the amount of
code generated.
I think the best way to do what you want is to create a separate
debugging library.
The point about
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
is that it's a silly thing to do deliberately, but if I was porting
some hairy old C code I'd tend to expect it to work. C is not a
language in which you go out of your way to prevent people making
mistakes.
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: page fault question
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 sounds like there's something about your first trap that kills DDB (eg. an invalid instruction pointer, etc.) I did check the SP, and it looks like the kernel stack stays in the "temporary" 8k stack set up in i386/i386/locore.s Does that sound right? In some cases. AFAIK it'll also appear in the UPAGES area in userspace if you're calling into the kernel that way. Hope this helps; let us know if the first trap isn't any more illuminating. You might also try using remote gdb instead of ddb. Thanks. I also had to dig out a couple bugs involving word alignment when doing DMA transfers, and learned NOT to mess with the data inside mbufs with external data ;-) I guess I've left enough offerings at the altar of stupidity, so maybe Loki will leave me alone now. *grin* Good luck! -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IP Accounting Daemon
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: http://www.simon.org.ua/ IP Accounting Daemon is a highly configurable IP accounting software. It allows to make IP accounting based on IP Firewall and/or IP Filter accounting rules. In most cases IP Accounting Daemon is run on public servers, software routers, etc. It uses powerful IP Firewall and/or IP Filter accounting rules and bases on its configuration allows to escape from writing scripts to manage network accounting. It is not required to be run from the cron daemon. ipa is a daemon. It has flexible configuration file with many section and options. It is possible to make accounting during specified period of week, accounting per some time interval, etc. Limits or quotas are supported and there can be many limits for one accounting rule. It can operate with such time interval as "end of day", "end of week", "end of month", etc. Each accounting rule can be protected by access control list and there is special viewer ipastat. Its configuration file looks like simple program with subroutines, variables and condition statements. Many other features. ipa is developed for FreeBSD. Main features: - support IP Firewall and IP Filter - it is not required to be run from the cron daemon - IP accounting per specified period of week [not implemented] - IP accounting per specified period of time - support byte limits or bytes quotas - support limit's events: reach limit, restart (zero) limit, expire reached limit - support time intervals like "end of week", "end of day", etc. - there is special viewer ipastat - support access control lists for ipastat - flexible configuration for accounting rules and limits - counters overflow control - low processor time and disk space utilization To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Byte order?
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 endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" :
"no");
#if BYTE_ORDER == BIG_ENDIAN
printf("Big endian\n");
#elif BYTE_ORDER == LITTLE_ENDIAN
printf("Little endian\n");
#else
printf("Unknown\n");
#endif
}
Give me a strange result:
Little endian? no
Little endian
On my FreeBSD 4.2-BETA BYTE_ORDER = LITTLE_ENDIAN!
I`m very confused and some programms detect my machine as Little Endian, by
example freetds.
Alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
4.2R CDROM from Walnut Creek CDROM?
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, +1-925-674-0821 (FAX) | |Or via the Internet from [EMAIL PROTECTED] or http://www.cdrom.com. |Their current catalog can be obtained via ftp from: | |ftp://ftp.cdrom.com/cdrom/catalog Correct needless? -- Toshihiko ARAI / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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 endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" :
"no");
#if BYTE_ORDER == BIG_ENDIAN
printf("Big endian\n");
#elif BYTE_ORDER == LITTLE_ENDIAN
printf("Little endian\n");
#else
printf("Unknown\n");
#endif
}
Give me a strange result:
Little endian? no
Little endian
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).
On my FreeBSD 4.2-BETA BYTE_ORDER = LITTLE_ENDIAN!
I`m very confused and some programms detect my machine as Little Endian,
by
example freetds.
The x86 architecture _is_ little endian.
- Thomas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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 00 00 Lesser significant byte is first and most significant is last To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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 _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 Exactly - the least significant byte comes first, the number is stored in memory from its 'little' end towards its 'big' end - hence, little-endian. G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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. http://www.whatis.com/WhatIs_Definition_Page/0,4152,211659,00.html -- Kim Deokhwan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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. Brian Moffet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
ÐÎ , 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 end" is at the 1st byte). 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 Exactly - the least significant byte comes first, the number is stored in memory from its 'little' end towards its 'big' end - hence, little-endian. Thanks. We all mean same thing, but I called it incorrectly ;-) I`m stupid Sorry and thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
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 (long)];
} u;
u.l = 1;
printf ("Little endian? %s\n", (u.c[sizeof (long) - 1] == 1) ? "yes" :
"no");
#if BYTE_ORDER == BIG_ENDIAN
printf("Big endian\n");
#elif BYTE_ORDER == LITTLE_ENDIAN
printf("Little endian\n");
#else
printf("Unknown\n");
#endif
}
Just to be different, why not use something like:
if(htonl(1) == 1)
bigendian
else
littleendian
Of course, that spoils the fun of figuring out what the
compiler is doing with the union :-)
All the best,
-Richard
---
Richard Hodges | Matriplex, inc.
title | 769 Basque Way
[EMAIL PROTECTED] | Carson City, NV 89706
775-886-6477| www.matriplex.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
truss -f
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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SVR4 missing syscall
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 sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL execve(0xbfbff9a3,0xbfbff880,0xbfbff88c) 39525 ktrace NAMI "./scobin" 39525 ktrace NAMI "/compat/svr4/usr/lib/libc.so.1" 39525 scobin RET execve 0 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL setlogin(0x72,0x805056c) 39525 scobin RET setlogin 0 39525 scobin CALL setlogin(0x28,0x280a9764) 39525 scobin RET setlogin 0 39525 scobin CALL break(0x8051580) 39525 scobin RET break 0 39525 scobin CALL setlogin(0x68,0x8049830) 39525 scobin RET setlogin 0 39525 scobin CALL getpid 39525 scobin RET getpid 39525/0x9a65 39525 scobin CALL old.lstat 39525 scobin PSIG SIGSYS SIG_DFL 39525 scobin NAMI "scobin.core" Which call is it about? I see an "old.lstat" but I couldn't find any reference in the kernel source tree. Is there any doc I could read to see if I can hack this syscall in the emulator? Thanks, -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
