------------------------------------------------------------------------------- Watch your use of the `const' keyword in pointer declarations const char *ptr; /* variable pointer to constant non-changable data */ char *const ptr; /* constant pointer to variable data (like an array name) */ all other cases can not have two different meanings const char ptr[]; /* ptr and data is const (array names are always const) */ ------------------------------------------------------------------------------- Core Dump by Varargs on Sparc machine, SunOS 4.0.3 but works find on Sun3's Varargs for ints and shorts are a major problem In the man page for varargs(3) it has this statement as part of the description. In standard C, arguments that are char or short are con- verted to int and should be accessed as int, ... I think that this is where your problem could lie. If indeed it works (using int rather than char) for both 4.0.3 and 4.1.1 then is this a workaround to your problem? ---- Glenn Satchell - Software Support Australia glenn@Aus.Sun.COM ------------------------------------------------------------------------------- Pclose hangs when 2 Popens are used (this is not a problem under SunOS) Sample code :- fp1 = popen ("cat","w"); fp2 = popen ("cat","w"); fprintf (fp1,"This is output to first filehandle\n"); fflush (fp1); fprintf (fp2,"This is output to second filehandle\n"); fflush (fp2); pclose(fp1); /* this call never returns */ pclose(fp2); NOTE: pclose() doesn't kill the child, it just closes pipe to the child, so the child gets EOF and exits by itself. Or gets SIGPIPE on the next attempt to write to a `read' popen(). This was a fun problem to solve. I might even use it when I next interview somebody claiming to be a UNIX wizard It seems that the pipe file handle for the first popen is duplicated the second popen is executed. As such the wait in the first pclose continues to wait as the child dosn't exit as the duplicated pipe is still open. The solution is to close the second popen first (reverse the order of pclose's). This just leaves the mistery of why this works on a Sun. --- Anna Pluzhnikov -- besp@ellis.uchicago.edu The reason is, on SunOS 4.x and SVR3/SVR4 systems, child processes created by popen() close any popen()'ed pipes they may have inherited from their parent. The BSD popen() doesn't do this. --- Matt Day -- mday@lachman.com -------------------------------------------------------------------------------