[PATCH] do not decode supersedes header

Hello,

tin displays a decoded version of the Supersedes:-header of this
article (Supersedes in news_headers_to_display or after
PageToggleAllHeaders '*'):

| From: Guido Hennecke <nospam-2012-remove-this <at> usenet.debian.dyndns.org>
| Newsgroups: de.sci.physik,de.comm.software.newsreader
| Date: Fri, 26 Apr 2013 23:36:05 +0200
| Subject: Re: Das Garagen-Paradox der ART
| Supersedes: =?UTF-8?Q?=3Cslrnknlsl6=2Epb4=2Enospam=2D2012=2Dremove=2Dthi?=
|  =?UTF-8?Q?s=40msgid=2Eusenet=2Edebian=2Edyndns=2Eorg=3E?=
| Message-ID: <slrnknlsq5.pb4.nospam-2012-remove-this <at> msgid.usenet.debian.dyndns.o
rg>

This header is broken (encoded, folded), but displaying a decoded
version seems not the best choice to me. With the attached patch tin no
longer decodes the Supersede:-headers before displaying.

Dennis

diff -urp tin-2.1.2_r4/src/cook.c tin-2.1.2_r5/src/cook.c
--- tin-2.1.2_r4/src/cook.c	2012-12-24 11:22:00.000000000 +0100
+++ tin-2.1.2_r5/src/cook.c	2013-04-29 17:50:02.000000000 +0200
 <at>  <at>  -872,7 +872,7  <at>  <at>  cook_article(
 			} while (!found && *(++strptr) != 0);

 			/* unstructured but must not be decoded */
