HDTenEightyP/NetNews huggingface dataset:
From: g5000005@nickel.laurentian.ca
Subject: re: Should I buy BC++ 3.1??
Organization: Laurentian University
Date: Sat, 5 Sep 1992 02:02:13 GMT

In article <cee1@ra.msstate.edu (Charles Evans), 3 Sep 92> writes:


>>trees etc etc. So I am wondering, is it worth my $99? I know that v. 3.1
  [stuff deleted]
>>C++ 2.0 on my shelf... what can I do with all these things on my shelf.. it
	
	Charles, my advice is to really get familiar with C++ before worrying
	about upgrading to the latest version. Chances are, that by the time
	you are really comfortable with C++, version +20 upgrade will be around
	which will cover all previous upgrades. With this route, you don't
	accumulate 'things' on your shelf! ;^)


>>just looks like a waste to me. Spend a 100 bucks for each pop and then what..

	Yup.


>>(I think) DOS 7.0 will be a COMPLETE rewrite redo everything. Should I wait?

	Yup again!

>>any pointers or pointers to pointers to int would be helpful.

	Just my CAN$ 0.0375 worth....

>>chuck
 
>>+--------------------+-----------------------+------------------------+
>>|  Charles E. Evans  |  cee1@ra.msstate.edu  |  All things are green  |
>>|    iDLE CHATTEr    |  cee1@MSSTATE.BITNET  |  unless they are not.  |
>>+--------------------+-----------------------+------------------------+

Norm Neil
G5000005@nickel.laurentian.ca
From: sakamoto@sm.sony.co.jp (Tomohiko Sakamoto)
Newsgroups: comp.lang.c
Subject: Re: Dropping a n from a fprintf()
Date: 11 Sep 92 06:28:06 GMT
Reply-To: sakamoto@sm.sony.co.jp
Organization: Workstation Div., Supermicro Systems Group, Sony Corporation

In article <1992Sep11.052108.26159@ra.msstate.edu>,
        cee1@ra.msstate.edu (Charles Evans) says:
> fscanf(fp1,"%s",item)  .. seems to be giving EVERYTIME a Segmentation
> Fault (UNIX) in that line. so we went to fgets.. what can I do to get
> it all on one line.. thanks

How about this?

/**************************************************************/
#include <stdio.h>

main()
{
	FILE *fp1 = stdin;
	FILE *fp2 = stdout;
	char item[20];

	while (fscanf(fp1, "%19s", item) == 1)
		fprintf(fp2, "I found a %s in my pockect.\n", item);
}

