Question About OPTIONAL Parameters

[Clay Clear]

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

[Tom Hanlin]

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

[Clay Clear]

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


------------------
clayclear4 at mchsi dot com

[Tom Hanlin]

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

[Clay Clear]

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
recoding.


------------------
clayclear4 at mchsi dot com

[Clay Clear]

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:

DECLARE FUNCTION test1 CDECL (BYVAL STRING, BYVAL STRING [, BYVAL INTEGER]) AS INTEGER

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

[Tom Hanlin]

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
approach?

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

[Clay Clear]

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

[Tom Hanlin]

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