Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2192

Re: A strange syntactic loophole available in xpost (gs doesn't do it).

Show all headers | View raw

On Thursday, February 26, 2015 at 3:33:14 PM UTC-6, tlvp wrote:
> On Wed, 25 Feb 2015 22:57:13 -0800 (PST), luser- -droog wrote:
> 
> > While cleaning up a bug in my scanner which was preventing me from 
> > placing a closing curly-brace in a string in a procedure, eg. this
> > 
> >   { (}) }
> > 
> > was giving me an undefined error. This was because it builds the
> > array on the stack, essentially doing the manual method:
> > 
> >   [ object object object ] cvx
> > 
> > But it was using "dictionary" semantics to detect the closing brace.
> > That is, the scanner calls itself recursively in a loop until the
> > top of stack compares equal to the closing curly, "}".
> > 
> > So that's why it was blowing up on the string in the proc, but the
> > real story is that } is a name, an executable name. It's hard to 
> > get at, and mean to use, but in xpost at least. It's a 1-character
> > self-delimiting token. So you *could* (if you're sufficiently 
> > perverse), define a procedure.
> > 
> >   (}) { some crazy shit }
> > 
> > Which can *only* be executed from the top level. Because it's painful
> > to get it into a proc. You can't use //immediately-loaded names, 
> > because that happens in the "child call" of the scanner, and so a
> > resulting } will terminate the proc. You'd have to hard-patch it,
> > and that's going to lose you any golfing gains. Oh, yeah. This is
> > only potentially useful for golfers. Rest of ya'lls just wasted some
> > time! haha.
> 
> No way to "escape" it? or "quote" it? That's a real drag :-{ .  -- tlvp

Hm. I can't think of any way. It's an implementation detail whether it
even exists as an independent object, depending on the details of the
scanner code.

Here's my current version.

    case '{': { // This is the one part that makes it a recursive-descent parser
                  int ret;
                  Xpost_Object tail;
                  tail = xpost_name_cons(ctx, "}");
                  xpost_stack_push(ctx->lo, ctx->os, mark);
                  while (1) {
                      Xpost_Object t;
                      ret = toke(ctx, src, next, back, &t);
                      //printf("grok: x?%d", xpost_object_is_exe(t));
                      if (ret)
                          return ret;
                      if ((xpost_object_get_type(t) == nametype)
                              && (xpost_dict_compare_objects(ctx, t, tail) == 0)) 
                          break;
                      xpost_stack_push(ctx->lo, ctx->os, t); 
                  }
                  ret = xpost_op_array_to_mark(ctx);  // ie. the /] operator
                  if (ret)
                      return ret;
                  //return xpost_object_cvx(xpost_stack_pop(ctx->lo, ctx->os));
                  *retval = xpost_object_cvx(xpost_stack_pop(ctx->lo, ctx->os));
                  return 0;
              }

which you may snip in replies in favor of this pseudocode:

   object tail = name("}")
   push(mark)
   while(1)
      object t = token()    ;;< recursive call to scanner
      if (t.type == nametype) and (compare(t,tail)==0)
         break
      push(t)
   counttomark array astore cvx

This produces the correct behavior for correct constructs,
but for a bare right-curly }
it will yield the executable name `}`
which the interpreter will then execute.

If you choose not to abuse it, the only difference apparent
to the user is that ghostscript signals a syntaxerror and
xpost signals an undefined error.

Ghostscript scanning is much more complicated, but does
a superior job of dealing with the spectrum of line-termination
conventions than xpost. I fear I will have to learn more
details from gs before I'm through.

-- 
s/fear/hope
s/have/get

Back to comp.lang.postscript | Previous | Next — Previous in thread | Find similar

Thread

A strange syntactic loophole available in xpost (gs doesn't do it). luser- -droog <mijoryx@yahoo.com> - 2015-02-25 22:57 -0800
  Re: A strange syntactic loophole available in xpost (gs doesn't do it). tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2015-02-26 16:33 -0500
    Re: A strange syntactic loophole available in xpost (gs doesn't do it). luser- -droog <mijoryx@yahoo.com> - 2015-02-26 23:02 -0800

csiph-web