>> calloc() is not correct for floats; all-0-bits (which is what calloc
>> gives you) may be nonzero; it may not even be a valid float at all.
> Well, [...], but I'm pretty sure that IEEE floats are organised so
> that binary zero is float and double zero too.

Sure, if you're willing to assume you're using IEEE floats on an
architecture with a relatively simple memory system, it's fine.

> I doubt whether there are any machines that support NetBSD that don't
> have IEEE floats.  (Vax maybe?  Is that port running?)

VAX floats are not IEEE.  In VAX floats, too, though, all-0-bits is
zero.

But before you go ahead and use calloc, remember, there was a time when
everybody was using VAXen and people wrote code assuming all manner of
things that were "true everywhere" at the time but not promised by
anything, like little-endianism, or that address 0 was valid and held a
zero byte, or that you could write code to memory and then execute it
without doing anything special.  Then computers evolved and suddenly
such code was broken not only in theory but in fact.

I fully expect this to happen again; perhaps not soon with floats, but
eventually.  It's a bad idea to assume everyone uses IEEE floats and
always will for the life of your code, or that a nil pointer is
all-0-bits, or that ints are 32-bit, or any of the various other
unpleasant nonportabilities that keep cropping up.  Such things are
fine when you explicitly assume them - for example, MD code for a SPARC
can probably assume big-endianism - but slipping from "true on the
three machines I currently care about" to "true everywhere" is Bad.

>>> but I dont know how to malloc multidimentional arrays offhand
>> You allocate an array of arrays (which is what a "multidimensional"
>> array in C actually is) the same way you allocate an array of
>> anything else:
> If you're trying to do any serious math, that is NOT the way you want
> to do it: it's just too inefficient.

I don't remember what the code you were complaining about was.  If, as
I suspect, it was more or less

	float (*array)[XSIZE];
	array = malloc(YSIZE*sizeof(*array));
	...array[y][x]...

then it is a critical compiler bug if this is significantly less
efficient than your "right way" (allocating a 1-D array and doing the
subscript arithmetic yourself).  You seem to be under the impression
that what I wrote amounted to

	float *array[YSIZE];
	for (i=0;i<YSIZE;i++) array[i] = malloc(XSIZE*sizeof(float));

or perhaps

	float *array[YSIZE];
	array[0] = malloc(XSIZE*YSIZE*sizeof(float));
	for (i=1;i<YSIZE;i++) array[i] = array[i-1] + XSIZE;

> Using arrays of arrays may let you use the indexing syntax, but it
> costs you an extra, usually non-cacheable, usually pipeline stalling
> memory reference for every element.

What do you think that memory reference is fetching?  I am unable to
figure this out; an array of arrays doesn't have any such thing in
memory to fetch.  (This is why I think you have array-of-arrays
confused with array-of-pointers.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B