HDTenEightyP/NetNews huggingface dataset:
From: robertp@spot.tv.tek.com (Bob Proebstel)
Subject: SVGA .28 Pitch Monitor for sale
Originator: robertp@spot
Organization: Tektronix, Inc.  Beaverton, Oregon
Distribution: or
Date: Tue, 15 Dec 1992 19:36:37 GMT

	BRAND New SVGA .28 Pitch Laser Monitor for
	Sale. Asking $250 Or Best Offer.

	I bought the monitor before I purchased my
	PC. The system I bought cam as a package deal
 	with it's own monitor. Hence, I am selling this 
	one.
	
	
	
Xref: sparky or.forsale:2141 pdx.forsale:3330
From: crowhurs@admin.ogi.edu (Jon Crowhurst)
Newsgroups: or.forsale,pdx.forsale
Subject: * * * * *  6" Reflector Telescope - Criterion  * * * * *
Date: 18 Dec 92 00:23:26 GMT
Article-I.D.: ogicse.47463
Distribution: or
Organization: Oregon Graduate Institute



	* * * * *  6" Reflector Telescope - Criterion  * * * * *

	6" main mirror
	50" fiberglass tube
	6 x 30mm siting scope
	Equatorial mount
	110VAC motor drive
	Setting circles
	Vertical stand with 3 feet (very stable)
	4 eyepieces 4mm, 7mm, 12.7mm, 18mm
	Barlow lens

	Asking $350


--
--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-=--=--=--=--=--=--=--
Jon Crowhurst                   (503) 690-1035        crowhurs@admin.ogi.edu
Oregon Graduate Institute,   19600 NW Von Neumann Dr.,   Beaverton, OR 97006
--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-=--=--=--=--=--=--=--
From: chip.schnarel@tek.com (Chip Schnarel)
Newsgroups: or.forsale
Subject: MODEM for sale
Date: 15 Dec 92 01:37:24 GMT
Followup-To: or.forsale
Distribution: or
Organization: Tektronix, Inc.

I have a Packard Bell 2400/1200/300 baud MODEM that I no longer need.  I
will also include a cable suitable for connection to a Macintosh and a
couple of public domain/shareware communication programs.  The MODEM is a
couple of years old but not really used much.  It is in fine shape.  I'm
asking $100, or best offer.

Chip

///////////////////////////////////
/ Chip Schnarel                   /
/ Tektronix, Inc.                 /
/ P.O. Box 4600, MS 92-734        /
/ Beaverton, OR  97076-4600       /
/                                 /
/ chip.schnarel@tek.com           /
/ GEnie - C.SCHNAREL              /
/ CompuServe - 72000,3605         /
///////////////////////////////////
From: robohen@ocf.berkeley.edu (Henry Robertson)
Newsgroups: or.forsale
Subject: ONE-DOLLAR JAPANESE CARTOONS FOR SALE
Date: 17 Dec 1992 14:06:33 GMT
Organization: U. C. Berkeley Open Computing Facility
NNTP-Posting-Host: headcrash.berkeley.edu

I have here a vast collection of rare & unusual manga, that I've trimmed
down through sales....but, I have kept the very best, so that you manga
fans of the world can enjoy them with me.  By just sending ONE DOLLAR,
cash or money order, you receive an 8-page sample of the far-beyond-mainstream
cyberpunk stuff I have to offer.  No, it's not Akira or some other childish
fare.  If what you got out of that stuff was like an amphetamine high, this
would be a crack high.  One dollar is not a very big risk to take, folks.
What I have to offer is some of the most rare Japanese cartoons in existence,
by a man of distubring vision.  If you dare, contact robohen@ocf.berkeley.edu 
I know no holidays.  In any case, if you are interested in the 8-page
sample then send a self-addressed stamped business-size envelope to

Henry Robertson
2206 Durant Ave. #5
Berkeley, CA 94704  

and don't forget the dollar.  I'll look forward to hearing from you.
English subtitles are provided.
From: timothyf@tekig5.pen.tek.com (Timothy T Fox)
Newsgroups: or.forsale
Subject: ORGAN AND COUGAR
Date: 11 Dec 92 22:04:04 GMT
Distribution: or




