0

There are a couple nice questions addressing use of structs in the Bison %union (notably Include struct in the %union def with Bison/Yacc), but I think they fail to specify that, if a struct with pointers is defined, and then those pointers are used (so I have to allocate some memory for them), who's responsibility is to free(void *) them.

Am I responsible for freeing pointers in this situation?

If a memory error occurs then how do I debug it?

jww
  • 97,681
  • 90
  • 411
  • 885
1737973
  • 159
  • 18
  • 42
  • Can't you traverse the parsed tree and free the resources once you are done with the tree (or a sub tree)? – Ajay Brahmakshatriya Aug 30 '18 at 19:15
  • 1
    Possible duplicate of [freeing the string allocated in strdup() from flex/bison](https://stackoverflow.com/questions/31104302/freeing-the-string-allocated-in-strdup-from-flex-bison). – melpomene Aug 30 '18 at 19:28
  • I've no idea @AjayBrahmakshatriya. I guess now that's something I shall research. – 1737973 Aug 30 '18 at 19:29
  • @melpomene thank you, by what I read in https://stackoverflow.com/a/31105408/1737973, I think serializing the object in a string should also be viable as a solution for issues I'm surely going to hit. – 1737973 Aug 30 '18 at 19:49

1 Answers1

2

You need to free the pointers when you're done with them. That means that in an action that runs for a reduce with those pointers, you need to do it in that action (unless you copy the pointers elsewhere that will 'own' them).

The tricky part is dealing with error recovery -- after a syntax error, bison will pop and discard items in an attempt to recover. Fortunately, bison provides the %destructor directive which can be used to clean up, freeing these pointers as they are discarded.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • I'm surely stepping in some kind of anti pattern here, but I just don't want to free the reserved memory in the production rule. I want to create a custom variant like struct, and let the next production rule manipulate it. Which makes that upper production rule a good candidate to be the point which frees the child's struct and every hanging resource. I wonder if Bison would support that, but I can try that easily. – 1737973 Aug 30 '18 at 19:35
  • Aha, understood. I guess copying the pointers elsewhere owning them will do. I just want each node tree holding an UUID to identify it. That looks like an awesome way to do what I want, and also looks like a nice easener for a potential migration to a custom parser in replacement for Bison, or to a different LALR parser generator provider (for whatever reason). – 1737973 Aug 30 '18 at 19:38
  • For the sake of the single responsibility principle, the code as a whole should look nicer and more maintainable if I limit the Bison use here to it's thing - parsing - as much as possible, proxying variant manipulation elsewhere. – 1737973 Aug 30 '18 at 19:41
  • `after a syntax error, bison will pop and discard items in an attempt to recover` Does this mean nodes ought to be immutable? Can avoiding _shift or reduce_ conflicts help get less syntax errors? – 1737973 Sep 04 '18 at 11:32
  • 1
    @uprego: Not sure quite what you're asking here, but conflicts have nothing to do with syntax errors. – Chris Dodd Sep 04 '18 at 16:43