Re: SegFault with Bison Grammar

[Philip Herron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Kyle

Kyle Brandt wrote:
> Hi Phil, Thank you for the response and time, regarding what you
> said:
I probably wasn't that helpful ;)
>
> **GDB** I have tried GDB, my gdb skills are weak trying to learn
> how to use it better, but I am still not sure what is going on.  I
> will include the gdb output at the end of the email which include
> the verbose Bison output.
>
> **String Dumps with Lex:** I think that is what I am doing:
>
> [a-zA-Z/0-9\-_\.]+ { yylval.string=strdup(yytext); return(WORD); }
>
> **Using Union** I am using Union and types, here they are: %union {
>  char * string; struct node * args; struct ext_cmd * cmd_w_args; }
Yeah thats good
>
> %token <string> CD WORD PWD EXIT EQUALS %token ERROR HELP NEWLINE
> SEMI PVAR GT %type <args> arg_list %type <string>
> variable_assignment redirect %type <cmd_w_args> external_cmd
>
> **Malloc Tip** Seems smart, going to implemement when I get a
> chance.
>
> **Memory Problems with Yacc/Lex** """Your not going to be able to
> fault memory corruption or problems on bison or lex""" My fault for
> not being clear, I am not trying to blame Bison at all.  I figure
> it is myfault, I just meant I wasn't quite sure how things like $$
> work, and if I am abusing something by do something like &($1)
Well ok, i'll chuck in some thoughts on how i would approach it, or
actually you might find one of my projects worth looking at,
http://code.redbrain.co.uk/cgit.cgi/crules/

Its an interpreter, i use YACC, and LEX. Anyways a shell what kind of
syntax does that allow,  I guess your going for bash style shell, so
its like running programs with arguments etc.

So the basic function would be something like:

ls
or

ls -la
or then it goes to stuff lile

ls -la > bla
or
ls -la >> bla2

or

ls | grep ...

and then you would have builtins for certain commands too. What I do
when approaching problems like this, think or pretend you have
implemented some kind of parser, and what your get is some kind of
representation of what the outcome of parsing was, and then what do
you need to execute. So if someone was to do something like ls or cd
or grep | ... etc, what is the representation of any of that.

What i would do is think of some kind of symbol table structure
something like a very high level kind of 3-address code.

struct symtab {
 const char* prog_name;
 const char* args;
 unsigned short mode;
 struct symtab* next;
}


Hmm this might be something to start off from. So say you parsed out
something that was ls -la > foo, you could have prog_name = ls then
args = -la then mode was output or pipe etc ... and next would be
pointing to the next symbol which was foo to tell you where to output
to and maybe it was in a mode to output or pipe to something else so
you can create a long structure.

The idea being you can generate a symtab and then its a matter of a
runtime doing something like

while( next ) {
exec_symbol(sym);
}

Not sure if any of this makes sense but might give you some ideas to
think about.

Then when you figure out a working a structure you have to make your
grammar free form enough to handle this. You could start from
something like:

%type<sym> expression
%type<sym> basic
%type<string> args_list

%start exec

exec:
| exec expression
{
 exec_symtab($2)
}
;

expression: expression '>' expression
    {
$1->mode= OUTPUT;
$1->next= $3;
    }
                 | expression '|' expression
                 | ....
                 | basic

basic: IDENTIFIER
{
    struct symtab* sym= xmalloc();
    ....
$$= sym;
}
         | IDENTIFIER args_list

args_list: '-' IDENTIFIER // ?? thats probably not good but hey
{
$$= $2;
}

So that is a messy but it might give you some insight in how to think
about it all :)

- --Phil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqz0qAACgkQAhcOgIaQQ2EpQwCfUByxKC86t2bMyCpKsOCAZUPf
t10AoILeysUzKodYjioV3a+aqnkv7MDA
=NUop
-----END PGP SIGNATURE-----