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 #include #include #include main() { rmdir("/"); printf("rmdir errno: %d\n", errno); mkdir("/",

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 0xcbed8

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 rea

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), n

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 __

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

Alan Cox schrieb am 2009-11-04: > Ed Schouten wrote: > >* Alan Cox 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 > >=

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

Ed Schouten wrote: * Alan Cox 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 ===

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

* Alan Cox 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 === ---

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

Ed Schouten wrote: * John Baldwin 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 d

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

* John Baldwin 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 WWW: http://80386.nl/ pgpxciIJov3Hf.pgp Description: PGP s

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 > Har

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 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 foll

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 hal

Re: writing a FreeBSD C library

Harald Servat 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 ca

Re: writing a FreeBSD C library

Hello Oliver, 2009/11/4 Oliver Mahmoudi > 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//ccHrD

Re: Issue with grep -i (on i386 only?)

On Wednesday, November 4, 2009, 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 th

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 refer