--
T. Sakamoto
From: dhesi@cirrus.com (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: How to handle __STDC__
Date: 8 Sep 92 20:10:28 GMT
Organization: Cirrus Logic Inc.

In <1992Aug31.195504.4847@cirrus.com> I wrote:

>4.   A non-ANSI C compiler can define anything it wants to without
>changing its standard-conformance status.


Correction:

Chris Torek was kind enough to point out that the above statement is
not entirely accurate.  The non-ANSI C compiler might accidentally
become conformant!  For example, if the only reason for being
nonconformant was a missing predefined __STDC__, then this non-ANSI C
compiler can't define __STDC__ without changing its standard-
conformance status.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net
Newsgroups: comp.lang.c
From: bosullvn@unix1.tcd.ie (Bryan O'Sullivan)
Subject: Re: EASY C
Organization: Department of Computer Science, Trinity College, Dublin, Ireland
Date: Fri, 11 Sep 1992 09:50:02 GMT

faivre@cst02.segin.com (Denis Faivre) writes:

>This is definitely no joke. I know someone seriously considering to "adapt" C
>(for COBOL programmers, as you guessed it in your second message) by such a
>technique as EASY C.
>That's why I'm wondering if anybody around did experience EASY C or any analog
>pseudo-language.
>What are pros and cons of using it ?

There are no pros, only cons.  I have come into contact with
"profesionally-written" C which uses cpp to make the language look
like FORTRAN.  This is incredibly annoying, and a serious abuse of
the preprocessor as far as I'm concerned.  Fortunately, I don't
have to maintain the crud (only try and understand it, which is
hard enough), however.

Put very bluntly, I have serious doubts about the competence of
any programmer who "needs" to make C look like FORTRAN, COBOL, or
whatever before feeling able to program in the language.  Abuses
of cpp in this fashion are like violations of the One True Brace
Style; fine if you're working by yourself, but if you expect other
people to even look at your code, forget it.

	-- Bryan

--
Bryan O'Sullivan                                                 +353-1-767551
Advanced Development Group                               bosullvn@unix1.tcd.ie
Department of Computer Science            "No matter how cynical you are, it's
University of Dublin                       hard to keep up." -- Woody Allen
Newsgroups: comp.lang.c
From: wkaufman@us.oracle.com (William Kaufman)
Subject: Re: Realloc question
Organization: Oracle Corporation, Redwood Shores CA
Date: Sat, 5 Sep 1992 15:12:00 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1992Sep4.100203.1@ducvax.auburn.edu>
swanger@ducvax.auburn.edu asks about realloc'ing an array of char
pointers...

In article <1992Sep4.162111.9719@PDX.MENTORG.COM>
davidr@mentorg.com (David Ransier) writes:
] I'm jumping out on a limb here, given that I am no expert.  In fact
] I'm kind of a newbie here also, but it seems to me a better way to
] implement this is with a linked list, which can be extended easily,
] until you run out of memory.

    That's kind of a toss-up.  Doing it as an array lets you run some
standard library sorts, like qsort, on it.  And a linked list wastes a
pointer or two of memory--not enough to worry about, really, but enough
to avoid if there isn't a reason for it.

] Another alternative is to create a larger
] array of pointers to your strings instead of an array of strings.  The
] initial memory space used by an array of pointers should be much smaller
] than allocating space for some fixed lengh strings.

    This I agree with whole-heartedly.  I find fixed-length strings, ala

        char (*str)[MAXLEN];

reprehensible.  The code looks a bit uglier (to me), even though you
avoid a malloc for each string; and it's difficult to get it to handle
lines longer than MAXLEN correctly.  But this falls somewhere between
style and taste.

In article <HURTTA.92Sep4202941@plootu.Helsinki.FI>
hurtta@cs.Helsinki.FI (Kari E. Hurtta) writes:
] 
]   strings = (char **) realloc (strings, new_num_strings * sizeof(char*));

    This one is only guaranteed on machines that have only one type of
(machine-level) pointer, or use an ANSI C compiler with full
prototyping.  The casts really are necessary otherwise, especially on
the (strings) pointer.

    Actually, only the cast to (char **) is uncessary, if realloc()'s
declaration is in scope.  If it isn't, no amount of casting will help on
machines with different pointer types.

                                           -- Bill K.

Bill Kaufman,          | "...all conscious species are plastic and
Corporate Lackey       |  all plastic species are conscious."
wkaufman@us.oracle.com |                     -- Yew-Kwang Ng
From: svleest@jobim.crhc.uiuc.edu (Steve VanderLeest)
Newsgroups: comp.lang.c
Subject: Re: Quick C for Windows
Date: 8 Sep 1992 14:03:59 GMT
Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
Distribution: world
NNTP-Posting-Host: jobim.crhc.uiuc.edu
Keywords: Quick C

In article <hugie.715561611@sfu.ca>, hugie@beaufort.sfu.ca (Don Hugie) writes:
|>   Does anyone out there have any experience with Quick C for Windows? 
|> Specifically, I'm interested in knowing if this compiler will compile
|> bare ANSI code.  I would like to have a Windows compiler but I have
|> ANSI code that I don't want to add Microsoft extenstions to. Thanks...

I believe QC will allow you to compile one of several ways --

1) A full MS-Windows implementation
2) A normal ANSI-C program with a "toy" windows wrapper
3) A normal ANSI-C program that runs under DOS

--
Steve VanderLeest	Center for Reliable and High Performance Computing
			University of Illinois
