Conference hydra::amiga_v1

    
    That should read 
		fwrite (&part, sizeof(part), 1, fptr);
    
    	Damm escape characters highlighting errors .. mumble.. mumble...
    
    
    			-Pete-
    
    

> 
> 		fwrite (&part, sizeof(part), 1, fptr);

Try type casting the part variable. Lattice (SAS/C) is more Ansi compliant
than the VAX compiler. 

		fwrite((void *)&part, sizeof(part), 1, fptr);

Look in (I think) stdio.h for the prototype to see exactly what
LAttice expects for the "part" parameter's type.

john

> 
> 		fwrite (&part, sizeof(part), 1, fptr);


	Cast it to a (char *), i.e.:

		fwrite((char *)&part, sizeof(part), 1, fptr);


	How much char would a char * *, if a char * could * char ?

	~art

Re: .2

>Try type casting the part variable. Lattice (SAS/C) is more Ansi compliant
>than the VAX compiler. 

SAS C is more more ANSI C compliant in most things, but it looks like
they blew this one.

The function prototype for fwrite from the ANSI C standard is:

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);

const void * is compatible with any pointer type.
size_t is compatible with any integer type.

So, the call in the program was correct.  No message was deserved.  No
casts are necessary.

I suspect that SAS C has a bad prototype in their headers.  (I suspect
that they have the first argument as char * instead of void *.)

My previous impression of the SAS C headers was that they needed a
lot of updating to be ANSI compliant.

By the way, VAX C does not complain about pointer type mismatches
in function calls unless you use the /STANDARD=PORTABLE qualifier.

>> My previous impression of the SAS C headers was that they needed a
>> lot of updating to be ANSI compliant.

The people at SAS agree with you. They've been saying that the 5.x version
predates the ANSI standard, and is only compliant if you don't look very
hard, especially at the headers. They're not planning on fixing the 5.x
version.

The 6.x version (currently in beta test) is being billed as the ANSI compliant
version of the compiler.

	<mike

    I did compile it on the VMS system with /standard=portable.
    
    	This is why I was annoyed about the message .
    
    	I will try typecasting  to char etc. and post the results.
    
    
    Roll on V6.x that's what I say  :-)
    
    			-Pete-

    Well limited success.....
    
    Yes casting the fwrite to void or char did stop the Compiler 
    complaining, but the file PART.FIL still remained empty.
    	Again this does not happen on the VMS system.
    
    			Pete  :-( :-(

I just tried this with SAS 5.1 and it looks fine.  The input was contained
in the file PART.FIL.  If you ^C out of the prompt loop, then those records may
not actually get written to the file, due to the RTL buffering I/O.

One thing to watch is that writing structures to a file via fwrite is not
portable.  Many compilers (esp RISC) will pad the structures so that fields
align properly (longs on longword boundries, etc).  Also note that DEC 
hardware uses little-endian for integers, where the Amiga uses big-endian.

Trying to move the binary file around to different systems will have limited
success, although the code itself may be "portable".  As pointed out previously
the safest bet is to output ASCII files and then fscanf the records back in.
 
Steve   

    Hi Steve,
    	Thanks for giving it a try on 5.10 .
    	Glad to hear it works Ok on that anyway, did you have to cast it
    as in previous notes , or did it work as is ?
    
    Would it be portable if I kept to ascii in the structure and used 
    fwrite, or is it something about the structure it does not like.
    
    
    I ran the program after casting the first argument to fwrite , but
    what should have gone to the file after the fourth record just got sent
    to the screen, and the file remained empty.!
    
    	Guess it's time to get the credit card out and upgrade to 5.10 .
    
    Is the IBM PC clone family (8086, 80286, 80386) little-endian or
    big-endian ?
    
    			-Pete-

    80X86 family is little-endian (just like VAX and DEC MIPS).

Hi Pete,

     I did cast the fwrite((char *)&part, ...), as was suggested earlier.
That's to appease the function prototype.

     Using fwrite can be portable, but you have to make sure that 
the buffer that it's outputting is portable.  Two potential problems are
that different compilers will pad structure elements to align things properly
for their architecture.  Your part structure looks ok, but potentially the
name[] or number[] field could actually be larger than you've defined.
This may cause problems when reading the files on different machines.

     Another problem is that fwrite just writes bytes to the file, and
that integers are represented differently on different machines.  If
portability is an issue, perhaps a (or something like this):

fprintf(fptr, "%12s %8s %8d\n", part.name, part.number, part.amount)   

might work out better.  Then again, if portability isn't a concern, leave
it as it is - it works. 

Steve - not trying to turn this into the "portability"notefile :^)  I've been
        bitten with these things in the past, so I keep an eye out for them... 

    
    	Well I finaly got it working.
    
    	The problem appeared to be the last scanf as %d this was corrupting
    the short in the structure . I tried it as %hd but to noavail.
    
    Anyway to cut a long story short (short being the operative word).
    
    I changed the declaration of amnt from short to int and cast the
    argument in fwrite to void and it worked fine..
    
    When you compiled with 5.10 what options did you use ?
    
    			_pete_  :-) :-)
    
    

    Things get more interesting....
    
    If you optimise the code ( with the short still in ) it works fine !
    
    lc -L -O file.c
    
    
    			-Pete-