Is there a way of telling if a pointer is valid?

[Pat Bullman]

I'm working on a DLL which will have strings passed to it.

Initially the DLL accepted a string long pointer but I've been changing it to basic strings, as in:

Old Way

DbSaveData( lpStringData as String Pointer )

New Way

DbSaveData( StringData as String )

In either way I need to know if the string is valid. Any suggestions.


Pat

[John Gleason]

This may help:

#COMPILE EXE
#DIM ALL

FUNCTION DbSaveData( StringData AS STRING ) AS LONG
   IF LEN(stringData) > 0 THEN FUNCTION = 1 ELSE FUNCTION = 0
END FUNCTION

FUNCTION DbSaveData2( BYVAL lpStringData AS STRING POINTER ) AS LONG
   IF lpStringData > 0 THEN FUNCTION = 1 ELSE FUNCTION = 0
END FUNCTION

FUNCTION PBMAIN () AS LONG
  LOCAL StringData AS STRING
  LOCAL lpStringData, lpStringData2 AS STRING POINTER

  IF DbSaveData( StringData ) = 1 THEN   'always valid, may be 0 length
     ? "len > 0"
  ELSE
     ? "len = 0"
  END IF

  lpStringData = STRPTR(stringData)      'valid pointer
  IF DbSaveData2( lpStringData ) = 1 THEN
     ? "valid ptr" & STR$(lpStringData)
  ELSE
     ? "invalid ptr" & STR$(lpStringData)
  END IF

'  lpStringData2 = STRPTR(stringData)   << here commented out so 0 is parameter passed
  IF DbSaveData2( lpStringData2 ) = 1 THEN
     ? "valid ptr" & STR$(lpStringData2)
  ELSE
     ? "invalid ptr" & STR$(lpStringData2)
  END IF
END FUNCTION

[Michael Mattias]

There are some cautions you should read, but the Windows' API includes these functions:

IsBadReadPtr()
IsBadWritePtr()
IsBadCodePtr()

FWIW...
>I'm working on a DLL which will have strings passed to it.

If this DLL is for use by "other language" programmers, you should take a look at passing 'AS ASCIIZ' . That's pretty common.

The one caution there is, "by convention" when the passed address is %NULL it means "null string," so you will have to test that in your function.

When you pass "AS STRING" you will always have (well, SHOULD have) a non-zero address, although the string itself may have no length.

MCM

[Bob Zale]

Pat, You should not use the following functions at all. They have serious, known problems.

IsBadReadPtr()
IsBadWritePtr()
IsBadCodePtr()

"When you pass "AS STRING" you will always have (well, SHOULD have) a non-zero address, although the string itself may have no length."

Not true. Zero is perfectly acceptable.

Best of luck...

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

>In either way I need to know if the string is valid. Any suggestions.

That's an application decision. is "YES" valid? Is "YELLOW" valid? Is "" (null) valid?

You can test an address for validity; you can test a string for content. What the results of those tests "mean" is up to you.

[Cliff Nichols]

<deleted> looks like you guys already posted, and informed my answer would be wrong

[Michael Mattias]

>Not true. Zero is perfectly acceptable

Sure, you can pass zero; but what is the called function doing with it? There are cases where zero can be used without error: when using an 'all-PowerBASIC-created' application, if called function is simply passing along that address to OLE string functions, and most Windows functions expecting 'lpstring' parameter. (Probably some more things are safe, too).

I am reading here that a function in a DLL is being created for use by many programs and possibly many programmers using many different programming tools to effect the call. If that function wants a "non null" string it should test for NULL address before doing whatever it does, unless that address is used only as above.

e.g, if NULL address is passed to "AS STRING" function, STRPTR() works in the sense it returns a value; however, that value may not be a valid address.


Not true other times. I have GPFs to prove it. (No, not stuff I wrote).

[Michael Mattias]

Here's an interesting page on IsBadWritePtr.....

http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

[Pat Bullman]

I guess the decision is whether I develop the dll for use with other languages.

As Bob says, if the calling is PB and if the string is passed "AS STRING" then it should always result in a valid pointer.

If I expect the dll to be called by other languages then I need (??) to specify that the parameter should be a OLE string or as Micheal suggested I use ASCIIZ string which all languages support.

I haven't yet used ASCIIZ strings in PowerBASIC but I assume that the assignment of data between a PB string and an ASCIIZ is straightforward, as in:

sPbString = lpzString1

On another issue, by default PowerBASIC passes parameters BYREF which means that only the address of the variable is passed, so for OLE string only the OLE string pointer is passed and there is little overhead in passing a very large string from one procedure to another.

This is the opposite of VB?

Also, if this is the case, then there'd be no difference between passing an OLE string and ASCIIZ string??


Pat

[Pat Bullman]

Here's an interesting page on IsBadWritePtr.....

Thanks Michael. I had read something like that years ago - I knew the IsBadxxxxPtr suite of functions carried some terrible baggage but couldn't remember the exact nature.

This brings me to another issue - What does TRY...CATCH...FINALLY actually catch?

The dll I'm porting to PowerBASIC used TRY...CATCH to catch a bad pointer. But in PB it doesn't work like the SEH of say "C".