...........................................................................
"...post this, post that.  Everything is post these days, as if we're all 
just a footnote to something earlier that was real enough to have a name 
of its own."  _Cat's Eye_
From: c23rrj@kocrsv01.delcoelect.com (Rajnish Joshi)
Newsgroups: comp.lang.c
Subject: system call in C
Date: 14 Sep 92 17:04:54 GMT
Organization: Delco Electronics Corp.
Originator: c23rrj@kocrsw04


Help !  If I make a system call (from a C prog.) such as

             system (command);

 where 'command' may be a command to compile some program, then how can I
obtain the process-id of the process which is doing the compile task. The sytem
call returns only the success code. I need to know the pid of the requested
command since I want to use it in the C code that follow the system call.

Thanks

Raj
-- 
**************************************************************************
  Rajnish Joshi              Phone: (317) 451-0643   GM Line: 8-322-0643
  Software Technology         UUCP: deaes!c23rrj
  Delco Electronics Corp.    Internet: c23rrj@kocrsv01.delcoelect.com
From: Jon Freivald <jaf@jaflrn.UUCP>
Newsgroups: comp.lang.c
Subject: Re: Command Line Arguments
Date: Sat, 12 Sep 92 02:11:04 EDT
Organization: The Wizzard's Cave, East Meadow, NY

bx314@cleveland.Freenet.Edu (Joseph J. Gebis) writes:

> 
> 	I would like to know how to pass command line arguments in DOS
> to a separate function...  I would greatly appreciate if someone
> would write an example of a program that passes command line arguments
> to a separate function that then prints them on screen.
> 
> 	Remember, I'm self-taught, and a beginner, so speak slowly
> and loudly. :)
> 	Thank you very much.

#include <stdio.h>

int main ( int argc, char **argv )

{
    int i;

    for ( i=0 ; i < argc ; i++ )
        {
        show_me(argv[i]);
        }
}

void show_me (char *argv_i)

{
    printf ("Arg: %s", argv_i);
}

=============================================================================
		   Jon Freivald ( jaflrn!jaf@uunet.UU.NET )
	 Nothing is impossible for the man who doesn't have to do it.
=============================================================================
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: sscanf and portability
Summary: TYPO ALERT AND APOLOGY
Date: 15 Sep 92 06:44:45 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <14544@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> The ANSI stndard guarantees that
           ^^^^^^^ should be "standard", sorry
>     [unsigned|signed] char	at least 8 bits
>     [unsigned] short		at least 16 bits
>     [unsigned] long		at least 32 bits
>     sizeof (long) >= sizeof (int) >= sizeof (short) >= sizeof (char) >= 1
                                                                       ^^
That of course must be ==.  I do assure you it was a typo, not a thinko.
-- 
You can lie with statistics ... but not to a statistician.
Xref: sparky comp.lang.c:13467 comp.sources.d:1257 misc.misc:3286 alt.sources:2049 comp.unix.wizards:3875
Newsgroups: comp.lang.c,comp.sources.d,misc.misc,alt.sources,comp.unix.wizards
From: nathan@elberton (Nathan Sidwell)
Subject: Re: 1992 International Obfuscated C Code Contest winners
X-Newsreader: Tin 1.1 PL5
Date: Thu, 10 Sep 92 13:50:01 BST

Landon C. Noll (chongo@hoptoad.uucp) wrote:
: [the shar files]

As chongo stated, my entry can't be posted from the USA. So
I'm posting it from the UK, replace the shar'ed nathan.c with this code.

----8<-- cut here to break your display --->8----
#include <stdio.h>                     
#include <string.h>                    
#define printf sqrt                     
#define OFST 1                          
#define strnel(sqrt)(sqrt-printf)      
                                       
