RinstrX returns an index (for use with file extensions)

[jj2007]

I needed an index as a function of a file extension:

Code Select Expand

    xor ecx, ecx    ; file format index
    .if Instr_(edi, ".xls", 1)
        inc ecx
    .else
        .if Instr_(edi, ".mdb", 1)
            inc ecx
            inc ecx
        .else
            .if Instr_(edi, ".dbf", 1)
                add ecx, 3
            .else
                .if Instr_(edi, ".wk", 1)    ; Lotus wk*, Works
                    add ecx, 4
                .endif
            .endif
        .endif
    .endif
    dec ecx
    js NoFile        ; Extension not implemented
So far, so clear. However, there are lots of ifs, which is somewhat clumsy if you have more than 3 or 4 extensions to test. So I wrote a macro that shortens the exercise:

Code Select Expand

test ecx, RinstrX(edi, 1, .xls, .mdb, .dbf, .wk)  ; returns index in ecx: 0=xls, 1=mdb, etc
js NoFile                                         ; Extension not implemented
Here is the RinstrX macro:

Code Select Expand

RinstrX MACRO src, mode, args:VARARG
LOCAL is, arg, tmp$
  push ebp
  mov ebp, esp
  is=0
  for arg, <args>
    tmp$ CATSTR <Chr$(">, <arg>, <")>
    push tmp$
    is=is+1
  endm
  push is-1
  pop ecx
  .Repeat
    pop eax
    .Break .if Rinstr(src, eax, mode)
    dec ecx
  .Until esp>=ebp
  leave            ; returns 1-based index in ecx, pointer to the
  EXITM <ecx>        ; match in eax, and position of match in edx
ENDM
If you don't use MasmBasic, just replace Chr$() and Rinstr() with the corresponding functions of your library

[NoCforMe]

I prefer a data-driven approach to problems like this:

Code Select Expand

.data
Ext1    DB "xls", 0
Ext2    DB "mdb", 0
Ext3    DB "dbf", 0
Ext4    DB "wk", 0
Ext5    DB "xyz", 0

ExtensionList    LABEL DWORD
  DD Ext1
  DD Ext2
  DD Ext3
  DD Ext4
  DD Ext5
  DD -1          ;End o'list

.code
GetExtIndex    PROC    ;Ptr. to extension in EDI
       LOCAL    index:DWORD

       MOV    index, 0

       PUSH   EBX
       MOV    EBX, OFFSET ExtensionList
getlp: CMP    DWORD PTR [EBX], -1
       JE     nofind
       INVOKE Instr, EDI, EBX, 1
       CMP    EAX, 1
       JE     found
       INC    index
       ADD    EBX, SIZEOF DWORD
       JMP    getlp

found: MOV    EAX, index   
       POP    EBX
       RET

nofind:MOV    EAX, -1
       POP    EBX
       RET
GetExtIndex    ENDP

Need more or different extensions? Just edit the list.

[TimoVJL]

When MS-DOS extensions are MAX 3, those are like DWORDs and easy to access.

[jj2007]

I prefer a data-driven approach

Why waste time on a two-liner if you can do the same with 40 lines?

Code Select Expand

test ecx, RinstrX(edi, 1, .xls, .mdb, .dbf, .wk)  ; returns index in ecx: 0=xls, 1=mdb, etc
js NoFile                                         ; Extension not implemented

When MS-DOS extensions are MAX 3, those are like DWORDs and easy to access.

Valid point.

[NoCforMe]

What're you talking about? Mine works w/4 lines, minus the function (and let's not forget you have ~20 lines of macro):

Code Select Expand

    LEA   EDI, <buffer w/text>
    CALL  GetExtIndex
    CMP   EAX, -1
    JE    NoFile


[jj2007]

Mine works w/4 lines

You need a whole bunch of .DATA declarations, plus the function. My version really works with just a path and an extension.

Need more or different extensions? Just edit the list.