1970 COUGAR
85,000 origanal miles
PS,PB,AC,AUTOMATIC
White, with Black Vynal Top
Runs Exel. Good body
$3000.00 OBO  

Car is in Vancouver, Wash.

Contact Tim Fox
Home # (206) 256-7061
Work # (503) 627-5974  If not in, Leave voice mail message.



KIMBALL CARAVAN ORGAN
SOUNDS GREAT
SMALL, FITS ANYWHERE
DARK WOOD
$300.00 OBO     

ORGAN IS AT BROTHERS IN VANC. WASH.

CONTACT TIM FOX AT 
HM # (206) 256-7061
WK # (503) 627-5874
From: henrya@ucs.orst.edu (Jean-Luc Picard)
Newsgroups: or.forsale
Subject: diamond!
Date: 17 Dec 92 18:02:15 GMT
Article-I.D.: gaia.1gqfb7INNdb2
Organization: University Computing Services - OSU
NNTP-Posting-Host: ucs.orst.edu

The holidays are here, and you haven't gotten your hunny a present yet???  No
need to fear!!

I have a beautiful diamond that I must unfortunately sell to help pay for my
next term school expenses.  The dis apx 1 ct/wt, I-J in color, and has
VERY few occlusions!  The thing sparkles in light like a wild fire!  You
would easily pay $3000 to purchase this rock in stores (unofficial appraisal)
I am asking $2000, but will consider reasonable offers.  The stone has not
been officially appraised, but if you require this before purchase, it can
be done.  Please e-mail me if you are interested and we can set up a time and
place where you can see the stone for yourself and make a final decision.
Please do this only if you are seriously interested, I am sure we are all busy
people.

Thank you!
Xref: sparky or.forsale:2135 pdx.forsale:3308
From: timothyf@tekig5.pen.tek.com (Timothy T Fox)
Newsgroups: tek.forsale,or.forsale,pdx.forsale
Subject: ROLLER BLADES *REPEAT*
Keywords: LIKE NEW. **NOT!!**
Date: 16 Dec 92 18:27:15 GMT
Followup-To: tek.forsale
Distribution: pnw




***ROLLER BLADES***

**Like new,** NOT!!**
I just got a look at my sons "like new" roller blades. The have
been used four or five times but, trust me, they do not look like
new. They have more time spent an their  sides and tips then on the
wheels.

Black/floresent green 
Boy's size 7 1/2 or 8
Very good wheels (appears he did'nt spend much time on them, the wheels
that is.)   

Were **$35.00** Now, $20.00 

Contact Tim Fox
HM# (206) 256-7061
WK# (503) 627-5874
From: fanglu@mse.ogi.edu (Lu Fang)
Newsgroups: or.forsale
Subject: Water Bed for Sale
Date: 15 Dec 92 03:50:12 GMT
Article-I.D.: ogicse.47267
Distribution: pnw
Organization: Oregon Graduate Institute, Material Science & Engineering


		Water Bed for Sale

    We have a dark wood water bed for sale.  It consists of a 
head baord, a box, a matrix (not waveless type), and a heater kit.  
Everything works fine.  Asking for $55/OBO.  Send mail to this 
account.  Thank you.
Newsgroups: or.forsale
From: nilva@netcom.com (Leonid Nilva)
Subject: SPARCbook for $4499
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Fri, 18 Dec 1992 19:56:50 GMT


	New SPARCbook for sale

TriGem TGstation SLT-100:
	20 Mhz, FPU, 8 Meg RAM, 120 Meg HD (28 ms) 3.5 FD;
	B/W, mouse, AC adapter, Case, Manuals;
	Ports: SCSI, Ethernet, 2 Ser., Ext. Video, Mouse, Audio;
	SunOS 4.1.1 with Open Win loaded.

Asking: $4499 obo.

Contact: Leonid Frid (415)858-1306 or nilva@netcom.com

-- 
 |----------------------------------------------------------------------------|
 | Leonid Nilva                                              nilva@netcom.com |
 |----------------------------------------------------------------------------|
From: timothyf@tekig5.pen.tek.com (Timothy T Fox)
Newsgroups: or.forsale,tek.forsale
Subject: ***ROLLER BLADES***
Keywords: $35.00
Date: 14 Dec 92 21:16:12 GMT
Followup-To: or.forsale
Distribution: pdx




