HDTenEightyP/NetNews huggingface dataset:
From: andyh@syma.sussex.ac.uk (Andy Holyer)
Subject: Re: Editors
Organization: University of Sussex
Date: Thu, 17 Dec 1992 12:30:49 GMT

In article <BzDIJo.Jq1@cs.bham.ac.uk> axs@cs.bham.ac.uk (Aaron Sloman) writes:
>sfk@otter.hpl.hp.com (Steve Knight) writes:
>> My own conclusion would be (3), POPLOG should be extended to provide more
>> standard tools, such as mailers and readers, but this extension should NOT
>> be done using VED but using the X-toolkit interface.  It is completely
>> unacceptable to me to use a text editor to process my mail.
>
>It is completely unacceptable to me to have to use mouse and menus
>to process my mail. I want a collection of text editing facilities
>tailored to doing various things like, preparing a reply to the
>current message, deleting the current message, marking the current
>message, copying the current message to another file, creating an
>index of messages in the current file, going to a selected message,
>going to the next message, going to the previous message, going to
>the next message from the current sender, removing unwanted lines in
>the current mail header etc. etc. I would use function keys and/or
>ENTER commands for all of this.
>
Um... this might defuse the issue a bit:  remember that the concept of a
client-server architecture (which you're both referring to, and which BTW
would be really wonderful and we should do immediately) is actually a
completely independent thing from mice/windows/menus/X/etc. There's no real
reason why Steve's off-line mail and news readers shouldn't use a
character-based interface, with typed commands etc. I do agree however that
binding mailers and newsreaders to ved is not a good solution, largely because
ved is just *too* amorphous. Emacs I still feel does quite well as a
mail-reading environment, largely because it uses minor modes to stop you
oding anything too stupid to your messages.

A news-reader is not a text-editor (and vice-versa as well). It is a good
thing IMHO for their fuctionalities to be isolated (for a number of reasons
which I'm too lazy to go and look up). However there are certain features
which it would be useful for them to share - keyboard (or, yes, mouse)
mappings, text handling, programmability (whic I don't personally approve of,
but see no reason to explicitly ban). Hence the real challenge is to produce a
nice graceful API to this client-server architecture, allowing any fool to
throw together a news reader in a few days :-)

And yes, a lot of this probably should be in UIDE. What I described up there
won't. Which now I come to think of it, is something of a pity....

-Andy
-- 
&ndy Holyer, School of Cognitive and     |Due to recent events in the USA,
Computing Studies, University of Sussex, |I find I can no longer use this
JANET: andyh@cogs.sussex.ac.uk           |.sig quote. Normal service will
                                         |be resumed when I find another one.
Newsgroups: comp.lang.pop

In comp.lang.pop, tmr@cs.bham.ac.uk (Tim Read) writes:
> Using LIB * RC_GRAPHIC I wish to tile my window (created with rc_start) with
> a bitmap. I have tried doing:

When you find out the answer to this Tim, please can you post this as a 
library package?  I'll then add it to the PLUG source code archive.

(My only observation is that you clearly have to do _something_ with the
returned pixmap.  But, with X-windows, you're always having to RTFM because
it is so FCI [*])

Steve

[*] CI = Counter Intuitive
From: pop@cs.umass.edu ( Robin Popplestone )
Newsgroups: comp.lang.pop
Subject: Editors
Date: 11 Dec 92 21:03:47 GMT
Organization: University of Massachusetts, Amherst
Originator: pop@roo.cs.umass.edu

I must confess to using Ved for almost everything, even having hitched it
up to viewers for .dvi, .ps and .o files. In general computationally
literate culture (as opposed to computer science types) it would appear to
be evolving as more consistent with how most people actually use computers
than is EMACS, and thus arguably a more general purpose ASCII editor.

There are certain architectural features of EMACS one does like however.
The interpretation of commands via the neat argument descriptors for
functions is better than VED's ad-hoc vedargument stuff. The modes (like
them or not - often I feel imprisoned by modes) are an interesting
application of the shallow binding of variables (i.e. the simple
forms of dlocal in POP-11). Since shallow binding is usually regarded as a
BAD THING by theorists, one finds its use in EMACS interesting.
(Essentially an EMACS buffer has a set of shallow-bound variables which are
related to the mode, whereas VED in fact has a fixed set of shallow-bound
variables for each buffer).