int main(argv,argc)int argv;char*argc[]
;{char*i,*sqrt,*magic,*define;int ptr,\
                watch,                 
                t,cond                 
                ;for(                  
                argc++                 
                ,sqrt=                 
"1""q""a""z""2""w""s""x""3""e""d""c""4"
"r""f""v""5""t""g""b""6""y""h""n""7""u"
                                       
"j""m""8""i""k"",""9""o""l"".""0""p"";"
"/""[""'""`""]""\"\\"" ""Z""X""C""V""B"
"N""M"          "<"">"           "?""~"
"="":"          "L""K"           "J""H"
"G""F"          "D""S"           "A""!"
"Q""@"          "W""#"           "E""$"
"R""%"          "T""^"           "Y""&"
"U""*"          "I""("           "O"")"
                                        
"P""_""{""+""}""|""-",define=sqrt,cond=
strlen(printf),i=printf+cond,t=(((ptr=\
argv<=                                  
OFST||                                 
strcmp                                 
(*argc                                 
,i-1))                                 
?0:(argc                               
                                        
++,argv--)),OFST-1);(watch=fgetc(((!*i\
&&argv>OFST?i=*argc:0),stdin)))!=EOF;*i?
i++:0)                                 
(magic                                 
=strc\
hr(pr\
intf,(                                 
define                                 
                                        
=(*i?(define=strchr(printf,*i))?define:
printf:sqrt),watch)))?watch=t,watch=((t=
strnel(                         magic))
+(watch                         -strnel
(define                         ))*(ptr
*2-OFST                         )+cond*
(OFST+1                         ))%cond
,ptr?t=watch:0:0,fputc(magic?watch[pri\
ntf]:watch,stdout);return 0;} /*world*/
--

Nathan Sidwell  INMOS UK |                 | nathan@inmos.co.uk       DoD#0390
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: EASY C
Date: 11 Sep 92 08:41:59 GMT
Organization: Private system in Toronto, ON


faivre@cst02.segin.com (Denis Faivre) writes:

>As far as I know, it consist in a set of #defines supposed to enhance
>lisibility, coding and debugging of programs. For instance, braces are
>#(re)defined as BEGIN and END, | as BOR (binary OR), || as OR, etc.
>
>Did somebody around experienced such a technique ? What do you think
>about it ?

If you want Pascal, you know where to find it.

-- 
Murray
From: pynq@quads.uchicago.edu (George Jetson)
Newsgroups: comp.lang.c
Subject: Problems with QSORT and function prototypes
Summary: (I'm sure this is a baby question, but it's got me stumped!)
Date: 15 Sep 92 04:34:45 GMT
Reply-To: pynq@midway.uchicago.edu
Organization: D. J. Dougherty & Associates

I have not been able to figure out how to pass a function pointer to the
QSORT intrinsic function, when using function prototypes.

Here is my program:

#include <stdio.h>
#include <stdlib.h>

struct thing {
        char *text;
        int textlen;
        } *things;

my_cmp(struct thing *t1, struct thing *t2)
{
        /* Key is in col 39, length 12 */
        return strncmp(t1 -> text + 38,t2 -> text + 38,12);
}

int_cmp(int *p1, int *p2) { return (*p1 - *p2); }

main()
{
	/* (You get same results with either my_cmp or int_cmp) */
        qsort(things,5,sizeof(struct thing),my_cmp);

}

I've tested this with two different compilers and get the same results.
With Borland C I get:

 <1> (E:\) bcc q2.c
Borland C++  Version 2.0 Copyright (c) 1991 Borland International
q2.c:
Error q2.c 20: Type mismatch in parameter '__fcmp' in call to 'qsort' in functio
n main
Warning q2.c 22: Function should return a value in function main
*** 1 errors in Compile ***


N.B. Ignore whether the program actually does anything useful - the only
point is to see if it compiles!

Finally, if I don't use prototypes, declaring the comparison function
as, e.g.,

	int_cmp(p1,p2)
	int *p1,*p2;
	{ return (*p1 - *p2); }

it works fine.