-			if (l == NULL && (!strncasecmp(line, "References: ", 12) || !strncasecmp(line, "Message-ID: ", 12)

Re: tin problem: Error: From: line missing.

On Fri, Jan 04, 2013 at 06:37:53PM +0700, Victor Sudakov wrote:
> > > It may be a FreeBSD-specific bug
> > as it seems to be locale related it might be a somewhat broken isacii() or
> > the like.
> It also seems to work with LANG=ru_RU.UTF-8. Only KOI8-R is somehow
> problematic.

Looks like I traced it down:

if the locale charset is the same as the network charset (in your case both
were KOI8-R) tin tries to convert the string in the local charset to the
network charset (waste of cpu cycles, but sould work!). But FreeBSDs
iconv(3) seems to have a problem with that, the mapage states:

[...]
| After calling iconv(), the values pointed to by src,
| srcleft, dst, and dstleft are updated as follows:
[...]
|     *dst      Pointer to the byte just after the last character stored.
[...]

but this is not the case, right befor the conversion
(misc.c:buffer_to_network()):

(gdb) print inbuf
$2 = 0x80163d200 "From: Urs Janssen <urs <at> tin.org>"
(gdb) print &outbuf
$3 = (char **) 0x7fffffffa5e0
(gdb) print outbuf
$4 = 0x80144d6c0 "G"

Re: [tin 2.1.1] snaphsots

On Tue, Feb 21, 2012 at 11:10:55AM +0100, Urs Jan??en wrote:
> I've made snapshots of the upcomming tin 2.1.1 (unstable) release
> including the --enbale-heapsort configure option. If specified a new
> 'M'enu option is available to specify the sorting function used. Tit
> defaults to qsort(3) and can be changed to heapsort(3) which may
> speed up sorting when the data is somewhat presorted (usualy the case
> in large groups with long threads).
> 
> <ftp://ftp.tin.org/pub/news/clients/tin/unstable/snapshots/≥
> 
>  <at> Thomas: vsnprintf is doubled in configure.in:AC_CHECK_FUNCS() and on

agreed (cut/paste error).  It can be removed.

> debian based linux systems a useable heapsort is available in libbsd
> (-lbsd /  <bsd/stdlib.h>) - I don't know if it's worth checking for

on Linux?  I'm using that port with Lynx, but haven't really decided
if it's a good thing to use since its headers seem to change without
much reasoning involved.  (It can be troublesome to support in different
versions).  Something to think about.

--

-- 
Thomas E. Dickey <dickey <at> invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

Re: [tin 2.1.1] snaphsots

On Tue, Feb 21, 2012 at 11:10:55AM +0100, Urs Janßen wrote:
> I've made snapshots of the upcomming tin 2.1.1 (unstable) release
> including the --enbale-heapsort configure option. If specified a new
> 'M'enu option is available to specify the sorting function used.

I think this is not group specific. We can undo the changes which would
be necessary only for group specific attributes (read_attributes_file(),
attribute state).

Dennis

diff -urp tin-2.1.1/include/tin.h tin-2.1.1_r1/include/tin.h
--- tin-2.1.1/include/tin.h	2012-02-21 16:58:50.000000000 +0100
+++ tin-2.1.1_r1/include/tin.h	2012-02-21 17:20:37.000000000 +0100
 <at>  <at>  -1672,9 +1672,6  <at>  <at>  struct t_attribute_state {
 	unsigned signature_repost:1;
 	unsigned sort_article_type:1;
 	unsigned sort_threads_type:1;
-#ifdef USE_HEAPSORT
-	unsigned sort_function:1;
-#endif
 	unsigned start_editor_offset:1;
 	unsigned tex2iso_conv:1;
 	unsigned thread_articles:1;
diff -urp tin-2.1.1/src/attrib.c tin-2.1.1_r1/src/attrib.c
--- tin-2.1.1/src/attrib.c	2012-02-21 09:42:39.000000000 +0100
+++ tin-2.1.1_r1/src/attrib.c	2012-02-21 17:16:54.000000000 +0100
 <at>  <at>  -224,9 +224,6  <at>  <at>  set_default_state(
 	state->signature_repost = FALSE;
 	state->sort_article_type = FALSE;

Re: qsort can get very slow

On Sat, Feb 18, 2012 at 07:54:45AM +0400, Valeriy E. Ushakov wrote:
> For me ("gmane" is from newsrctable):
> 
>   $ time tin -g gmane gmane.comp.lang.lua.general 
> 
> gives
> 
>   real    1m1.770s
>   user    0m15.600s
>   sys     0m2.261s
> 
> vs.
> 
>   real    2m32.274s
>   user    1m58.352s
>   sys     0m2.303s
> 
> 
> Where the time in the original version with qsort is spent between
> 
>   Group gmane.comp.lang.lua.general ('q' to quit)...  99% (0:00 remaining)
> 
> and 
> 
>   Threading articles ...
> 
> The machine is B&W G3 running NetBSD/macppc
> 
> cpu0 at mainbus0: 750 (Revision 2.2), ID 0 (primary)
> cpu0: HID0 8090c0a4<EMCP,DOZE,DPM,ICE,DCE,SGE,BTIC,BHT>, powersave: 1

[ANNOUNCE] tin 2.1.0 released

tin 2.1.0 includes the bugfixes from 2.0.1 plus the 64 bit stuff

<ftp://ftp.tin.org/pub/news/clients/tin/v2.1/CHANGES>

<ftp://ftp.tin.org/pub/news/clients/tin/v2.1/tin-2.1.0.tar.gz>
<ftp://ftp.tin.org/pub/news/clients/tin/v2.1/tin-2.1.0.tar.bz2>
<ftp://ftp.tin.org/pub/news/clients/tin/v2.1/tin-2.1.0.tar.lzma>

[ANNOUNCE] tin 2.0.1 released

tin 2.0.1 is a bugfix release fixing some minor issues

<ftp://ftp.tin.org/pub/news/clients/tin/v2.0/CHANGES>

<ftp://ftp.tin.org/pub/news/clients/tin/v2.0/tin-2.0.1.tar.gz>
<ftp://ftp.tin.org/pub/news/clients/tin/v2.0/tin-2.0.1.tar.bz2>
<ftp://ftp.tin.org/pub/news/clients/tin/v2.0/tin-2.0.1.tar.lzma>

Detached signatures are in the related *.sign files in the same
directory.

urs

superseded articles and posted_articles_file

Is it intended that superseded articles are not stored in
posted_articles_file? If not, I've attached a patch for that.

(POST_SUPERSEDE can not be used because of conflicts with "enum
defined_functions" in keymap.h.)

Dennis

diff -urp tin-2.1.0/src/post.c tin-2.1.0_r1/src/post.c
--- tin-2.1.0/src/post.c	2011-11-11 22:31:20.000000000 +0100
+++ tin-2.1.0_r1/src/post.c	2011-12-23 14:49:07.000000000 +0100
 <at>  <at>  -107,6 +107,7  <at>  <at> 
 #define POST_NORMAL		2
 #define POST_RESPONSE	3
 #define POST_REPOST		4
+#define POST_SUPERSEDED	5

 /* When prompting for subject, display no more than 20 characters */
 #define DISPLAY_SUBJECT_LEN 20
 <at>  <at>  -1821,7 +1822,7  <at>  <at>  post_article_loop:
 				break;
 		}
 		signal_context = cPost;
-		if (type != POST_REPOST) {
+		if (type != POST_REPOST && type != POST_SUPERSEDED) {
 			char keyedit[MAXKEYLEN], keypost[MAXKEYLEN];
 			char keypostpone[MAXKEYLEN], keyquit[MAXKEYLEN];
 			char keymenu[MAXKEYLEN];
 <at>  <at>  -1984,6 +1985,7  <at>  <at>  post_article_done:
 					break;

[tin 2.1.0] snaphsots

I've made snapshots of the upcomming tin 2.1.0 (unstable) release
fixing the crash with ncurses6

<ftp://ftp.tin.org/pub/news/clients/tin/unstable/snapshots/≥

[tin 2.1.0] snaphsots

I've made snapshots of the upcomming tin 2.1.0 (unstable) release.
New stuff:

- support for huge article numbers (2^63-1) if configured with
  --enable-long-article-numbers and system has int_least64_t or
  long long or quad_t. It's not enabled by default as article numbers
  higher than 2^63-1 do violate the current NNTP RFC.

- with getart_limit set use LISTGROUP range instead of plain
  LISTGROUP, if LISTGROUP range is not supported use only GROUP
  (reduces traffic)

- with getart_limit set don't malloc base[]/arts[] for articles
  below first_unread and outside the range. (reduces memory usage).

Even with --enable-long-article-numbers tin still can't handle more
than INT_MAX articles per group (i.e. 2^31-1). But as such groups
would require several GB of RAM just for the meta-data this isn't a
real problem (there is at least one provider with such a group:
alt.binaries.boneless 5896156915 1527513710 y) and starting
with this snapshot the group can be read with -G limit.

<ftp://ftp.tin.org/pub/news/clients/tin/unstable/snapshots/≥

urs
--

-- 
Jef Poskanzer:
"When people aren't stupid Usenet is even more useful. Too bad this happens
 so rarely."

[PATCH] atoi() -> atol() in art.c

In art.c we read in article numbers from NNTP-responses via atoi(). I
think this should be atol().

Dennis

diff -urp tin-2.1.0_r4/src/art.c tin-2.1.0_r5/src/art.c
--- tin-2.1.0_r4/src/art.c	2011-09-12 23:23:31.000000000 +0200
+++ tin-2.1.0_r5/src/art.c	2011-11-01 19:42:51.000000000 +0100
 <at>  <at>  -248,7 +248,7  <at>  <at>  setup_hard_base(
 			while ((ptr = tin_fgets(fp, FALSE)) != NULL) {
 				if (grpmenu.max >= max_art)
 					expand_art();
-				base[grpmenu.max++] = atoi(ptr);
+				base[grpmenu.max++] = atol(ptr);
 			}

 			if (tin_errno)
 <at>  <at>  -591,7 +591,7  <at>  <at>  open_art_header(
 		i = new_nntp_command("NEXT", OK_NOTEXT, buf, sizeof(buf));
 		switch (i) {
 			case OK_NOTEXT:
-				*next = atoi(buf);		/* Set next art number */
+				*next = atol(buf);		/* Set next art number */
 				break;

 #	ifndef BROKEN_LISTGROUP
 <at>  <at>  -608,7 +608,7  <at>  <at>  open_art_header(
 				if ((fp = nntp_command(buf, OK_HEAD, NULL, 0)) != NULL)
 					return fp;
 				if (nntp_command("NEXT", OK_NOTEXT, buf, sizeof(buf)))