[comp.windows.ms.programmer] Speaking of _lread

kentfo@polari.UUCP (Kent Forschmiedt) (05/24/91)

_lread() ans _lwrite() are misdeclared in windows.h.  They are
declared as WORD, which means unsigned int, which means the compiler
believes that they cannot return -1, which they must do to report
an error.  If you compile with -W2 under C6.0x, which is apparently
the convention in microsftland, the compiler will quietly reduce
things like:

if (_lwrite(...) < 0) {
	// do something about it
}

to:

_lwrite(...)

because an unsigned cannot be less than zero.  If you use -W3 it will
tell you that it is breaking your code.

The sample dib code in the SDK depends on this misdeclaration; if you
correct the declaration in windows.h, the sample code will break.  I
suspect that there is other similarly broken code floating around microsoft.
Do you suppose Excel would pass lint?  nyuk nyuk nyuk

I think it's kind of cute the way they turn off the warning messages
that the compiler generates.  I knew a guy once who disconnected
the oil pressure warning light from his engine because he didn't like
it shining there on his dashboard.  Guess what happened to his motor?
-- 
Kent Forschmiedt ... kentfo@polari ... uw-beaver!sumax!polari!kentfo

Norbert_Unterberg@p4.f36.n245.z2.fidonet.org (Norbert Unterberg) (06/04/91)

 > _lread() ans _lwrite() are misdeclared in windows.h.  They are
 > declared as WORD, which means unsigned int, which means the compiler
 > believes that they cannot return -1, which they must do to report
 > an error.

I think they are declared correctly, but the documentation is not uptodate. 
Since _lread/_lwrite can handle nearly 64KB of data, a return value of type int 
does not allow the function to return the number of read/written bytes, if it 
is above 32 KB. So the functions return the unsigned number of bytes, or 0xffff 
if an error occured. If the return type is int, code like

if (_lread(file, buffer, n) != n)
      error();

does not work for n > INT_MAX.

Norbert