HDTenEightyP/NetNews huggingface dataset:
From: molagnon@ditigo.ifremer.fr (Michel Olagnon, Ifremer DITI GO, 98.22.41.44)
Subject: Re: Fast I/O
Reply-To: molagnon@ditigo.ifremer.fr
Organization: Ifremer   
Date: Thu, 21 Jan 93 08:11:05 GMT

In article 1jhqkhINNno3@bigboote.WPI.EDU, ustundag@blakey.WPI.EDU (Afsin Ustundag) writes:
>I have to write a Fortran program which writes and reads tremendous amount
>of data to to and from hard-disc.I wrote it in C using binary files and
>low level I/O.It worked quite well.I tried to use unformatted files in
>Fortran but they're at least 4 times slower.I used following open, write
>and read statements
>    open(8,File='Filename',FORM='unformatted')
>    write(8)(A(J),J=1,N) 
>    read(8)(A(J),J=1,N)   ( A is a double )
>I also tried direct-access unformatted files but i couldn't figure out
>how to specify RECL most efficiently.
>I'm working in UNIX.
>I will greatly appreciate any help that will make I/O in the Fortran 
>program faster.
>Please respond to ustundag@blakey.WPI.EDU
>thanks
>  


Many Fortran compilers are not efficient on I/O with implied DO loops.
Replacing 
      write (lu) (a (j), j=1,n)
with
      call fstwrt (lu, a, n)
         .
         .
      subroutine fstwrt (lu, a, n)
      double precision a (n)
      write (lu) a
      return
usually gives dramatic improvement.

I have a follow-up question : why don't compilers execute this optimization ?

---
| Michel OLAGNON            | email : Michel.Olagnon@ifremer.fr         |
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|


Newsgroups: comp.lang.fortran
From: Patrick F. McGehearty <patrick@convex.COM>
Subject: Re: Fast I/O
Originator: patrick@wagner.convex.com
Date: Fri, 22 Jan 1993 19:30:19 GMT
Reply-To: patrick@convex.COM (Patrick F. McGehearty)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1993Jan21.081105.4047@molene.ifremer.fr> molagnon@ditigo.ifremer.fr writes:
(revised for brevity):
Why don't compilers optimize I/O lists such as

      write (lu) (a (j), j=1,n)
to be as fast as
      write (lu) a


Convex Fortran does, and in the recent past, also added the optimization for:
      write (lu) (a (j,i), j=1,n)

In my opinion, the answer to the question is that there is no technical
reason for compilers to not make this optimization.  Rather it is a
question of resources and structural pressures.  There are always more
potential optimizations and features to add to a language like Fortran
than there are resources to add them (Fortran 90 makes this statement
self-evident :-).  If a compiler group has been entirely driven by the old
simple benchmarks such as Whetstones, Dhrystones, and Linpack 100x100, 
they will not even realize that there is a worthwhile optimization to be
made in this case.  If they use real production applications, then the
optimization may get on their to-do list, depending on their target market
segment.
From: leus@aix.rpi.edu (Sheua-Wan Leu)
Newsgroups: comp.lang.fortran
Subject: extend precision more tham double
Keywords: double precision
Date: 24 Jan 93 22:48:38 GMT

Please send you exclusive help to 
	leus@rpi.edu
Thanks 
Newsgroups: comp.lang.fortran
From: kenbell@panix.com (Ken Bell)
Subject: Re: Help with UNIX f77 file buffer system
Organization: PANIX Public Access Unix, NYC
Date: Tue, 26 Jan 1993 05:15:50 GMT

In <1993Jan25.091937.5738@doug.cae.wisc.edu> dafnioti@cae.wisc.edu (Petros Dafniotis) writes:

>no info in the output files. I am guessing that the UNIX file buffer system
>still keeps these numbers in the buffer and what he needs is to flush the
>buffers after each single write. Could someone tell me how can this be
>accomplished in UNIX? (he is using HP-RISC and SUN SPARC-I workstations)."

Why not catch SIGINT (see signal(3C)) and simply close() all files
before exiting?