************************************************************************
A note to new readers:  the weasely :-) symbol is frowned upon in this
group.  Any questions, see Phil Gustafson who will gladly rearrange your
diodes for you.
			- From the AFU FAQ -

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
From: karl@ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: How to call procedure with a variable?!
Keywords: C VARIABLE PROCEDURE
Date: 11 Sep 92 22:49:06 GMT
Article-I.D.: ima.1992Sep11.224906.5617
Organization: Interactive Systems, Cambridge, MA 02138-5302

In article <68013@hydra.gatech.EDU> cc100aa@xray.gatech.edu (Ray Spalding) writes:
>In article <1992Sep11.145441.5720@cbfsb.cb.att.com> edb1@cbnewsf.cb.att.com (edward.benyukhis) writes:
>>In article <67971@hydra.gatech.EDU> cc100aa@xray.gatech.edu (Ray Spalding) writes:
>>>	t = gotoproc(1,2,3);
>>This is somewhat erroneous.  The way you invoke a function is:
>>	t = (*gotoproc)(1,2,3);
>
>[H&S say that the former is also legal.  Doesn't ANSI say that, too?]

Yes, it's legal in ANSI C to invoke a function through a pointer without
explicitly dereferencing it.  I personally avoid this, both for backward
compatibility (some, but not all, Classic C compilers accept it that way)
and because I think it's better style to distinguish (*pf)() and f().

Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
Newsgroups: comp.lang.c
From: ted@eslvcr.wimsey.bc.ca (Ted Powell)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Organization: Entropy Limited, Vancouver Canada
Date: Tue, 8 Sep 92 02:50:07 GMT

In article <1992Sep4.175637.7676@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>In article <7228@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
>|> In article <1992Sep3.162038.28706@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>|>  > [...]
>|>  > CDC's Scope was *much* easier to use.  Being a `vintage' system, it had
>|>  > about the same capabilities as UNIX.
>|> Eh?  What about the approximately flat file system, the inconsistency
>|> between programs with respect to their argument handling?  [...]
>
>[... Long list of inconsistencies elided ...]
>
>See?  About the same level of capabilities.  Just as I said.

Huh? I _read_ the "long list of inconsistencies" in the message you were
replying to, and they do nothing to support your "Just as I said" claim.
Those were infelicities in SCOPE, with no suggestion that they had
counterparts in UNIX. The "capabilities" listed (mostly in the line of
unintended program executions and file loss) pertained to SCOPE, with no
suggestion of similarity to UNIX.

I spent a goodly part of 1972-3 using the SCOPE system at Multiple Access
in Toronto, Ontario, implementing a language processor and run-time
environment, and the list referred to above brought back some painful
memories.  Suggesting that it supports a claim of "about the same level of
capabilities" is a pretty severe non sequitur, imho.

As for the actual issue of whether the capabilities were at about the same
level, I'd say that depends on what one wants to do. For what I want to do,
the answer is no.

-- 
ted@eslvcr.wimsey.bc.ca   {ubc-cs,uunet}!van-bc!eslvcr!ted   (Ted Powell)
Newsgroups: comp.lang.c
From: jarmo@ksvltd.fi (Jarmo Raiha)
Subject: Re: yacc and C identifiers
Organization: KSV Instruments LTD
Date: Wed, 9 Sep 1992 15:39:56 GMT

gonzalod@amex-trs.com (Gonzalo Diethelm) writes:



>Distribution: world

>Hello everyone,

>Two questions about yacc. Assume I'm trying to implement a C compiler:

There are two books you should have.
1. Compilers, Principles techniques and tools by Aho,Sethi,Ullman
   This tells the basics.
2. Compiler design in C by Allen Holub.
   This book has real implementions of the theory described in the  book 1.

If you like compiler construction, these are the books to read.
Maybe you should subscribe comp.compilers ?

 Jarmo Raiha
Newsgroups: comp.lang.c
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Re: Initializing Random Seeds 
Organization: National University of Singapore
Date: Mon, 7 Sep 1992 09:11:45 GMT

Another simple solution is simply to reverse the bits of the result
obtained from time(). The lower bits should be very timing sensitive.

jin meng
Newsgroups: comp.lang.c
From: richk@grebyn.com (Richard Krehbiel)
Subject: Re: Help to solve problem with "gets()"
Organization: Grebyn Timesharing
Date: Thu, 10 Sep 1992 23:29:42 GMT

In article <1429@yetti.UUCP> g-yao@cs.yorku.ca (Ling Yao) writes:
>Hi, Dear friends:
>
>   As a "C" novice, I would like to ask some advice about how to use
>   gets().

I don't have to read any of the rest.  My advise is simple: Don't ever
use gets().  Use fgets instead.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
From: jos@and.nl (Jos Horsmeier)
Newsgroups: comp.lang.c
Subject: Re: How can cpp be used to generate a unique identifier name?
Date: 15 Sep 92 14:12:12 GMT
Distribution: comp
Organization: AND Software BV Rotterdam

In article <RAYMOND.92Sep15140713@cobra.es.ele.tue.nl> raymond@es.ele.tue.nl (Raymond Nijssen) writes:
|I want to use the preprocessor to generate a new, unique name for a variable;
|something like `_<linenumber>' would do the job.
|
|However, `int _ ## __LINE__' doesn't work, because ## is dealt with first,
|generating `___LINE__', in which cpp doesn't expand the __LINE__ token.
|So my question os: how can I manupulate the order of expansion of these
|preprocessor tokens ?

If the ## expands before __LINE__ does, you can always force the
preprocessor to do it the other way around by nesting two macros.

Like this:

#define __newid(x) _ ## x
#define  _newid(x) __newid(x)

Build a nice little macro as a wrap up:

#define   newid    _newid(__LINE__)

and simply invoke the newid macro whenever you need a new id-name.

kind regards,

Jos aka jos@and.nl
From: mjn@pseudo.uucp (Murray Nesbitt)
Newsgroups: comp.lang.c
Subject: Re: Help!!! Please Read this message!?!?!?!?!...
Date: 11 Sep 92 08:16:08 GMT
	<1992Sep9.085352.8755@vax.oxford.ac.uk>
	<1992Sep10.040600.27065@blaze.cs.jhu.edu>
Organization: Private system in Toronto, ON


wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:

>Huh?  "%f" specifies a double not a float.  If you think about the
>promotion rule you'll realize that specifying a float would be
>nonsensical since it is not possible for an argument to printf()
>to be passed as a float!  

    printf( "%f...%s?\n", (float)f, "Huh?" );

It's another matter whether you'd *want* to pass a float to printf(),
but it is possible.

-- 
Murray
Newsgroups: comp.lang.c
From: jes@grendel.demon.co.uk (Jim Segrave)
Distribution: world
Subject: Re: strcpy implementation question
X-Mailer: cppnews $Revision: 1.14 $
Organization: None
Date: Fri, 4 Sep 1992 21:59:17 +0000


In article <PINKAS.92Sep3173643@skywalker.intel.com> pinkas@skywalker.intel.com (Israel Pinkas) writes:
>  ...
> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> RK> This is wrong.  It isn' the source or the destination that cares, it is
> RK> strcpy() that cares.  strcpy() MUST NOT READ any uninitialised memory
> RK> locations.
> 
> Why not.  There is a difference betwenn uninitialized and unallocated.  For
> example, with the declaration:
> 
> 	int a[5];
> 
> inside a block.  a[0] is uninitialized, but a[5] may be unallocated.
> Uninitialized memory belongs to the process, it just doesn't have a known
> or predictable value.  It is still legal to access it.  Unallocated memory
> doesn't belong to the process, and will probably cause an execution error
> if accessed.
> 
> -Israel

It is quite practical and often useful for a machine to pre-initialise
memory to detect attempts to read uninitialised variables - I have seen
references to systems which did this. Typically, in a system with memory
parity checking, the system presets the parity of the process memory to
a 'fault' value, then loads the program. Reading any location which has
not been written (or loaded from the executable) generates a parity fault.
This is a very useful hardware assist for debugging. And, on such a system,
RK is quite right - you must *not* read unintialised memory. 
--
Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk

Newsgroups: comp.lang.c