aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/007705.html
blob: 88f85ecfdbd0f7664b2552d2ac5092650fd375de (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [fetchmail] Patch for IMAP idling where idling is unsupported
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:fetchmail-friends%40cmb.is-a-geek.org">
   <META NAME="robots" CONTENT="index,nofollow">
   
   <LINK REL="Previous"  HREF="007711.html">
   <LINK REL="Next"  HREF="007713.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[fetchmail] Patch for IMAP idling where idling is unsupported
   </H1>
    <B>Chris Boyle
    </B> 
    <A HREF="mailto:fetchmail-friends%40cmb.is-a-geek.org"
       TITLE="[fetchmail] Patch for IMAP idling where idling is unsupported">fetchmail-friends@cmb.is-a-geek.org
       </A><BR>
    <I>21 Jul 2003 18:20:43 +0100</I>
    <P><UL>
        <LI> Previous message: <A HREF="007711.html">[fetchmail] Problem - truncated messages
</A></li>
        <LI> Next message: <A HREF="007713.html">[fetchmail] Patch for IMAP idling where idling is unsupported
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#7705">[ date ]</a>
              <a href="thread.html#7705">[ thread ]</a>
              <a href="subject.html#7705">[ subject ]</a>
              <a href="author.html#7705">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Here's a patch I've written: where IDLE is unavailable, it uses periodic
NOOP commands instead (every 28 seconds). Important behavioural change:
the option &quot;idle&quot; will now always result in *some* form of idle. I think
I read somewhere that some servers will unilaterally send status updates
if you just hold the connection open, i.e. NOOPs would be unnecessary,
but that doesn't seem to be the case anywhere I've tried. In any case,
this patch copes with updates both as a response to the NOOPs and
unilaterally sent between them. It functions exactly like normal idling
(N.B. like normal idling, it is single-folder only), and hopefully
includes all the appropriate changes to the documentation. Enjoy. :-)

<A HREF="http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz">http://cmb.is-a-geek.org/downloads/fetchmail-6.2.2+noopidle.diff.gz</A>

-- 
Chris Boyle - <A HREF="http://people.debian.org/~cmb/">http://people.debian.org/~cmb/</A>
GPG: B7D86E0F, MSN: <A HREF="mailto:shortcipher@hotmail.com">shortcipher@hotmail.com</A>, ICQ: 24151961,
AIM: kerneloops, Yahoo: kerneloops, IRC: cmb on freenode.net

</PRE>
<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI> Previous message: <A HREF="007711.html">[fetchmail] Problem - truncated messages
</A></li>
	<LI> Next message: <A HREF="007713.html">[fetchmail] Patch for IMAP idling where idling is unsupported
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#7705">[ date ]</a>
              <a href="thread.html#7705">[ thread ]</a>
              <a href="subject.html#7705">[ subject ]</a>
              <a href="author.html#7705">[ author ]</a>
         </LI>
       </UL>
</body></html>
n strlcpy that means the length of .Fa src . For .Fn strlcat that means the initial length of .Fa dst plus the length of .Fa src . While this may seem somewhat confusing it was done to make truncation detection simple. .Pp Note however, that if .Fn strlcat traverses .Fa size characters without finding a NUL, the length of the string is considered to be .Fa size and the destination string will not be NUL-terminated (since there was no space for the NUL). This keeps .Fn strlcat from running off the end of a string. In practice this should not happen (as it means that either .Fa size is incorrect or that .Fa dst is not a proper .Dq C string). The check exists to prevent potential security problems in incorrect code. .Sh EXAMPLES The following code fragment illustrates the simple case: .Bd -literal -offset indent char *s, *p, buf[BUFSIZ]; \&... (void)strlcpy(buf, s, sizeof(buf)); (void)strlcat(buf, p, sizeof(buf)); .Ed .Pp To detect truncation, perhaps while building a pathname, something like the following might be used: .Bd -literal -offset indent char *dir, *file, pname[MAXPATHLEN]; \&... if (strlcpy(pname, dir, sizeof(pname)) \*[Ge] sizeof(pname)) goto toolong; if (strlcat(pname, file, sizeof(pname)) \*[Ge] sizeof(pname)) goto toolong; .Ed .Pp Since we know how many characters we copied the first time, we can speed things up a bit by using a copy instead of an append: .Bd -literal -offset indent char *dir, *file, pname[MAXPATHLEN]; size_t n; \&... n = strlcpy(pname, dir, sizeof(pname)); if (n \*[Ge] sizeof(pname)) goto toolong; if (strlcpy(pname + n, file, sizeof(pname) - n) \*[Ge] sizeof(pname) - n) goto toolong; .Ed .Pp However, one may question the validity of such optimizations, as they defeat the whole purpose of .Fn strlcpy and .Fn strlcat . .Sh SEE ALSO .Xr snprintf 3 , .Xr strncat 3 , .Xr strncpy 3 .Sh HISTORY .Fn strlcpy and .Fn strlcat first appeared in .Ox 2.4 , then in .Nx 1.4.3 and .Fx 3.3 .