-- 
Ken Bell  (kenbell@panix.com  -or-  syklb@nasagiss.giss.nasa.gov)
From: kaszeta@egr.msu.edu (Richard Kaszeta)
Newsgroups: comp.lang.fortran
Subject: Gaussian Elimination
Keywords: Gauss
Date: 21 Jan 93 22:08:44 GMT
Organization: Michigan State University
NNTP-Posting-Host: frith.egr.msu.edu

Does anyone have some example FORTRAN code showing how to do eigenvalue
calculations and Gaussian elimination? Or know of an FTP site where such
code can be obtained?

please post or email to kaszeta@frith.egr.msu.edu

Thanks.
Newsgroups: comp.lang.fortran
From: steinman@me.utoronto.ca (David Steinman)
Subject: Re: dbx headache
Organization: UofT Mechanical Engineering
Date: Sat, 23 Jan 1993 21:00:41 GMT

rvenable@helix.nih.gov (Richard M. Venable) writes:

>Sorry, but this thread was discussing debugging FORTRAN with dbx, not C; I
>don't think gcc and gdb are relevant to this thread, and possibly newsgroup.

Oops.  I got caught because the author stated that his program could easily
be patched into dbx.  Maybe someone out there would like to modify DUEL for
Fortran use?
--
Dave!
From: frank.carrillo@nitelog.com (Frank Carrillo) 
Newsgroups: comp.lang.fortran
Subject: Fortran Code Generators
Date: 26 Jan 93 19:29:00 GMT
Distribution: world
Organization: Nitelog BBS - Monterey, CA - 408-655-1096
Reply-To: frank.carrillo@nitelog.com (Frank Carrillo) 

Greatings!

Does anyone know of any Fortran code generators?

By code generator I mean a tool that ingests CASE tool generated
design data and emits compilable Fortran code. I would like to
know of such tools even if they only generate code skeletons.
Please include vendor name and contact information if known.

Thanks in advance.

Regards, Frank (frank.carrillo@nitelog.com)

---
 . JABBER v1.2 .
From: cflatter@nrao.edu (Chris Flatters)
Newsgroups: comp.lang.fortran
Subject: Re: Wanted: folk theorems in Fortran Progra
Date: 27 Jan 93 20:36:53 GMT
Reply-To: cflatter@nrao.edu
Organization: NRAO

In article 199@comp.compilers, dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd) writes:
>"Steve" Stevenson <steve@hubcap.clemson.edu> writes:
>> I am trying to make a catalog of folk wisdom in fortran programming.
>
>My personal favorite is the one discussed on page 137 of the 1st edition of
>Numerical Recipes (Fortran edition, of course):
>
>BAD
>
>P = c(1) + c(2)*x + c(3)*x**2 + c(4)*x**3 + c(5)*x**4
>
>GOOD
>
>P = c(1) + x*(c(2) + x*(c(3) + x*(c(4) + x*c(5))))
>
>It is a little harder to read but you won't be `summarily executed'

