Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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
    Code:
    DbSaveData( lpStringData as String Pointer )
    New Way

    Code:
    DbSaveData( StringData as String )
    In either way I need to know if the string is valid. Any suggestions.


    Pat

  • #2
    This may help:
    Code:
    #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

    Comment


    • #3
      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
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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.

        Comment


        • #5
          >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.
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            <deleted> looks like you guys already posted, and informed my answer would be wrong
            Engineer's Motto: If it aint broke take it apart and fix it

            "If at 1st you don't succeed... call it version 1.0"

            "Half of Programming is coding"....."The other 90% is DEBUGGING"

            "Document my code????" .... "WHYYY??? do you think they call it CODE? "

            Comment


            • #7
              >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
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                Here's an interesting page on IsBadWritePtr.....

                http://blogs.msdn.com/oldnewthing/ar...27/773741.aspx
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  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:

                  Code:
                  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

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      >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.
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          Originally posted by Bob Zale View Post
                          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

                          Comment


                          • #14
                            Pat,
                            has anyone written SEH rountines for PB
                            Try here:
                            http://www.powerbasic.com/support/pb...ad.php?t=37821

                            Paul.

                            Comment


                            • #15
                              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* :shhh:
                              Engineer's Motto: If it aint broke take it apart and fix it

                              "If at 1st you don't succeed... call it version 1.0"

                              "Half of Programming is coding"....."The other 90% is DEBUGGING"

                              "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                              Comment


                              • #16
                                Originally posted by John Petty View Post
                                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

                                Comment


                                • #17
                                  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

                                  Comment


                                  • #18
                                    > Unfortunately that valuable instruction [ISMISSING] is not in 8.03...
                                    Code:
                                    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...

                                    Code:
                                    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
                                    Michael Mattias
                                    Tal Systems Inc. (retired)
                                    Racine WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      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.

                                      Comment

                                      Working...
                                      X