Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ODBC uses correct null-tolerant rebSpellWideMaybe()
As a convenience, routines like rebSpell() used to give back a C nullptr if the code you passed it produced a Rebol NULL. But in usermode Rebol in general, nulls are designed to create disruptions and warnings of something not being right. You have to use MAYBE to turn them into voids to get the opt out behavior. >> third [a b] == ~null~ ; anti >> length of third [a b] ** Error: LENGTH doesn't take NULL >> maybe third [a b] == ~void~ ; anti >> length of maybe third [a b] == ~null~ ; anti This "void-in-null-out" concept gives you the ability to streamline operations in a chain but still have good error locality anytime you didn't think that nulls could happen. It was decided that the API should have a similar level of safety vs. giving back nullptr that could crash C code that wasn't expecting it. So functions like rebSpell() were split into two variants: rebSpell() -> triggers interpreter failure when given null rebSpellMaybe() -> gives back nullptr when given null You could accomplish what rebSpellMaybe() does with just: rebSpell("maybe", ...) But this offers slightly more efficiency, as well as robustness when the term "maybe" may have been redefined in the applicable Rebol module. In any case, there was a straggling call to rebSpellWide() which hadn't been updated to be a call to rebSpellWideMaybe().
- Loading branch information