On Sun, Mar 02, 2003 at 02:33:55AM +0100, Jens Rehsack wrote: ... > >>+ n = write ( ilmi_fd[intf], resp+1, resp[0] ); > > > >Here's a case where it matters whether something is u_char or char. > >write(2) takes a size_t as its third arg, and extension of a char to > >that may not be the same as for u_char, for example on Sparc. If the > >response is ever >127 bytes, this will fail. You're going to have to > >look carefully at how things are used to see when char is appropriate > >and when u_char is necessary. > > That is really right, but for those check I have to know more 'bout ATM, > right? I just have detected some compiler errors using > -finline-functions (yes, I'm playing with optimization options :-)). If > you know a real good online-reference, one fine day I'll check it and > check the entire ilmid.c code for valid signment.
This has nothing to do with ATM. It has to do with how the code that's in the file uses 8-bit bytes, and how it calls standard functions. If you make changes blindly just to get rid of compiler warnings, you will introduce bugs in operation that may be difficult to find, years later. The fact that Resp_Buf needs to remain a u_char[] is just one example. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
