stricmp
in [ASM]
|
From: Sevag Krikorian on 12 Mar 2005 18:04 Randall Hyde wrote: > "Frank Kotler" <fbkotler(a)comcast.net> wrote in message > news:4232E151.64C11C07(a)comcast.net... > >>... >> >>>Humm, I thought I covered that when I mentioned fileio.read >>>expects a pointer to byte. Sorry if I wasn't clear. > > > Actually, it takes the address of whatever variable you supply. > Including the address of a *pointer* variable, if you supply > a pointer variable. > Well, okay. The stdlib manual needs a little fix then. "fileio.read( Handle:dword; var buffer:byte; count:uns32 )" But in the actual source, its "var buffer: var" > 3. Or you could simply tell HLA to use the value of myBuff > rather than its address: > > stdin.read( fOpen, val myBuff, 1024 ); > > Cheers, > Randy Hyde > Thanks, I had completely forgotten about val! -- [kain] http://www.geocities.com/kahlinor
From: Frank Kotler on 12 Mar 2005 18:18 Randall Hyde wrote: .... > The fundamental problem with the sample program at hand is that > the "buffer" parameter to fileio.read is passed by "untyped reference". > This means that HLA will take the address of *whatever* you pass > as a parameter. The following code, therefore, won't work properly > because myBuff is itself a pointer, not a buffer. So you're passing the > address of a pointer rather than the address of a buffer. Easily fixed > by calling fileio.read as follows: > > fileio.read( fOpen, val myBuff, 1024 ); // Pass value of myBuff rather than > its address Why didn't I think of that? .... > > I think this is your problem. "fileio.read", as I understand > > it, is *supposed* to return the number of bytes read, but > > look at the code! > > Yes, it is supposed to. The BytesRead statement is a carry-over > from the Windows code that doesn't belong there. It's gone in > HLA v1.75. That's all anyone can ask. Thanks, Randy! (don't forget that sys_read won't be returning -1 - no matter what the man page says) .... > But, and this is very important, people who want to use > the library functions need to learn the difference between > pass by value, pass by reference, and (especially) pass > by untyped reference. They all do different things to the > parameters you pass to a procedure. Is this a feature or a bug? :) Best, Frank
From: Randall Hyde on 12 Mar 2005 20:01
"Frank Kotler" <fbkotler(a)comcast.net> wrote in message news:423378CF.B358F79D(a)comcast.net... > > > > Yes, it is supposed to. The BytesRead statement is a carry-over > > from the Windows code that doesn't belong there. It's gone in > > HLA v1.75. > > That's all anyone can ask. Thanks, Randy! (don't forget that > sys_read won't be returning -1 - no matter what the man page > says) How does one test for error return from READ in assembly under Linux? > ... > > But, and this is very important, people who want to use > > the library functions need to learn the difference between > > pass by value, pass by reference, and (especially) pass > > by untyped reference. They all do different things to the > > parameters you pass to a procedure. > > Is this a feature or a bug? :) That's their design. So I guess you could say it's a feature. The one *problem* I see is that the HLA Standard Library doesn't always use these facilities consistently. Indeed, as Sevag noted, the documentation claims that fileio.read gets passed a VAR byte parameter. This was changed at some point in the past to make the parameter usage more consistent with other stdlib functions that accept arbitrary typed buffers. So the documentation is currently out of phase (not surprising). Of course, the documentation doesn't mention the fact that the size actually read is returned in EAX, either. Another problem that will need to be corrected someday. Cheers, Randy Hyde |