Menu
▾
▴
pidgin-patches — Updates to the Gaim patches tracker
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(435) |
Dec
(252) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(177) |
Feb
(157) |
Mar
(187) |
Apr
(168) |
May
(127) |
Jun
(291) |
Jul
(38) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-03-21 03:38:03
|
Patches item #1153243, was opened at 2005-02-28 00:55 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1153243&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Richard Laager (rlaager) >Assigned to: Mark Doliner (thekingant) Summary: Implement IRC Response #437 Initial Comment: I made a joke in #gaim about joining a channel with a really long name. I then tried (just for the heck of it) joining that channel. As it turns out, the server didn't like that channel name and returned an error. I only know that because I had the debug window open at the time. This patch handles the 437 response code by popping up an error message, which is what I would expect under those circumstances. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-20 22:37 Message: Logged In: YES user_id=20979 I applied this to head (with a few minor changes (the location of the function declaration in irc.h and the message printed)), but I can't test it because I can't sign on to IRC With head. Maybe I'll fix that... Anyhoo, I'm sure you'll let us know if this doesn't quite work right :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1153243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 02:25:58
|
Patches item #1167243, was opened at 2005-03-20 21:19 Message generated for change (Comment added) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167243&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: Log Viewer Double-Click Initial Comment: (20:07:30) LSchiere: rlaager: I think you fixed 1166616 for cvs head, was it fixed for oldstatus also? can it be? (20:09:08) rlaager: LSchiere: it wasn't fixed for oldstatus, I included those changes in my big patch that started with the contact log viewing (20:09:19) LSchiere: that's what I suspected Here's the fix. It's untested. It may not even compile. ---------------------------------------------------------------------- >Comment By: Luke Schierer (lschiere) Date: 2005-03-20 21:25 Message: Logged In: YES user_id=28833 you rock. thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 02:19:19
|
Patches item #1167243, was opened at 2005-03-20 20:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167243&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Nobody/Anonymous (nobody) Summary: Log Viewer Double-Click Initial Comment: (20:07:30) LSchiere: rlaager: I think you fixed 1166616 for cvs head, was it fixed for oldstatus also? can it be? (20:09:08) rlaager: LSchiere: it wasn't fixed for oldstatus, I included those changes in my big patch that started with the contact log viewing (20:09:19) LSchiere: that's what I suspected Here's the fix. It's untested. It may not even compile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 19:43:55
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-20 14:43 Message: Logged In: YES user_id=20979 Hmm, I have a feeling you weren't really looking at the current file in CVS (there's a ~5 hour delay between anonymous and developer CVS). I changed it so that rc is always sent (as a 4 byte int), and the size_t 0 is no longer sent before the char array. So the case where rc = 0 should look like this. 1. 4 Byte int, (rc) 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t (zero) Or am I still missing something? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-20 14:34 Message: Logged In: YES user_id=801658 Sorry but I just looked through your changes and what you have in CVS still isnt' right either. I'll be very descriptive. The important part of the host_resolved function is from line 325 to line 316. This is the transaction it expects: 1. Read an int (4 bytes) (might be an error code) 2. If int is zero (this is the case we are worried about) and we just read more than zero bytes bytes then start the address loop. 3. Read a size_t, then read size_t bytes, keep doing this until the original size_t is 0. So on a 64bit machine the transaction wants to be this: 1. 4 Byte int 2. 8 Byte size_t, * Byte char array (repeat n times) 3. stop when the size_t = 0. But in the gaim_dns_childthread you chaned zero to a size_t, this isn't entirely correct because if rc != 0 (line 482) then the childthread sends an int error code, if not it sends a zero size_t. This is inconsistent. In the case where rc = 0, the transaction it sends is this: 1. 8 Byte size_t 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t Do you see the inconsistency? As long the host_resolved function is originally reading an int as the value to test for success or not, you can't just send the first zero as a size_t. That's why my patch is the way it is, it only ends with a size_t. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 13:04 Message: Logged In: YES user_id=20979 Ok, no, an int isn't right either. I changed zero back to a size_t. The data sent from the child to the parent looks like this: int rc (regardless of whether rc is zero or non-zero) size_t addrlen char* addr (repeat addrlen and char*) size_t zero ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 19:34:50
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by chrono86 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: rian hunter (chrono86) Date: 2005-03-20 14:34 Message: Logged In: YES user_id=801658 Sorry but I just looked through your changes and what you have in CVS still isnt' right either. I'll be very descriptive. The important part of the host_resolved function is from line 325 to line 316. This is the transaction it expects: 1. Read an int (4 bytes) (might be an error code) 2. If int is zero (this is the case we are worried about) and we just read more than zero bytes bytes then start the address loop. 3. Read a size_t, then read size_t bytes, keep doing this until the original size_t is 0. So on a 64bit machine the transaction wants to be this: 1. 4 Byte int 2. 8 Byte size_t, * Byte char array (repeat n times) 3. stop when the size_t = 0. But in the gaim_dns_childthread you chaned zero to a size_t, this isn't entirely correct because if rc != 0 (line 482) then the childthread sends an int error code, if not it sends a zero size_t. This is inconsistent. In the case where rc = 0, the transaction it sends is this: 1. 8 Byte size_t 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t Do you see the inconsistency? As long the host_resolved function is originally reading an int as the value to test for success or not, you can't just send the first zero as a size_t. That's why my patch is the way it is, it only ends with a size_t. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 13:04 Message: Logged In: YES user_id=20979 Ok, no, an int isn't right either. I changed zero back to a size_t. The data sent from the child to the parent looks like this: int rc (regardless of whether rc is zero or non-zero) size_t addrlen char* addr (repeat addrlen and char*) size_t zero ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 18:04:12
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-20 13:04 Message: Logged In: YES user_id=20979 Ok, no, an int isn't right either. I changed zero back to a size_t. The data sent from the child to the parent looks like this: int rc (regardless of whether rc is zero or non-zero) size_t addrlen char* addr (repeat addrlen and char*) size_t zero ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 17:15:54
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 16:39:19
|
Patches item #1166135, was opened at 2005-03-18 12:05 Message generated for change (Comment added) made by marv_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166135&group_id=235 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Robert Mende (mendepie) Assigned to: Tim Ringenbach (marv_sf) Summary: 1.2.0 Compile bug with gcc 2.95 Initial Comment: src/protocols/yahoo/yahoochat.c has a number of variable declarations interspersed in the function yahoo_process_chat_join. Attached Patch just declares these at the top of the function. ---------------------------------------------------------------------- >Comment By: Tim Ringenbach (marv_sf) Date: 2005-03-20 10:38 Message: Logged In: YES user_id=790708 This is already fixed in CVS oldstatus, probably with the exact same changes. So you're either too late, or Luke assigned to me too late :P In the future, a unified diff is prefered, "cvs diff -dup" is prefered in fact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166135&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 16:21:51
|
Patches item #1166135, was opened at 2005-03-18 13:05 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166135&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Mende (mendepie) Assigned to: Tim Ringenbach (marv_sf) Summary: 1.2.0 Compile bug with gcc 2.95 Initial Comment: src/protocols/yahoo/yahoochat.c has a number of variable declarations interspersed in the function yahoo_process_chat_join. Attached Patch just declares these at the top of the function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166135&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 14:16:57
|
Patches item #1166337, was opened at 2005-03-18 19:49 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166337&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Weyl (cweyl) >Assigned to: Etan Reisner (deryni9) Summary: [perl] add /commnd api support for perl plugins Initial Comment: This patch exposes the /command api to perl plugins. This should apply cleanly against head and oldstatus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166337&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 03:24:51
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by chrono86 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 02:06:39
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 02:02:06
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Settings changed) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) >Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 01:19:38
|
Patches item #1166667, was opened at 2005-03-19 16:58 Message generated for change (Settings changed) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Mark Doliner (thekingant) Summary: Yahoo privacy fixups for 1.2.1cvs Initial Comment: Remove hard coded value of 0 from previous patch (makes this patch dependant on patch 1166665) Better logic in signin routines so that users on the ignore list don't force us into an un-necessary privacy state. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-19 20:19 Message: Logged In: YES user_id=20979 Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 00:45:57
|
Patches item #1166667, was opened at 2005-03-19 16:58 Message generated for change (Settings changed) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) >Assigned to: Mark Doliner (thekingant) Summary: Yahoo privacy fixups for 1.2.1cvs Initial Comment: Remove hard coded value of 0 from previous patch (makes this patch dependant on patch 1166665) Better logic in signin routines so that users on the ignore list don't force us into an un-necessary privacy state. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 00:37:10
|
Patches item #1166665, was opened at 2005-03-19 16:52 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Mark Doliner (thekingant) Summary: Privacy fixups Initial Comment: From discussion with kingant, schedule_blist_save should really be exposed. We can then use this to save privacy state in a nice way. Additionally, GAIM_PRIVACY_NONE = 0 is introduced because, well, sometimes perm_deny seems to = 0. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-19 19:37 Message: Logged In: YES user_id=20979 I didn't accept the change to privacy.h becuase I don't think we should have a GAIM_PRIVACY_NONE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 21:58:31
|
Patches item #1166667, was opened at 2005-03-20 08:58 Message generated for change (Settings changed) made by bleeter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) >Assigned to: Tim Ringenbach (marv_sf) Summary: Yahoo privacy fixups for 1.2.1cvs Initial Comment: Remove hard coded value of 0 from previous patch (makes this patch dependant on patch 1166665) Better logic in signin routines so that users on the ignore list don't force us into an un-necessary privacy state. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 21:58:08
|
Patches item #1166667, was opened at 2005-03-20 08:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Nobody/Anonymous (nobody) Summary: Yahoo privacy fixups for 1.2.1cvs Initial Comment: Remove hard coded value of 0 from previous patch (makes this patch dependant on patch 1166665) Better logic in signin routines so that users on the ignore list don't force us into an un-necessary privacy state. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166667&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 21:53:23
|
Patches item #1166665, was opened at 2005-03-20 08:52 Message generated for change (Settings changed) made by bleeter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) >Assigned to: Mark Doliner (thekingant) Summary: Privacy fixups Initial Comment: From discussion with kingant, schedule_blist_save should really be exposed. We can then use this to save privacy state in a nice way. Additionally, GAIM_PRIVACY_NONE = 0 is introduced because, well, sometimes perm_deny seems to = 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 21:53:00
|
Patches item #1166665, was opened at 2005-03-20 08:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Nobody/Anonymous (nobody) Summary: Privacy fixups Initial Comment: From discussion with kingant, schedule_blist_save should really be exposed. We can then use this to save privacy state in a nice way. Additionally, GAIM_PRIVACY_NONE = 0 is introduced because, well, sometimes perm_deny seems to = 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166665&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 00:49:23
|
Patches item #1166337, was opened at 2005-03-19 00:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166337&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Weyl (cweyl) Assigned to: Nobody/Anonymous (nobody) Summary: [perl] add /commnd api support for perl plugins Initial Comment: This patch exposes the /command api to perl plugins. This should apply cleanly against head and oldstatus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166337&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-18 16:55:02
|
Patches item #1166073, was opened at 2005-03-18 11:38 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Kahn (xkahn) >Assigned to: Sean Egan (seanegan) Summary: Make the autocorrect plugin work Initial Comment: Autocorrect in gaim... um... sucks. The problem is that the correction only happens AFTER you send a message. This means that you don't actually know what message you are sending until it is sent. Horrible. My new patch works AS YOU TYPE with the following rules: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. * Check whole words ONLY. Partial words don't count. * If the dictionary word has capital letters in it, match only words with that capitalization. (FPT -> FTP doesn't match ftp.) * If the dictionary word doesn't have capital letters, preserve the capitalization the user used. (The code assumes three possible capitalization schemes: ALLCAPS, lowercase, and Proper.) Unless the solution has capital letters. In that case, force the capitalization used in the solution. * A word may have quote characters in it and still be a word. * If the user immediately hits the backspace key after a correction, undo the correction. ---------------------------------------------------------------------- Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 11:49 Message: Logged In: YES user_id=7632 Umm... Regarding the first point: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. It is possible for the code to do this, however it purposely does NOT. This is because because pasted text is normally fairly long and may have multiple subtle corrections. This makes it difficult for users to understand what is happening and spot errors. Also, pasted text is often either wrong on purpose (and then he said: "hey d00d!"), or correct already. ---------------------------------------------------------------------- Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 11:41 Message: Logged In: YES user_id=7632 Oh! And we'll need some good text replacements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-18 16:49:29
|
Patches item #1166073, was opened at 2005-03-18 16:38 Message generated for change (Comment added) made by xkahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Kahn (xkahn) >Assigned to: Nobody/Anonymous (nobody) Summary: Make the autocorrect plugin work Initial Comment: Autocorrect in gaim... um... sucks. The problem is that the correction only happens AFTER you send a message. This means that you don't actually know what message you are sending until it is sent. Horrible. My new patch works AS YOU TYPE with the following rules: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. * Check whole words ONLY. Partial words don't count. * If the dictionary word has capital letters in it, match only words with that capitalization. (FPT -> FTP doesn't match ftp.) * If the dictionary word doesn't have capital letters, preserve the capitalization the user used. (The code assumes three possible capitalization schemes: ALLCAPS, lowercase, and Proper.) Unless the solution has capital letters. In that case, force the capitalization used in the solution. * A word may have quote characters in it and still be a word. * If the user immediately hits the backspace key after a correction, undo the correction. ---------------------------------------------------------------------- >Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 16:49 Message: Logged In: YES user_id=7632 Umm... Regarding the first point: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. It is possible for the code to do this, however it purposely does NOT. This is because because pasted text is normally fairly long and may have multiple subtle corrections. This makes it difficult for users to understand what is happening and spot errors. Also, pasted text is often either wrong on purpose (and then he said: "hey d00d!"), or correct already. ---------------------------------------------------------------------- Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 16:41 Message: Logged In: YES user_id=7632 Oh! And we'll need some good text replacements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-18 16:49:26
|
Patches item #1166073, was opened at 2005-03-18 11:38 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Kahn (xkahn) >Assigned to: Sean Egan (seanegan) Summary: Make the autocorrect plugin work Initial Comment: Autocorrect in gaim... um... sucks. The problem is that the correction only happens AFTER you send a message. This means that you don't actually know what message you are sending until it is sent. Horrible. My new patch works AS YOU TYPE with the following rules: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. * Check whole words ONLY. Partial words don't count. * If the dictionary word has capital letters in it, match only words with that capitalization. (FPT -> FTP doesn't match ftp.) * If the dictionary word doesn't have capital letters, preserve the capitalization the user used. (The code assumes three possible capitalization schemes: ALLCAPS, lowercase, and Proper.) Unless the solution has capital letters. In that case, force the capitalization used in the solution. * A word may have quote characters in it and still be a word. * If the user immediately hits the backspace key after a correction, undo the correction. ---------------------------------------------------------------------- Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 11:41 Message: Logged In: YES user_id=7632 Oh! And we'll need some good text replacements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-18 16:41:05
|
Patches item #1166073, was opened at 2005-03-18 16:38 Message generated for change (Comment added) made by xkahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Kahn (xkahn) Assigned to: Nobody/Anonymous (nobody) Summary: Make the autocorrect plugin work Initial Comment: Autocorrect in gaim... um... sucks. The problem is that the correction only happens AFTER you send a message. This means that you don't actually know what message you are sending until it is sent. Horrible. My new patch works AS YOU TYPE with the following rules: * You must be typing, not pasting in text. If you paste in teh and there is a rule to correct teh to the, it won't be corrected. This is because it would be impossible to go back and check all the text. * Check whole words ONLY. Partial words don't count. * If the dictionary word has capital letters in it, match only words with that capitalization. (FPT -> FTP doesn't match ftp.) * If the dictionary word doesn't have capital letters, preserve the capitalization the user used. (The code assumes three possible capitalization schemes: ALLCAPS, lowercase, and Proper.) Unless the solution has capital letters. In that case, force the capitalization used in the solution. * A word may have quote characters in it and still be a word. * If the user immediately hits the backspace key after a correction, undo the correction. ---------------------------------------------------------------------- >Comment By: Benjamin Kahn (xkahn) Date: 2005-03-18 16:41 Message: Logged In: YES user_id=7632 Oh! And we'll need some good text replacements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1166073&group_id=235 |
3 messages has been excluded from this view by a project administrator.
