RE: how to handle large varible sized semanitc values (in C-basedparsers)?

[Gary Funck]

Hans, thanks for the follow-up.  I noticed after the
fact that I didn't modify my current %union definition
to the form where it held the storage for the binary
data within the node itself. To clarify, the defintion
should have been:

%union {
  uda_tword_t val;
  uda_tword_t val2[2];
  uda_tint_t signed_val;
  uda_taddr_t addr_val;
  uda_debugger_pts_t pts;
  char *str;
  uda_binary_data_t data;
}

where uda_binary_data_t is defined as:

typedef uint8_t uda_byte_t;
typedef struct uda_binary_data_struct
{ 
  size_t len;
  uda_byte_t bytes[16*1024];
} uda_binary_data_t;

I think that main points of your reply still apply.

Hans Aberg wrote:
> The Bison generated parser just implements %union as a C/C++ 
> "union", which is copied as memory. [...] The rest will have  
> to be implemented in the actions, and during error recovery, using % 
> destructor (typically for cleanups).

To offset the overhaed of copying, I was thinking of keeping
a parallel stack of uda_binary_t objects which held the storage
for those objects, and which could be pointed to by a <data> variant,
with that <data> item being defined as a pointer, instead of a full
object as above.   To do this, I need to be able to map yacc's
stack pointer into an index into a parallel array (of <data> objects).
I was thinking that setting YYINITDEPTH to YYMAXDEPTH (making sure
that they are suitably large) might help me get there, because it
would ensure that the semantic value stack is contiguous.  But
handling the current semantic value (yylval) in this way is another matter,
(because it isn't realized as an item on the semantic value stack).
As I understand the way Bison is set up, only the use of C++'s
constructors and destructors would give me the required tools to
manage such a "parallel data store" facility.

Changing back to example that I sent previously, where <data> is
a pointer to a malloc'd object, I realize now that I hadn't thought
of the error/abort cases and the need for %destructor.  Probably,
I should go with some sort of stack allocator which can be reset
at the beginning of each parse (the parser is driving a simple
server protocol, and must run continuously).  Thanks for mentioning
that aspect of storage management.

  - Gary