No announcement yet.

Question About OPTIONAL Parameters

  • Filter
  • Time
  • Show
Clear All
new posts

  • Question About OPTIONAL Parameters

    When the calling code does NOT pass an optional parameter to a
    CDECL procedure, does the PB engine pass zeroes for the parameter, or
    does it pass nothing at all for that parameter? I have tried two
    different codes, one using production code, the other using temporary
    test code. The end results were not identical. So, I am trying to narrow
    down to what I think is an error in my production code implementation.
    Otherwise, I cannot explain the differences. I do not want to post
    the code (I no longer have the test code) unless I absolutely
    have to, because it uses other features in my PB setup, and I do not
    really want to go into a long explanation of the whatfors of why this
    does that.

    Thank you for any assistance.

    clayclear4 at mchsi dot com

  • #2
    I'd guess PB/DOS passes null values as placeholders, as BASIC routines
    don't expect the parameter stack to vary. C does allow for variable-sized
    parameter stacks, but I don't think you can create those from PB unless
    you use asm code.

    Let me check with R&D...

    Tom Hanlin
    PowerBASIC Staff


    • #3
      Thanks, Tom. I use MASM 6.14, not C, for my OBJ files.

      clayclear4 at mchsi dot com


      • #4
        I got that wrong. The Windows compilers pass null values, but
        PB/DOS only passes a value if the parameter is actually specified.

        Tom Hanlin
        PowerBASIC Staff


        • #5
          Thanks, Tom. Then I would like to put in a wishlist item
          request: make the next release of PB/DOS behave like the
          Windows compilers with OPTIONAL params: pass NULL's if the
          OPTIONAL params are not specified by the calling code.

          Since I now know that PB/DOS does not pass nonspecified optional params,
          my 5 CDECL functions are useless. They were nothing but my "lazy programmer"
          utilities, but I had used them quite heavily (the "lazy" part
          applies to not having to type in the optional param <grin> ).
          I am not whining or complaining, am just commenting.

          OK, thanks for looking into my question, Tom. I'll go now and set about

          clayclear4 at mchsi dot com


          • #6
            I found a "cure" - the ENTER 0, 0 opcode. I "discovered" it while
            going through my MASM 6.14 sample files looking for how THEY did it.
            ENTER 0, 0 will still only use the number of params passed to the
            CDECL, BUT, somehow, it sets any overrange word ptr [bp + *] readings to
            return zero. In other words, if you have:


            and in you calling code you have

            PRINT test1("test string 1", "test string 2")

            and in your CDECL function you include the line:

            test word ptr [bp + 0ah], -1
            jz ThisLabel
            jnz ThatLabel

            it will correctly jump to ThisLabel if the third parasm is not passed,
            and jump to ThatLabel if the third param is passed and is nonzero.

            Note to the lurkers: if you use the ENTER 0, 0, make sure you include
            a corresponding LEAVE at the end of the proc. Also note that ENETER/LEAVE will
            take care of the lines:

            push bp
            mov bp, sp
            pop bp

            for you.

            Now, I only need Bob's or Tom's or Lance's blessings for my newfound
            approach so I know it is safe to be used with the PB engine. I have
            done extensive testing in the past few hours, and have not had ANY
            errors, Windows or otherwise. However, since this is grey area to me,
            I seek assurance.

            clayclear4 at mchsi dot com


            • #7
              That wish is unlikely to be granted, as it could break existing code.

              In C, a routine that accepts a variable number of parameters has some
              way of knowing how many parameters to expect. Typically, the first
              parameter provides this information. Perhaps you could use the same

              The way you're using them, I don't think ENTER and LEAVE actually do
              anything different than the previous PUSH BP / MOV BP,SP and POP BP
              sequences. Certainly, you can't rely on stack values that are outside
              the range of the passed parameters.

              Tom Hanlin
              PowerBASIC Staff


              • #8
                Sorry for bringing up this "old" topic again, Tom.

                Could you add it to the wishlist for the next release (or upgrade)
                of PB/DOS so it behaves as the 32-bit compilers do with optional
                params, in that it passes nulls if the/a optional param is not
                passed by the calling code? I made this request earlier in this topic,
                I know, and I apologize for being boorish about it, but you did
                not reply concerning it, so I am making an "official" request, now.

                I have spent the past few days mulling over your last posting, Tom,
                and finally decided that your wisdom would win out. Until now, I kept
                using my "newfound" method because it performed flawlessly, never any
                errors, BUT, I decided it'd be best to heed your wisdom, in the rare
                eventuality that I return to releasing DOS programs to the Public. As you
                stated, I would not be able to rely on the use of unpassed params
                having the same results on the stack, regardless of using ENTER/LEAVE,
                on OTHER users' end platforms.

                Thank you.

                clayclear4 at mchsi dot com


                • #9
                  All requests get their due hearing, Clay. I just don't want to tell
                  you "yes" when the answer is more likely to be "ummm..."

                  A better solution is likely to be macros, which seem likely to come
                  over to PB/DOS, now that they're part of the Windows compilers.

                  Tom Hanlin
                  PowerBASIC Staff