Announcement

**Lance Edmonds** · 17 May 2001, 09:43 PM

When the string is empty, VB will be passing a null-pointer to PowerBASIC (you passed the dynamic string BYVAL, right?). As you probably know, null pointers are a no-no.

I've not tried it, but if you should be able to test the ASCIIZ pointer (something like IF ISFALSE VARPTR(azstr) THEN...) and react accordingly.

Alternatively, you may prefer to pass the dynamic string BYREF from VB, and receive the string BYREF in PowerBASIC instead. This will work fine even if the string is empty, since a pointer to the string handle is passed instead of a null pointer.

In summary, this is not a bug, but an implementation/usage issue.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Daniel Corbier** · 18 May 2001, 12:18 PM

Thanks Lance. Yes I was passing the string from VB (ByVal), but
a call to that function is placed from within the DLL as well. I
was thinking of making sure that the value being passed had at
least a space (" ") in it. But the VARPTR idea you suggested
looks better, as it should handle any kind of string passed from
any external program.

I do hope that things like this will be clearly discussed in the
next help file, so that we don't have to learn it the hard way.
It would be appropriate in Appendix B, where it explains how
to pass strings from VB to PB (There are probably other places
where it can be mentioned as well).

Also, is there no way for the compiler (future version) to
gracefully do a conversion from null to an empty string, when
this ASCIIZ variable is assigned to a non-ASCIIZ string, or when
it's used in a string expression, and spare the unsuspecting
programmer from this scenario?

While on this topic, here's another related wishlist item. I
have Exported functions in my DLL which are also called from
routines within the DLL. The compiler always requires that I
add "ByCopy" when I'm passing a regular string to a function
which takes ASCIIZ. I would like the compiler to just pass it
by copy for me, without me having to explicitely type ByCopy
all the time.

Also, support for a centralized error trapping routine of some
sort would be a great time saver. Having to add "On Error Goto"
to several functions until you norrow down errors like the above
can get tedious (especially when the error might be locately
elsewhere from where you'd think of looking).

And speaking of On Error Goto I noticed that the compiler does
not let me give the label a name that exists in another
unrelated routine as a variable name. I thought labels were
local.

On the other hand I really need a way to use labels from other
routines, like I was able to do with PB 5. I won't actually be
jumping from one routine to another but I just need to get the
CodePtr address from another routine, as described in a previous
message at http://www.powerbasic.com/support/fo...-4-000497.html
This is a major wish for me. For now, I'm weighing the option
of compiling a particular project with PB 5 just for that.

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

**Lance Edmonds** · 18 May 2001, 05:24 PM

Also, is there no way for the compiler (future version) to
gracefully do a conversion from null to an empty string, when
this ASCIIZ variable is assigned to a non-ASCIIZ string, or when
it's used in a string expression, and spare the unsuspecting
programmer from this scenario?

It is not really the place of the compiler to start altering what is being passed to your code... afterall, you may actually want to be passed a nul-pointer at some stage!

While on this topic, here's another related wishlist item. I
have Exported functions in my DLL which are also called from
routines within the DLL. The compiler always requires that I
add "ByCopy" when I'm passing a regular string to a function
which takes ASCIIZ. I would like the compiler to just pass it
by copy for me, without me having to explicitely type ByCopy
all the time.

You can simply enclose that parameter in parenthesis to force it to be evaluated as an expression (2 characters instead of 7), and hence gets passed BYCOPY. What you are asking is for the compiler to anticipate how you want the string passed, and again, this is not really the job of the compiler.

Also, support for a centralized error trapping routine of some
sort would be a great time saver. Having to add "On Error Goto"
to several functions until you norrow down errors like the above
can get tedious (especially when the error might be locately
elsewhere from where you'd think of looking).

The problem is that a global error trap adds a lot of overhead and serious complications to the app, mostly because a global error trap is effectively out of scope of the code that would have triggered the error. Threads make the problem even more complex, since more than one thread could trigger an error trap, so the error trap would need to be thread-safe!)

Basically (no pun intended), this gets incredibly messy incredibly quickly. R&D have discussed this before and have said that it is unlikely to be implemented unless someone can come up with a significant reason for such a feature.

And speaking of On Error Goto I noticed that the compiler does
not let me give the label a name that exists in another
unrelated routine as a variable name. I thought labels were
local.

Labels are indeed local, but they must also be unique.

On the other hand I really need a way to use labels from other
routines, like I was able to do with PB 5.

I understand, but this behavior in 6.0 was intentional, and not likely to be relaxed any time soon.
However, the easiest way around the problem would be have the target sub/function sort out the codeptr address array when first run, so there would be only the very small overhead of one numeric test (over and above the time-critical code):
ie,

Code:

GLOBAL ProcArray() AS LONG
SUB MySub
  STATIC Init&
  IF ISFALSE Init& THEN
     ProcArray(1) = CODEPTR(label1)
     ProcArray(2) = CODEPTR(label2)
     ...
     Init& = %TRUE
     EXIT SUB
  END IF
 
  ... normal code goes here, ie:
 
Label1:
  GOSUB DWORD ProcArray(n&)
 
Label2:
 
END SUB

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Daniel Corbier** · 19 May 2001, 10:58 PM

Lance, after reading your first response, I printed VarPtr(Arg)
with MsgBox to verify that it returned a 0 for empty strings.
I thought I now had a solution on hand, until I actually tried
to implement VarPtr(Arg) with an IF statement. It seems like
VarPtr(Arg) triggers an error when Arg is null in this context,
which seems strange. Here's what I tried:

Code:

$Compile Exe
$Debug Error On

Sub Test(Arg As Asciiz)
   If VarPtr(Arg) = 0 Then Temp$ = "" Else Temp$ = Arg
         
   MsgBox Str$(Err) ' Still returns an error
End Sub

Function PbMain As Long
   Call Test("")
End Function

I also got the same result using ISFALSE.

It is not really the place of the compiler to start altering what is being passed to your code... afterall, you may actually want to be passed a nul-pointer at some stage!

I don't need for the compiler to modify the argument that's being
passed. What I was thinking of was for the compiler to check for
null when an ASCIIZ string is mixed with a regular string, as in:

LocalString$ = AsciiZArg

If the compiler won't do it automatically, perhaps PB can add a
CSTR() function which would work just like CBYT(), CCUR(), etc...
So if necessary, I can do this:

LocalString$ = CSTR(AsciiZArg)

And it would take care of converting the null value to a proper
empty string.

You can simply enclose that parameter in parenthesis to force it to be evaluated as an expression (2 characters instead of 7), and hence gets passed BYCOPY. What you are asking is for the compiler to anticipate how you want the string passed, and again, this is not really the job of the compiler.

If there were several options for the way that variable could be
passed, I'd understand, but the compiler does not let me pass this
string argument ByRef or ByVal. There's no other apparent option
other than BYCOPY. The compiler stops compiling at that line and
even suggests that I use BYCOPY (as though I had a choice).

The problem is that a global error trap adds a lot of overhead and serious complications to the app, mostly because a global error trap is effectively out of scope of the code that would have triggered the error. Threads make the problem even more complex, since more than one thread could trigger an error trap, so the error trap would need to be thread-safe!)
Basically (no pun intended), this gets incredibly messy incredibly quickly. R&D have discussed this before and have said that it is unlikely to be implemented unless someone can come up with a significant reason for such a feature.

