Re: I created a faster JSON parser

[Herman , Géza]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:
> >  I added that easily, tough admittedly it's a little bit 
> >  awkward to
> > maintain these variables.  If emacs has a way to tell from the
> > byte-pointer the line/col position (both for strings and 
> > buffers), I
> > am happy to use that instead.
>
> Since error handling isn't performance-critical it doesn't 
> matter if it's a bit slow. (I'd just count newlines.)

Basically this is what the current code does, it's just not 
postponed until an actual error, but registered during parsing. 
I'm tempted to keep it as is, as line/col information can be 
useful in other circumstances as well.  Like, for example, if we 
wanted to tag the created objects with their source location.

> You can't test that code is GC-safe, you have to show that it's 
> correct by design.

Sure, but there has to be an explanation why the current way 
doesn't have any problems.  Having a glance at garbage collection 
in emacs, it seems that it only runs during elisp code execution 
(is this true?).  As the parser doesn't call back to any elisp 
code which runs the VM, it should be safe.  If GC could happen any 
time, then I suppose the whole C Emacs code should be checked for 
that, because one can never be sure that if something is allocated 
at the C side, then at the very next moment it will be immediately 
freed by the GC. Conceptually, I see no difference between calling 
a single Fcons vs. the what the whole parser does.  If calling 
Fcons and then using its result is safe, then the parser should 
also be safe. Or is there some magic about the GC which makes this 
argument false?