fwrite() problem with DECStation Ultrix 4.0

[From the screen of Deneva...]

To: mjr at decuac.DEC.COM

(I tried to send this direct, but it kept coming back - it seems that
"decuac.DEC.COM" is down.  I don't know were else to send it to. I'm
hoping that mjr is reading comp.unix.ultrix on some machine somewhere.)

>>	Uhm, are the data blocks being written some kind of C-type data
>>structures ? If you write code like:
>>
>>struct	ff	{
>>	int	x2;
>>	char	tag;
>>} xx;
>>
>>write(fd,&xx,sizeof(xx));

No, this is not what I am doing.  Most of the fwrite()'s are actually writing 
one byte at a time.  I know about byte order and variations in sizeof(int) - the 
code is explicitly written to normalize this.  The only time I'm calling 
fwrite() with a size greater than one is when I'm writing arrays of either 
characters (ASCII strings) or arrays of unsigned bytes (generally arrays of bits 
that have been built with the "correct" bit and byte order).  For everything 
else I am using these functions:

write_byte8(file,value)
FILE *file;
unsigned char value;
{
    if (fwrite(&value,1,1,file) < 1) return(0);
    else return(1);
    }

write_byte16(file,value)
FILE *file;
short int value;
{
    if (!write_byte8(file,(value & 0x00ff))) return(0);
    if (!write_byte8(file,((value >> 8) & 0x00ff))) return(0);
    return(1);
    }

write_byte32(file,value)
FILE *file;
long int value;
{
    if (!write_byte8(file,(value & 0x00ff))) return(0);
    if (!write_byte8(file,((value >> 8) & 0x00ff))) return(0);
    if (!write_byte8(file,((value >> 16) & 0x00ff))) return(0);
    if (!write_byte8(file,((value >> 24) & 0x00ff))) return(0);
    return(1);
    }


write_float32(file,value)
FILE *file;
float value;
{
    union {
        long int l;
        float    f;
        } fl_union;

    fl_union.f = value;
    return(write_byte32(file,fl_union.l));
    }


I know that this is not real effiencient, but this is portable and byte order 
independent (the only non-portable function is write_float32() - this would only 
be a problem if I were to run this on a VAX - all of the other machines involved 
(TI Explorer LISP machines, Suns, and DECStations) use the same sort of FP rep. 
- IEEE - we won't be running this code on a VAX, since the KBV package is not 
available (and probably won't ever be available) on VAXes).  All of the higher 
level structures beyond ASCII strings and arrays of bytes, are written out 
piecemeal using the above functions.

What is real strange is the fact the files are different on different 
file-systems, even when the program is run on the SAME machine, without 
re-compiling or re-linking.  That is, fwrite() is behaving differently depending 
on where it is writing to, not where it is writing from.  The implication is 
that the problem is in the file-system, kernel, or device driver.  If this is 
the case, then we could come in one morning and find ourselves with a bunch of 
trashed file-systems.  A very scary thought...

		Robert Heller
ARPANet:	Heller at CS.UMass.EDU
BITNET:		Heller at UMass.BITNET
BIX:		locks.hill.bbs
GEnie:		RHeller
FidoNet:	1:321/153 (Locks Hill BBS, Wendell, MA)
CompuServe	71450,3432
Local PV VAXen:	COINS::HELLER
UCC Cyber/DG:	Heller at CS