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.)

diff --git a/date.c b/date.c
index 102d688afc86e1d8791a191ce5b5eed558194f5c..514f84046ab2998fc36dcd4915f8dab69aa3fc32 100644 (file)
--- a/date.c
+++ b/date.c
@@ -115,8 +115,8 @@ typedef struct _date_token {
        size_t len;
 } 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)
 
 static date_token *
 datetok (const char *date)