From owner-freebsd-hackers Sat Jun 1 22:49:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA01663 for hackers-outgoing; Sat, 1 Jun 1996 22:49:16 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA01656; Sat, 1 Jun 1996 22:49:01 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA12662; Sun, 2 Jun 1996 15:43:37 +1000 Date: Sun, 2 Jun 1996 15:43:37 +1000 From: Bruce Evans Message-Id: <199606020543.PAA12662@godzilla.zeta.org.au> To: bde@freebsd.org, pjf@cts.com Subject: Re: bugs Cc: dyson@freebsd.org, hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hi, here are some problems I encountered while trying to port na >application to FreeBSD. I have workarounds for all of them, but >I thought you might like to know. Which version of FreeBSD? :-) >(1) mmap doesn't seem to work for extending a file. Here's a sample: >------------------------------------------ >#include >#include >#include >main() >{ > int fd = open("newfile", O_RDWR|O_CREAT|O_EXCL, 0660); > char *buf = mmap(NULL, 100, PROT_WRITE, MAP_SHARED, fd, 0); > printf("%lx\n", buf); > strcpy(buf, "hi!"); >} >------------------------------------------ >This test program dies when trying to do the strcpy. What we're >trying to do is create a file using mmap() instead of write(). >(This is in BSDI too.) I don't know much about mmap. This still seems to be broken. It works if the file already exists and is nonempty and is opened in non-exclusive mode. I tried a file of length 512. Setting buf[4095] to 1 didn't trap but the file wasn't extended. Setting buf[4096] to 1 trapped. >(2) there seems to be some bad interation between setgid and setgroups. >Here's a test program: >------------------------------------------ >#include >#include >#include >#include >main(int ac, char **av) >{ > int f; > if(setgroups(0, NULL) < 0) perror("setgroups"); > if(setgid(atoi(av[1])) < 0) perror("setgid"); > if(setuid(atoi(av[1])) < 0) perror("setuid"); > f = access("somefile", X_OK); > printf("%d %d\n", f, errno); >} >------------------------------------------ >Create a file called "somefile", chown it to root, chgrp it to group 123, >chmod it 770. Run this program as root with argument "123". The >setgroups() clears the group id set; setgid() sets the gid, but doesn't >add it to the group id set (?). The result is that the access() fails, >even though our group id has permission to execute the file. (This is >in BSDI too) This is more or less fixed. setgroups(0, any) now returns EINVAL. It previously gave no groups or something silly like that. The program worked right with setgroups(1, gr) (gr[0] = getegid()). >(3) There seems to be a problem with sys/signal.h. Try compiling >the following program, called foo.cxx: >------------------------------------------ >#include >void sigfunc(int s) >{ >} >main() // this is a C++ program >{ > struct sigaction sa; > sa.sa_handler = SIG_IGN; > sa.sa_handler = sigfunc; > sa.sa_handler = (sig_t) sigfunc; > signal(SIGINT, sigfunc); > signal(SIGINT, SIG_IGN); >} >------------------------------------------ >The result of compiling this is: >foo.cxx: In function `int main()': >foo.cxx:10: assignment to `void (*)()' from `void (*)(int)' >foo.cxx:11: assignment to `void (*)()' from `void (*)(int)' >foo.cxx:12: assignment to `void (*)()' from `void (*)(int)' >It looks like sa_handler isn't declared to match SIG_IGN. This has been "fixed" in -current for a year but the fix isn't in -stable. Sigh. POSIX.1-1990 specifies sa_handler to have the broken incomplete type `void (*sa_handler)()'. This causes C compiler warnings and C++ compiler errors, so I completed the type to `void (*sa_handler)(int)'. I think this change is valid because conforming programs won't be able to tell the difference. Bruce