***ROLLER BLADES***

Like new, Black/floresent green 
Boy's size 7 1/2 or 8
Very good shape

**$35.00** OBO

Contact Tim Fox
HM# (206) 256-7061
WK# (503) 627-5874

Newsgroups: or.forsale,pdx.forsale,tek.forsale,pnw.forsale
From: eric@tvnews.tv.tek.com (Eric F. Dorondo)
Subject: Water plants for sale
Organization: Tektronix TV Measurement Systems, Beaverton, OR
Distribution: or
Date: Tue, 15 Dec 1992 06:24:41 GMT


	Water plants:
		Water Lillies
		Water Iris

	Plants are healthy and ready for fall planting in ponds.  They
	provide shade for fish and help oxygenate the water.

	For more info, call (503) 648-3943, Hillsboro
	Leave a message and we'll get right back to you.
From: rankin@eql.caltech.edu (Pat Rankin)
Newsgroups: vmsnet.alpha
Subject: Re: Should /standard=xxxx affect link behavior?
Date: 14 Dec 1992 18:53 PDT
Organization: California Institute of Technology
Distribution: world
NNTP-Posting-Host: eql.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

In article <4052@mitech.com>, gjc@mitech.com (George J. Carrette) writes...
> Here is an interesting one, compiling a file with
> the setting /STANDARD=RELAXED_ANSI89 vs /STANDARD=portable
> has an effect on how the linker sees external references
> the the DECC$SHR.EXE

     No, not really.  It has an effect on whether or not the compiler
automatically attaches the "decc$" prefix to the external name.  Of course
that does indirectly affect linker behavior.

> %LINK-I-UDFSYM,         TIMES

     times() is not an ANSI standard function, so the compiler can not
usurp external identifier `times' from the user's namespace when it's
operating in ANSI mode.  DEC C is doing exactly the right thing here.
If you look through <time.h>, you'll see a comment telling you to use
/undefine="__HIDE_FORBIDDEN_NAMES" when compiling.  In the one I'm looking
at it says that that's needed for strict ANSI mode rather than relaxed.
It should apply to any mode which purports to be standard conforming.

		Pat Rankin, rankin@eql.caltech.edu
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Re: Should /standard=xxxx affect link behavior?
Date: 15 Dec 92 13:14:12 GMT
Distribution: world
Organization: Mitech Corporation, Concord MA

In article <14DEC199218530277@eql.caltech.edu>, rankin@eql.caltech.edu (Pat Rankin) writes:
>      times() is not an ANSI standard function, so the compiler can not
> usurp external identifier `times' from the user's namespace when it's
> operating in ANSI mode.  DEC C is doing exactly the right thing here.
> If you look through <time.h>, you'll see a comment telling you to use
> /undefine="__HIDE_FORBIDDEN_NAMES" when compiling.  In the one I'm looking
> at it says that that's needed for strict ANSI mode rather than relaxed.
> It should apply to any mode which purports to be standard conforming.
> 
> 		Pat Rankin, rankin@eql.caltech.edu

Mine says that too. But it turned out I also needed 
/PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES

Sorting out all these compiler switches. Argh!

Really, my problem is that I didn't sit down and study this stuff.
I just let some guy at the DEC porting center "do it for me."
Obviously disadvantages to that.

For example, all of a sudden with the new C compiler (X1.3)
lots of things work that I was having trouble with before.

I'm stilling trying to track down how some of my files
seem to have NOMEMBER_ALIGNMENT turned on without my knowing it.

-gjc
Newsgroups: vmsnet.alpha
From: jl@geoblue.gcn.uoknor.edu (Jay Liang)
Subject: DEC7000-610 Alpha AXP LINPACK TPP result anomaly
Originator: usenet@midway.ecn.uoknor.edu
Date: Tue, 15 Dec 1992 17:50:29 GMT
Reply-To: jay@alliant.backbone.uoknor.edu
Organization: University of Oklahoma, Norman OK

In the letest LINPACK benchmark dated December 7, 1992, the TPP result
for DEC 7000-610 Alpha AXP (182 MHz) is listed as 43 MFLOPS, however,
similar benchmark results for DEC 10000-610 (200 MHz) and 4000-610 (160 MHz)
are listed as 112 MFLOPS and 86 MFLOPS, respectively.  Was 43MFLOPS a
typo or was it caused by insufficient memory?

