From c2c50d50c572fcd2a015aeba87d33a8ccf5a76b8 Mon Sep 17 00:00:00 2001 From: Carl Worth Date: Mon, 19 Oct 2009 13:14:37 -0700 Subject: [PATCH 1/1] date.c: Don't use glib's slice allocator. This change is gratuitous. For now, notmuch is still linking against glib, so I don't have any requirement to remove this, (unlike the last few changes where good taste really did require the changes). The motivation here is two-fold: 1. I'm considering switching away from all glib-based allocation soon so that I can more easily verify that the memory management is solid. I want valgrind to say "no leaks are possible" not "there is tons of memory still allocated, but probably reachable so who knows if there are leaks or not?". And glib seems to make that impossible. 2. I don't think there's anything performance-sensitive about the allocation here. (In fact, if there is, then the right answer would be to do this parsing without any allocation whatsoever.) --- date.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/date.c b/date.c index 102d688a..514f8404 100644 --- a/date.c +++ b/date.c @@ -115,8 +115,8 @@ typedef struct _date_token { size_t len; } date_token; -#define date_token_free(tok) g_slice_free (date_token, tok) -#define date_token_new() g_slice_new (date_token) +#define date_token_free(tok) free (tok) +#define date_token_new() malloc (sizeof (date_token)) static date_token * datetok (const char *date) -- 2.43.0