Pure FB Runtime Library (in progress)

[fxm]

Either way, it seems that this most significant bit is always masked when the string length is evaluated from the descriptor:

Code: Select all

function salut() as string
   '' temporary string returned
   return "salut"
end function

dim f as function() as any ptr = cast(function() as any ptr, @salut)

dim as STRING ptr tmp =  cptr(string ptr, f())

'' passing a temporary string to PRINT will automatically delete it
'' print *tmp '' salut

'' print it as a zstring instead
print *cptr(zstring ptr, cptr(uinteger ptr, tmp)[0])         '' salut                                                   

print hex(cptr(uinteger ptr, tmp)[1], sizeof(uinteger) * 2)  '' 8000...005
print hex(cptr(uinteger ptr, tmp)[2], sizeof(uinteger) * 2)  '' 0000...020
print len(*tmp)                                              '' 5

'' clean-up the temporary (if we didn't already pass it to some other rlib function)
fb_hStrDelTemp( *tmp )

For temporary strings, the most significant bit is set on the 'len' member which is the second member of the string descriptor type.

Finally, I thus found there an explanation on the maximum size of variable strings: 2 ^ (31 or 63) - 1
:-)

Am I right ?

[coderJeff]

For temporary strings, the most significant bit is set on the 'len' member which is the second member of the string descriptor type.

Finally, I thus found there an explanation on the maximum size of variable strings: 2 ^ (31 or 63) - 1
:-)

Am I right ?

You are correct. And the most significant bit is masked whenever the the field is used to determine length.

[adeyblue]

Any other burning jobs? I looked at the todo and the only other thing that seems within fixable reach is this

The decimal separator used/recognized by the CRT float <-> string conversion
functions (strtod, wcstod, sprintf, swprintf) depends on the CRT's locale
setting (setlocale()), i.e. STR()/VAL() and other internal users of these
functions will break if anyone calls setlocale() for LC_NUMERIC or LC_ALL
and changes away from the '.' decimal separator (e.g. gtk_init() sets LC_ALL).
However FB should always use '.' for portability.
We'd need our own float <-> string routines (PRINT USING/FORMAT may have one
part of that already) to really fix this.

and that seems trivially fixable by just wrapping the crt calls in a setlocale to C and back rather than going full boar on writing half of printf/scanf ourselves.

[marcov]

Any other burning jobs? I looked at the todo and the only other thing that seems within fixable reach is this
and that seems trivially fixable by just wrapping the crt calls in a setlocale to C and back rather than going full boar on writing half of printf/scanf ourselves.

And using a critical section around it so that two threads using scanf don't fail (or is locale threadvar?)? I googled a bit and I didn't find a way to pass e.g. a locale record to (s/f)scanf. For C++ there seems to be stream::imbue to set locale on a per file basis for fscanf.

[adeyblue]

Nah, that sounds like work. If it returns incorrect results ever, it's the same as now so we're being 'compatible', if it works fine ever, we've fixed a bug. Best of both worlds. Work smarter Marcov, not harder.

[adeyblue]

I was looking into symbol info because of the stack trace request and managed to be able to get the required info with libdwarf on Windows.

The question I have now is, do all our viable native backends produce dwarf debugging information? I would've used libbfd, but it's full GPL so I think that's a no-go.

The main problem from a libdwarf usage point of view, is that it's only buildable as a dll on Windows for some reason. So you have to cart a dll around as well a compile with debugging info and without optimization for completely accurate stack walks

Is this desirable to add as a built-in?

(also wow libdwarf is verbose)

Edit: Should've googled. The answer is no, they don't. And there doesn't seem to be a library besides bfd for reading stabs info :-(