test ecx, RinstrX(edi, 1, .xls, .mdb, .dbf, .wk)  ; old
test ecx, RinstrX(edi, 1, .xls, .ldb, .dbf, .wk4, .xyz)  ;new

Minor point: yours will fail for .xls in C:\.xlsAnd.dbf\MyFile.dbf - you need to use some variant of InString that starts from the end.

[jj2007]

Just for fun, the Masm32 SDK versions of RinstrX and GetExtIndex. Main differences:

- RinstrX is a macro, so code will be generated only if it's effectively being used; in contrast, GetExtIndex is a proc, so it depends on how the library is constructed whether code will be generated or not.
- MB RinstrX works from the end, so a path like C:\.xlsAnd.dbf\MyFile.dbf will not falsely return the index for .xls
- RinstrX is case-insensitive, so .XLS and .xls will be found
- RinstrX is 10 bytes shorter
- a bug in NoCforMe's code was fixed

[NoCforMe]

Minor point: yours will fail for .xls in C:\.xlsAnd.dbf\MyFile.dbf - you need to use some variant of InString that starts from the end.

I thought of that. Wouldn't yours fail for the same reason? You're not using any special variant of InString() either.

[jj2007]

Wouldn't yours fail for the same reason? You're not using any special variant of InString() either.

Correct for the Masm32 SDK variant. The MasmBasic RinstrX macro uses Rinstr().

AFAIK there is no Masm32 SDK equivalent to Rinstr - maybe the CRT has one?

[NoCforMe]

Well, I'll have to say that your solution here is, as usual, a shining example of elegance--even if I'll never use it!

[NoCforMe]

Gratuitous rant here:

All this reminds me of how retarded the Windows file system is when it comes to file names and type identification, which of course is a holdover from the dim dark days of DOS.

I always thought that whatever its faults, Apple's file system was much smarter in this regard. Instead of relying on a group of 3 characters tacked onto the end of the name after a period, Apple files have the type embedded within the file directory, which makes a whole lot more sense. (Well, unless you wanted to play games, as back in DOS days, where you could change the type of a file just by renaming it, say from SOMEPROG.BIN to SOMEPROG.COM.) You set the file type when you create the file, and that's that. There are (presumably) ways to retrieve the file type through the OS.

Plus, why the stupid restrictions on allowable characters in filenames? No "?/\|=<>", etc.? (Sheesh, at least we can now actually use spaces in "long filenames"; whoop-te-do.) Again, a throwback to DOS.

<end_rant>

[HSE]

.jpeg and .json files are very common now. Is the point necessary?

[jj2007]

Well, I'll have to say that your solution here is, as usual, a shining example of elegance--even if I'll never use it!

That is very kind of you

Searching for Rinstr or InstrRev, I stumbled over an old VB library - see this post in the FreeBasic forum. There is a direct download to a DLL.

I made a quick test:

include \masm32\MasmBasic\MasmBasic.inc
  Init            ; old VB library
  Dll "mslib145"      ; download
  Declare InStrRev, 2
  Declare Replace, 3
  Print Str$("Test=%i\n", InStrRev("This test tests InStrRev: test", "test"))
  REPEAT 5
  NanoTimer()
  push 999999
  .Repeat
   Let esi=Replace("quick brown fox","brown","red")
   dec stack
  .Until Sign?
  pop edx
  PrintLine NanoTimer$(), " for VB: ", esi
  NanoTimer()
  push 999999
  .Repeat
   Let esi=Replace$("quick brown fox","brown","red")
   dec stack
  .Until Sign?
  pop edx
  PrintLine NanoTimer$(), " for MB: ", esi
  ENDM
EndOfCode

Works like a charm: Test=27

The Replace() function is also reasonably fast. There are quite a number of goodies in that library.

.jpeg and .json files are very common now. Is the point necessary?

Wrong thread?

[HSE]

.jpeg and .json files are very common now. Is the point necessary?

Wrong thread?

No. Exactly here. Perhaps you don't have an answer.

[NoCforMe]

Are you referring to the fact that these extensions are 4 characters, not 3?