[comp.lang.c] Zortech C/C++

paul@tucson.sie.arizona.edu (Paul Sanchez) (11/25/90)

I am using the Zortech C/C++ compiler, v.2.1 on an IBM PS-2/80 running
DOS 3.3.  Overall I've been very happy with it, but recently I've run
into a couple of snags. Any help would be appreciated:

1) I appear to be running into the 64k barrier.  Is there any way I
can create a vector of doubles >8k in length?  (I am writing software
for time series analysis, and I'd like to be able to go up to about
50k for the length of my vector.)  I compiled using the large model,
thinking that I would get far pointers automatically, but it didn't
seem to work.

2) The "%g" format in printf works as described by K&R II, but is
different from all of the UNIX implementations I deal with and from
Microsoft.  The ZTC version loses significant digits.  This is
illustrated by the small program below:

#include <stdio.h>

main()
{
    double x;

    for (x = 1.23456789e-5; x < 1e5; x *= 10.0)
	printf("%8.3g\n", x);
}

with ZTC produces:

1.235e-005
       0
   0.001
   0.012
   0.123
   1.235
  12.346
 123.457
1234.568
1.235e+004

while with GNU cc, Microsoft, Berkeley cc, and others it produces:

1.23e-05
0.000123
 0.00123
  0.0123
   0.123
    1.23
    12.3
     123
1.23e+03
1.23e+04

the latter is a heck of a lot better for labelling graphs, which is what
I'm trying to do.  What does the ANSI standard have to say about this?

--paul sanchez
paul@tucson.sie.arizona.edu

bright@nazgul.UUCP (Walter Bright) (11/27/90)

In article <PAUL.90Nov24170411@tucson.sie.arizona.edu> paul@tucson.sie.arizona.edu (Paul Sanchez) writes:
/I am using the Zortech C/C++ compiler, v.2.1 on an IBM PS-2/80 running
/DOS 3.3.
/1) I appear to be running into the 64k barrier.  Is there any way I
/can create a vector of doubles >8k in length?

Sure. Declare:
	double *a[10];

	for (i = 0; i < 10; i++)
		a[i] = (double *) malloc(4096 * sizeof(double));
To access it:
	#define a(j)	a[j>>12][j&(4096-1)]

	a(m) = y;
	x = a(n);

/2) The "%g" format in printf works as described by K&R II, but is
/different from all of the UNIX implementations I deal with and from
/Microsoft.

This will be fixed.