headers
Florian Schlichting | 1 Jul 2010 19:20
Picon
Picon

Re: [PATCH] make tags / make ctags broken

On Wed, Jun 30, 2010 at 10:17:43AM -0700, Russ Allbery wrote:
> I suspect you're the first person to run that command in a while, so if
> there's now a better way that doesn't require Makefile infrastructure, I
> vote for just removing it.

this is my suggestion on how to do this. Note that my patch also removes
the etags target (only in the toplevel makefile), which is probably
still functional and thus not really necessary...

Florian

---
remove broken tags / ctags make targets

These targets have been broken for some time and wouldn't work with GNU
ctags anyway. Just do 'ctags -R' in the toplevel source directory and
put 'set tags=./tags,tags,/path/to/source/tags' in your .vimrc if you
want to use tags.
---
 Makefile            |    9 +++------
 Makefile.global.in  |    1 -
 authprogs/Makefile  |    3 ---
 backends/Makefile   |    8 +-------
 doc/Makefile        |    1 -
 doc/man/Makefile    |    1 -
 doc/pod/hacking.pod |    9 ++++-----
 expire/Makefile     |    8 +-------
 frontends/Makefile  |    8 +-------
 history/Makefile    |    3 ---
 include/Makefile    |    2 +-
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russ Allbery | 3 Jul 2010 19:17
Picon
Favicon
Gravatar

Re: [PATCH] make tags / make ctags broken

Florian Schlichting <fschlich <at> CIS.FU-Berlin.DE> writes:

> this is my suggestion on how to do this. Note that my patch also removes
> the etags target (only in the toplevel makefile), which is probably
> still functional and thus not really necessary...

Looks good to me.  Thanks, applied.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
John F. Morse | 5 Jul 2010 06:04

Test message for RRA

Russ Allbery wrote:

> "John F. Morse" writes:
>   
>> If you wish, I could send a test message to the inn-workers list. If it
>> fails to propagate, then I guess it won't be bothering all of the list
>> members.
>>     
>
> Please give that a try.  I've double-checked the list configuration and
> confirmed that you're subscribed with that address, so I don't see any
> obvious reason why posts from that address wouldn't make it through the
> list (assuming that's exactly the address that you're using).  I've also
> turned off the "nodupes" option for your address so that Mailman won't try
> to suppress supposedly duplicate copies of messages that were cc'd
> directly to you, in case that's causing some sort of strange problem.
Here you are, Russ.

Thanks for looking into this for me.

--

-- 
John
Permalink | Reply | 1 comment |
headers
Russ Allbery | 5 Jul 2010 06:24
Picon
Favicon
Gravatar

Re: Test message for RRA

"John F. Morse" <inn <at> xanadu-bbs.net> writes:
> Russ Allbery wrote:
>> "John F. Morse" writes:

>>> If you wish, I could send a test message to the inn-workers list. If it
>>> fails to propagate, then I guess it won't be bothering all of the list
>>> members.

>> Please give that a try.  I've double-checked the list configuration and
>> confirmed that you're subscribed with that address, so I don't see any
>> obvious reason why posts from that address wouldn't make it through the
>> list (assuming that's exactly the address that you're using).  I've also
>> turned off the "nodupes" option for your address so that Mailman won't try
>> to suppress supposedly duplicate copies of messages that were cc'd
>> directly to you, in case that's causing some sort of strange problem.

> Here you are, Russ.

> Thanks for looking into this for me.

That seems to have worked -- at least, I got it.  :)

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 17 Jul 2010 09:58
Favicon

Re: eliminating MAXHEADERSIZE

Hi Florian,

I sometimes have security warnings with your signed mails.
Windows Mail complains that the expeditor is not the right one:
mismatch between "zedat.fu-berlin.de" and "CIS.FU-Berlin.DE".

> yes, and I think it's a good idea to call it something other than
> MAXHEADERSIZE - how about MAXARTLINELENGTH, or is there a reason why
> we'd speak of a line size rather than a line length?

MAXARTLINELENGTH is fine.  Adopted.

> Please be careful when carrying out the substitutions, though, I'm not
> really familiar with all the occurrences and I think I was wrong when I
> said above that innd/art.c:848 is the only place where it really means line
> length; I think innd/art.c:1438 should also become MAXARTLINELENGTH and
> not MED_BUFFER.

