Re: Correct way to push an empty string?

[sur-behoffski <sur_behoffski@...>]

> > what about making backwards compatible change in the future API releases?
> > Given that responsible API user will need to check the pointer for NULL
> > anyway (at least in the case above), maybe it would be reasonable to embed
> > this check in the API and push synthetic empty string in case len is zero
> > and the pointer is NULL. Either it will be done inside the API or each and
> > every developer will be forced to write additional wrappers on top of
> > pushlstring (or write unreliable code)...
> > This change does not seem to break anything. Just adding this point to
> > the documentation will force people to, well, read documentation in
> > some buggy situations like this.
>
> I thought about that. It is not true that "responsible API user will
> need to check the pointer for NULL anyway".  I checked all uses of
> lua_pushlstring in the standard libraries and some other libraries I
> wrote (without knowing that it was wrong to pass NULL): I did not find
> a single case that needed that check.  (Even though many places could
> call lua_pushlstring with a zero length, none would pass NULL as a
> pointer.) To make everybody pay for a check that seems to be rarely
> needed is not a good idea. (This is a C API, after all.)
>
> -- Roberto

[Replying from the digest... apologies in advance for any thread
breakage...]

On the question of costly checks, modern CPUs are using pipelined
execution, speculative execution and the like, such that a check for
zero might effectively have no overhead (the instruction could be
retired in parallel with another instruction).  However, this would
vary (and would need to be checked) for quite a number of different
platforms/architectures/compilers/libraries.

If, however, the zero check causes a pipeline stall (until the
outcome of the check is known), then this could be a significant
slowdown.

Perhaps split the existing call into two cases:

    (a) Known-okay (where wither the caller's parameters can be
        trusted, and/or where the caller (another library function)
        is known to be well-behaved); plus
    (b) A conservative interface (macro?) that checks before it
        calls the known-okay interface;

might give value and reduce surprises.

-----

On a separate note, I'm seeing lots of references to "read the
manual" and/or "read PiL" for 5.2/5.3 questions on this list.
I have a personal aversion to screens, and a preference for paper,
for various reasons, and as a result have several copies of the
second edition from the 5.1 era, of the English versions of both
PiL and of the Reference Manual.

Is there a time frame for an updated paper edition of the
Reference Manual for 5.3 ([perhaps with 5.2 annotations])?

I missed the announcement of PiL, third edition, covering 5.2...
and would like to obtain an updated version covering 5.3.  Is there
a time frame for producing a paper version of PiL for 5.3?

cheers,

sur-behoffski (Brenton Hoff)
Programmer, Grouse Software