I hope that you don't mean folk wisdom in the sense of things that are
widely believed without justification: there is a good reason for
preferring the latter version.  The former version requires 4
additions, 4 multipications and 3 applications of the power operator
(should total 15 or 16 fp operations using an efficient algorithm for
raising fp numbers to integer powers.  The latter version does not
require application of the power operator.  Not only will it be
approximately twice as fast but it will accumulate less rounding
error.

	Chris Flatters
	cflatter@nrao.edu
Newsgroups: comp.lang.fortran
From: eng10370@nusunix1.nus.sg (CHEW JOO SIANG)
Subject: 256 colours
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 27 Jan 1993 12:03:29 GMT

Does anyone out there know how to get Fortran to display 256 colours? I
intend to convert a gif file to pcx format and import it in. The
problem is, the user's manual only specifies 16 colours for vga mode.I'm
using the salford compiler (ftn77/286 ver 2.65). The manual also said
something about a configdb file but I'm not sure how it works. I tried
using the subrountine high_resolution_graphics_mode but it doesn't seem
to work either. Can someone please help? I need the information urgently
as I have a project to hand up.
Thank you.

Basil Chew
eng10370@nusunix1.nus.sg

 
Newsgroups: comp.lang.fortran
From: jtbell@hubcap.clemson.edu (Jon Bell)
Subject: Re: Poor programming (was: Block Data is evil)
Organization: Presbyterian College, Clinton SC
Date: Sun, 24 Jan 1993 02:17:52 GMT

In article <C1BEIn.8MA@umassd.edu> hshubs@cis.umassd.edu (Howard S Shubs) writes:
>In <1993Jan23.151052.6593@hubcap.clemson.edu> jtbell@hubcap.clemson.edu (Jon Bell) writes:
>
>>It's already been done.  When I was a grad student in experimental
>>particle physics, I worked with CERN's HYDRA library, which implemented
>>dynamic memory allocation in FORTRAN using the same basic idea.  I 
>>think this package is still widely used in particle physics.
>
>That's meaningless.  Just because something has been done poorly is not
>a reason to continue to do it poorly.  Someone has to maintain that code.

The CERN HYDRA package first appeared in the late 60's, I think.  Its goal
was to provide linked data structures and dynamic memory management in
the context of standard Fortran (at that time, Fortran 66) so that it could
be run on as many platforms as possible.  Particle physicists work in large
collaborations, on a wide variety of computers, and source-code
portability is important to them.  

In in ideal world, I suppose the best solution would have been to migrate
to another language which had built-in support for dynamic memory allocation.
But at the time, I don't think there _was_ any other suitable language.
Algol was basically used only in Europe.  PL/I was used mostly on IBM
machines.  C and Pascal hadn't even been invented yet!

Now, of course, we _do_ have widely-used languages which have dynamic 
memory allocation, but physicists still love Fortran, and there's an awful
lot of code out there.

Actually, HYDRA was pretty well documented.  Most of the problems in using
it were the standard conceptual ones involving linked data structures and
dynamic memory management, dangling pointers and the like.  And since it
was a very widely used package, you could always find somebody who 
understood it and its coding conventions.  Maintenance wasn't _that_ big
a problem.

I certainly wouldn't recommend this approach nowadays for a new software
system.  If it needed dynamic memory allocation, I'd say, "Use C... or
Pascal... or maybe Fortran 90.  Don't even think about doing it in 
Fortran 77."  But for its time, HYDRA was the only possible solution.

Jon Bell / Dept. of Physics & C.S. / Presbyterian College / Clinton SC
From: scst90@csc.liv.ac.uk (Mr. J.J. Willmott)
Newsgroups: comp.lang.fortran
Subject: Wanted: Simple Fortran Progs
Date: 25 Jan 93 12:22:48 GMT
Organization: Computer Science, Liverpool University


 I need a couple of simple programs (adding a couple of numbers together, that sort of thing) to test out a piece of software. I have never used Fortran, which is why I am asking for simple code.
                                   thanx...

                              _
 Jamie 'WeirdWolf' Willmott  / ])  "Given that God is infinite, and given
  scst90@uk.ac.liv.compsci  RED/    that the universe is also infinite...
                           DWARF
    "Better Than Life"    ([_/  ...would you like a cheese & ham breville ?"
Newsgroups: comp.lang.fortran
From: lfini@sisifo (Luca Fini)
Subject: Re: Block Data is evil
Organization: Osservatorio di Arcetri
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 21 Jan 1993 07:47:55 GMT

W. Donald Rolph (a722756@roper.mc.ti.com) wrote:
: 
: Equivalence is in some cases the only possiblity for run time memory allocation
:

Equivalence is *not* a run rime memory allocation, you simply call the
same memory area with different names (and possibly use it as different
data types).

+------------------------------------------------------------------------+
| Luca Fini                                                              |
| Osservatorio Astrofisico di Arcetri     Tel.   +55 2752 253            |
| L.go E.Fermi, 5                         Fax.:  +55 220039              |
| 50125 Firenze                           e-mail: lfini@arcetri.astro.it |
| Italia                                                                 |
+------------------------------------------------------------------------+
Newsgroups: comp.lang.fortran
From: morgan@sitka.triumf.ca (Morgan Burke)
Newsgroups: comp.lang.fortran,comp.lang.c
Subject: world's worst comment
Date: 27 Jan 1993 23:52:19 GMT
Organization: TRIUMF, Vancouver BC
Distribution: world
NNTP-Posting-Host: sitka.triumf.ca

Here is my candidate for the world's most useless comment:
[X-windows C-code generated by XDesigner 2.0 Motif UI builder]


Display *display;  /* Display      */


-- Morgan Burke
   morgan@sitka.triumf.ca
Newsgroups: comp.lang.fortran
From: hshubs@cis.umassd.edu (Howard S Shubs)
Subject: Re: Block Data is evil
Organization: University of Massachusetts Dartmouth
Date: Sat, 23 Jan 1993 06:15:10 GMT

In <1993Jan22.183106.15813@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:

>In article <1993Jan21.074755.14939@arcetri.astro.it>, lfini@sisifo (Luca Fini) writes:
>|> W. Donald Rolph (a722756@roper.mc.ti.com) wrote:
>|> : 
>|> : Equivalence is in some cases the only possiblity for run time memory allocation
>|> :
>|> 
>|> Equivalence is *not* a run rime memory allocation, you simply call the
>|> same memory area with different names (and possibly use it as different
>|> data types).

>Yes, and that permits you to do run-time management of a statically
>allocated "maximum" space.  You figure out what the maximum memory
>you ever need is and you statically allocate that much:

>      PARAMETER (MAXMEM=1000000)
>      COMMON /MEMORY/ MEM(MAXMEM)

>This reserves one million integer sized words.  Now, you can write
>a MALLOC routine which returns avalable space from within this array
>in the form of an index (you actually have two mallocs, one for
>integers and reals, the other for complex and doubles - since the
>indices must be scaled differently).  To use:

You're not seriously suggesting that this be used in production code,
are you?  If you are, is this intended as job security?
-- 
Howard S Shubs    hshubs@bix.com          For to win 100 victories in 100
The Denim Adept   hshubs@cis.umassd.edu   battles is not the acme of skill.
Newsgroups: comp.lang.fortran,comp.sys.sgi
From: davea@quasar.mti.sgi.com (David B.Anderson)
Subject: Re: Linking problem in Fortran
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 25 Jan 1993 16:32:57 GMT

In article <1993Jan25.125943.13209@syma.sussex.ac.uk> johnu@syma.sussex.ac.uk (John E. Upham) writes:
>I am trying to link two files and get the following error message:
>
>/usr/bin/ld:
>No symbolic information for: test.o
>
>
>I'm using the  Makefile appended below and the file test.o is
>mipseb demand paged stripped - version 2.0 and I havnt got access to the
>.f file. My compiler is 3.4.1 on OS 4.0.5f on a SG Indigo R4000.

Well, there's your answer: 
	mipseb demand paged stripped
means that strip(1) or ld -s has been done on the .o.
(Or perhaps the .o was damaged somehow: disk error?)
Use odump(1) to see what is left of the .o (try 'man odump').

Such a .o is unusable.

You are going to have to find a way to rebuild test.o.
[ David B. Anderson             (415)390-4263             davea@sgi.com ]
From: robin@ruchem.ru.ac.za
Newsgroups: comp.lang.fortran
Subject: f2c
Date: 28 Jan 93 09:39:33 GMT
Reply-To: robin@ruchem.ru.ac.za
Organization: Rhodes University, Grahamstown, SA

I'm using f2c (for the first time!) to translate a simple Jacobi
eigen-value/-vector routine to C (TurboC to be exact, that's what
I've got on my PC. It won't work, if I try translate *just* the
jacobi subroutine f2c complains about finding RETURN; if I translate
a short prog which calls jacobi then f2c moans about finding SUBROUTINE
and RETURN as well as mentioning segmentation errors. I'm doing
all this on a SUN. man f2c does not help. What am I doing wrong?
Robin
Newsgroups: comp.lang.fortran
From: bvaughan@sheps.Princeton.EDU (Barbara Vaughan)
Subject: Re: Maximum number of openfiles on MS FORTRAN 5.1?
Originator: news@nimaster
Organization: Princeton University
Date: Fri, 22 Jan 1993 16:25:37 GMT

In article <Jan.22.09.43.13.1993.26857@gandalf.rutgers.edu> hempatel@gandalf.rutgers.edu (Hemanshu Patel) writes:
>
>	I am using MS Fortan 5.1 on a PC running DOS, and I've written 
>	a program on a SPARC 1 which opens 20 or so files. It compiles
>	and runs fine.  I then transfered it to a PC, it compiles fine
>	but I  get a runtime  error of  too many files opened. I don't 
>	remember the  exact error code. Does  anyone know  the maximum 
>	number of files openable at one time under MS Fortran 5.1, and
>	any tricks around. I really don't want to  open and close each 
>	file every time,  especially since the data  stored in them is 
>	sequentially  written. Any help  would be appreciated. Than...

I don't know anything about MS Fortran 5.1 (I use Lahey), but you might
want to check your DOS config.sys file.  There may be a line in it saying
"files = 15" or something.  If so, change it.  If there's no such line,
add one, with a limit you can live with.

Barbara Vaughan
Newsgroups: comp.lang.fortran
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: Help with UNIX f77 file buffer system
Organization: University of Toronto Chemistry Department
Date: Mon, 25 Jan 1993 16:17:32 GMT

In article <1993Jan25.091937.5738@doug.cae.wisc.edu> dafnioti@cae.wisc.edu (Petros Dafniotis) writes:
>Hello netters,
>
>  I know very little about UNIX (in fact I am using VMS for almost 9yrs now).
>A friend of mine had the following problem:
>"His program (all written in FORTRAN by 1-2 people years ago) takes quite
>some time to finish. He is writing info produced at
>run time to 2-3 output files. However, 90% of the runs are proved to be
>useless quite soon; so he uses CTRL-C to abort execution. But then he finds
>no info in the output files. I am guessing that the UNIX file buffer system
>still keeps these numbers in the buffer and what he needs is to flush the
>buffers after each single write. Could someone tell me how can this be
>accomplished in UNIX? (he is using HP-RISC and SUN SPARC-I workstations)."

Try the 'flush' routine from the BSD F77 library (it should be in HP-UX
9.0, but is not in HP-UX 8.07); Sun has had that library for ages.
If you are stuck at 8.07, write a C routine that calls fflush
after using FSTREAM (see p. 9-30 of the FORTRAN manual) to get the
C "FILE *" pointer. This approach will not work on stdin/stdout/stderr
at 8.07, but works fine on other unit numbers.
-- 
core error - bus dumped    -*-    Mike Peterson, SysAdmin, U/Toronto Chemistry
 *******   As usual, I speak only for me, myself and I; nobody else   *******
E-mail: system@alchemy.chem.utoronto.ca  Tel: (416)978-7094  Fax: (416)978-8775
From: hamjavar@hydra.unm.edu (Farid Hamjavar)
Newsgroups: comp.lang.fortran
Subject: FORTRAN compiler for PC
Date: 27 Jan 93 04:34:37 GMT
Article-I.D.: lynx.1k53ctINN3vr
Distribution: world
Organization: University of New Mexico, Albuquerque
NNTP-Posting-Host: hydra.unm.edu



Hello :

On behalf of a friend who has no access to the net, I would like to
know how much should a person look into spending  for a PC version
of fortran compiler.

Please reply by e-mail
Thanks
Farid Hamjavar
hamjavar@carina.unm.edu
University of  New Mexico
From: bugsy@yoyodyne.WPI.EDU (Christopher Sean Moran)
Newsgroups: comp.lang.fortran
Subject: compiling FORTRAN IV on Unix f77
Date: 27 Jan 93 16:45:00 GMT
Organization: Worcester Polytechnic Institute
NNTP-Posting-Host: yoyodyne.wpi.edu

Help me... I have a program called VORLAX which I need to compile.
It was written and compiled originally on CDC FORTRAN IV.  All
I have access to is Unix f77.  I have tried to compile it, but
its a no go.  One problem is the first line

PROGRAM VORLAX(INPUT,OUTPUT, etc)

the compiler doesnt like the parenthesis after the program 
declaration.  Past that there are no other problems.

I do get an executable after compiling if I take the stuff
in the parenthesis out. But UNIX dumps my core every time
I run the program.  Can anyone help me?
From: klauck@dfki.uni-kl.de (Christoph Klauck)
Newsgroups: comp.lang.fortran
Subject: "Feynman Diagrams"
Date: 27 Jan 1993 18:29:15 GMT
Organization: DFKI Kaiserslautern
Distribution: world
NNTP-Posting-Host: ws-300.dfki.uni-kl.de

Hi everybody,
I am searching for a program to draw "Feynman Diagrams" and also 
some introduction on how to use it.
Thanks in advance.
	Christoph Klauck
Newsgroups: comp.lang.fortran
From: rvenable@helix.nih.gov (Richard M. Venable)
Subject: Re: How to get command line arguments from unix with FORTRAN?
Reply-To: rvenable@helix.nih.gov (Richard M. Venable)
Organization: National Institutes of Health
Date: Wed, 27 Jan 1993 01:03:11 GMT

In article <PMURPHY.93Jan26121847@orangutan.cv.nrao.edu>,
pmurphy@nrao.edu (Pat Murphy) writes:
|> A brief experiment with telnet shows that his posting machine is not
a
|> Sun: "ULTRIX V4.2A (Rev. 47)".  My f77 info for Ultrix (4.0),
|> fortunately shows getarg identical to the above.  However I know
that
|> for other flavors of unix it is different.  For example, HP-UX uses
a
|> function IGETARG with three arguments.

Ah, but you can still use GETARG under HP-UX; it's just that IGETARG
provides info on the length of the string returned, while GETARG does
not.  Also, a compiler directive is required to use GETARG.  However,
I think HP's biggest sin here is that  CALL GETARG(1,string)  returns
the program name, where most other implementations consider that to be
argument 0 (zero) and not 1 (one).

-----------------------------------------------------------------
 Rick Venable                  |    "Eschew
 FDA/CBER Biophysics Lab       |   Obfuscation"  
 rvenable@helix.nih.gov        |         -- the Phantom Nerd   
-----------------------------------------------------------------

Newsgroups: comp.lang.fortran
From: shen@athena.cs.uga.edu (Mingzuo Shen)
Subject: What are the popular nonstandard Fortran 77 features?
Organization: University of Georgia, Athens
Distribution: usa
Date: Mon, 25 Jan 1993 22:25:33 GMT

Hi all,

    Just now there is some discussion about IAND, IOR, etc.
and I realized that these are nonstandard intrinsic functions.

    Question:

    what are some popular nonstandard functions and features
used to supplement Fortran 77: including the platform,
definition, and if appropriate, equivalent functions/features
in C and C++, and Fortran 90?

    Thanks in advance,

Mingzuo Shen
From: raskin@ccu.umanitoba.ca (Alan Raskin)
Newsgroups: comp.lang.c
Subject: Re: HALLOC and HUGE ptrs in Microsoft C
Date: 23 Jan 93 16:43:20 GMT
Distribution: world,local
Organization: University of Manitoba, Winnipeg, Canada

In <1993Jan21.175608.4279@arizona.edu> jjr@ace.ece.arizona.edu (Jeffrey J. Rodriguez) writes:

>On a 486 running DOS, I need to allocate an array that's bigger than 64K,
>fill it up with data, and write it to a binary file.
>The MSC 7.0 manual says to use halloc(), which returns a "huge ptr".
>It also says that huge ptrs cannot be passed as args to library functions.
>Therefore, I can't pass the array to fwrite()!
>So, how do I write the data? (Do I really have to loop through putchar?)

Actually, I think that fwrite is one of the library routines that *will*
take huge pointers; according to an old QuickC manual, "a huge array can
be passed without difficulty to any of these [bsearch, fread, fwrite, halloc,
hfree, lfind, lsearch, mem* and qsort] functions in a compact-, large-, or
huge-model program."

>This sure seems cumbersome.
>It also seems that a program written for PC-DOS using halloc and huge
>ptrs would not run on a Sun running UNIX.
>So much for portable C.

Because of the <expletive deleted> segmented-memory architecture of the Intel 
80x86 CPUs, which at times requires the use of the non-portable "near", "far" 
and "huge" keywords, the only way to write "portable" C would be to use 

#if defined ( MSDOS )  /* M_I86 is also defined by MSC; what about Borland? */
.
.	halloc(...);
.
#else
.
.	malloc(...);
.
#endif

at the appropriate places in your file. 

*SIGH*

>Jeff Rodriguez
>rodriguez@ece.arizona.edu

Alan Raskin
raskin@ccu.umanitoba.ca
Xref: sparky comp.lang.c:20271 comp.lang.fortran:5204