Re: SCSI HBA device detection?
On Fri, Jun 23, 2000 at 13:10:26 -0400, Nat Lanza wrote: I'm writing a SCSI HBA driver that simulates a bus with some ramdisk-backed disks attached to it. I've read through the HBA tutorial in Daemon News, but I'm still unsure how to tell the system about my pretend disk devices. I suspect part of the problem is that I don't actually have real devices or a real IO bus. Anyone feel like explaining this? Well, when the system boots, it sends out a SCSI INQUIRY command to each target on each bus. Each target that responds and sends back inquiry data will get further along in the probe process. The same thing happens when you do 'camcontrol rescan 4' to rescan SCSI bus 4. You need to have your "disks" respond to the inquiry command with inquiry data, as well as have them respond suitably to the various other commands that CAM will send. The commands you'll need to support include (but are not limited to), inquiry, test unit ready, read capacity, read (6, 10 and maybe 12 byte), write (6, 10 and maybe 12 byte) and perhaps mode sense. Those commands will probably get you most of the way towards probing and attaching with the da(4) driver. Another alternative to a ramdisk-like driver is a target mode driver. There is a target mode processor target device in sys/cam/scsi/scsi_target.c that you can look at as an example. You'd be limited to the SCSI bus speed (40, 80, 160MB/sec) for throughput though. You'll need specific hardware (Adaptec or QLogic) to do it as well. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disassembling
On Sun, 25 Jun 2000, Chuck Robey wrote: Is there any tools whatever (free or commercial) that does disassembly on FreeBSD obj's AND will show you the C line and the code that the C line caused to be assembled? Yes, you can do it with the objdump utility which is in the base system. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disassembling
In message [EMAIL PROTECTED] Chuck Robey writes: : Is there any tools whatever (free or commercial) that does disassembly on : FreeBSD obj's AND will show you the C line and the code that the C line : caused to be assembled? Yes. man objdump. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
unsubscribe freebsd-hackers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VM coloring description in NOTES
Hi. ** this discussion is for i386 architectures ** I think there is some unclearness on the description about VM subsystem coloring in NOTES (formerly called LINT). Currently, # Options for the VM subsystem #optionsPQ_NOOPT# No coloring options PQ_LARGECACHE # color for 512k/16k cache #optionsPQ_HUGECACHE# color for 1024k/16k cache #optionsPQ_MEDIUMCACHE # color for 64k/16k cache #optionsPQ_NORMALCACHE # color for 256k/16k cache But, in /sys/vm/vm_page.h, PQ_PRIME1, PQ_PRIME2, PQ_L2_SIZE are defined as below. PQ_NOOPTdefines 1/1/1 to disable coloring PQ_LARGECACHE defines 31/23/128 for 512k cache PQ_HUGECACHEdefines 31/23/256 for 1M cache PQ_MEDIUMCACHE defines 13/7/64 for 256k cache PQ_NORMALCACHE defines 5/3/16 for 64k cache and, on the default, these parameters are defined as 9/5/32. NOTES has obviously incorrect description about MEDIUM and NORMAL case, and there are no discription about the default coloring. Yes, this situation arise from its incomprehensive name. I suggest that these options should be renamed as follows: currently - candidate PQ_HUGECACHEPQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHE PQ_CACHE256 PQ_NORMALCACHE PQ_CACHE64 and newly PQ_CACHE128 should be defined as default. Any ideas? -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: your mail
Hi! Ever read the bottom of the mails?? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Regardsm Freddy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/ufs/ufs/ufs_quota.c
In message [EMAIL PROTECTED], "clemensF" writes: Marius Bendiksen: the various quota routines, rather than a (struct proc *). As I can see from the code, chkdq(), for example, should rather be using an suser() check upon a process structure, than testing cred-cr_uid==0. Are there any objections to changing this? this should be more portable and future-save, right? Isn't there an issue with NFS server side ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Measuring network-protocol implementation's performance
Hi there, Recently we started implementing specific network protocols support code here. As a part of this process I would like to have the ability to measure the performance of the code and probably find a way to improve its speed once we have a working version. I would like to ask if somebody could point me to some article/documentation/etc about such methods? Best Regards: Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disassembling
On Sun, 25 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Chuck Robey writes: : Is there any tools whatever (free or commercial) that does disassembly on : FreeBSD obj's AND will show you the C line and the code that the C line : caused to be assembled? Yes. man objdump. Thanks (also to Boris Popov), I didn't realize objdump would do that. I'd used disassembly before, with line number, but I hadn't seen that -S option. Just what I needed. Warner Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Passing values between shell-variables
Dan Nelson [EMAIL PROTECTED] resonded on Thu, 22 Jun 2000 17:42:37 -0500with In the last episode (Jun 22), gerald stoller said: I want to take an integer value from one shell-variable and pass a modified value to another shell-variable. First I tried setint_v (after using local to get tbl structures for the two shell-variables) and second I tried various forms of the var.c functions intval setint . To see if things worked, I print the shell-variable (to which I assigned a value) afterwards, but neither path seems to have succeeded. I may try getint next, and also make my tests more basic, but if anyone could give me a good hint, I'd appreciate it. One thing that puzzles me is can be illustrated by the following code: struct tbl *var1 ; int val1 ; var1 = local( "LINENO" , FALSE ) ; getint( var1 , val1 ) ; printf( "%d %d\n" , var1-val.i , val1 ) ; which gives differing values in the two fields (the val1 value appears to be correct). Isn't val.i (from struct tbl ) where the integer (or is it floating point?, but it is declared long ) is stored? Please send a response directly to me, my bulk-mail folder is over-stuffed. I'm not sure what local() and getint() are, since you didn't include the source to them, but you should probably be using the getenv() and putenv() functions to read environment variables. -- Dan Nelson [EMAIL PROTECTED] Sorry for leaving out info; local() and getint() are functions in the file var.c of pdksh as is setint_v() , which I also tried. I am using version 3.3 . struct tbl is a structure defined in the file table.h of pdksh . Probably soon I will upgrade to version 4.1 or so. I want to be able to work with general variables, not only environment variables, so I don't feel that getenv()putenv() are the way to go. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/ufs/ufs/ufs_quota.c
[cred-cr_uid==0] this should be more portable and future-save, right? Isn't there an issue with NFS server side ? There might be. I have not looked at the NFS code. However, offhand, I do not see any reason why this should be the case, except for bugs in the code, given that any requrest with uid 0 should, at the moment, have Super powers anyway. Marius To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VM coloring description in NOTES
On 25-Jun-00 Motomichi Matsuzaki wrote: Hi. ** this discussion is for i386 architectures ** I think there is some unclearness on the description about VM subsystem coloring in NOTES (formerly called LINT). Currently, # Options for the VM subsystem #optionsPQ_NOOPT# No coloring options PQ_LARGECACHE # color for 512k/16k cache #optionsPQ_HUGECACHE# color for 1024k/16k cache #optionsPQ_MEDIUMCACHE # color for 64k/16k cache #optionsPQ_NORMALCACHE # color for 256k/16k cache But, in /sys/vm/vm_page.h, PQ_PRIME1, PQ_PRIME2, PQ_L2_SIZE are defined as below. PQ_NOOPT defines 1/1/1 to disable coloring PQ_LARGECACHE defines 31/23/128 for 512k cache PQ_HUGECACHE defines 31/23/256 for 1M cache PQ_MEDIUMCACHEdefines 13/7/64 for 256k cache PQ_NORMALCACHEdefines 5/3/16 for 64k cache and, on the default, these parameters are defined as 9/5/32. NOTES has obviously incorrect description about MEDIUM and NORMAL case, and there are no discription about the default coloring. Yes, this situation arise from its incomprehensive name. I suggest that these options should be renamed as follows: currently - candidate PQ_HUGECACHE PQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHEPQ_CACHE256 PQ_NORMALCACHEPQ_CACHE64 and newly PQ_CACHE128 should be defined as default. Any ideas? Sounds ok to me. Do you have any patches for this? If not, I'll make some and see if they pass muster. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: libc_r/_read(), should the errno be reset to 0?
At 12:28 AM -0400 6/25/00, Chuck Robey wrote: On Fri, 23 Jun 2000, Bohne, Peter wrote: True enough. That's the best advice. However, your original post indicated an expectation on your part that errno would be somehow automatically reset to 0 before a system call, which is definitely *not* the case. You have to clear it - the kernel does not do it for you. Why would you bother to clear it? You don't check errno to determine fail/success, you check the function return. If it returns fail, then errno is going to be correct whether or not you bothered to reset it or not. Setting it to zero might give you a warm fuzzy feeling, but if you're correctly detected errors, it's not going to change anything. There are times when clearing errno is significant. What you said is correct for the routine which actually calls the system routine (is it some *_read() routine here?), but some library routines will call several system routines, and only return an error to caller (of that library routine) in some cases. For instance, it might stat() some file, which sets errno if that file does not exist. To the library routine, it isn't really an error if that file does not exist, it just creates the file or perhaps skips over some optional processing. Later on, it may return an error due to some OTHER condition, a condition which did not set errno. Someone checking errno will think that "file does not exist" is the problem, when the problem is elsewhere. As usual with this topic, I can never remember a good example of this, except that I know I've run into it on some occasions... For those occasions, it IS important to zero out errno "at the right place" (wherever that might be...). One of these days I'll have the presence of mind to save a good example of this... Please note that I'm not saying the system routine should necessarily set errno to zero, I'm just saying that there ARE occasions where it IS important for the programmer to reset it to zero before calling some other routines. In those situations, it does much more than just giving someone a "warm and fuzzy" feeling. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VM coloring description in NOTES
At Sun, 25 Jun 2000 12:07:38 -0700 (PDT), John Baldwin [EMAIL PROTECTED] wrote: Sounds ok to me. Do you have any patches for this? If not, I'll make some and see if they pass muster. I have no patches. I would put it in your hands. Thank you. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: VM coloring description in NOTES
: PQ_HUGECACHE PQ_CACHE1024 : PQ_LARGECACHE PQ_CACHE512 : PQ_MEDIUMCACHEPQ_CACHE256 : PQ_NORMALCACHEPQ_CACHE64 : : and newly PQ_CACHE128 should be defined as default. : : Any ideas? : :Sounds ok to me. Do you have any patches for this? If not, :I'll make some and see if they pass muster. : :-- : :John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ I haven't worked any up. If you work up a set of patches I'll do a once-over and a quick test of them if you want, or you can and commit them straight. There being no operational changes I wouldn't expect any problems. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Passing values between shell-variables
In the last episode (Jun 25), gerald stoller said: Sorry for leaving out info; local() and getint() are functions in the file var.c of pdksh as is setint_v() , which I also tried. I am using version 3.3 . struct tbl is a structure defined in the file table.h of pdksh . Probably soon I will upgrade to version 4.1 or so. I want to be able to work with general variables, not only environment variables, so I don't feel that getenv() putenv() are the way to go. So what you're really doing is modifying the pdksh source, maybe adding a command or something? You should be asking a ksh developers list then. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: libc_r/_read(), should the errno be reset to 0?
On Sun, 25 Jun 2000, Garance A Drosihn wrote: At 12:28 AM -0400 6/25/00, Chuck Robey wrote: On Fri, 23 Jun 2000, Bohne, Peter wrote: True enough. That's the best advice. However, your original post indicated an expectation on your part that errno would be somehow automatically reset to 0 before a system call, which is definitely *not* the case. You have to clear it - the kernel does not do it for you. Why would you bother to clear it? You don't check errno to determine fail/success, you check the function return. If it returns fail, then errno is going to be correct whether or not you bothered to reset it or not. Setting it to zero might give you a warm fuzzy feeling, but if you're correctly detected errors, it's not going to change anything. There are times when clearing errno is significant. What you said is correct for the routine which actually calls the system routine (is it some *_read() routine here?), but some library routines will call several system routines, and only return an error to caller (of that library routine) in some cases. For instance, it might stat() some file, which sets errno if that file does not exist. To the library routine, it isn't really an error if that file does not exist, it just creates the file or perhaps skips over some optional processing. Later on, it may return an error due to some OTHER condition, a condition which did not set errno. Someone checking errno will think that "file does not exist" is the problem, when the problem is elsewhere. As usual with this topic, I can never remember a good example of this, except that I know I've run into it on some occasions... If there is an example, tell me and I'll fix it. I can't comment, Garance, on a nebulous "I know it's out there somewhere" type of reply. I know how it's supposed to work, and how it does in all cases I've seen. Anyone who knows of an exception, bail Garance out here. Context is, a system call that requires setting errno to zero before making the call in order to get a correct error return. Fair enough, Garance? Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: VM coloring description in NOTES
On Sun, 25 Jun 2000, John Baldwin wrote: currently - candidate PQ_HUGECACHE PQ_CACHE1024 PQ_LARGECACHE PQ_CACHE512 PQ_MEDIUMCACHEPQ_CACHE256 PQ_NORMALCACHEPQ_CACHE64 and newly PQ_CACHE128 should be defined as default. Any ideas? Sounds ok to me. Do you have any patches for this? If not, I'll make some and see if they pass muster. John, I've actually got something similar I worked up a while back on my local machine. It's not exactly the same (you set PQ_CACHESIZE to the value of your L2 cache as opposed to having multiple #defines/config options). I just cleaned it up and added backward-compatibility with the pre-existing PQ_ options so as to not break anyone's config files. :) Patches are attached below. I can only say that they've been working on my 4.0-STABLE machines for a few weeks. Kelly -- Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ --- sys/vm/vm_page.h.orig Sun Jun 25 17:52:37 2000 +++ sys/vm/vm_page.hSun Jun 25 18:13:45 2000 @@ -150,46 +150,51 @@ */ /* Each of PQ_FREE, and PQ_CACHE have PQ_HASH_SIZE entries */ -/* Define one of the following */ +/* Backward compatibility for existing PQ_*CACHE config options. */ +#if !defined(PQ_CACHESIZE) #if defined(PQ_HUGECACHE) +#define PQ_CACHESIZE 1024 +#elsif defined(PQ_LARGECACHE) +#define PQ_CACHESIZE 512 +#elsif defined(PQ_MEDIUMCACHE) +#define PQ_CACHESIZE 256 +#elsif defined(PQ_NORMALCACHE) +#define PQ_CACHESIZE 64 +#else +#define PQ_CACHESIZE 0 +#endif +#endif + +#if PQ_CACHESIZE = 1024 #define PQ_PRIME1 31 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_PRIME2 23 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_L2_SIZE 256 /* A number of colors opt for 1M cache */ -#endif -/* Define one of the following */ -#if defined(PQ_LARGECACHE) +#elsif PQ_CACHESIZE = 512 #define PQ_PRIME1 31 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_PRIME2 23 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_L2_SIZE 128 /* A number of colors opt for 512K cache */ -#endif +#elsif PQ_CACHESIZE = 256 +#define PQ_PRIME1 13 /* Prime number somewhat less than PQ_HASH_SIZE */ +#define PQ_PRIME2 7/* Prime number somewhat less than PQ_HASH_SIZE */ +#define PQ_L2_SIZE 64 /* A number of colors opt for 256K cache */ -/* - * Use 'options PQ_NOOPT' to disable page coloring - */ -#if defined(PQ_NOOPT) -#define PQ_PRIME1 1 -#define PQ_PRIME2 1 -#define PQ_L2_SIZE 1 -#endif +#elsif PQ_CACHESIZE = 128 +#define PQ_PRIME1 9/* Produces a good PQ_L2_SIZE/3 + PQ_PRIME1 */ +#define PQ_PRIME2 5/* Prime number somewhat less than PQ_HASH_SIZE */ +#define PQ_L2_SIZE 32 /* A number of colors opt for 128k cache */ -#if defined(PQ_NORMALCACHE) +#elsif PQ_CACHESIZE = 64 #define PQ_PRIME1 5/* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_PRIME2 3/* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_L2_SIZE 16 /* A reasonable number of colors (opt for 64K cache) */ -#endif -#if defined(PQ_MEDIUMCACHE) -#define PQ_PRIME1 13 /* Prime number somewhat less than PQ_HASH_SIZE */ -#define PQ_PRIME2 7/* Prime number somewhat less than PQ_HASH_SIZE */ -#define PQ_L2_SIZE 64 /* A number of colors opt for 256K cache */ -#endif +#else +#define PQ_PRIME1 1/* Disable page coloring. */ +#define PQ_PRIME2 1 +#define PQ_L2_SIZE 1 -#if !defined(PQ_L2_SIZE) -#define PQ_PRIME1 9/* Produces a good PQ_L2_SIZE/3 + PQ_PRIME1 */ -#define PQ_PRIME2 5/* Prime number somewhat less than PQ_HASH_SIZE */ -#define PQ_L2_SIZE 32 /* 512KB or smaller, 4-way set-associative cache */ #endif #define PQ_L2_MASK (PQ_L2_SIZE - 1) --- sys/conf/options.orig Sun Jun 25 18:08:22 2000 +++ sys/conf/optionsSun Jun 25 18:14:11 2000 @@ -364,6 +364,7 @@ PQ_MEDIUMCACHE opt_vmpage.h PQ_LARGECACHE opt_vmpage.h PQ_HUGECACHE opt_vmpage.h +PQ_CACHESIZE opt_vmpage.h # Standard SMP options SMPopt_global.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How many files can I put in one diretory?
"Nicole Harrington." wrote: On 22-Jun-00 Luigi Rizzo wrote: Hello I have a user who needs to store a large amount of small html files. Like around 2 million... that sounds insane! Because a name is a name, why dont they call those files xx/yy/zz/tt.html and the like, to get down to a more reasonable # of files per directory. Well.. Yea that's the idea.. But what is a reasonable number? 10K 100K etc. I heard 10k a while back from several sources I considered reliable. I've always stuck to that limit and never had a problem on freebsd or sun. I've also had very good luck with a hashed directory structure, such as: /a/b/c/abcfile The level of hashing, and the number of characters per level can be determined by your expected number of files, naming schemes, etc. Good luck, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: libc_r/_read(), should the errno be reset to 0?
At 8:35 PM -0400 6/25/00, Chuck Robey wrote:
On Sun, 25 Jun 2000, Garance A Drosihn wrote:
At 12:28 AM -0400 6/25/00, Chuck Robey wrote:
Why would you bother to clear it? You don't check errno to
determine fail/success, you check the function return. If it
returns fail, then errno is going to be correct whether or not
you bothered to reset it or not.
There are times when clearing errno is significant. What you said is
correct for the routine which actually calls the system routine (is it
some *_read() routine here?), but some library routines will call
several system routines, and only return an error to caller (of that
library routine) in some cases.
As usual with this topic, I can never remember a good example of
this, except that I know I've run into it on some occasions...
If there is an example, tell me and I'll fix it. I can't comment,
Garance, on a nebulous "I know it's out there somewhere" type of
reply. I know how it's supposed to work, and how it does in all
cases I've seen.
Anyone who knows of an exception, bail Garance out here. Context
is, a system call that requires setting errno to zero before making
the call in order to get a correct error return.
Fair enough, Garance?
Almost. The thing is, I am almost certain I *have* had this same
conversation before in a freebsd mailing list. While looking for
whatever that conversation was, I came across the thread you get
if you search freebsd-current for:
Bogus errno twiddling by lstat
I said "almost", because it's not just system calls which fiddle
around with errno. I may have missed the original context of the
current thread, but my vague hand-waving memory was not limiting
itself to system calls. From the earlier thread in freebsd-current,
for instance, there was a message from Bill Fenner which said:
Someone else wrote:
So the question becomes: "At what point can I expect a
library routine to behave like a system call"?
When it's documented to do so.
I *thought* that there were some ISO/POSIX requirements
that errno not be touched in non-error cases
ISO/ANSI C says that library functions may modify errno unless
the standard says otherwise. The standard says otherwise for
at least the math functions, which set errno to things like
EDOM and ERANGE or leave it alone if no error occurred, and
the calling sequence
errno = 0;
y = asin(x);
if (errno == EDOM) {
...
}
is meant to work in that situation. However, normal library
functions are explicitly allowed to modify errno even if no
error occurs.
Note that in this case you would have to explicitly set errno
before calling the library routine, if you wanted to check
errno after calling the library routine. That's all I was
saying (although this thread isn't the one I remember having
earlier). The above message seems to be in reply to Terry
Lambert, who gave some other examples. In reviewing the whole
thread, my basic impression is that errno is a mechanism that
no one particularly likes, but no one has come up with a
replacement for, either. I don't know how much things have
changed since that thread (June 1998).
This isn't quite the situation I was trying to remember, but it
will do good enough that I can go home now without feeling like
I am merely ducking the question... :-)
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