Is there a way arround that? SEH is API driven (I think) so has anyone written SEH rountines for PB or am I being too anal here.


Pat

[Michael Mattias]

>so has anyone written SEH rountines for PB or am I being too anal here.

I know there is code here (I wrote and posted one demo, and I know Cliff Nichols did, too) but I'm pretty sure it's not in the Source Code fourm.

Try a full text search here on "SetUnhandledExceptionFilter" and you should find them.

[Pat Bullman]

Michael,

The search routine failed to find any matches. Maybe because the search string is too long:

The following words are either very common, too long, or too short and were not included in your search : SetUnhandledExceptionFilter

Will do a more thorough search later.


Pat

[John Petty]

Pat, You should not use the following functions at all. They have serious, known problems.

IsBadReadPtr()
IsBadWritePtr()
IsBadCodePtr()

"When you pass "AS STRING" you will always have (well, SHOULD have) a non-zero address, although the string itself may have no length."

Not true. Zero is perfectly acceptable.

Best of luck...

Bob Zale
PowerBASIC Inc.

Bob could you elaborate on that statement. Some time ago I had a problem passing strings as optional parameters (8.03). My understanding is PB will set a space on the stack for each optional parameter and assuming they are BYREF Strings then if @(VARPTR that optional) returns zero the option was not used.
Is that correct?
John

[Paul Dixon]

Pat,

has anyone written SEH rountines for PB

Try here:

http://www.powerbasic.com/support/pbforums/showthread.php?t=37821

Paul.

[Cliff Nichols]

Pat,

SEH is API driven (I think) so has anyone written SEH rountines for PB or am I being too anal here.

Nope, not too anal at all.....you are just trying to port and account for when things go wrong (and learn WHY they go wrong)

One of your other posts I was about to reply that you should use
IsBadReadPtr()
IsBadWritePtr()
IsBadCodePtr()
But while posting I saw other posts including "Mr.Zale" telling you to not use them...so I held off (seeing how I do NOT know exactly what they do or function)

As you know, from other discussions, I have been looking into troubleshooting by avoiding, and/or correcting the problem in the 1st place....so for me this is "Thin Ice"

So far...(I say that with Tounge-In-Cheek) I have lucked out with a string being passed to my function, or a language that really used a ASCIIZ passed to my function.....(My Function inside a DLL) and been able to handle it....but I too have these worries of what if???

Some languages include M$(VisualStudio), MathWorks(Matlab), NationalInstruments(Labview) <--- "MY own personal ANTICHRIST but a story for another forum)

All in all...my "Gibbs Instinct" says it can be done, but how its done??? not sure yet....

When mixing and matching languages, there is BOUND to be some confusion and possible international incidents *LOL*

[Bob Zale]

Bob could you elaborate on that statement. Some time ago I had a problem passing strings as optional parameters (8.03). My understanding is PB will set a space on the stack for each optional parameter and assuming they are BYREF Strings then if @(VARPTR that optional) returns zero the option was not used.
Is that correct?

The best way is to define all optional parameters ByRef. Then you can use ISMISSING() to definitively tell whether it was passed or not.

Bob

[John Petty]

Thanks Bob
Unfortunately that valuable instruction is not in 8.03. Yes I will get to 9, not an OOP fan but other reasons are adding up, along with AUD recovering, and I understand a matching PBForms 2 soon as well.
John

[Michael Mattias]

> Unfortunately that valuable instruction [ISMISSING] is not in 8.03...

FUNCTION foo (OPTIONAL BYREF variable) AS anything
   IF VARPTR(variable) = 0 THEN 
       param not passed
   ELSE
      it was
   END IF

That has worked since like, "forever."

ISMISSING adds test for VARIANT present but of type VT_ERROR/DISP_E_PARAMNOTFOUND. Presumably this is added to METHOD calls if the param is not included in the method call param string, but I have not got that far yet.

In this thread note that question was not, "Was string passed?" it was "Is String Valid?"

I woudl think ISMISSING would report a passed null string as FALSE if it were passed.

Let me test that real quick...

FUNCTION Test0002 (T AS STRING, OPTIONAL X AS STRING ) AS LONG
    
  MSGBOX USING$ (" X IS & MISSING WHEN &", IIF$(ISTRUE ISMISSING(X), "", "NOT"), T)
END FUNCTION

FUNCTION PBMAIN () AS LONG
    
    LOCAL T AS STRING, Z AS STRING
    T = "Not Passed"
    CALL Test0002(T)
    
    T = "Passed as variable = Null"
    Z = ""
    CALL Test0002 (T, Z)
    
    T = "Passed as inline null literal"
    CALL Test0002 (T,"")
    
END FUNCTION

Yes, it still works. Returns "X iS MISSING when X Is Not Passed" and "X Is NOT MISSING
when either a variable null or literal null is passed.


MCM

[John Petty]

Thanks Micheal I realise I had an @ too many

In this thread note that question was not, "Was string passed?" it was "Is String Valid?"

Actually his question was whether the pointer was valid (see thread heading), I'm not sure how you define an invalid string.