








             Known Porting Problems With C News


                       Henry Spencer

                      Dept. of Zoology
                   University of Toronto





_I_n_t_r_o

     C News in general is pretty portable.  People have  got
it  to run on a very wide range of systems with little trou-
ble.  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.

_U_n_i_x _D_e_p_e_n_d_e_n_c_i_e_s

     The biggest portability glitch in C  News  is  that  it
depends  a lot on Unix utilities.  The extensive use of com-
plex shell files, _s_e_d and _a_w_k 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 _r_e_a_d  system  calls  in  _e_x_p_i_r_e,  to
avoid  difficulties  with stdio end-of-file behavior; we now
know how to avoid this but  haven't  implemented  the  fixes
yet.)

     We know that _a_w_k and the colon (:) operator of _e_x_p_r are
problem areas under Minix.

_S_h_e_l_l _P_r_o_b_l_e_m_s

     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.

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



                       10 Dec 1990





                           - 2 -


everywhere.  We know that at least some  releases  of  Xenix
have  this  problem.   It  is not necessary that your kernel
understand the ``#!'' feature-we believe that nothing  in  C
News  relies  on  it-but  it  is essential that it not cause
invocation of the C Shell.

     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:

        x=y
        if test " $x" != " y"
        then
                echo oops
        fi

prints ``oops''.  This is, again, big trouble, because we do
that a lot.

     Many people using 3B1s, aka  UNIX  PCs,  run  the  Korn
shell  as  their /_b_i_n/_s_h.  Some other folks may do this too.
Beware that _k_s_h was not fully _s_h-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 _i_n_e_w_s, are known to hit these bugs.  We are
_t_o_l_d that current _k_s_hs have fixed them.

     It is reliably reported that SunOS  4.0._x  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.

     It is reliably reported that the VAX 3.1  Ultrix  shell
is  somewhat  broken  and  gives  various  kinds of trouble.
Switching to /_b_i_n/_s_h_5 (note that this  requires  fixing  the
first  line  of a zillion shell files) is reported to banish
the problems.

     In some environments, when processing batches which are
not  compressed, extremely mysterious malfunctions occur and
messages reporting a _r_e_l_a_y_n_e_w_s exit status of 1005 (and  the
like)  are  seen.  This is believed to be a subtle shell bug
that shows up when a pipeline is used as the condition in  a
shell  _i_f.   Unless  you use _c_7_e_n_c_o_d_ed transmission-which is
very rare-a workaround is to comment out the following lines
in _i_n_p_u_t/_n_e_w_s_r_u_n:

        elif c7decode <$f 2>/dev/null | compress -d >$text 2>/dev/null
        then
                : okay

A minor bonus is that this  will  improve  processing  speed
(!).   We  plan  improvements  to input processing, and this



                       10 Dec 1990





                           - 3 -


problem should be eliminated as a side effect of that.

     (Note, this is _n_o_t  the  well-known  bug  of  many  old
shells,  in which the choice of process whose exit status is
picked up is semi-random in such situations.   Exercise  for
the reader:  show that _t_h_a_t is not a problem in _n_e_w_s_r_u_n.)

_M_a_k_e _v_s. _T_e_s_t

     There is a persistent problem on 3B2s with  implementa-
tions  of  _m_a_k_e 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 metacharac-
ters.  This means that if-as on many 3B2s-_t_e_s_t  is  a  shell
builtin _a_n_d _t_h_e_r_e _i_s _n_o /_b_i_n/_t_e_s_t _p_r_o_g_r_a_m, the makefile line
``test -s file'' will cause _m_a_k_e to complain about  an  unk-
nown 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 _m_a_k_e to run a shell on  the  sys-
tems  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.

_O_f_f_s_e_t_o_f

     ANSI C requires C compilers to supply a macro _o_f_f_s_e_t_o_f,
which  can  be used to find the offset of a structure member
within the structure.  _R_e_l_a_y_n_e_w_s's header-parsing code  uses
it,  defining  it if the system has not supplied it.  Unfor-
tunately, it is really hard to write a portable  version  of
this.  The implementation we currently use is:

        #define offsetof(type, mem) ((char *)&((type *)NULL)->mem - (char *)NULL)