You're totally right.  We're checking the Xref: header field length
at line 1438.

Incidentally, isn't there two bugs in this function?

* When resizing the buffer, extra place for a CRLF that may be added
  by a continuation line is not taken into account.  Consequently,
  when p[0] = '\r' and p[1] = '\n' are used, a segfault may occur!

* When comparing to MAXARTLINELENGTH, the final CRLF is not taken into
  account ("+2" is missing in the count), so the generated Xref: header
  field might end up with 1002 bytes!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Julien ÉLIE | 17 Jul 2010 10:57
Favicon

Re: count single \r or \n as \r\n while checking line length against MAXHEADERSIZE

Hi Florian,

>> Incidentally, I see that your patch fixes the issue for headers.
>> But we may have the same problem with the body.  What if the lines end
>> with a single '\r' or a single '\n'?  Why shouldn't it be treated the same
>> way as in headers?
>
> I hadn't thought of it, but AFAIKS we just count LFwithoutCR and
> LFwithoutCR (hey, shouldn't the second one be CRwithoutLF? that's all
> the way down in ARTparsebody)

Yes, that's an error.  I'll fix it.

> for the body and don't error out in any
> case - it seems we don't even look at the resulting line length. So no
> need to change anything for the body, I believe.

Yet, RFC 5536 :
  body = <see RFC 5322 Section 3.5>

I do not see notes about length of body lines in RFC 5536 and RFC 5537.
So RFC 5322 fully applies.

RFC 5322 :

3.5. Overall Message Syntax

   A message consists of header fields, optionally followed by a message
   body.  Lines in a message MUST be a maximum of 998 characters
   excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
(Continue reading)

Permalink | Reply | 13 comments |
headers
Julien ÉLIE | 30 Jul 2010 15:46
Favicon

Re: Filters and multiple occurrences of headers

Hi all,

> Note:  I will soon have a look at how our overview deals with
> duplicated headers in INN.  With INN 2.5.2, it returns an empty
> header when it appears more than once!  Both for OVER and HDR
> using overview.
> HDR works only when directly searching inside an article,
> and not the overview data.

Fixed in INN 2.5.3.  The content of the first occurrence is now
returned, in accordance with RFC 3977.
We previously had an empty field (header length was set to -1).

Duplicated headers for mandatory headers like Date: and Subject:
are still properly handled, and the article rejected.

--

-- 
Julien ÉLIE

« Il faut mettre un frein à l'immobilisme. »
Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 30 Jul 2010 15:56
Favicon

Re: Filters and multiple occurrences of headers

Hi again,

> A few Netnews header fields can occur more than once in headers.
>
> HDR is supposed to return the first occurrence.
> (Probably the same for OVER.)
>
> Yet, our filters keep the last occurrence of them.
>
>  http://www.eyrie.org/~eagle/software/inn/docs/hook-perl.html
>
>    "If any of the headers are duplicated, though, %hdr will contain
>    only the value of the last occurrence of the header."
>
> Shouldn't it be better to keep the first occurrence?
> Are there people relying on the behaviour of keeping the last
> occurrence?

I have just tested and our documentation is inaccurate.  %hdr contains
the same value as what is in the overview.
Consequently, when a header was duplicated, filters contained nothing
at all!

Now that our overview data is fixed and contains the first occurrence of
duplicated headers, %hdr is properly set and contains the value of the
first occurrence of the header.
I believe that's the best behaviour to have (homogeneity).

--

-- 
Julien ÉLIE
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julien ÉLIE | 30 Jul 2010 16:23
Favicon

Re: Filters and multiple occurrences of headers

>>    "If any of the headers are duplicated, though, %hdr will contain
>>    only the value of the last occurrence of the header."
>
> I have just tested and our documentation is inaccurate.  %hdr contains
> the same value as what is in the overview.

Hmm...  The documentation was in fact true, but incomplete.
It is what happens with nnrpd (*last* occurrence in the Perl filter,
because of the way the array is parsed).
But with innd, it is the *first* occurence (written in the overview,
for both Perl and Python filters).

--

-- 
Julien ÉLIE

« Il avait juste assez de culture pour faire
  des citations fausses. » (Byron)
Permalink | Reply | 0 comments |

Gmane