








             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