The table in _r_e_l_a_y/_h_d_r_d_e_f_s._c puts invocations of _o_f_f_s_e_t_o_f in
initializers.  This turns out to be a severe stress test for
C compilers.  A compilation error  in  _h_d_r_d_e_f_s._c  is  almost
certain  to  be  problems  with this macro.  Some compilers,
notably the one in Microport System V for  the  286,  reject
it.   We  have heard a report that System V Release 2 on the
VAX silently miscompiles  it!   If  you  have  trouble  with
_o_f_f_s_e_t_o_f, you might try this version instead:

        #define offsetof(type, mem) ((int)&((type *)NULL)->mem)


_F_a_s_t _S_t_d_i_o _R_o_u_t_i_n_e_s

     We supply a set of fast standard-I/O routines that  are
compatible  with most AT&T-derived implementations of _s_t_d_i_o.
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



                       10 Dec 1990





                           - 4 -


problems 100% of the time.  It has been reported in the past
that A/UX and Microport 386 stdios 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 rou-
tines run correctly under it.

     In any case, if you are feeling nervous or  are  having
mysterious  problems,  telling  _b_u_i_l_d that you don't want to
use the fast-stdio stuff is always safe.

_v_o_i_d

     Old compilers that don't understand the _v_o_i_d type  will
choke  on  much  of  our  code.   There  is  a commented-out
``#define void int'' in _n_e_w_s._h 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  _l_i_b_v_7  if  you're
using  that  library.)  C  News  does not rely on the ANSI C
``void *'' type as far as we know.

_R_e_a_d/_w_r_i_t_e _M_o_d_e_s _i_n _f_o_p_e_n

     Unix V7 documented only  ``r'',  ``w'',  and  ``a''  as
suitable  mode  arguments to _f_o_p_e_n.  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.

_M_A_X_L_O_N_G

     The _r_e_l_a_y/_c_p_u._h file formerly defined a  constant  _M_A_X_-
_L_O_N_G  which  is  the  biggest positive value of a _l_o_n_g.  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 _r_e_l_a_y_n_e_w_s is asked
to process a single article, not a batch.  This happens pri-
marily when an article is posted locally, with _i_n_e_w_s.) It is
still barely possible that the plausibility check will  fail
on some bizarre system.

_d_f _O_u_t_p_u_t _F_o_r_m_a_t

     The _s_p_a_c_e_f_o_r utility needs  to  understand  the  output
format  of  _d_f.  There are numerous variations on _d_f.  _B_u_i_l_d
and the relevant makefiles know about the more common  ones,
but  customization  may be necessary.  _S_p_a_c_e_f_o_r is commented
well enough that it should be possible  to  figure  out  the
necessary  changes; usually the initializations of _n_r and _n_f
are all that need changing.  If there are colons (:) in your
_d_f's  output  format,  you  should  probably  start from the



                       10 Dec 1990





                           - 5 -


``sysv'' _s_p_a_c_e_f_o_r, which attempts to preprocess  the  output
to get rid of System V garbage; otherwise the ``bsd'' one is
a reasonable starting point.

     One constant nuisance is _d_fs that  are  too  stupid  to
take  a  directory name as an argument.  The long-term solu-
tion to this is to edit a suitable variant  of  _s_p_a_c_e_f_o_r  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.

     We're told that HP-UX 7.0 users  are  best  advised  to
choose  the ``bsd'' variant of spacefor, and edit it to call
_b_d_f instead of _d_f.  Similar  approaches  may  be  useful  on
other hybrid SysV/BSD systems.

_F_l_o_a_t_i_n_g _P_o_i_n_t

     The only place in C News where floating point is  used,
as  far as we know, is in the calculation of expiry dates in
_e_x_p_i_r_e.  This is  not  a  performance  bottleneck,  so  slow
floating-point   arithmetic  is  not  a  problem.   Complete
absence of floating point would require minor  modifications
to _e_x_p_i_r_e.