It would be nice to find a POP-11 program which summarised one's mail file.

Robin
Newsgroups: comp.lang.pop
From: ianr@syma.sussex.ac.uk (Ian Rogers)
Subject: Re: POP syntax
Summary: Embaras de richesse
Keywords: syntax, list, lexical, unfortunate
Organization: University of Sussex at Brighton
Date: Fri, 18 Dec 1992 15:59:12 GMT

pop@cs.umass.edu ( Robin Popplestone ) writes:
> On a more radical note, I have been doing some C programming recently. Now
> as far as the semantics of C go, it feels rather like wiring one's house
> with bare copper. But one has to admit that the syntax has a certain
> concise elegance. Try out a CPOP (Popsie is already spoken for)
>
>     maplist(x,f) { x=[]?[]:f(x)::maplist(tl(x),f)}

Your definition won't work. Replace f(x) with f(hd(x)).

Besides, the (literaly) equivalent Pop11 is no less concise (or more clear :)

    define maplist(x, f); x=[]and[]or f(hd(x))::maplist(tl(x),f) enddefine;

Ian.
From: tmr@cs.bham.ac.uk (Tim Read)
Newsgroups: comp.lang.pop
Subject: Re: Editors
Date: 17 Dec 92 11:30:38 GMT
	<BzDIJo.Jq1@cs.bham.ac.uk>
Organization: School of Computer Science, University of Birmingham, UK

>>>>> On Wed, 16 Dec 1992 22:31:00 GMT, axs@cs.bham.ac.uk (Aaron Sloman) said:

> This would not be necessary if the sort of protocol I listed above
> were used, which would have the advantage that you could use the
> editor on a machine that did not have the files that Poplog had
> access to. (It's beginning to sound like a poplog version of NFS ?)

I think it sounds more like a poplog version of PLAN-9 ! That is the way to
go. NFS is just an unnecessary burden most of the time.

 Tim
--
    --------------------------------------------------------------------
    Tim Read, Email: tmr@cs.bham.ac.uk, The Attention and Affect Project
    Room LG23, School of Computer Science, The University of Birmingham,
    B15 2TT, England, Phone: +44-(0)21-414-4766, Fax: +44-(0)21-414-4281
    --------------------------------------------------------------------
From: sfk@otter.hpl.hp.com (Steve Knight)
Date: Wed, 16 Dec 1992 17:11:54 GMT
Subject: List and Vector Syntax (long)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
From: g_dotzel@tron.gun.de (Guenter Dotzel)
Newsgroups: comp.lang.modula2
Subject: Re^2: Generic stack implementation
Organization: TRON Public Mailbox, Neurath, Germany
Date: Thu, 17 Dec 1992 09:14:00 +0100

Message-Id:   <01.23294@ame.nbg.sub.org>

EEPJM%WOMBAT.NEWCASTLE.EDU.AU@USENET.ZER wrote on Tue, 12-15-1992 at 23:47 h
under the subject 'Re: Generic stack implementation':

> I know that Wirth's original idea was that uses of SYSTEM should be
> rare, so that importation of SYSTEM should act as a marker that
> something suspect is being done; but IMO this has failed because:
>  (a) there are some non-portable features which were (accidentally?)
>      left out of SYSTEM - e.g. address arithmetic, type BITSET,

Both problems solved by ISO_M2: 

1. Address arithmetic can only be done by SYSTEM.(ADDADR, SUBADR, DIFADR).

2. A new keyword PACKEDSET in addition to SET was introduced in ISO_M2
  to be able to declare a type such as BITSET. 
  
  TYPE BITSET = PACKEDSET OF [0..SIZE(BITSET)*8-1];
  
 The type BITSET is still pervasive and is not in SYSTEM (as in PiM).

>      type casting - so that it's possible to write non-portable code

Solved by ISO_M2's SYSTEM.CAST (T, expr). 
PiM's form T(expr) cast is no longer allowed.

>      without ever importing from SYSTEM.  This is especially evident
>      among programmers who learnt C before learning Modula-2.

You shouldn't learn C before Modula-2! This has to be guaranteed by
those who are responsible for programmers' education. :-)

>  (b) SYSTEM is too big, and contains some things that don't belong
>      there.  Every man and his dog ends up importing from SYSTEM,
>      so that uses of SYSTEM no longer stand out as being something
>      unusual.

> The solution, I believe, is to break up SYSTEM into a set of smaller
> low-level modules, to give the reader of a source listing a better
> idea of what low-level features are being used.  (Many M2 implementations
> already do this to a limited extent.  For example, it's become common
> to put TRANSFER/IOTRANSFER in a module other than SYSTEM.  This is a
> good example of something which didn't belong in SYSTEM in the first
> place.)  The low-level features of Modula-2 are certainly worth
> keeping (otherwise you drive people like me towards C and possible
> suicide), but their uses need to be flagged in a more visible way.

Already done in ISO_M2. SYSTEM is now very small, although individual
implementations are allowed to extend it. ISO_M2 has several
additional system modules for 

  -library exceptions,
  -language exceptions, 
  -termination, and
  -coroutines.

> One obvious approach, by the way, is to have a compiler option to
> generate warning messages for things which might be non-portable
> - e.g. type-casting.  Strangely, I've never seen a M2 compiler

No warnings needed in ISO_M2.

Guenter Dotzel, 
ModulaWare GmbH, Wilhelmstr. 17A, D-W 8520 Erlangen/F.R.Germany
Tel. +49 (9131) 208395, Fax +49 (9131) 28205.
E-mail/Internet: 100023.2527@compuserve.com
                 g_dotzel@ame.nbg.sub.org
From: andrea@ESSEX.STFX.CA (John Andrea)
Newsgroups: comp.lang.modula2
Subject: Re: Metrowerks Modula-2 on Macintosh
Date: 14 Dec 92 13:58:59 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet

I just got a catalogue from Macboutique (mail order in Canada 1-800-668-4477)
which lists Metrowerks Pascal 1.1 & Modula-2 4.0 for $49.00

still seems worthwhile for the price, to let me play with the Mac here at work.

john andrea
andrea@essex.stfx.ca
From: g_dotzel@tron.gun.de (Guenter Dotzel)
Newsgroups: comp.lang.modula2
Subject: summary of Oberon[-2] implementations
Organization: TRON Public Mailbox, Neurath, Germany
Date: Thu, 17 Dec 1992 08:55:00 +0100

Message-Id:   <01.23295@ame.nbg.sub.org>


In contrast to ISO M2 (which could help to solve all incompatiblities
and ambiguities), there are several different flavours of Oberon[-2].
There are not many ambiguities, but these have to be addressed; if possible
avoiding the overhead of international standardisation.

Here is an uncomplete summary of language reports and implementations.
There are other implementations, but I don't know what they are based on.
Please correct me if I'm wrong:

Oberon[-1],
  - PC/386 running under MS/DR-DOS Oberon System (ETH-Zuerich),
    current version V1.3 has 16 bit restrictions for array indices

Oberon-2 (Report 160 by H.P. Moessenboeck and N. Wirth, May 1991).
Oberon-2 Compilers based on the ETH-Report 160 (i.e. not based on OP2):

 - xTech Oberon-2 for PC/386 (xTech/Russia), no 16 bit restrictions,
   some language extensions.

 - Amiga Oberon (it's a nice Oberon-2 compiler with some minor extensions, such
   as the keyword STRUCT for RECORDS without type descriptor; I call this
   implementation "Froderon"; it comes with yet another library)

 - Andreas Borchert's Oberon-2 compiler (University Ulm/Germany)
   for ?-processor(s)/Unix

Oberon-2 (Report 160 by H.P. Moessenboeck, revised May 1992)

Oberon-2 (based on Crelier's portable compiler OP2, which itself is based on 
 the revised ETH-Report 160)

 - Oberon/386+ for MS Windows 3 (Robinson Associates/UK and FIM/Linz/Austria)

 - DecOberon (ETH-Zuerich)

 - H2O for VAX/VMS with ISO Modula-2 Standard Library (ModulaWare GmbH/Germany)

 - ??? for DEC 64 bit AlphaRISC AXP/OSF (DEC)

Guenter Dotzel, ModulaWare GmbH, Wilhelmstr. 17A, D-W 8520 Erlangen/F.R.Germany
Tel. +49 (9131) 208395, Fax +49 (9131) 28205.
E-mail/Internet: 100023.2527@compuserve.com
                 g_dotzel@ame.nbg.sub.org
From: John.Mcmonagle@f590.n139.z1.fidonet.org (John Mcmonagle)
Newsgroups: comp.lang.modula2
Subject: Compiler Tools
Date: Wed, 16 Dec 92 20:36:58 PDT
Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI

I have had several  inquiries in the last month for compiler tools. 

I know of 2 modula-2 systems.
Coco by P.Rechenberg and H.Mossenbock and
Rex and lalr-ell by Josef Grosch.
I hope I'm giving credit to the correct people.

Is there anyone who has used either of these?
If so what are there capabilites and limitations?
Which is better?


John McMonagle

-----------------------------------------------------------
| (414)468-6040 voice (414)465-0464 fax (414)465-1656 bbs | | PMI                     BIX as PMI                      | | 3279 N Nicolet Drive    zzmcmonaglej@gbvaxa.uwgb.edu    |
| Green Bay, WI 54311     Fidonet 1:139/590               | -----------------------------------------------------------
   


--  
uucp: uunet!m2xenix!puddle!139!590!John.Mcmonagle
Internet: John.Mcmonagle@f590.n139.z1.fidonet.org
From: andrea@ESSEX.STFX.CA (John Andrea)
Newsgroups: comp.lang.modula2
Subject: RE: DOS compilers
Date: 11 Dec 92 19:29:38 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet

>Woody  asks
>I need a DOS Modula-2 compiler that will pack subranges, for example,
>[0..255] would be stored in 1 BYTE.  The compiler that I ues store it as an
>INTEGER.

For a case like this i just use an ordinary character as a byte value
then do the conversions with the standard built in functions.

VAR
  c :CHAR;
  i :CARDINAL;

BEGIN

  i := 100;

  c := CHR( i );

  i := ORD( c );

  WriteCard( i, 0 );
    -----------> should show "100"

John Andrea
andrea@essex.stfx.ca
From: g_dotzel@tron.gun.de (Guenter Dotzel)
Newsgroups: comp.lang.modula2
Subject: Re^2: Generic stack implementation
Organization: TRON Public Mailbox, Neurath, Germany
Date: Tue, 15 Dec 1992 08:43:00 +0100

Message-Id:   <01.23293@ame.nbg.sub.org>

911288C%ACE.ACADIAU.CA@USENET.ZER wrote on Sat, 12-12-1992 at 19:17 h
under the subject 'Re: Generic stack implementation':

> >         item[wordcount] := location^;
> >         INC(location, TSIZE(WORD));
>               ^^^^^^
>               parameter not correct type ??
> 
>       Is this some problem ...???
>       I am using TopSpeed Modular-2.
> 
>       Can anybody help ??
>                                                       

In ISO Modula-2 (yes, I'm told that the document was dispatched in 14-Dec-1992)
this is written:

        location := SYSTEM.ADDADR(location, SIZE(WORD));


Guenter Dotzel, ModulaWare GmbH, Wilhelmstr. 17A, D-W 8520 Erlangen/F.R.Germany
Tel. +49 (9131) 208395, Fax +49 (9131) 28205.
E-mail/Internet: 100023.2527@compuserve.com
                 g_dotzel@ame.nbg.sub.org
From: jordan@aero.org (Larry M. Jordan)
Newsgroups: comp.lang.modula2
Subject: Free Modula-2 for UNIX?
Date: 16 Dec 1992 23:39:31 GMT
Organization: The Aerospace Corporation
NNTP-Posting-Host: uniblab.aero.org

From time to time I see requests for free Modula-2 Systems
for UNIX.  I've not seen a positive reply?!  If there is such
a system, would someone please post?  

Thanks,

--Larry %)
 
Newsgroups: comp.lang.modula2
From: seurer@rchland.vnet.ibm.com (Bill Seurer)
Subject: Re: Generic stack implementation
Date: Thu, 17 Dec 1992 15:08:09 GMT
Reply-To: BillSeurer@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

I have ported lots of Modula-2 and C code between machines with VASTLY
different architectures, especially when it comes to addresses.  The
Modula-2 code was generally easier to port but both it and the C code
suffered from one big problem.

On most Unix machines the size of pointers and integers is the same.
Vast amounts of C code is written that exploits this fact and makes it
extremely difficult to port to machines where this isn't the case.  Even
code that is supposed to be relatively machine independent usually has
this flaw.  Often it is very subtle, easy to miss, and worst of all, 
compiles OK.

The "ADDRESS is compatible with CARDINAL" part of Modula-2 is a mistake,
pure and simple.
-- 

- Bill Seurer     Language and Compiler Development      IBM Rochester, MN
  Internet: BillSeurer@vnet.ibm.com    America On-Line: BillSeurer@aol.com
Newsgroups: comp.lang.modula2
Subject: TDI Software Inc. (Modula2)
From: leb@violet.ccit.arizona.edu (BASEL, LESLIE)
Date: 11 Dec 1992 21:32 MST  
Distribution: world,local
Organization: University of Arizona
Keywords: Where
News-Software: VAX/VMS VNEWS 1.41    

I seem to have lost contact with TDI, who produced a M2 product for the 
Amiga.  It seems pretty good to me (but what do I know for sure).
Does anyone know if they are still in existence (where can they
be contacted) 
or
if someone else has picked up their M2 product?

Any help getting support would be appreciated.

Rodger Coghlan

PS I have version 3.00b if anyone is familiar with the product
Thanks
From: Rachel Harrison <R.Harrison@ecs.soton.ac.uk>
Newsgroups: comp.lang.modula2
Subject: public domain compiler wanted
Date: 14 Dec 92 08:25:23 GMT

Is there a public domain modula-2 compiler available for sun4/sparcs ?
And if there is, is it availble via ftp ?
Thanks,

R. Harrison                           email:  rh@ecs.soton.ac.uk 
Dept. of Electronics and Computer Science, 
307 Mountbatten Building, 
University of Southampton  
Southampton, SO9 5NH, UK 
Tel: +44 703 593249  Messages: +44 703 593649 Fax: +44 703 593045
From: Ian.Evans@puddle.fidonet.org (Ian Evans)
Newsgroups: comp.lang.modula2
Subject: BAUDEVILLE BBS...
Date: 11 Dec 92 09:21:11 GMT
Article-I.D.: puddle.29424.2B2B85FB
Organization: Pacific Systems Group

-> I'd like to F'REQ the FST 3.1 Modula-2 compiler at Baudeville
-> BBS(Toronto area).  First, do this BBS allow File Request?  Second,
-> what is the "magic name" for this (these) file(s).

I'm not set up for file requests here...however if you want to call, the
files are free downloads.

FM2V31A.ZIP  186860 bytes
FM2V31B.ZIP  209920 bytes

--  
uucp: uunet!m2xenix!puddle!Ian.Evans
Internet: Ian.Evans@puddle.fidonet.org
From: andrea@ESSEX.STFX.CA (John Andrea)
Newsgroups: comp.lang.modula2
Subject: Re: GENERIC TYPE IN MODULA-2
Date: 15 Dec 92 15:15:45 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Organization: The Internet


  I wrote
  >Unfortunately that approach removes type checking and you can put the wrong
  >data type into your tree.

  bevan replied
  >Not if you create a separate module where the parameters have the
  >correct type and must be coerced to the above.

But how many types could you have that you would want to have in a tree.
All the cards, ints, reals, chars, arrays of cards, arrays of chars,
records with a card and a sting, records with a string and a real, records
with two strings, ..... Quite a large variety, would you want to have a
module for every type.

  bevan also replied
  >Granted you could get this wrong, but if you do it once, you can use
  >it as a template and then just use search/replace to create a new
  >module with the correct type.  If the compiler is any good, it should
  >be able to inline all the interface procedures and so it doesn't cost
  >you anything at runtime.

Templates. Yes thats the way i do it. I don't use generic tree modules like
that as a pre-compiled library but i get the source code, make a part of the
current project and compile it as part of the current project.
  Its less useful that a true library module, but it does allow for code
reuse with no modifications so chances are that it works correctly.

John Andrea
Newsgroups: comp.lang.modula2
From: cspt@giraffe.ru.ac.za (Prof. P. Terry)
Subject: Re: Compiler Tools
Organization: Rhodes University, Grahamstown, South Africa
Date: Fri, 18 Dec 1992 08:55:00 GMT

In article <30679.2B30418D@puddle.fidonet.org> John.Mcmonagle@f590.n139.z1.fidonet.org (John Mcmonagle) writes:
>
>I know of 2 modula-2 systems.
>Coco by P.Rechenberg and H.Mossenbock and
>Rex and lalr-ell by Josef Grosch.
>I hope I'm giving credit to the correct people.
>
>Is there anyone who has used either of these?

I have used Coco, Coco-2 and Coco/r on PC's.

Coco/r is very easy to use.  It generates recursive descen parsers
I ported it to four PC compilers.  Send e-mail if you want to know more
(Pat.Terry of 5:7104/4 on Fidonet if you like)
Newsgroups: comp.lang.modula2
From: Benoit.St-jean@f159.n167.z1.fidonet.org (Benoit St-jean)
Newsgroups: comp.lang.modula2
Subject: FST
Date: Sun, 13 Dec 92 05:31:11 PDT
Organization: FidoNet node 1:167/159 - XON/XOFF Informatio, Montreal QC

YA>Benoit,
YA> I have FST 3.1 here in Saint-Jerome and I can send it to you. I send a netm
YA>to 167/159 but I didn't receive a response so. Leave me a netmail and It wou
YA>be possible.

Too late, je l'ai...


 * SLMR 2.1a * WATCH THIS!!      PrestO! ChangeO!   

--  
uucp: uunet!m2xenix!puddle!167!159!Benoit.St-jean
Internet: Benoit.St-jean@f159.n167.z1.fidonet.org
Newsgroups: comp.lang.modula2
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Subject: Re: Generic stack implementation
Organization: University of Newcastle, AUSTRALIA
Date: Mon, 14 Dec 1992 02:37:50 GMT

In article <911288c.32.724187845@ace.acadiau.ca>, 911288c@ace.acadiau.ca (HON (EDWIN) KIN CHUNG) writes:

>>VAR
>>   [...]
>>   location: ADDRESS;
>>BEGIN
>>   [...]
>>         INC(location, TSIZE(WORD));
> 		^^^^^^
> 		parameter not correct type ??
> 
> 	Is this some problem ...???
> 	I am using TopSpeed Modular-2.

TopSpeed Modula-2 won't let you do arithmetic on addresses.  And a
good thing, too, in my opinion.  Address arithmetic is one of the
most non-portable things you can do, and I'm a little shocked to
see an example of it in a textbook.

There's a procedure in one of the TopSpeed libraries called AddAddr
or something similar (sorry I can't be more explicit, my TopSpeed
manuals are at home) which will be an adequate substitute for the
INC in this example.  A better solution, though, would be to 
redesign the algorithm so that it didn't need to do address arithmetic.

-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au
Newsgroups: comp.lang.modula2
Subject: Re: DOS compilers
Reply-To: tchannon@black.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: null
Date: Wed, 16 Dec 1992 03:06:04 +0000

> : >>I need a DOS Modula-2 compiler that will pack subranges, for example,
> : >>[0..255] would be stored in 1 BYTE.  The compiler that I ues store it as
> : 
> : Problem is I'm doing cross platform development and my code already takes
> : advantage of subrange packing on the Mac side.
> 
> Most DOS compilers should -- for one I know that the TopSpeed
> compilers pack all data types into the smallest possible memory.  You

I checked when I saw the posting and JPI V3.02 does not seem to pack CARDINALs
which have a subrange of <= 255
It does pack BITSET and this is very useful for sets of flags, particularly
when the underlying data has to exactly match a binary file.

Personally I am nervous about relying on particular optimisations used by a
compiler because of just this sort of problem.

Maintenance might be easier if an explicit cast is used at some point instead
of a completely hidden side effect?

  TC. 
    E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
                                nu.c