-- 
Jay Liang
jay@alliant.uoknor.edu
Xref: sparky vmsnet.alpha:41 comp.os.vms:19217 comp.org.decus:1028
From: goldberg@davidsys.com
Newsgroups: vmsnet.alpha,comp.os.vms,comp.org.decus
Subject: BAYVAX meeting on Alpha (Palo Alto)
Date: 14 Dec 92 00:24:50 PST
Summary: DECUS LUG meeting on Alpha - Palo Alto
Followup-To: vmsnet.alpha,comp.org.decus
Distribution: ba
Organization: DAVID Systems Inc, Sunnyvale CA

BAYVAX, the DECUS LUG for the San Francisco Bay Area, will hold their
next meeting on Tuesday, December 15, from 9 am to noon, at Syntex in
Palo Alto (on Hillview between Foothill and Arastradero).

The topic is Alpha and Open VMS.  Eric La Franchi (who is writing a
series of articles for VAX Professional on Alpha) is our first speaker.
The second speaker will be from Digital's Alpha Systems Product
Management team.  This specialist will present the latest on Alpha
system capabilities as well as information regarding the Alpha layered
software rollout schedule.

For more information contact either
Rich Taylor (408)776-4978 (taylor@csd.com) or
Seth Goldberg (408)541-6834 (goldberg@davidsys.com)
Newsgroups: vmsnet.alpha
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Subject: Re: Having hassle with C linking
Originator: usenet@kittyhawk.ecn.uoknor.edu
Date: Mon, 14 Dec 1992 17:02:52 GMT
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma

In article <Bz85qD.79F@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
|>Perhaps if they had mentioned the change in the manual... The problem is that
|>the diffs for AXP manual only lists the differences of that compiler running on
|>the AXP as opposed to VAX. They do not mention the differences between the VAX C
|>and DEC C on VAX...
|>
|>Unless they provide some form of check to ensure that external references are to
|>the same type at every point I fail to see any value in this change. If I wanted
|>a compiler to give me type checking information that makes it refuse to produce
|>an object I would not be using C. I really cannot see a bug that this system
|>could catch, that should be the test.
|>
|>Still, ANSI have been buggering up languages with silly standards since the
|>pascal fiasco where they defined vectors of length 3 as being incompatible with
|>those of length 4 making it impossible to write a string handling routine or
|>general matrix multiplication routine in ANSI standard Pascal.
|>
|>The reason why I am moving data about via pseudo common blocks is not "sloppy"
|>code. It is becuase I am producing routines using a preprocessor and do not want
|>the user to have to know what data is being exported to the run time library, in
|>fact I don't want them to know that they are exporting data...
|>
|>The type definitions are themselves produced by a preprocessor, this restriction
|>now subjects what was a very nicely symetrical system to preprocessor hackery.
|>
|>Phill Hallam-Baker

The ANSI C Document, RATIONALE Section 3.1.2.2 "Linkages of identifiers"
actually explains that they inidicated that external linkage was "a major
standardization issue". This section explains very well why this was a problem
and the reason it is done the way it is  done. It is not silly or unreasonable,
but a good policy to enforce proper typing and control where the acutal
storage definition occurs, and scoping problems involved with linkage.

The short form is that ANSI C is that "extern" indicates a pure reference
which does not define storage, and only one definition is allowed.
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
From: rankin@eql.caltech.edu (Pat Rankin)
Newsgroups: vmsnet.alpha
Subject: Re: Having hassle with C linking
Date: 12 Dec 1992 22:50 PDT
Organization: California Institute of Technology
Distribution: world
NNTP-Posting-Host: eql.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

In article <Bz5M1C.Kns@dscomsa.desy.de>, Hallam@zeus02.desy.de writes...
> There is a difference in the behaviour of the C compiler, The VAX compiler
> was lax about insisting that extern variables be declared at some point
> (ie without the extern part).

     There is a CC qualifier available for controlling the model used for
extern objects.  You can get behavior identical to VAX C's by using it.

> Bit of a silly C feature I think, a declaration should be a declaration.

     A declaration is not a definition, and the old sloppy code was what
