FILE_SEEK to EOF prototype and/or compiler issues.

Joe Hebert

Hi,

From the help manual the prototype for FILE_SEEK is:

SLONG FILE_SEEK (LONG hFile, LONG Pos)

And the parameter Pos is defined as:

The byte position to set the file pointer (0 = beginning of file, -1 = end of file)

So in order to seek to the EOF you need to pass in -1, however, Pos is declared as a LONG not an SLONG. It?s one of those you can?t get there from here and you are kind of forced to shoot yourself in the foot.

If you compile the following line:

FILE_SEEK(1, -1)

Two warnings are generated. The first warning makes sense (according to the prototype but not to the parameter usage) and is referenced to the FILE_SEEK line:

WARNING: C:\... (16): C10571: Converting type [SINTEGER] to [LONG]

The second warning that is generated from that one line of code makes no sense (at least to me) and is referenced to the last line in the file whatever that last line happens to be (a comment, a blank line, or whatever.)

WARNING: C:\... (25): C10571: Converting type [SINTEGER] to [SINTEGER]

I realize these are only warnings but I don?t think compiling with warnings is good practice and I should be able to TYPE_CAST to get rid of them but in this case I don?t know how I can.

One other oddity I found with generating the compiled code with these warnings is with the debugger. I have a FILE_SEEK (to end of file) line in a module. When I go into the debugger and I step into said module, the debugger steps on blanks lines and comments and I?m not really sure where I?m breaking at.

I use FILE_SEEK to EOF to determine file size. Is there another way to accomplish this instead without the warnings?

Thanks,
Joe

Edit: I failed to mention that FILE_SEEK to EOF does work.

frthomas

Two random ideas:

Use the hex value of -1 for pos (two complement bla bla bla). After all, it's just a question of interpretation by the underlying code.

Seek to some arbitrary large pos you know is larger than the file size (like maxlong i.e. $FFFFFFFF and see where is stops (my hunch is this is just what -1 achieves since if memory serves me right, -1 is really close to $FFFFFFFF in two complement).

Fred

Joe Hebert

Sometimes random ideas are the best ones. Seeking to some arbitrary number that is larger than the file size won?t work. The return value is -6 for that which is - Invalid parameter (pos points beyond the end-of-file.) Or if you make the number too big then you get back a -5 which is a disk I/O error.

However, as you said $FFFFFFFF is indeed -1 for a LONG and it works like a charm with no warnings generated. We have a winner!

I wish I had a touch panel handy right now because I?d love to see if I can use this same logic to fix the problem that I posted here: http://www.amxforums.com/showthread.php?s=&threadid=339

Thanks Fred!

Joe

LegacyUser

i know this is a little late in coming, but for any others reading this, here goes.

yes, as far as i know, this is the only way to get the file size.
to get around the warning messages, i used something like the following code...

(assume a file has been opened to handle hFile)

stack_var sLONG minus1
stack_var sLONG SizeOfFile

minus1 = -1
SizeOfFile = -1
if(hFile)
{
SizeOfFile = FILE_SEEK(hFile,type_cast(minus1))
FILE_CLOSE(hFile)
}

vining

Joe Hebert wrote: »

Sometimes random ideas are the best ones. Seeking to some arbitrary number that is larger than the file size won?t work. The return value is -6 for that which is - Invalid parameter (pos points beyond the end-of-file.) Or if you make the number too big then you get back a -5 which is a disk I/O error.

However, as you said $FFFFFFFF is indeed -1 for a LONG and it works like a charm with no warnings generated. We have a winner!

I wish I had a touch panel handy right now because I?d love to see if I can use this same logic to fix the problem that I posted here: http://www.amxforums.com/showthread.php?s=&threadid=339

Thanks Fred!

Joe

Is this the way you still seek or have you found anything more elegant.

Joe Hebert

vining wrote: »

Is this the way you still seek or have you found anything more elegant.

Can you clarify your question? More elegant than what?

vining

Bad choice of words I guess.

Are you still using $FFFFFFFF for -1 or did you modify the Netlinx.axi to an include a system constant like FILE_SEEK_EOF = $FFFFFFFF or maybe change the parameter data type in DEFINE_LIBRARY_FUNCTION SINTEGER FILE_SEEK().

Seems odd that since the OP in 2004 AMX hasn't done anything to fix this.

Joe Hebert

Yes, I still use $FFFFFFFF to get around the prototype Catch-22.

You can either hardcode the $FFFFFFFF or declare a constant long equal to $FFFFFFFF and use that instead.

I never modify Netlinx.axi as I consider it bad practice to do so.