_3_8_6 _O_p_t_i_m_i_z_e_r _v_s. _d_b_z

     We have a reliable report that the System V 386  optim-
izer  (invoked  when  _c_c is given the -O option) miscompiles
the _d_b_z package badly enough to cripple it, without  produc-
ing  any  error  messages.   The  only fix is to compile _d_b_z
without -O.

     SCO Xenix/386 2.3 has the same problem.

_n_n_a_f_r_e_e _a_n_d _n_n_f_r_e_e

     We have a reliable report that the HP Spectrum  C  com-
piler  has  an  optimiser bug that makes it throw up (with a
``cc: Internal error 3279:  Please  contact  your  local  HP
representative''  message) on the _n_n_a_f_r_e_e macro (and _n_n_f_r_e_e,
a historical synonym) in _h/_n_e_w_s._h.   The  following  revised
version of the macro reportedly avoids the problem.

        #define nnafree(mempp) do { if (*(mempp) != 0) { free((char *)*(mempp)); \
           *(mempp) = 0; }} while (0)


     It is also reliably reported that  the  Microport  com-
piler  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



                       10 Dec 1990





                           - 6 -


function  can,  in  fact,  be  found  in  _h/_n_e_w_s._h,   inside
`#ifdef lint'.

_A_N_S_I _C

     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 com-
plaints from ANSI C compilers.

     Work is in progress on moving us closer to ANSI  compa-
tibility.   Beware  that if __STDC__ is defined by your com-
piler but it is _n_o_t 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  preproces-
sors  choke  on  the  appearance of an unknown identifier in
#if.)

_G_N_U _C

     If compiling with the GNU compiler, you  may  need  the
-traditional flag.  Beware, also, that if you are using your
system's _d_b_m 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 -fpcc-struct-return option cures this.

_A_w_k _P_r_o_b_l_e_m_s

     A number of problems can arise if your  _a_w_k  has  bugs,
since  the  shell files rely on _a_w_k fairly extensively.  For
example, _a_w_k is a prime suspect if  _s_p_a_c_e_f_o_r  doesn't  work.
We've  fixed  the  worst trouble spots, but would appreciate
detailed information on any more.

     One known problem that is hard to avoid is  line-length
limits  in  _a_w_k.   In  particular,  for  several purposes in
control-message handling C News wants to build  a  ``canoni-
cal''  representation of the _s_y_s file, with backslashed new-
lines removed.  This is done by  NEWSBIN/_r_e_l_a_y/_c_a_n_o_n_s_y_s._a_w_k.
Most _a_w_ks have limits on line length, and some of the limits
are too low to cope with long multiply-continued _s_y_s  lines.
512-byte limits, found in a number of old _a_w_ks, are particu-
larly troublesome.  A quick look indicates  that  this  will
interfere,  to  some  uncertain extent, with _c_h_e_c_k_g_r_o_u_p_s and
_s_e_n_d_s_y_s.  Big deal. :-) The complaint may also  appear  from
_n_e_w_g_r_o_u_p, but there it should be harmless.

_S_y_s_t_e_m_s _W_i_t_h_o_u_t _H_a_r_d _L_i_n_k_s

     Some vaguely Unixoid systems have trouble  implementing



                       10 Dec 1990





                           - 7 -


real (``hard'') links.  Examples are VMS in general and Eun-
ice in particular.  There are some hooks  for  dealing  with
this, but it's not trivial.

     _R_e_l_a_y_n_e_w_s will try to make symbolic links if real  ones
fail.  There is one exception: if _r_e_l_a_y_n_e_w_s 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 essen-
tially never happen except on 16-bit machines, and should be
rare even on them.

     _E_x_p_i_r_e has a -l 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  oth-
ers.  This has not been tested much recently.

     The locking system (both C routines  and  the  _n_e_w_s_l_o_c_k
program)  will need revision in some system-dependent way to
avoid use of links.

     There is one minor use of links in installation  (_i_n_e_w_s
is  found  in  two  places, and the Makefile attempts a link
before doing a copy), and substantially more in the  regres-
sion tests.

_1_6-_b_i_t _M_a_c_h_i_n_e_s

     C News has been tested  on  16-bit  machines-indeed,  a
good  bit  of the early development work was done on one-and
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.

     However, there are some fundamental limits to consider.
Both  _r_e_l_a_y_n_e_w_s and _e_x_p_i_r_e-the usual trouble spots for space
shortages-want to keep lots of stuff in core.   There  isn't
any easy way around this one.

_N_u_m_b_e_r _o_f _F_i_l_e _D_e_s_c_r_i_p_t_o_r_s

     There is a constant, NOPENBFS, in _r_e_l_a_y/_t_r_b_a_t_c_h._c, that
defines  how  many batch files are kept open simultaneously.
If you are feeding much news  to  more  systems  than  this,
_r_e_l_a_y_n_e_w_s performance will suffer.

     The major limit on NOPENBFS is available file  descrip-
tors  (although  on  a  16-bit machine there might also be a
shortage of memory  for  _s_t_d_i_o  buffers).   Other  parts  of
_r_e_l_a_y_n_e_w_s   want  perhaps  10  file  descriptors  for  other



                       10 Dec 1990





                           - 8 -


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.

_S_h_e_l_l _P_r_o_c_e_s_s_i_n_g _O_r_d_e_r

     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, _r_e_l_a_y/_s_h/_a_n_n_e._j_o_n_e_s, which can be fixed by
changing (circa line 44)

        "")     USER="`who am i <&$fd |