I hope I can make a convincing case for this. For me a very
significant reason is the time involved in tracking down tricky
errors which may be located nowhere near the apparent source
of the problem.

1. Narrowing down an error by placing On Error Goto and
accompanying code to each line until the error is found is very
time consuming.

2. The code which accompanies On Error Goto is itself prone to
adding more errors to the program. When adding these lines
everywhere you might type it in correctly for most functions,
and add an undetected typo in just one of them.

3. Speed and file size are not extremely important when debugging.
I understand that PB wants to make a compiler that's very fast.
Speed is indeed very important for me in the non-debug version
of my DLL. But when I'm debugging, micro-seconds are irrelevant.
(Actually, the current debugger is a little slower than I excpect.
But I live with it).

4. With Multiple error handlers, one is unlikely to uncover bugs
that would be revealed with a centralized error handler. In a
case like the above with ASCIIZ strings causing GPFs, I was lucky
that this error happened to be in a routine where arrays were
being defined and used, but even then I took a lot of time
because I was after arrays. Had it been caused by a small
innocent-looking function with no arrays or pointers in it, it
might not have occurred to me to check for errors there at all
(at least not before I would start growing gray hairs

By the way, you can restrict global error-handling to files
that are compiled as stand-alone EXEs. When debugging for things
like this I simply load my DLL code into PB/CC, and run it as a
stand-alone (conditional $If statements with alternative PBMain
program for when I'm running it in PB/CC makes this easy to do).
You can also simply document the multi-thread limitation. Even
a rudimentary global error handler would be an incredible time
saver, and it would also catch obscure bugs that me not ever be
cought otherwise.

Labels are indeed local, but they must also be unique.

I'm not sure I understand how this rule is implemented. I find
that I can use the same label name ErrorHandler in
different functions (it would be terrible if I had to have a
unique error handler label for each routine). But then if I
don't want to type a long word like that and just name
the label x, then when I compile, it gives a
Duplicate name error because I happen to have a variable
named x somewhere in a different function. I can
understand the need for a unique label name within the same
function but I don't see why the compiler should complain if the
label shares the same name as an unrelated variable located in a
different function.

However, the easiest way around the problem would be have the target sub/function sort out the codeptr address array when first run, so there would be only the very small overhead of one numeric test (over and above the time-critical code):

You're right. I tried it, and the overhead is minimal. The
speed difference was so small that it was hard to measure. I
had implemented another equally effective work-around but assumed
that it must have a speed penalty. However, one speed-related
feature that I still hope for is _fastcall. That one showed a
very remarkable speed difference when I measured earlier this year.

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

Announcement

ASCIIZ empty parameter bug (or feature?)

ASCIIZ empty parameter bug (or feature?)

Comment

Comment

Comment

Comment