Il CD di internet

home *** CD-ROM | disk | FTP | other *** search

/ Il CD di internet / CD.iso / SOURCE / N / CNEWS / _CNEWS.TAR / usr / doc / cnews / docs / problems < prev next >

Wrap

Text File | 1994-09-02 | 31.6 KB | 1,130 lines

.Ch "Known Porting Problems With C News" .Ix problems porting .SH Intro .PP C News in general is pretty portable. People have got it to run on a very wide range of systems with little trouble. Difficulties are usually problems in the system, not C News. Some of them, however, are widespread enough to be worth comment, for the guidance of people having problems. If you run into a novel problem, we are always interested in hearing about such things. .SH Unix Dependencies .PP The biggest portability glitch in C News is that it depends a lot on Unix utilities. The extensive use of complex shell files, \fIsed\fR and \fIawk\fR programs, and a wide range of lesser Unix utilities would make it quite difficult to move C News to a system that is seriously non-Unix-like. The actual C programs seldom depend on Unix in major ways. (An exception is the use of \fIread\fR system calls in \fIexpire\fR, to avoid difficulties with stdio end-of-file behavior; we now know how to avoid this but haven't implemented the fixes yet.) .PP .Ix Unix Minix .Ix Unix utilities .Ix sed .Ix awk We know that \fIawk\fR and the colon (:) operator of \fIexpr\fR are problem areas under Minix. .SH Shell Problems .PP C News seriously stress-tests shells. The current Minix shell is not robust enough in the face of complex inputs, botches some constructs entirely, and can run out of memory on the complex shell files. Any shell that is too old to implement comments begun by ``#'' is big trouble, since we use such comments everywhere. .PP Any system/shell combination that thinks that a shell script starting with ``#!\ /bin/sh'' should be run by the C Shell (because it starts with `#') is also big trouble: you will have to change that line to ``:\ use\ /bin/sh'' everywhere. We know that at least some releases of Xenix have this problem. It is not necessary that your kernel understand the ``#!'' feature\(emwe believe that nothing in C News relies on it\(embut it is essential that it not cause invocation of the C Shell. .PP We know that some Hewlett-Packard Unixes have broken shells, probably the result of mistakes in HP's efforts to make the shell 8-bit-clean; the symptom is that something like: .DS .ft B x=y if test " $x" != " y" then echo oops fi .ft .DE prints ``oops''. This is, again, big trouble, because we do that a lot. .PP .Ix machines 3b1 .Ix 3b1 Many people using 3B1s, aka UNIX PCs, run the Korn shell as their \fI/bin/sh\fR. .Ix shell Korn .Ix ksh Some other folks may do this too. Beware that \fIksh\fR was not fully \fIsh\fR-compatible for a long time, with some subtle differences in the ill-documented behavior of backquotes and backslashes. Some of the C News shell scripts, notably \fIinews\fR, are known to hit these bugs. We are \fItold\fR that current \fIksh\fRs have fixed them. .PP .Ix Unix SunOS 4.0 It is reliably reported that SunOS 4.0.\fIx\fR shells will dump core in some ill-defined circumstances, when the user environment (sum of all environment variables) is exactly the wrong size. Perhaps this has been fixed in 4.1. .PP .Ix Unix "Ultrix 3.1" It is reliably reported that the VAX 3.1 Ultrix shell is somewhat broken and gives various kinds of trouble. Switching to \fI/bin/sh5\fR (note that this requires fixing the first line of a zillion shell files) is reported to banish the problems. .PP .Ix wait .Ix breakage wait .Ix inews .Ix NNTP It is reliably reported that recent SunOS shells give the wrong exit status from the \fIwait\fR command: they give a 0 for a successful wait, rather than giving the exit status of the process waited for. This makes \fIinews \-W\fR appear to always succeed even if backgrounded parts of it failed, which can be troublesome in NNTP environments where correct exit status is important. .SH Make Problems .PP .Ix make .Ix machines 3b2 .Ix 3b2 .Ix SVID .Ix Unix A/UX There is a persistent problem on 3B2s with implementations of \fImake\fR that violate the SVID in a subtle way. They attempt to execute makefile commands directly, rather than via the shell, if the commands do not contain metacharacters. This means that if\(emas on many 3B2s\(em\fItest\fR is a shell builtin \fIand there is no /bin/test program\fR, the makefile line ``test\ \-s\ file'' will cause \fImake\fR to complain about an unknown command. (The SVID says that makefile commands must be executed as if by the shell, and the shell will execute this line correctly.) We've added `;' on the ends of such lines, which suffices to convince \fImake\fR to run a shell on the systems we've encountered, but AT&T is good at finding ways to break such workarounds. This problem is also known to occur in A/UX. .PP .Ix Unix Ultrix Another obscure problem, a bug in either \fImake\fR or the shell, appears in at least some releases of Ultrix: a construct like .DS .ft B ln ... || cp ... .ft .DE in a shell file is seen as an error\(emand \fImake\fR aborts\(emwhen the \fIln\fR fails, even though the \fIcp\fR would work. .SH Offsetof .Ix offsetof .Ix "ANSI C" .PP ANSI C requires C compilers to supply a macro \fIoffsetof\fR, which can be used to find the offset of a structure member within the structure. \fIRelaynews\fR's header-parsing code uses it, defining it if the system has not supplied it. Unfortunately, it is really hard to write a portable version of this. The implementation we currently use is: .DS .ft B #define offsetof(type, mem) ((char *)&((type *)NULL)\->mem \- (char *)NULL) .ft .DE The table in \fIrelay/hdrdefs.c\fR .Ix initializers .Ix hdrdefs.c puts invocations of \fIoffsetof\fR in initializers. This turns out to be a severe stress test for C compilers. A compilation error in \fIhdrdefs.c\fR is almost certain to be problems with this macro. Some compilers, notably the one in Microport System V for the 286, .Ix Unix "Microport System V for the 286" reject it. We have heard a report that System V Release 2 on the VAX silently miscompiles it! .Ix Unix "System V Release 2 on the VAX" If you have trouble with \fIoffsetof\fR, you might try this version instead: .DS .ft B #define offsetof(type, mem) ((int)&((type *)NULL)\->mem) .ft .DE .SH Fast Stdio Routines .Ix stdio "faster internals" .Ix problems stdio .PP We supply a set of fast standard-I/O routines that are compatible with most AT&T-derived implementations of \fIstdio\fR. They speed up C News quite a bit. However, they don't work on all Unixes. The tester program we supply, which the library-build procedure runs, is thought to diagnose such problems 100% of the time. It has been reported in the past that A/UX and Microport 386 stdios .Ix Unix A/UX .Ix Unix "Microport 386" flunk the test. SunOS 4.0 used to pass the test falsely, but improvements in both the test and the routines seem to have cured the problems: 4.0.3 passes the test and as far as we can tell, the routines run correctly under it. .PP In any case, if you are feeling nervous or are having mysterious problems, telling \fIbuild\fR that you don't want to use the fast-stdio stuff is always safe. This is also the best response if you have trouble compiling those routines. .SH void .Ix void .Ix "old compilers" .PP Old compilers that don't understand the \fIvoid\fR type will choke on much of our code. .Ix news.h There is a commented-out ``#define\ void\ int'' in \fInews.h\fR that cures most cases of this if you uncomment it. (We have a report that you might need to add ``\-Dvoid=int'' to the Makefile in \fIlibv7\fR if you're using that library.) C News does not rely on the ANSI C ``void\ *'' type as far as we know. .SH Modes in fopen .Ix fopen .Ix Unix Minix .PP Unix V7 documented only ``r'', ``w'', and ``a'' as suitable mode arguments to \fIfopen\fR. It actually implemented the read/write modes, ``r+'', ``w+'', and ``a+'', as well, and C News relies on them. Unix reimplementations based on old documentation may have trouble here; we know that at least the older versions of Minix really don't implement these modes. .PP A related complication in Minix is that \fIftell\fR reportedly doesn't give the right answer in ``a'' mode. This makes \fIdbz\fR flunk its regression test. .Ix dbz .SH MAXLONG .Ix MAXLONG .Ix Unix Unisys .PP The \fIrelay/cpu.h\fR file formerly defined a constant \fIMAXLONG\fR which is the biggest positive value of a \fIlong\fR. The definition was clever but failed on some odd systems (Unisys?). Current versions of C News generate the value dynamically in a less fallible way, and check the value for plausibility. (This is encountered when \fIrelaynews\fR is asked to process a single article, not a batch. This happens primarily when an article is posted locally, with \fIinews\fR.) .Ix inews It is still barely possible that the plausibility check will fail on some bizarre system. .SH df Output Format .Ix df .PP .Ix spacefor The \fIspacefor\fR utility needs to understand the output format of \fIdf\fR, unless you're lucky enough to have a system that has one of the semi-standard system calls to report disk space. There are numerous variations on \fIdf\fR. \fIBuild\fR and the relevant makefiles know about the more common ones, but customization may be necessary. \fISpacefor\fR is commented well enough that it should be possible to figure out the necessary changes; usually the initializations of \fInr\fR and \fInf\fR are all that need changing. If there are colons (:) in your \fIdf\fR's output format, you should probably start from the ``sysv'' \fIspacefor\fR, which attempts to preprocess the output to get rid of System V garbage; .Ix Unix "System V" .Ix "System V" breakage otherwise the ``bsd'' one is a reasonable starting point. .PP One constant nuisance is \fIdf\fRs that are too stupid to take a directory name as an argument. The long-term solution to this is to edit a suitable variant of \fIspacefor\fR to know about the proper arguments. A short-term solution is to use the ``null'' variant, sacrificing space checking for the sake of getting something working. .PP .Ix Unix HP-UX We're told that HP-UX 7.0 users are best advised to choose the ``bsd'' variant of spacefor, and edit it to call \fIbdf\fR instead of \fIdf\fR. Similar approaches may be useful on other hybrid SysV/BSD systems. .SH Floating Point .Ix "floating point" .Ix expire .Ix awk .PP The only places in our code where floating point is used, as far as we know, are in the calculation of expiry dates in \fIexpire\fR and the calculation of space in some of the variants of \fIspacefor\fR. These are not performance bottlenecks, so slow floating-point arithmetic is not a problem. Complete absence of floating point would require only minor modifications. Note, however, that we use \fIawk\fR a lot, and the typical \fIawk\fR implementation uses floating point extensively. .SH 386 Optimizer vs. dbz .Ix machines 386 .Ix dbz .Ix problems "broken 386 optimiser" .Ix Unix "System V" .Ix "System V" breakage .Ix Unix "SCO Xenix/386 2.3" .PP We have a reliable report that the System V 386 optimizer (invoked when \fIcc\fR is given the \fB\-O\fR option) miscompiles the \fIdbz\fR package badly enough to cripple it, without producing any error messages. The only fix is to compile \fIdbz\fR without \fB\-O\fR. .PP SCO Xenix/386 2.3 has the same problem. .SH nnafree and nnfree .Ix nnafree .Ix nnfree .Ix machines HP .PP We have a reliable report that the HP Spectrum C compiler has an optimiser bug that makes it throw up (with a ``cc: Internal error 3279: Please contact your local HP representative'' message) on the \fInnafree\fR macro (and \fInnfree\fR, a historical synonym) in \fIh/news.h\fR. .Ix news.h The following revised version of the macro reportedly avoids the problem. .DS .ft B #define nnafree(mempp) do { if (*(mempp) != 0) { free((char *)*(mempp)); \e *(mempp) = 0; }} while (0) .ft .DE .PP .Ix Unix Microport It is also reliably reported that the Microport compiler objects to these macros in large model. Whether the above fix would suffice is not known. Manual expansion [barf!] is known to work, although it would be less painful to define a function containing the right code and change the macro to call the function. Code for a suitable function can, in fact, be found in \fIh/news.h\fR, inside `#ifdef\ lint'. .SH ANSI C .Ix "ANSI C" .PP Although we made an effort to be ANSI-C compatible, lack of access to a real ANSI C compiler limits our ability to do this. A secondary problem is that it's really very difficult to get code that is 100% acceptable to both ANSI C compilers and older compilers. Some issues inevitably got resolved in favor of current compilers, and may cause complaints from ANSI C compilers. .PP Work is in progress on moving us closer to ANSI compatibility. Beware that if \fB__STDC__\fR is defined .Ix __STDC__ by your compiler but it is \fInot\fR ANSI compatible, you are on your own as far as we're concerned, even if the value is specified as 0. (We can't just use ``#if\ __STDC__'' because some preprocessors choke on the appearance of an unknown identifier in #if.) .SH GNU C .Ix "GNU C" .PP If compiling with the GNU compiler, you may need the \fB\-traditional\fR flag. Beware, also, that if you are using your system's \fIdbm\fR library, it contains functions that return structure values, and the GNU conventions for handling such values are incompatible with the ones in many AT&T-derived compilers. The \fB\-fpcc-struct-return\fR option cures this. .SH Awk Problems .Ix awk .PP A number of problems can arise if your \fIawk\fR has bugs, since the shell files rely on \fIawk\fR fairly extensively. For example, \fIawk\fR is a prime suspect if \fIspacefor\fR doesn't work. We've fixed the worst trouble spots, but would appreciate detailed information on any more. .PP .Ix awk "line length limits" One known problem that is hard to avoid is line-length limits in \fIawk\fR. In particular, for several purposes in control-message handling C News wants to build a ``canonical'' representation of the \fIsys\fR file, with backslashed newlines removed. This is done by NEWSBIN\fI/relay/canonsys.awk\fR. .Ix canonsys.awk Most \fIawk\fRs have limits on line length, and some of the limits are too low to cope with long multiply-continued \fIsys\fR lines. 512-byte limits, found in a number of old \fIawk\fRs, are particularly troublesome. A quick look indicates that this will interfere, to some uncertain extent, with \fIcheckgroups\fR and \fIsendsys\fR. .Ix checkgroups .Ix "control messages" checkgroups .Ix sendsys .Ix "control messages" sendsys Big deal. :-) The complaint may also appear from \fInewgroup\fR, .Ix newgroup .Ix "control messages" newgroup but there it should be harmless. .PP .Ix Unix HP-UX Bart Muyzer and Martijn Roos Lindgreen report that HP-UX 8.0 \fIawk\fR is badly broken, such that (for example) the regular expression ``/[\et ]/'' will match backslashes and t's as well as tabs and spaces. Installing the HP-UX 7.0 \fInawk\fR as \fIawk\fR is reportedly a workable fix. .SH Systems Without Hard Links .Ix links .PP .Ix Unix unoid Some vaguely Unixoid systems have trouble implementing real (``hard'') links. Examples are VMS in general and Eunice in particular. .Ix VMS .Ix Eunice There are some hooks for dealing with this, but it's not trivial. .PP .Ix relaynews \fIRelaynews\fR will try to make symbolic links if real ones fail. There is one exception: if \fIrelaynews\fR cannot buffer up enough of the article in memory to find the `Newsgroups:' line, it will drop the article into a temporary file and will rely on being able to move that to the first of the `real' locations by manipulating links. This should essentially never happen except on 16-bit machines, and should be rare even on them. .PP .Ix expire \fIExpire\fR has a \fB\-l\fR option which tells it to consider the first filename of an article its `leader', not expiring the article under that name until it has expired under all others. This has not been tested much recently. .PP .Ix lock The locking system (both C routines and the \fInewslock\fR program) will need revision in some system-dependent way to avoid use of links. .PP There is one minor use of links in installation (\fIinews\fR is found in two places, and the Makefile attempts a link before doing a copy), and substantially more in the regression tests. .SH 16-bit Machines .Ix machines small .Ix machines PDP-11 .PP C News has been tested on 16-bit machines\(emindeed, a good bit of the early development work was done on one\(emand does run on them. Nothing relies on ints being 32 bits. Nothing relies on pointers and ints being the same size, as far as we know. Nothing relies on large address spaces, although one or two modules come in separate small-space and large-space versions, and the small-space versions are slower. .PP However, there are some fundamental limits to consider. Both \fIrelaynews\fR and \fIexpire\fR\(emthe usual trouble spots for space shortages\(emwant to keep lots of stuff in core. There isn't any easy way around this one. .SH Number of File Descriptors .Ix "file descriptors" .PP There is a constant, NOPENBFS, in \fIrelay/trbatch.c\fR, .Ix relay/trbatch.c .Ix relaynews that defines how many batch files are kept open simultaneously. If you are feeding much news to more systems than this, \fIrelaynews\fR performance will suffer. .PP .Ix NOPENBFS The major limit on NOPENBFS is available file descriptors (although on a 16-bit machine there might also be a shortage of memory for \fIstdio\fR buffers). Other parts of \fIrelaynews\fR want perhaps 10 file descriptors for other purposes, so with the usual total supply of 20, a NOPENBFS value of 10 is the right default. If you feed many people, and your kernel provides a process with more than 20 file descriptors, you probably want to boost NOPENBFS (this can be done with -DNOPENBFS=xxx in the makefile). Remember to leave about 10 descriptors worth of headroom. .SH Shell Processing Order .Ix shell .Ix problems shell .PP Normally, shell variable expansion should take place before scanning for syntax elements such as ``0<&1''. At least one reimplementation of the shell (specifically, Bash 1.04) does things in the wrong order. This is known to affect, at least, \fIrelay/sh/anne.jones\fR, .Ix anne.jones which can be fixed by changing (circa line 44) .DS .ft B "") USER="`who am i <&$fd | .ft .DE to .DS .ft B "") USER="`eval \e"who am i <&$fd\e" | .ft .DE or so we are told. .SH Binary-Mode Fopen .Ix fopen .Ix "ANSI C" .Ix dbz .PP In several places, the new \fIdbz\fR uses ANSI C ``binary mode'' fopen codes, e.g. `fopen(...,\ "r+b")'. The text/binary distinction involved is meaningless under Unix, and most Unix implementations just ignore trailing nonsense in the second argument of \fIfopen\fR, so it all works out nicely. .PP .Ix Unix Ultrix Unfortunately... at least one version of DEC's Ultrix objects to the `b's, we are told. Sigh. DEC will have to fix this to make their systems ANSI compatible, but heaven only knows how long that will take. .PP Meanwhile, the fix is to delete the `b's in the second arguments of the \fIfopen\fRs in three places in \fIdbminit()\fR in \fIdbz/dbz.c\fR, if your system has this particular bit of brain damage. .SH size_t .Ix problems size_t .Ix size_t .Ix Unix Microport .PP Some systems, notably from Microport, do not define the \fIsize_t\fR type in the \fI<sys/types.h>\fR header. Worse, the \fIsize_t\fR in that header doesn't necessarily bear any relationship to the ANSI C \fIsize_t\fR. This causes trouble in the \fIdbz\fR library in particular. The proper type for \fIsize_t\fR is whatever the C \fIsizeof\fR operator returns, nominally an unsigned type which is large enough to contain the size of any memory object. We think nothing relies too heavily on it being unsigned. Note that \fIsize_t\fR must also be suitable for use in the two middle arguments of \fIfread\fR and \fIfwrite\fR, the last argument of \fImemcpy\fR, \fImemchr\fR, and \fImemcmp\fR, and the argument of \fImalloc\fR. .SH Background Processes vs. csh .Ix shell C .Ix csh .Ix problems csh .Ix inews .PP \fIInews\fR runs much of its processing in the background. We are told that this can hit problems, in some circumstances, with \fIcsh\fR's manipulations of signals, terminal modes, etc etc. We prefer a standard shell, and have made no attempt to understand the C shell's weirdnesses. We're aware that well-written programs can fail under the C shell due to bizarre problems with weird signals, etc., but we class this as the fault of the C shell and its co-conspirators and decline to contort our programs to compensate for its failings. We do sympathize with people victimized by it, but can be of no practical help. .SH Compress Behavior .Ix compress .Ix problems compress .Ix batcher .PP Extremely old (pre-1985) versions of \fIcompress\fR run off at the mouth with a status message on \fIstderr\fR even when nothing goes wrong in the compression. This upsets the batcher, which thinks any \fIstderr\fR output means trouble. .SH ulimit .Ix ulimit .Ix problems ulimit .Ix Unix "System V" .Ix "System V" breakage .PP Most versions of System V have the concept of \fIulimit\fR, a per-process limit on how big an individual file can be. This limit can be lowered by anyone but raised only by the super-user; normally \fIinit\fR or \fIlogin\fR initializes it to some suitable value. Unfortunately, many System Vs set it far too low, at 1 megabyte. This causes trouble with many things, but in particular, .Ix relaynews .Ix expire \fIrelaynews\fR, \fIexpire\fR, etc. need to be able to work with the \fIhistory\fR file, .Ix history which can easily be several megabytes. It's necessary to deal with this on all paths by which any of these programs might be invoked: from \fIuucp\fR or other transport software bringing in news, from \fIcron\fR, .Ix cron and by users via \fIinews\fR for local postings. .Ix inews It is difficult to do this in a portable way when super-user privileges are needed. .SH Restricted Shells .Ix shell restricted .Ix problems "restricted shells" .Ix Unix "System V" .Ix "System V" breakage .PP There is an unfortunate interaction between the `#!' feature in shell files and the ``restricted shell'' feature found in some Unixes (notably System V): the restricted shell typically is just a different way of invoking \fI/bin/sh\fR, and in some versions, careless code just checks the first letter of the name the shell was invoked under to see if it was `r'. Unfortunately, if the system has the `#!' feature and there is a shell file named, say, .Ix rnews \fIrnews\fR whose first line is `#!\ /bin/sh', this shell file will end up invoking the restricted shell! .PP Simply deleting the `#!' line might fix this; on systems which have the Korn shell, .Ix shell Korn .Ix /bin/ksh changing `#!\ /bin/sh' to `#!\ /bin/ksh' might work. Otherwise you will have .Ix cunbatch to arrange to have your neighbors invoke \fIcunbatch\fR instead of \fIrnews\fR, or else write a simple \fIrnews\fR that invokes the real one under another name. It would be wise to check for other shell files whose names begin with `r', also, as \fIrnews\fR definitely isn't the only one. .SH Remote Invocation vs. Nonstandard Shells .Ix shell non-standard .Ix problems "non-standard shells" .Ix rsh .\" thanks to Paul Eggert for most of this .PP When \fInewsrun\fR is invoked on a host that is not the news server, it uses \fIrsh\fP to propagate news batches to the server. It runs \fI/bin/sh\fR explicitly to avoid major difficulties with non-standard shells, but it has to rely on the invoker's login shell to run that one command. This means \fInewsrun\fR will emit spurious output if its invoker's login shell is the C shell and its invoker's \fI.cshrc\fR contains commands that generate output. A similar problem occurs with \fIbash\fP and \fI.bashrc\fP. .Ix bash .Ix shell bash .Ix csh .Ix shell C .PP The simplest solution is to use \fI/bin/sh\fP as the login shell for \fInewsrun\fP's invoker. Otherwise, if you have a networked news server, check that the login shell is standard enough to invoke \fI/bin/sh\fP by executing the following command as \fInewsrun\fP's invoker. .DS .ft B rsh \fInewsserver\fP exec /bin/sh \-c true .ft .DE This command should output nothing. .PP .Ix Unix "System V" .Ix "System V" breakage A slightly related problem is that not everyone calls the run-remote-shell command \fIrsh\fR; on System V in particular, \fIrsh\fR means something different. For the moment we have opted to ignore this issue, as the possibilities for gratuitous differences boggle the mind. People facing this problem may wish to place an \fIrsh\fR shell file in the search path to invoke the right command in the right way, whatever that is. .SH Values of Logical Operators .Ix "broken compilers" .Ix problems "broken compilers" .Ix Unix Ultrix .PP There seem to be compilers, e.g. the Ultrix one on DEC's new RISC workstations, that go into convulsions when they see something like .DS .ft B *p++ = isascii(c) && isalnum(c); .ft .DE because they don't know how to generate a numeric value for `&&', or because they don't know how to turn that value into a `char'. One or two places in C News use constructs like this. If you run into this, you might want to try replacing the right-hand side with something like ``(...)\ ?\ 1\ :\ 0'' to get the troublesome operator back into a conditional context. .SH Empty Lines .Ix "empty lines" .Ix problems "empty lines" .Ix relaynews .PP Some backward operating systems (through which your C News distribution may have passed on its way to you), and perhaps some stupid text-handling software even on sane operating systems, do not recognize the notion of an empty line. They think all lines must have at least one character in them; the closest they can come to an empty line is a line consisting of a single blank. This matters because \fIrelaynews\fR will tolerate white space only in certain places in the \fIsys\fR file, and in particular, it tolerates empty lines but not lines consisting solely of white space. The result will be complaints (in \fIerrlog\fR) about white space in the \fIsys\fR line for a system named ``\ ''. .SH active-File Date .Ix problems "broken file systems" .Ix "broken file systems" .Ix Unix "Bull DPX/2 B.O.S. 1.0" .Ix relaynews .Ix active .Ix files active .\" thanks to Simon J. Gerraty for this weirdie .PP On some Bull systems, at least ones running DPX/2 B.O.S. 1.0, apparently \fIrelaynews\fR updates the contents of the \fIactive\fR file correctly, but the file's date remains unchanged! This appears to be a kernel bug. It reportedly upsets some news readers. A workaround, said to be effective, is to add the line .DS .ft B utime(ctlfile(actrelnm), (time_t *)NULL); .ft .DE after the call to \fInnafree\fR in \fIactfsync\fR in \fIlibbig/active.big.c\fR. .Ix active.big.c .SH enum Operators .Ix "broken compilers" .Ix problems "broken compilers" .Ix readnews .\" thanks to Scott Reynolds for this one .PP Some compilers have difficulty compiling the \fIreadnews\fR we supply, because they object to applying the `!' operator to an \fIenum\fR type. Changing the definition of \fIbooltype\fR in \fIrna/defs.h\fR to .DS .ft B typedef int bool; #define false 0 #define true 1 .ft .DE is reported to solve this. .SH Amiga Library Ordering .Ix Unix "Amiga System V Release 4" .Ix problems "amiga loading" .PP It is reliably reported that when compiling some of the programs under SVR4 on the Amiga, it is necessary to give ``\-lc \-lucb'' as library options\(emlinking of the C library \fImust\fR precede linking of the Berkeley-emulation library, or the code links but will not run. .SH AIX and Mach vs. fsync() .Ix fsync .Ix problems fsync .Ix Unix AIX .Ix Unix Mach .Ix relaynews .Ix /dev/null .Ix machines NeXT .PP The .I relaynews regression test fails under some (all?) AIXes, because the system refuses to do an .I fsync on a file descriptor open to .I /dev/null . It is possible that this does not affect production use, however. Mach (at least on the NeXT) is reported to have similar problems. .SH AIX/370 vs. Shell Files .Ix problems AIX/370 .Ix Unix AIX/370 .Ix shell AIX/370 .Ix newsrunning .PP AIX/370 has added at least one keyword (``on'') to the shell, and this is known to cause syntax complaints in at least one shell script (\fInewsrunning\fR). Unless this is also a keyword in the final version of POSIX 1003.2, we don't plan to fix this. .SH Struct Conditional Expressions .Ix "broken compilers" .Ix problems "broken compilers" .Ix Unix "SCO Xenix" .PP Some (all?) SCO Xenix compilers take offense to expressions like .DS .ft B value = (dbzint) ? dbzfetch(key) : fetch(key); .ft .DE where the functions return .I struct values. This occurs in three places in .I dbz/dbzmain.c , .Ix dbz and the workaround is to expand those conditionals to statements like: .DS .ft B if (dbzint) value = dbzfetch(key); else value = fetch(key); .ft .DE .SH staleness vs. Ultrix .Ix Unix Ultrix .Ix staleness .Ix problems Ultrix .PP Several Ultrix users have reported a problem with the ``staleness'' command. It seems Ultrix's \fIsed\fR is an antique and blows up on the complex regular expression in \fIstaleness\fR. .Ix sed A fix, at some small cost in performance, is to change the last four lines of \fIstaleness\fR to something like .DS .ft B exec awk '$1 == "/expired/" { print "-o", $3 }' $NEWSCTL/explist .ft .DE .SH SCO Xenix string functions .Ix "botched libraries" .Ix problems "botched libraries" .Ix Unix "SCO Xenix 2.3" .\" Sydney S. Weinstein discovered this horror .PP Under SCO Xenix 2.3, and perhaps other recently-released SCO systems, the string functions like \fIstrchr\fR exist but can be inordinately slow when dealing with long strings. This is not an academic issue: one symptom is that \fIrelaynews\fR .Ix relaynews takes a long time to start up, eating 10-15 seconds of CPU time before it starts processing articles. This apparently is a combination of badly-written code and strange internationalization support. Just using our string functions, by telling \fIbuild\fR that your system does not have them, works much better. Telling the compiler \fB\-nointl\fR may be helpful if you don't want to go that far. .SH Old SCO Xenix vs. \fIsetvbuf\fP .Ix "botched libraries" .Ix problems "botched libraries" .Ix Unix "SCO Xenix" .Ix dbz .Ix problems setvbuf .Ix setvbuf .\" Ronald Khoo reported this unbelievable botch .PP The \fIdbz\fR package makes some use of the \fIsetvbuf\fR routine. Incredible though it sounds, old versions of SCO Xenix reportedly had the order of \fIsetvbuf\fR's arguments wrong! If you have SCO Xenix version 2.2 or earlier, check the arguments to \fIsetvbuf\fR: if the second and third are a type and a buffer pointer respectively (they are supposed to be a buffer pointer and a type), you're in trouble and will have to tinker with the \fIdbz\fR sources. .SH SunOS 4.1.1 vs. write() .Ix write .Ix problems SunOS 4.1 .Ix Unix "SunOS 4.1.1" .Ix problems "broken kernel" .Ix "broken kernel" .PP In some circumstances, a SunOS 4.1.1 \fIwrite\fR system call to a disk file can be interrupted by a signal. No other Unix does this, and routines like \fIfwrite\fR are not prepared to cope with it. This can result in gratuitous failures of \fIdbz\fR in particular. .PP It is thought not to be a problem in C News, but some other packages using \fIdbz\fR suffer, .Ix dbz and we mention it just in case. Sun acknowledges it as a bug. The bug-id is 1052649. It is fixed in patch 100293-01. .SH uucp Variations .Ix uucp .Ix problems queuelen .Ix queuelen .PP There are innumerable variations on the details of \fIuucp\fR that may require appropriate modifications to \fIqueuelen\fR. For example, some versions of Honey DanBer (aka BNU) \fIuucp\fR cut all system names down to seven characters, and \fIqueuelen\fR will have to be altered to do likewise. .SH malloc Variations .Ix malloc .Ix Unix A/UX .PP On some systems, performance is noticeably better if the \fB\-lmalloc\fR library is used, rather than relying on the \fImalloc\fR in the standard C library. A/UX is reportedly an example. .SH Slow egrep .Ix egrep .Ix "System V" breakage .Ix Unix "System V" .Ix Unix A/UX .PP At least some System V suppliers (including, reportedly, Apple in some [now obsolete?] A/UX versions) have broken \fIegrep\fR in such a way that it is inordinately slow. It may be worth substituting \fIgrep\fR for \fIegrep\fR in some of the shell scripts, with appropriate caution since they do not accept quite the same pattern syntax.