was silly (for C; it matched the FORTRAN common block behavior).  The
method used as the default by DEC C is sanctioned by the C standard.  If
you argue that /standard=vaxc ought to imply /extern_model=common_block
for better VAX C compatibility then I might agree with you, but the
current default is more appropriate for ANSI mode.  There is also a
#pragma directive for controlling this on a case-by-case basis.

		Pat Rankin, rankin@eql.caltech.edu
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Should /standard=xxxx affect link behavior?
Date: 14 Dec 92 15:02:59 GMT
Organization: Mitech Corporation, Concord MA

Here is an interesting one, compiling a file with
the setting /STANDARD=RELAXED_ANSI89 vs /STANDARD=portable
has an effect on how the linker sees external references
the the DECC$SHR.EXE

eg. using SIOD 2.9 as available from various servers around the internet:

 $ cc /STANDARD=portable slib
 $ link/exe=siod.exe siod.obj,slib.obj,sliba.obj,trace.obj

 $ cc /STANDARD=RELAXED_ANSI89 slib
 $ link/exe=siod.exe siod.obj,slib.obj,sliba.obj,trace.obj
 %LINK-W-NUDFSYMS, 1 undefined symbol:
 %LINK-I-UDFSYM,         TIMES
 %LINK-W-USEUNDEF, undefined symbol TIMES referenced
         in psect $LINK$ offset %X00000040
         in module SLIB file USER$DISK:[GJC.SIOD]SLIB.OBJ;4


This is with DECC 1.3-002. 
Newsgroups: vmsnet.alpha
From: dwight@geohub.gcn.uoknor.edu (Dwight D. Moore)
Subject: Re: Having hassle with C linking
Originator: usenet@kittyhawk.ecn.uoknor.edu
Date: Fri, 11 Dec 1992 16:58:37 GMT
Reply-To: dwight@geohub.gcn.uoknor.edu
Organization: Geosciences Computing Network, Univ. of Oklahoma

In article <Bz2DA5.6DE@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
|>Newsgroups: vmsnet.alpha
|>Path: constellation!convex!convex!cs.utexas.edu!uunet!mcsun!dxcern!dscomsa!zeus02.desy.de!hallam
|>From: hallam@zeus02.desy.de (Phill Hallam-Baker)
|
|>Hi, has anyone had problems with linking C on Alpha?
|>
|>The problem I get is with pointers defined as extern, eg :-
|>
|>extern TRJ_d_INTEGER    *TRJ_data_integer;
|>
|>This declaration is in the same form in each of the libraries. The linker
|>complains :-
|>
|>%LINK-W-USEUNDEF, undefined symbol TRJ_DATA_INTEGER referenced
|>        in psect $LINK$ offset %X000009A8
|>        in module TROJAN_MOTIF_SUPPORT file
|>FRL:[HALLAM.TROJAN.TEST]LIB_TROJAN.O
|>LB;4
|>
|>Which indicates that there is a problem to do with the declaration of the
|>externals... Has anyone else encountered this sort of problem? The code worked
|>OK on VAX and on DECstations (and SGIs).

|>Phill Hallam-Baker
|>
I haven't had any problem. What does your link statement look like.?Which
file is it defined in? What compile option are you using (/STANDARD=?)
----------------------------------------------------------------------------
Dwight D. Moore
Geosciences Computing Network
University of Oklahoma

dwight@geohub.gcn.uoknor.edu (129.15.40.10)
These opinions do not necessarily represent the opinions of OU or the GCN.
----------------------------------------------------------------------------
Newsgroups: vmsnet.alpha
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Having hassle with C linking
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Sat, 12 Dec 1992 16:05:36 GMT

Have had problem solved for me, thanks...

There is a difference in the behaviour of the C compiler, The VAX compiler was
lax about insisting that extern variables be declared at some point (ie without
the extern part).

Bit of a silly C feature I think, a declaration should be a declaration.


--

Phill Hallam-Baker
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Some benchmarks. VS-4000/90, ALPHA, VEST
Date: 16 Dec 92 17:32:46 GMT
Organization: Mitech Corporation, Concord MA

Benchmark using SIOD version 2.9 Scheme interpreter.
(DEC 3000 AXP Model 500.) Codesize is about 2x on Alpha.

