Re: flex {c,m}alloc() checks

2019-08-28 Thread Michael Mikonos
> I'd say go for the x* solution, > > -Otto Sure. When I looked at this again there are also realloc() return value checks missing, so I added xcalloc(), xmalloc() and xrealloc(). An old (unused) function yy_flex_xmalloc() gets removed. When building this I checked the resulting .o files

Re: flex {c,m}alloc() checks

2019-08-28 Thread Otto Moerbeek
On Wed, Aug 28, 2019 at 10:07:32AM +0800, Michael Mikonos wrote: > On Sun, Aug 25, 2019 at 02:58:47PM +0200, Otto Moerbeek wrote: > > On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote: > > > > > Hello, > > > > > > I noticed that flex is too trusting and assumes > > > calloc/malloc

Re: flex {c,m}alloc() checks

2019-08-27 Thread Michael Mikonos
On Sun, Aug 25, 2019 at 02:58:47PM +0200, Otto Moerbeek wrote: > On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote: > > > Hello, > > > > I noticed that flex is too trusting and assumes > > calloc/malloc will always succeed. Hopefully I > > caught all of them. > > I tried to follow

Re: flex {c,m}alloc() checks

2019-08-25 Thread Otto Moerbeek
On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote: > Hello, > > I noticed that flex is too trusting and assumes > calloc/malloc will always succeed. Hopefully I > caught all of them. > I tried to follow the existing idiom of > calling flexerror() and passing strings via > the _()

flex {c,m}alloc() checks

2019-08-25 Thread Michael Mikonos
Hello, I noticed that flex is too trusting and assumes calloc/malloc will always succeed. Hopefully I caught all of them. I tried to follow the existing idiom of calling flexerror() and passing strings via the _() macro. OK? - Michael Index: dfa.c