Re: writing a FreeBSD C library
Thank you for your emails. Neither one of the methods that you two suggested brought about the desired solution, but I have solved it. using gcc for the plain source with the -I switch gives: % gcc -o aprog aprog.c -I ~/mylib/ /var/tmp//ccHrDiyd.o(.text+0x19): In function `main': : undefined reference to `myprnf' creating an object file first and then linking with ld gives me: % ld -o aprog aprog.o mylib.a ld: warning: cannot find entry symbol _start; defaulting to 08048080 mylib.a(lb.o)(.text+0x33): In function `_myprf': : undefined reference to `puts' whereas placing mylib.a before the -o switch and then linking with ld gives: % ld mylib.a -o aprog aprog.o ld: warning: cannot find entry symbol _start; defaulting to 08048080 aprog.o(.text+0x19): In function `main': : undefined reference to `myprnf' which is essentially the same message it gives when compiling and linking with gcc in one step. The fact that the order of the arguments matters is also mentioned somewhere in gcc(1) and ld(1). The solution was to simply compile and link it like so: % gcc -o testfile aprog.c mylib.a % ./testfile hello world % This is in essence a synthesis of what you two suggested. Anyways, thanks again. Oliver ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Issue with grep -i (on i386 only?)
On Wednesday, November 4, 2009, Eygene Ryabinkin rea-f...@codelabs.ru wrote:
Mel, good day.
Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote:
So on the laptop I modified the testscript as it is attached now and
while there is still a significant delay, the wallclock time is less
then half, when the expression is rewritten with the same meaning:
= 16777216
= fgrep
0.04 real 0.03 user 0.00 sys
0.05 real 0.03 user 0.01 sys
0.02 real 0.00 user 0.00 sys
= pcregrep
0.26 real 0.21 user 0.02 sys
0.26 real 0.22 user 0.02 sys
0.44 real 0.35 user 0.01 sys
= grep
0.04 real 0.04 user 0.00 sys
4.45 real 4.15 user 0.01 sys
2.00 real 1.81 user 0.00 sys -- [fF][Oo][Oo]
Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor:
-
= 16777216
= fgrep
0,09 real 0,04 user 0,05 sys
0,18 real 0,06 user 0,03 sys
0,05 real 0,01 user 0,04 sys
= pcregrep
0,47 real 0,29 user 0,07 sys
0,52 real 0,33 user 0,07 sys
0,77 real 0,45 user 0,03 sys
= grep
0,09 real 0,08 user 0,01 sys
0,10 real 0,04 user 0,05 sys
0,23 real 0,12 user 0,03 sys
-
Pattern for the plain 'grep' is stable: first and second variants always
give the same time within a 0.01 second variation and the last variant
gives 2x slowdown.
I tried sizes up to the 64M -- the pattern stays. The same stuff for
the amd64, so in my case I don't see the difference in behaviour. So,
maybe, the problem isn't 32 vs 64 but lies somewhere else.
attached a little test script for grep's -i performance.
Some notes about the script, especially if (or some variant of it)
will be included to the testing framework.
#!/bin/sh
# vim: ts=4 sw=4 noet tw=78 ai
PCREGREP=`which pcregrep`
BSDGREP=`which bsdgrep`
[ -n ${PCREGREP} ] PCREGREP=`basename ${PCREGREP}`
[ -n ${BSDGREP} ] BSDGREP=`basename ${BSDGREP}`
You'll want '[ -n ${PCREGREP} ] ...' (with quoted variable) to
really achieve the kind of test you wanted.
if [ ! -x /usr/bin/jot ]; then
echo Need jot
exit 1
fi
if [ ! -x /usr/bin/rs ]; then
echo Need rs
exit 1
fi
Probably this is better be written as
-
for prog in jot rs; do
if [ -z `which $prog` ]; then
echo Need $prog
exit 1
fi
done
-
because the latter code uses unqualified 'jot' and 'rs'.
for b in ${BYTES}; do
TMPFILE=`mktemp -t ${me}`
if [ ! -f ${TMPFILE} ]; then
echo Can\'t create tmp files in ${TMPDIR:=/tmp}
exit 2
fi
jot -r -c ${b} a z |rs -g 0 20 ${TMPFILE}
echo = ${b}
for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
echo = ${prog}
/usr/bin/time ${prog} foo ${TMPFILE} /dev/null
/usr/bin/time ${prog} -i foo ${TMPFILE} /dev/null
/usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} /dev/null
done
rm ${TMPFILE}
done
Most likely, it is better to create the temporary file only once
and to trap the signals with the file removal -- this will handle
the cases when user presses ^C during the execution -- temporary
file should be cleaned in this case. The code is simple:
-
TMPFILE=`mktemp -t ${me}`
if [ ! -f ${TMPFILE} ]; then
echo Can't create tmp file in ${TMPDIR:=/tmp}
exit 2
fi
trap 'rm -f ${TMPFILE}' 0 1 2 3 15
-
Attaching modified version with the bonus -- 'K' and 'M' size prefixes:
it was boring to specify many digits when I had played with sizes ;))
--
Eygene
_ ___ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing a FreeBSD C library
Hello Oliver, 2009/11/4 Oliver Mahmoudi olivermahmo...@gmail.com Thank you for your emails. Neither one of the methods that you two suggested brought about the desired solution, but I have solved it. using gcc for the plain source with the -I switch gives: % gcc -o aprog aprog.c -I ~/mylib/ /var/tmp//ccHrDiyd.o(.text+0x19): In function `main': : undefined reference to `myprnf' creating an object file first and then linking with ld gives me: % ld -o aprog aprog.o mylib.a ld: warning: cannot find entry symbol _start; defaulting to 08048080 mylib.a(lb.o)(.text+0x33): In function `_myprf': : undefined reference to `puts' whereas placing mylib.a before the -o switch and then linking with ld gives: % ld mylib.a -o aprog aprog.o ld: warning: cannot find entry symbol _start; defaulting to 08048080 aprog.o(.text+0x19): In function `main': : undefined reference to `myprnf' which is essentially the same message it gives when compiling and linking with gcc in one step. The fact that the order of the arguments matters is also mentioned somewhere in gcc(1) and ld(1). The solution was to simply compile and link it like so: % gcc -o testfile aprog.c mylib.a % ./testfile hello world % This is in essence a synthesis of what you two suggested. I'm afraid that this is not the most common usage of libraries in the unix world. Libraries, typically, are called lib[SOMETHING].a (if they are static libraries) or lib[SOMETHING].so* (if they are shared libraries). In addition, the -l X option in the gcc compiler looks for libX.[a|so] in the all specified paths defined by -L, so in your first command gcc -o aprog aprog.c -I ~/mylib/ you're making gcc to look for for something called lib~/mylib/.[a|so] which I doubt it can be found. So, I suggest you to: 1.- Name your mylib.a into libmylib.a (or other name that begins with lib), 2.- add -L. to your 1st gcc invocation (in order to instruct gcc to look at the current directory, i.e., .), and 3.- add -lmylib (if you called your library libmylib.a) to the gcc Your compile instruction, then, should look like gcc -o aproc aprog.c -L. -lmylib Regards. Anyways, thanks again. Oliver ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- _ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing a FreeBSD C library
Harald Servat redcr...@gmail.com writes: In addition, the -l X option in the gcc compiler looks for libX.[a|so] in the all specified paths defined by -L, so in your first command gcc -o aprog aprog.c -I ~/mylib/ you're making gcc to look for for something called lib~/mylib/.[a|so] which I doubt it can be found. You're confusing -l with -I... but the rest of your email is correct. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Issue with grep -i (on i386 only?)
On Wednesday 04 November 2009 04:05:44 Eygene Ryabinkin wrote:
Mel, good day.
Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote:
So on the laptop I modified the testscript as it is attached now and
while there is still a significant delay, the wallclock time is less
then half, when the expression is rewritten with the same meaning:
= 16777216
= fgrep
0.04 real 0.03 user 0.00 sys
0.05 real 0.03 user 0.01 sys
0.02 real 0.00 user 0.00 sys
= pcregrep
0.26 real 0.21 user 0.02 sys
0.26 real 0.22 user 0.02 sys
0.44 real 0.35 user 0.01 sys
= grep
0.04 real 0.04 user 0.00 sys
4.45 real 4.15 user 0.01 sys
2.00 real 1.81 user 0.00 sys -- [fF][Oo][Oo]
Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor:
-
= 16777216
= fgrep
0,09 real 0,04 user 0,05 sys
0,18 real 0,06 user 0,03 sys
0,05 real 0,01 user 0,04 sys
= pcregrep
0,47 real 0,29 user 0,07 sys
0,52 real 0,33 user 0,07 sys
0,77 real 0,45 user 0,03 sys
= grep
0,09 real 0,08 user 0,01 sys
0,10 real 0,04 user 0,05 sys
0,23 real 0,12 user 0,03 sys
-
Pattern for the plain 'grep' is stable: first and second variants always
give the same time within a 0.01 second variation and the last variant
gives 2x slowdown.
I tried sizes up to the 64M -- the pattern stays. The same stuff for
the amd64, so in my case I don't see the difference in behaviour. So,
maybe, the problem isn't 32 vs 64 but lies somewhere else.
Well, just ruled out the last commonality: The i386 machines tested all had
MAXPHYS to 1M, except the one I just tried:
= 16777216
= fgrep
0.04 real 0.03 user 0.00 sys
0.04 real 0.03 user 0.00 sys
0.02 real 0.00 user 0.01 sys
= grep
0.04 real 0.02 user 0.02 sys
3.70 real 3.56 user 0.00 sys
1.91 real 1.83 user 0.02 sys
Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults
aren't that). Since fgrep is fast and basically seeds the cache for grep, I'm
ruling out disks/io reads. In fact, /tmp on this laptop is memory disk (one
reason I couldn't go up to 64M :)). I honestly can't figure out what my 'local
problem' could be or your optimization.
Thanks for the fix ups. One more below sig.
--
Mel
--- grep-test.sh.orig 2009-11-04 03:17:05.0 -0900
+++ grep-test.sh2009-11-04 03:29:55.0 -0900
@@ -34,6 +34,10 @@
;;
esac
+ if [ ! -f ${TMPFILE} ]; then
+ # signalled
+ exit 0;
+ fi
jot -r -c ${b} a z |rs -g 0 20 ${TMPFILE}
echo = ${b}
for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
On Tuesday 03 November 2009 12:24:52 pm Ed Schouten wrote: Hi Alan, * Alan Cox alan.l@gmail.com wrote: The standards for mmap(2) actually disallow values of off that are not a multiple of the page size. See http://www.opengroup.org/onlinepubs/95399/functions/mmap.html for the following: snip Just by accident I saw they changed that behaviour in a newer version of the spec: http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html Note that the spec doesn't cover MAP_ANON at all FWIW. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing a FreeBSD C library
Oh, yes! You're right DES. They look the same to me here in the web-browser :) Oliver, regarding the Dag-Erling correction, the -I option in gcc refers to include header files (typically files ended with .h), not for naming libraries as I mentioned. Regards. 2009/11/4 Dag-Erling Smørgrav d...@des.no Harald Servat redcr...@gmail.com writes: In addition, the -l X option in the gcc compiler looks for libX.[a|so] in the all specified paths defined by -L, so in your first command gcc -o aprog aprog.c -I ~/mylib/ you're making gcc to look for for something called lib~/mylib/.[a|so] which I doubt it can be found. You're confusing -l with -I... but the rest of your email is correct. DES -- Dag-Erling Smørgrav - d...@des.no -- _ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* John Baldwin j...@freebsd.org wrote: Note that the spec doesn't cover MAP_ANON at all FWIW. Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON. They do provide MAP_ANON for compatibility, if I remember correctly. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpxciIJov3Hf.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Ed Schouten wrote: * John Baldwin j...@freebsd.org wrote: Note that the spec doesn't cover MAP_ANON at all FWIW. Yes. I've noticed Linux also uses MAP_ANONYMOUS instead of MAP_ANON. They do provide MAP_ANON for compatibility, if I remember correctly. For what it's worth, I believe that Solaris does the exact opposite. They provide MAP_ANONYMOUS for compatibility. It seems like a good idea for us to do the same. We also have an unimplemented option MAP_RENAME defined for compatibility with Sun that is nowhere mentioned in modern Solaris documentation. Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
* Alan Cox a...@cs.rice.edu wrote: For what it's worth, I believe that Solaris does the exact opposite. They provide MAP_ANONYMOUS for compatibility. It seems like a good idea for us to do the same. Something like this? Index: mman.h === --- mman.h (revision 198919) +++ mman.h (working copy) @@ -82,6 +82,9 @@ */ #defineMAP_FILE 0x /* map from file (default) */ #defineMAP_ANON 0x1000 /* allocated from memory, swap space */ +#ifndef _KERNEL +#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ /* * Extended flags -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgprDCQBa0Gu9.pgp Description: PGP signature
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Ed Schouten wrote: * Alan Cox a...@cs.rice.edu wrote: For what it's worth, I believe that Solaris does the exact opposite. They provide MAP_ANONYMOUS for compatibility. It seems like a good idea for us to do the same. Something like this? Index: mman.h === --- mman.h (revision 198919) +++ mman.h (working copy) @@ -82,6 +82,9 @@ */ #defineMAP_FILE 0x /* map from file (default) */ #defineMAP_ANON 0x1000 /* allocated from memory, swap space */ +#ifndef _KERNEL +#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ /* * Extended flags Yes. If no one objects in the next day or so, then please commit this change. Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap(2) with MAP_ANON honouring offset although it shouldn't
Alan Cox schrieb am 2009-11-04: Ed Schouten wrote: * Alan Cox a...@cs.rice.edu wrote: For what it's worth, I believe that Solaris does the exact opposite. They provide MAP_ANONYMOUS for compatibility. It seems like a good idea for us to do the same. Something like this? Index: mman.h === --- mman.h (revision 198919) +++ mman.h (working copy) @@ -82,6 +82,9 @@ */ #defineMAP_FILE 0x /* map from file (default) */ #defineMAP_ANON 0x1000 /* allocated from memory, swap space */ +#ifndef _KERNEL +#defineMAP_ANONYMOUSMAP_ANON /* For compatibility. */ +#endif /* !_KERNEL */ /* * Extended flags Yes. If no one objects in the next day or so, then please commit this change. Alan should this compatibility addition be documented in the mmap(2) manual? any thoughts on the previous change request so mmap fails with MAP_ANON and pos=0? alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
just had a look at the linux mmap(2) manual and noticed a very neat thing they seem to have in most manuals: in the ERRORS section they also document which signals one has to expect. for mmap they are SIGSEGV and SIGBUS. thanks very useful imo. alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing a FreeBSD C library
On Wed, 4 Nov 2009, Harald Servat wrote:
Oh, yes! You're right DES. They look the same to me here in the web-browser
:)
Oh, no. shoulda used a serif font! {:P
Oliver, regarding the Dag-Erling correction, the -I option in gcc refers to
include header files (typically files ended with .h), not for naming
libraries as I mentioned.
Regards.
2009/11/4 Dag-Erling Smørgrav d...@des.no
Harald Servat redcr...@gmail.com writes:
In addition, the -l X option in the gcc compiler looks for libX.[a|so]
in
the all specified paths defined by -L, so in your first command
gcc -o aprog aprog.c -I ~/mylib/
you're making gcc to look for for something called lib~/mylib/.[a|so]
which I doubt it can be found.
You're confusing -l with -I... but the rest of your email is correct.
DES
--
Dag-Erling Smørgrav - d...@des.no
--
_
Fry: You can see how I lived before I met you.
Bender: You lived before you met me?!
Fry: Yeah, lots of people did.
Bender: Really?!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
*--*
Kayven Riese, BSCS, MS (Physiology and Biophysics)
(415) 902 5513 cellular
http://kayve.net
Webmaster http://ChessYoga.org
*--*___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Grep -i and UTF-8 (Was: Re: Issue with grep -i (on i386 only?))
On Wednesday 04 November 2009 13:49:54 Mel Flynn wrote: Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults aren't that). Since fgrep is fast and basically seeds the cache for grep, I'm ruling out disks/io reads. In fact, /tmp on this laptop is memory disk (one reason I couldn't go up to 64M :)). I honestly can't figure out what my 'local problem' could be or your optimization. It hit me. Rather then a local problem, it's a locale problem: = 16777216 = en_US.UTF-8 = fgrep 0.04 real 0.04 user 0.00 sys 0.04 real 0.02 user 0.02 sys 0.02 real 0.01 user 0.00 sys = grep 0.04 real 0.04 user 0.00 sys 3.74 real 3.55 user 0.02 sys 1.95 real 1.83 user 0.03 sys = en_US.ISO8859-1 = fgrep 0.04 real 0.04 user 0.00 sys 0.04 real 0.03 user 0.00 sys 0.02 real 0.01 user 0.01 sys = grep 0.05 real 0.03 user 0.00 sys 0.05 real 0.04 user 0.00 sys 0.08 real 0.04 user 0.03 sys = en_US.US-ASCII = fgrep 0.04 real 0.01 user 0.02 sys 0.05 real 0.03 user 0.01 sys 0.02 real 0.00 user 0.02 sys = grep 0.04 real 0.03 user 0.00 sys 0.05 real 0.03 user 0.00 sys 0.08 real 0.06 user 0.01 sys -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gdb/libkvm problem - can someone explain this?
With FreeBSD 4.x, gdb -k is able to read and interpret
the last 4 bytes of a page (4k) boundary.
In BSD 6.x/7.x/8.x using the kgdb program,
if one issues the kgdb command:
(gdb) x /x 0xcbed8ffd
An invalid address error is returned.
However, if one issues the command:
(gdb) x /10x 0xcbed8ff0
it is able to read the memory (and past) just fine.
The following patch returns the usr/src/lib/libkvm/kvm_i386.c
behavior closer to the BSD4.x version and seems to remedy this situation.
@@ -289,11 +289,13 @@
#definePG_FRAME4M (~PAGE4M_MASK)
pde_pa = ((u_long)pde PG_FRAME4M) + (va PAGE4M_MASK);
s = _kvm_pa2off(kd, pde_pa, ofs);
+#if 0
if (s sizeof pde) {
_kvm_syserr(kd, kd-program,
_kvm_vatop: pde_pa not found);
goto invalid;
}
+#endif
*pa = ofs;
return (NBPDR - (va PAGE4M_MASK));
}
Does anyone see any problem or have any comments about this?
Paul Lai
Engineer
Dorr H. Clark
Advisor
Graduate School of Engineering
Santa Clara University
Santa Clara, CA.
http://www.cse.scu.edu/~dclark/coen_284_FreeBSD/libkvm_problem.txt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
rmdir(2) and mkdir(2) both return EISDIR for argument /
hi there,
i dug up this old pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/59739 and
was surprised it still remains valid for 9-CURRENT. indeed running the
following code:
#include sys/stat.h
#include errno.h
#include stdio.h
#include unistd.h
main() {
rmdir(/);
printf(rmdir errno: %d\n, errno);
mkdir(/, 511);
printf(mkdir errno: %d\n, errno);
}
returns:
rmdir errno: 21
mkdir errno: 21
which is EISDIR. as the pr already said EISDIR isn't mentioned at all in
mkdir(2) or rmdir(2). so i guess this should either get fixed or we add a
BUGS section to both manuals where this problem gets mentioned.
alex
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