to

        "")     USER="`eval \"who am i <&$fd\" |

or so we are told.

_B_i_n_a_r_y-_M_o_d_e _F_o_p_e_n

     In several places, the new _d_b_z  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 _f_o_p_e_n, so it all works out nicely.

     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.

     Meanwhile, the fix is to delete the `b's in the  second
arguments  of  the  _f_o_p_e_ns  in  three places in _d_b_m_i_n_i_t() in
_d_b_z/_d_b_z._c, if your system has this particular bit  of  brain
damage.

_s_i_z_e__t

     Some systems, notably from Microport, do not define the
_s_i_z_e__t  type in the <_s_y_s/_t_y_p_e_s._h> header.  Worse, the _s_i_z_e__t
in that header doesn't necessarily bear any relationship  to
the  ANSI  C _s_i_z_e__t.  This causes trouble in the _d_b_z library
in particular.  The proper type for _s_i_z_e__t is whatever the C
_s_i_z_e_o_f 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 _s_i_z_e__t must also be suitable for use in the two  middle
arguments  of _f_r_e_a_d and _f_w_r_i_t_e, the last argument of _m_e_m_c_p_y,



                       10 Dec 1990





                           - 9 -


_m_e_m_c_h_r, and _m_e_m_c_m_p, and the argument of _m_a_l_l_o_c.

_B_a_c_k_g_r_o_u_n_d _P_r_o_c_e_s_s_e_s _v_s. _c_s_h

     _I_n_e_w_s runs much of its processing  in  the  background.
We  are  told  that  this  can  hit  problems,  in some cir-
cumstances, with _c_s_h'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  compen-
sate for its failings.  We do sympathize with people victim-
ized by it, but can be of no practical help.

_C_o_m_p_r_e_s_s _O_p_t_i_o_n_s

     Some imbecilic vendors have altered _c_o_m_p_r_e_s_s so that it
must  be  given  a -u option (instead of the standard -d) to
uncompress a file.  The symptoms of this are strange:  local
postings  and  occasional  outside articles come through all
right (because they weren't compressed),  but  most  outside
traffic  gets rejected by _r_e_l_a_y_n_e_w_s, which complains that it
lacks `Path:' lines.  In general, a complaint about  a  lack
of  `Path:'  tends  to  mean  that  _r_e_l_a_y_n_e_w_s  got fed total
gibberish.

_u_l_i_m_i_t

     Most versions of System V have the concept of _u_l_i_m_i_t, 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  _i_n_i_t  or _l_o_g_i_n 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, _r_e_l_a_y_n_e_w_s, _e_x_p_i_r_e, etc.  need  to
be  able  to work with the _h_i_s_t_o_r_y file, 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
_u_u_c_p or other transport  software  bringing  in  news,  from
_c_r_o_n, and by users via _i_n_e_w_s for local postings.  It is dif-
ficult  to  do  this  in  a  portable  way  when  super-user
privileges are needed.

_R_e_s_t_r_i_c_t_e_d _S_h_e_l_l_s

     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 /_b_i_n/_s_h,
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



                       10 Dec 1990





                           - 10 -


and there is a shell file named, say, _r_n_e_w_s whose first line
is `#! /bin/sh', this shell file will end  up  invoking  the
restricted shell!

     Simply deleting the `#!' line might fix this;  on  sys-
tems  which  have  the  Korn shell, changing `#! /bin/sh' to
`#! /bin/ksh'  might  work.   Otherwise  you  will  have  to
arrange  to  have  your neighbors invoke _c_u_n_b_a_t_c_h instead of
_r_n_e_w_s, or else write a simple _r_n_e_w_s 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  _r_n_e_w_s
definitely isn't the only one.

_R_e_m_o_t_e _I_n_v_o_c_a_t_i_o_n _v_s. _N_o_n_s_t_a_n_d_a_r_d _S_h_e_l_l_s

     When _n_e_w_s_r_u_n is invoked on a host that is not the  news
server, it uses _r_s_h to propagate news batches to the server.
It runs /_b_i_n/_s_h 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  _n_e_w_s_r_u_n
will  emit  spurious  output if its invoker's login shell is
the C shell and its invoker's ._c_s_h_r_c contains commands  that
generate  output.   A  similar  problem occurs with _b_a_s_h and
._b_a_s_h_r_c.

     The simplest solution is to use /_b_i_n/_s_h  as  the  login
shell  for  _n_e_w_s_r_u_n's  invoker.   Otherwise,  if  you have a
networked news server, check that the login shell  is  stan-
dard  enough  to  invoke  /_b_i_n/_s_h by executing the following
command as _n_e_w_s_r_u_n's invoker.

        rsh _n_e_w_s_s_e_r_v_e_r exec /bin/sh -c true

This command should output nothing.

     A slightly related problem is that not  everyone  calls
the run-remote-shell command _r_s_h; on System V in particular,
_r_s_h 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 _r_s_h shell file in the search path to invoke
the right command in the right way, whatever that is.

_V_a_l_u_e_s _o_f _L_o_g_i_c_a_l _O_p_e_r_a_t_o_r_s

     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

        *p++ = isascii(c) && isalnum(c);

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



                       10 Dec 1990





                           - 11 -


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 con-
text.

_E_m_p_t_y _L_i_n_e_s

     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
_r_e_l_a_y_n_e_w_s  will  tolerate white space only in certain places
in the _s_y_s file, and in particular, it tolerates empty lines
but  not lines consisting solely of white space.  The result
will be complaints (in _e_r_r_l_o_g) about white space in the  _s_y_s
line for a system named `` ''.

_a_c_t_i_v_e-_F_i_l_e _D_a_t_e

     On some Bull  systems,  at  least  ones  running  DPX/2
B.O.S. 1.0, apparently _r_e_l_a_y_n_e_w_s updates the contents of the
_a_c_t_i_v_e  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  effec-
tive, is to add the line

        utime(ctlfile(actrelnm), (time_t *)NULL);

after   the    call    to    _n_n_a_f_r_e_e    in    _a_c_t_f_s_y_n_c    in
_l_i_b_b_i_g/_a_c_t_i_v_e._b_i_g._c.

_e_n_u_m _O_p_e_r_a_t_o_r_s

     Some compilers have difficulty compiling  the  _r_e_a_d_n_e_w_s
we  supply, because they object to applying the `!' operator
to an _e_n_u_m type.  Changing the  definition  of  _b_o_o_l_t_y_p_e  in
_r_n_a/_d_e_f_s._h to

        typedef int bool;
        #define false   0
        #define true    1

is reported to solve this.











                       10 Dec 1990


