Mailing List Archive

Paul J Stevens wrote:
> Reading header.c I noticed a likely bug.
>
> read_header is supposed zero in case of errors, right? If so, attached
> patch should probably apply.
>
<snip patch>

You're absolutely correct.

applied and committed.

Thanks,
Ilja

Here's a suspect line possibly responsible for the binary chars in
messageblks.


in
db.c,db_insert_message_block_physmessage line 856:

escaped_query = (char *) my_malloc(sizeof(char) * maxesclen);

I don't see a:

memset(escaped_query,'\0',sizeof(char) * maxesclen);

around.


Paul J Stevens wrote:
>
> Reading header.c I noticed a likely bug.
>
> read_header is supposed zero in case of errors, right? If so, attached
> patch should probably apply.
>
>
>
> ------------------------------------------------------------------------
>
> Index: header.c
> ===================================================================
> RCS file: /cvsroot-dbmail/dbmail/header.c,v
> retrieving revision 1.6
> diff -u -r1.6 header.c
> --- header.c 2004/03/19 16:27:38 1.6
> +++ header.c 2004/04/02 12:44:18
> @@ -108,7 +108,7 @@
> my_free(tmpline);
> /* NOTA BENE: Make sure that the caller knows to free
> * the header block even if there's been an error! */
> - return -1;
> + return 0;
> }
>
> /* The end of the header could be \n\n, \r\n\r\n,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

Paul J Stevens wrote:

> Here's a suspect line possibly responsible for the binary chars in
> messageblks.
>
>
> in
> db.c,db_insert_message_block_physmessage line 856:
>
> escaped_query = (char *) my_malloc(sizeof(char) * maxesclen);
>
> I don't see a:
>
> memset(escaped_query,'\0',sizeof(char) * maxesclen);
>
> around.

I don't think this causes the malfunction. The escaped_query string is
printed to by snprintf() which adds a '\0' to the end. This last
character is then overwritten by db_escape_query(), adding another '\0',
which is again overwritten by the last snprintf(), which adds the last
'\0'. So, the string is always terminated. I did add the memset() call
though, because that should make it a lot safer to change this function
in the future. And besides, it's just good practice to NULL all strings
before using them.

Ilja

Hi all,

we should still resolve the bug that causes IMAP messages to parse badly
(resulting in empty messages or errors). I still need more info on when
things wrong. Can people who have had the problem please post some
traces and the raw messages. I'd like to be able to see a trace of the
message being inserted, and and a trace of the IMAP server trying to
retreive the message.

Oh, and please update to current CVS, to make sure we're working on the
same code. :)

Thanks,
Ilja

On Mon, 2004-04-05 at 12:07, Ilja Booij wrote:
> Paul J Stevens wrote:
>
> > Here's a suspect line possibly responsible for the binary chars in
> > messageblks.
> >
> >
> > in
> > db.c,db_insert_message_block_physmessage line 856:
> >
> > escaped_query = (char *) my_malloc(sizeof(char) * maxesclen);
> >
> > I don't see a:
> >
> > memset(escaped_query,'\0',sizeof(char) * maxesclen);
> >
> > around.
>
> I don't think this causes the malfunction. The escaped_query string is
> printed to by snprintf() which adds a '\0' to the end. This last
> character is then overwritten by db_escape_query(), adding another '\0',
> which is again overwritten by the last snprintf(), which adds the last
> '\0'. So, the string is always terminated. I did add the memset() call
> though, because that should make it a lot safer to change this function
> in the future. And besides, it's just good practice to NULL all strings
> before using them.
>
> Ilja
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

It is *not* dependant on the raw message. I've tried this with a messages that
first went haywire and on reinsertion always came out clean.

I don't have any traces at hand. It doesn't happen very often.

Ilja Booij wrote:
> Hi all,
>
> we should still resolve the bug that causes IMAP messages to parse badly
> (resulting in empty messages or errors). I still need more info on when
> things wrong. Can people who have had the problem please post some
> traces and the raw messages. I'd like to be able to see a trace of the
> message being inserted, and and a trace of the IMAP server trying to
> retreive the message.
>
> Oh, and please update to current CVS, to make sure we're working on the
> same code. :)
>
> Thanks,
> Ilja
>
> On Mon, 2004-04-05 at 12:07, Ilja Booij wrote:
>
>>Paul J Stevens wrote:
>>
>>
>>>Here's a suspect line possibly responsible for the binary chars in
>>>messageblks.
>>>
>>>
>>> in
>>>db.c,db_insert_message_block_physmessage line 856:
>>>
>>> escaped_query = (char *) my_malloc(sizeof(char) * maxesclen);
>>>
>>>I don't see a:
>>>
>>> memset(escaped_query,'\0',sizeof(char) * maxesclen);
>>>
>>>around.
>>
>>I don't think this causes the malfunction. The escaped_query string is
>>printed to by snprintf() which adds a '\0' to the end. This last
>>character is then overwritten by db_escape_query(), adding another '\0',
>>which is again overwritten by the last snprintf(), which adds the last
>>'\0'. So, the string is always terminated. I did add the memset() call
>>though, because that should make it a lot safer to change this function
>>in the future. And besides, it's just good practice to NULL all strings
>>before using them.
>>
>>Ilja
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl

On Wed, 2004-04-14 at 10:42, Paul J Stevens wrote:
> It is *not* dependant on the raw message. I've tried this with a messages that
> first went haywire and on reinsertion always came out clean.
So we only need the traces then.
>
> I don't have any traces at hand. It doesn't happen very often.
that's a pity..
Does anybody else have something (or is somebody willing to test until
he gets a trace?)

Ilja

Here is a bunch of attachments.

1) original message
2) messages as contained in the database, with the binary chars
3) imap trace of retreival.







Ilja Booij wrote:
> Hi all,
>
> we should still resolve the bug that causes IMAP messages to parse badly
> (resulting in empty messages or errors). I still need more info on when
> things wrong. Can people who have had the problem please post some
> traces and the raw messages. I'd like to be able to see a trace of the
> message being inserted, and and a trace of the IMAP server trying to
> retreive the message.
>
> Oh, and please update to current CVS, to make sure we're working on the
> same code. :)
>
> Thanks,
> Ilja
>
> On Mon, 2004-04-05 at 12:07, Ilja Booij wrote:
>
>>Paul J Stevens wrote:
>>
>>
>>>Here's a suspect line possibly responsible for the binary chars in
>>>messageblks.
>>>
>>>
>>> in
>>>db.c,db_insert_message_block_physmessage line 856:
>>>
>>> escaped_query = (char *) my_malloc(sizeof(char) * maxesclen);
>>>
>>>I don't see a:
>>>
>>> memset(escaped_query,'\0',sizeof(char) * maxesclen);
>>>
>>>around.
>>
>>I don't think this causes the malfunction. The escaped_query string is
>>printed to by snprintf() which adds a '\0' to the end. This last
>>character is then overwritten by db_escape_query(), adding another '\0',
>>which is again overwritten by the last snprintf(), which adds the last
>>'\0'. So, the string is always terminated. I did add the memset() call
>>though, because that should make it a lot safer to change this function
>>in the future. And besides, it's just good practice to NULL all strings
>>before using them.
>>
>>Ilja
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl

Are we talking about the mime parser bug, or the empty message body bug?

Ilja Booij wrote:
> On Wed, 2004-04-14 at 10:42, Paul J Stevens wrote:
>
>>It is *not* dependant on the raw message. I've tried this with a messages that
>>first went haywire and on reinsertion always came out clean.
>
> So we only need the traces then.
>
>>I don't have any traces at hand. It doesn't happen very often.
>
> that's a pity..
> Does anybody else have something (or is somebody willing to test until
> he gets a trace?)
>
> Ilja
>

On Wed, 2004-04-14 at 10:50, Blake Mitchell wrote:
> Are we talking about the mime parser bug, or the empty message body bug?
I inclined to think that these problems are related, so I'm talking
about both of them :)

Ilja

>
> Ilja Booij wrote:
> > On Wed, 2004-04-14 at 10:42, Paul J Stevens wrote:
> >
> >>It is *not* dependant on the raw message. I've tried this with a messages that
> >>first went haywire and on reinsertion always came out clean.
> >
> > So we only need the traces then.
> >
> >>I don't have any traces at hand. It doesn't happen very often.
> >
> > that's a pity..
> > Does anybody else have something (or is somebody willing to test until
> > he gets a trace?)
> >
> > Ilja
> >
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

On Wed, 2004-04-14 at 10:48, Paul J Stevens wrote:
> Here is a bunch of attachments.
>
> 1) original message
> 2) messages as contained in the database, with the binary chars
> 3) imap trace of retreival.
>
Thanks,

just to be clear (this was already answered a while ago, I just want to
make sure): Is the message in the database OK?

Ilja

I've made a small change to dbmsgbuf.c (diff below). I don't think it'll
have any influence on these problems, however. It's another one of those
"initialise the buffer before you start working with it"-fixes.

Ilja


ilja@test01:~/sandbox/dbmail$ cvs diff -r 1.7 dbmsgbuf.c
Index: dbmsgbuf.c
===================================================================
RCS file: /cvsroot-dbmail/dbmail/dbmsgbuf.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -r1.7 -r1.8
2c2
< $Id: dbmsgbuf.c,v 1.7 2004/03/19 16:27:38 ilja Exp $
---
> $Id: dbmsgbuf.c,v 1.8 2004/04/14 09:04:55 ilja Exp $
68a69
> memset(msgbuf_buf, '\0', MSGBUF_WINDOWSIZE);

No. The attachment messageblks.blob is a dump of the message as in the database.
The messageblks.orig is the original message (as dumped from my Sent box).

The message is in the database, but with additional chars. They are at the end
of the first messageblk. Hexdump shows they are NULLs.



Ilja Booij wrote:
> On Wed, 2004-04-14 at 10:48, Paul J Stevens wrote:
>
>>Here is a bunch of attachments.
>>
>>1) original message
>>2) messages as contained in the database, with the binary chars
>>3) imap trace of retreival.
>>
>
> Thanks,
>
> just to be clear (this was already answered a while ago, I just want to
> make sure): Is the message in the database OK?
>
> Ilja
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl

Perhaps db_init_fetch could strip trailing NULLs from resulting rows to allow
current users of 2.0 to retreive messages that were inserted with the parser bug
still in place.

Not a fix, of course. Just a (temporary, partial) workaround.


Ilja Booij wrote:
> I've made a small change to dbmsgbuf.c (diff below). I don't think it'll
> have any influence on these problems, however. It's another one of those
> "initialise the buffer before you start working with it"-fixes.
>
> Ilja
>
>
> ilja@test01:~/sandbox/dbmail$ cvs diff -r 1.7 dbmsgbuf.c
> Index: dbmsgbuf.c
> ===================================================================
> RCS file: /cvsroot-dbmail/dbmail/dbmsgbuf.c,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -r1.7 -r1.8
> 2c2
> < $Id: dbmsgbuf.c,v 1.7 2004/03/19 16:27:38 ilja Exp $
> ---
>
>> $Id: dbmsgbuf.c,v 1.8 2004/04/14 09:04:55 ilja Exp $
>
> 68a69
>
>> memset(msgbuf_buf, '\0', MSGBUF_WINDOWSIZE);
>
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl

On Wed, 2004-04-14 at 11:36, Paul J Stevens wrote:
> Perhaps db_init_fetch could strip trailing NULLs from resulting rows to allow
> current users of 2.0 to retreive messages that were inserted with the parser bug
> still in place.
I'd think that the NULLs would get stripped from the message because the
string copy functions, which should stop after encountering a NULL,
shouldn't they?

Ilja

Nope.

info strncpy sez:

This function is similar to `strcpy' but always copies exactly
SIZE characters into TO.



If the length of FROM is more than SIZE, then `strncpy' copies
just the first SIZE characters. Note that in this case there is
no null terminator written into TO.



If the length of FROM is less than SIZE, then `strncpy' copies all
of FROM, followed by enough null characters to add up to SIZE
characters in all. This behavior is rarely useful, but it is
specified by the ISO C standard.

So, if the row contains nulls, or db_get_length return value bigger than the
actual string length, msgbuf_buf is filled with nulls, correct?


Ilja Booij wrote:
> On Wed, 2004-04-14 at 11:36, Paul J Stevens wrote:
>
>>Perhaps db_init_fetch could strip trailing NULLs from resulting rows to allow
>>current users of 2.0 to retreive messages that were inserted with the parser bug
>>still in place.
>
> I'd think that the NULLs would get stripped from the message because the
> string copy functions, which should stop after encountering a NULL,
> shouldn't they?
>
> Ilja
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl

On Wed, 2004-04-14 at 14:13, Paul J Stevens wrote:
<snip info page>
>
> So, if the row contains nulls, or db_get_length return value bigger than the
> actual string length, msgbuf_buf is filled with nulls, correct?
I guess you're right :)
So, we should take the length of the string with strlen(), which would
result in the length up to the first NUL character, and use only that
part, and not send the NUL characters themselves.

This seems like logical behaviour, even though at first it's only a
workaround for our current problem.

Ilja

Hello,

I've not been following this thread terribly closely, but does dbmail
allow messages with null's to be inserted properly? rfc 2822 allows
nulls within the message body, so if there were some in the original
message, and dbmail-{s,l}mtp allowed those to be inserted properly,
the behavior described below would cause incomplete messages to be
returned. I think the Right Thing(tm) is to allow nulls to be contained
in the message and returned just as the original message was - but I
know that gets ugly in C. Definitely put it on the future todo list
if nothing else...


---- Original Message ----
From: Ilja Booij <dbmail-dev@dbmail.org>
To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
Subject: Re: [Dbmail-dev] parser bug
Sent: Wed, 14 Apr 2004 14:39:36 +0200

> On Wed, 2004-04-14 at 14:13, Paul J Stevens wrote:
> <snip info page>
> >
> > So, if the row contains nulls, or db_get_length return value bigger than the
> > actual string length, msgbuf_buf is filled with nulls, correct?
> I guess you're right :)
> So, we should take the length of the string with strlen(), which would
> result in the length up to the first NUL character, and use only that
> part, and not send the NUL characters themselves.
>
> This seems like logical behaviour, even though at first it's only a
> workaround for our current problem.
>
> Ilja
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
-- End Original Message --


--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--

I'v put this on the TODO list.

Anyway, we should really squash this last bug and move on to 2.0!
Problem is that I'll be really hard pressed for time the coming weeks so
it will really be helpful if everybody joins in to fix these strange
characters appearing in emails and the empty mail bodies.

Ilja

On Wed, 2004-04-14 at 16:41, Jesse Norell wrote:
> Hello,
>
> I've not been following this thread terribly closely, but does dbmail
> allow messages with null's to be inserted properly? rfc 2822 allows
> nulls within the message body, so if there were some in the original
> message, and dbmail-{s,l}mtp allowed those to be inserted properly,
> the behavior described below would cause incomplete messages to be
> returned. I think the Right Thing(tm) is to allow nulls to be contained
> in the message and returned just as the original message was - but I
> know that gets ugly in C. Definitely put it on the future todo list
> if nothing else...
>
>
> ---- Original Message ----
> From: Ilja Booij <dbmail-dev@dbmail.org>
> To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
> Subject: Re: [Dbmail-dev] parser bug
> Sent: Wed, 14 Apr 2004 14:39:36 +0200
>
> > On Wed, 2004-04-14 at 14:13, Paul J Stevens wrote:
> > <snip info page>
> > >
> > > So, if the row contains nulls, or db_get_length return value bigger than the
> > > actual string length, msgbuf_buf is filled with nulls, correct?
> > I guess you're right :)
> > So, we should take the length of the string with strlen(), which would
> > result in the length up to the first NUL character, and use only that
> > part, and not send the NUL characters themselves.
> >
> > This seems like logical behaviour, even though at first it's only a
> > workaround for our current problem.
> >
> > Ilja
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
> -- End Original Message --
>
>
> --
> Jesse Norell
>
> administrator@kci.net is not my email address;
> change "administrator" to my first name.
> --
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

I've implemented a partial/temp fix for this problem I stipulated
earlier. In dbmsgbuf.c/db_init_msgfetch the first two messageblks are
fetched and stored in a char pointer (msgbuf_buf).

Messages are still getting inserted with erroneous null's but at least
now users can still retrieve those messages. Since this problem appears
to manifest itself in the first messageblk, and my fix only strips off
nulls at the end of the first two blocks, I don't think Jesse's remarks
have much direct bearing on the issue, other than indicate the real
problem we have to fix.

Anyway, dispite a garbage-in situation still exists, we no longer have
to suffer from garbage out now :-)


Ilja Booij wrote:
> I'v put this on the TODO list.
>
> Anyway, we should really squash this last bug and move on to 2.0!
> Problem is that I'll be really hard pressed for time the coming weeks so
> it will really be helpful if everybody joins in to fix these strange
> characters appearing in emails and the empty mail bodies.
>
> Ilja
>
> On Wed, 2004-04-14 at 16:41, Jesse Norell wrote:
>
>>Hello,
>>
>> I've not been following this thread terribly closely, but does dbmail
>>allow messages with null's to be inserted properly? rfc 2822 allows
>>nulls within the message body, so if there were some in the original
>>message, and dbmail-{s,l}mtp allowed those to be inserted properly,
>>the behavior described below would cause incomplete messages to be
>>returned. I think the Right Thing(tm) is to allow nulls to be contained
>>in the message and returned just as the original message was - but I
>>know that gets ugly in C. Definitely put it on the future todo list
>>if nothing else...
>>
>>
>>---- Original Message ----
>>From: Ilja Booij <dbmail-dev@dbmail.org>
>>To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
>>Subject: Re: [Dbmail-dev] parser bug
>>Sent: Wed, 14 Apr 2004 14:39:36 +0200
>>
>>
>>>On Wed, 2004-04-14 at 14:13, Paul J Stevens wrote:
>>><snip info page>
>>>
>>>>So, if the row contains nulls, or db_get_length return value bigger than the
>>>>actual string length, msgbuf_buf is filled with nulls, correct?
>>>
>>>I guess you're right :)
>>>So, we should take the length of the string with strlen(), which would
>>>result in the length up to the first NUL character, and use only that
>>>part, and not send the NUL characters themselves.
>>>
>>>This seems like logical behaviour, even though at first it's only a
>>>workaround for our current problem.
>>>
>>>Ilja
>>>
>>>
>>>_______________________________________________
>>>Dbmail-dev mailing list
>>>Dbmail-dev@dbmail.org
>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>
>>
>>-- End Original Message --
>>
>>
>>--
>>Jesse Norell
>>
>>administrator@kci.net is not my email address;
>>change "administrator" to my first name.
>>--
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

Just a quick look into main.c, assuming it to be the most like suspect
wrt the parser bug.

Shouldn't we use getline instead of fgets? I've done a patch and it
looks ok in my tests.

Ilja Booij wrote:
> I'v put this on the TODO list.
>
> Anyway, we should really squash this last bug and move on to 2.0!
> Problem is that I'll be really hard pressed for time the coming weeks so
> it will really be helpful if everybody joins in to fix these strange
> characters appearing in emails and the empty mail bodies.
>
> Ilja
>
> On Wed, 2004-04-14 at 16:41, Jesse Norell wrote:
>
>>Hello,
>>
>> I've not been following this thread terribly closely, but does dbmail
>>allow messages with null's to be inserted properly? rfc 2822 allows
>>nulls within the message body, so if there were some in the original
>>message, and dbmail-{s,l}mtp allowed those to be inserted properly,
>>the behavior described below would cause incomplete messages to be
>>returned. I think the Right Thing(tm) is to allow nulls to be contained
>>in the message and returned just as the original message was - but I
>>know that gets ugly in C. Definitely put it on the future todo list
>>if nothing else...
>>
>>
>>---- Original Message ----
>>From: Ilja Booij <dbmail-dev@dbmail.org>
>>To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
>>Subject: Re: [Dbmail-dev] parser bug
>>Sent: Wed, 14 Apr 2004 14:39:36 +0200
>>
>>
>>>On Wed, 2004-04-14 at 14:13, Paul J Stevens wrote:
>>><snip info page>
>>>
>>>>So, if the row contains nulls, or db_get_length return value bigger than the
>>>>actual string length, msgbuf_buf is filled with nulls, correct?
>>>
>>>I guess you're right :)
>>>So, we should take the length of the string with strlen(), which would
>>>result in the length up to the first NUL character, and use only that
>>>part, and not send the NUL characters themselves.
>>>
>>>This seems like logical behaviour, even though at first it's only a
>>>workaround for our current problem.
>>>
>>>Ilja
>>>
>>>
>>>_______________________________________________
>>>Dbmail-dev mailing list
>>>Dbmail-dev@dbmail.org
>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>
>>
>>-- End Original Message --
>>
>>
>>--
>>Jesse Norell
>>
>>administrator@kci.net is not my email address;
>>change "administrator" to my first name.
>>--
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

On Thu, 2004-04-22 at 15:57, Paul J Stevens wrote:
> Just a quick look into main.c, assuming it to be the most like suspect
> wrt the parser bug.
>
> Shouldn't we use getline instead of fgets? I've done a patch and it
> looks ok in my tests.
>
I didn't know there was a getline() function, but it seems to be a GNU
extension. Debian doesn't even have a manpage for it (well, my install
doesn't have it). My Fedora box does.

Looks like a very useful thing, but I wonder if the function is also
available on FreeBSD. If it's not, I think it's a no-go. If it is, it
might be useful.

Ilja

One solution just for freebsd might be:

http://anjuta.sourceforge.net/cvs/HEAD/anjuta/src/getline.c

But probably far superior given our long term goals:

http://developer.gnome.org/doc/API/2.0/glib/glib-IO-Channels.html#g-io-channel-read-line-string




Ilja Booij wrote:
> On Thu, 2004-04-22 at 15:57, Paul J Stevens wrote:
>
>>Just a quick look into main.c, assuming it to be the most like suspect
>>wrt the parser bug.
>>
>>Shouldn't we use getline instead of fgets? I've done a patch and it
>>looks ok in my tests.
>>
>
> I didn't know there was a getline() function, but it seems to be a GNU
> extension. Debian doesn't even have a manpage for it (well, my install
> doesn't have it). My Fedora box does.
>
> Looks like a very useful thing, but I wonder if the function is also
> available on FreeBSD. If it's not, I think it's a no-go. If it is, it
> might be useful.
>
> Ilja
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

Hi Ilja,

> I didn't know there was a getline() function, but it seems to be a GNU
> extension. Debian doesn't even have a manpage for it

Debian Sarge has a manpage saying:

CONFORMING TO
Both getline() and getdelim() are GNU extensions. They are
available since libc 4.6.27.


Thomas
--
http://www.tmueller.com for pgp key (95702B3B)

I think that fread() is what we want, although it is a slight bit more
cumbersome in the arguments department.

Aaron


Ilja Booij <ilja@ic-s.nl> said:

>
> On Thu, 2004-04-22 at 15:57, Paul J Stevens wrote:
> > Just a quick look into main.c, assuming it to be the most like suspect
> > wrt the parser bug.
> >
> > Shouldn't we use getline instead of fgets? I've done a patch and it
> > looks ok in my tests.
> >
> I didn't know there was a getline() function, but it seems to be a GNU
> extension. Debian doesn't even have a manpage for it (well, my install
> doesn't have it). My Fedora box does.
>
> Looks like a very useful thing, but I wonder if the function is also
> available on FreeBSD. If it's not, I think it's a no-go. If it is, it
> might be useful.
>
> Ilja
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--