Test A:   $ siod -g0 -h50000 -isiod.scm
          (standard-fib 20)

TEST B:   $ siod -g0 -h150000 -ibfib.scm
          (b->number (b-fib '(A A B A B)))

                                     A                B

CC/OPT  NATIVE ALPHA              : 0.46 seconds.    8.33
CC/OPT  VS-4000 MODEL 90          : 1.41 seconds.   23.76
VEST/OPT of the above             : 1.37 seconds.   23.66

CC/NOOPT      NATIVE ALPHA        : 0.74 seconds.
CC/NOOPT      VS-4000 MODEL 90    : 1.71 seconds.
VEST/OPT      of the above        : 1.82 seconds.

CC/OPT/G_FLOAT VS-4000 MODEL 90   : 1.40 seconds.
VEST/OPT of the above             : 1.44

CC/NOOPT/G_FLOAT VS-4000 MODEL 90 : 1.62 seconds.
VEST/OPT of the above             : 1.85

If you want the lisp code BFIB.SCM, send me mail, it is not included
in standard siod releases.


Newsgroups: vmsnet.alpha
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Having hassle with C linking
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Mon, 14 Dec 1992 01:06:13 GMT

In article <12DEC199222504264@eql.caltech.edu>, rankin@eql.caltech.edu (Pat
Rankin) writes:

|>In article <Bz5M1C.Kns@dscomsa.desy.de>, Hallam@zeus02.desy.de writes...
|>> There is a difference in the behaviour of the C compiler, The VAX compiler
|>> was lax about insisting that extern variables be declared at some point
|>> (ie without the extern part).
|>
|>     There is a CC qualifier available for controlling the model used for
|>extern objects.  You can get behavior identical to VAX C's by using it.
|>
|>> Bit of a silly C feature I think, a declaration should be a declaration.
|>
|>     A declaration is not a definition, and the old sloppy code was what
|>was silly (for C; it matched the FORTRAN common block behavior).  The
|>method used as the default by DEC C is sanctioned by the C standard.  If
|>you argue that /standard=vaxc ought to imply /extern_model=common_block
|>for better VAX C compatibility then I might agree with you, but the
|>current default is more appropriate for ANSI mode.  There is also a
|>#pragma directive for controlling this on a case-by-case basis.

Perhaps if they had mentioned the change in the manual... The problem is that
the diffs for AXP manual only lists the differences of that compiler running on
the AXP as opposed to VAX. They do not mention the differences between the VAX C
and DEC C on VAX...

Unless they provide some form of check to ensure that external references are to
the same type at every point I fail to see any value in this change. If I wanted
a compiler to give me type checking information that makes it refuse to produce
an object I would not be using C. I really cannot see a bug that this system
could catch, that should be the test.

Still, ANSI have been buggering up languages with silly standards since the
pascal fiasco where they defined vectors of length 3 as being incompatible with
those of length 4 making it impossible to write a string handling routine or
general matrix multiplication routine in ANSI standard Pascal.

The reason why I am moving data about via pseudo common blocks is not "sloppy"
code. It is becuase I am producing routines using a preprocessor and do not want
the user to have to know what data is being exported to the run time library, in
fact I don't want them to know that they are exporting data...

The type definitions are themselves produced by a preprocessor, this restriction
now subjects what was a very nicely symetrical system to preprocessor hackery.


--

Phill Hallam-Baker
Newsgroups: vmsnet.alpha
From: ccdk001@utxvms.cc.utexas.edu
Subject: Re: Fortran compiler real time REAL format conversion/representation
Organization: University of Texas @ Austin
Date: 16 Dec 92 18:35:00 CST

In article <Bz233I.BDG@constellation.ecn.uoknor.edu>, dwight@geohub.gcn.uoknor.edu (Dwight D. Moore) writes:
> Has anyone used the Alpha's new Fortran capability of using different
> internal REAL formats or the run-time conversion to/from different
> REAL formats?...it is a neat trick, but is it really useful for anyone?
> ...inquiring minds want to know.

They're kinda nice when you are trying to read UNFORMATTED I/O written
on a different type of computer.  D_Float is pretty lame in terms of
performance (and you lose some precision), but it still beats having
to mask bytes & shift bits to read an imported binary file.

++ Dave