Menu
▾
▴
icqlib-dev
You can subscribe to this list here.
| 2000 |
Jan
(16) |
Feb
(6) |
Mar
(1) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(4) |
Sep
(2) |
Oct
(5) |
Nov
(2) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(22) |
Feb
(12) |
Mar
(23) |
Apr
(3) |
May
(10) |
Jun
(26) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Erwin K. <erw...@ao...> - 2001-08-14 20:47:38
|
hi, i came across a weird problem. i wrote a mini-client that has a contact-list with uin's but no details for the contacts. so the first thing the client does as soon as you go online (apart from sending the contact list to the server and retrieving the online status of the contacts in the list) is it tries to retrieve the info and the extended info of every contact in the list, using icq_SendInfoReq() and icq_SendExtInfoReq(). of course if there are many contacts, i have to send out quite a few requests at once. i noticed that only the first 5 requests are actually processed (3 "basic" and 2 extended info requests), though i do receive the notification of the requests, the actual data is never sent. now, i have a mechanism that tries to re-request the info after 20 seconds in case the process "failed". and here comes the strange thing... only after i send the next keep-alive message (once every 2 minutes) the next 5 requests (3 basic and 2 extended) are being processed. and now comes the weirdest thing of all: during this period, while the info-requests are "stuck", i can't send messages! or in fact i DO get the notification, seeming that the message was sent, but in fact it never arrived at the recipient... in fact EVERY task (like changing my online status to "away" or something) fails... it's just ignored by the server... it seems that due to the load of info-requests i sent, the server seems to ignore me (though sending notifications) until the next keep-alive. so i fiddled with my method of requesting info-requests. clearly if i remove the whole mechanism of requesting "details", i never experience any problems with sending messages. btw, the client i send to is ICQ2000b. ok, so what i tried first was to send out the requests one by one, waiting for the previous one to complete... but no such luck, it has to do with the keep-alive message. so i added the keep-alive message after one request succeeded successfully. that seemed to help a little... i could now send messages right from the beginning, but still after sending 5 requests i needed to wait a little longer. so the next thing i tried was, send a request, wait for its completion, wait 10 seconds, then send the keep alive and after that request the next one... that again seemed to improve things. but i am not sure what the correct method is. has anyone come across this? could this have something to do with occasional reports of people saying that the messages they sent never arrived at the recipient? maybe they requested details right before that, and now due to "not sticking to the rules" the server refused to send messages? but actually the messages could have been sent "direct" and the server does not even know about them...? hmmm i am confused. just thought i post this here, maybe this is a hint for you icqlib developers, or maybe someone even knows what's going on and how to fix this? cheers anyway erwin kloibhofer austria |
|
From: Bill S. <we...@ri...> - 2001-06-16 03:14:17
|
On Fri, 15 Jun 2001, Erwin Kloibhofer wrote: > hi all! i d/loaded the icq-lib a couple of days ago, and am very greatful to > the developers for investing time and effort into it - great job! > > here's my first question: > i noticed that the icq_SetTimeout callback has been removed. as i understand > it whenever the client receives the "set-timeout message", it is supposed to > call the icq_HandleTimeout function after the specified amount of time. is > this behaviour obsolete now, and managed by the timeout-manager entirely? or > is there any other way how to handle timeouts? No, it hasn't been removed! The 'timeout manager' is just the name for some internal code that manages the timeouts. The icq_SetTimeout callback and icq_HandleTimeout method are still required! Bill |
|
From: Erwin K. <erw...@ao...> - 2001-06-15 10:08:54
|
hi all! i d/loaded the icq-lib a couple of days ago, and am very greatful to the developers for investing time and effort into it - great job! here's my first question: i noticed that the icq_SetTimeout callback has been removed. as i understand it whenever the client receives the "set-timeout message", it is supposed to call the icq_HandleTimeout function after the specified amount of time. is this behaviour obsolete now, and managed by the timeout-manager entirely? or is there any other way how to handle timeouts? thanks |
|
From: Jeff H. <va...@nw...> - 2001-06-13 01:38:20
|
Yeah, I noticed that patch, and it has seemed to fix the problem. On Tuesday 12 June 2001 11:44, you wrote: | Hi. | | There was a bug-fix yesterday which fixes this problem. Did you try it? | | * icqlib/contacts.c: | Applied patch #431950 which fixes bug with invisibility to a random | set of buddies. | | > Just so you know it isn't you. When I use licq (on my PPC box, no choice | > can't get kicq to work) I ocassionally have this problem. It comes and | > goes for no apparent reason. | > | > On Sun, Jun 10, 2001 at 12:00:45PM -0700, Jeff Hughes wrote: | > > I've recently been testing the latest CVS version of icqlib and I've | > > been experiencing a weird problem. When I connect to the icq server I | > > see (with a client with it's own icq implementation) that I go online | > > for a brief second then go to offline. But as far as what icqlib is | > > telling me I'm online and I still get contact notifications and | > > messages from other users and i can send messages, I just appear | > > offline though. I was wondering if anyone has been experiencing this | > > problem or if I should keep looking through my code for a problem. |
|
From: Ben R. <be...@re...> - 2001-06-12 21:59:00
|
On Tue, Jun 12, 2001 at 02:44:13PM -0400, Denis V. Dmitrienko wrote: > Hi. > > There was a bug-fix yesterday which fixes this problem. Did you try it? > > * icqlib/contacts.c: > Applied patch #431950 which fixes bug with invisibility to a random > set of buddies. If you mean me no. Like I said before I'm using licq not kicq because kicq won't run under PPC, my current platform. -- Ben Reser <be...@re...> http://ben.reser.org Wizard's First Rule - People are stupid, they will believe anything if they want it to be true or they fear it is true - Terry Goodkind |
|
From: Denis V. D. <de...@de...> - 2001-06-12 18:39:16
|
Hi. There was a bug-fix yesterday which fixes this problem. Did you try it? * icqlib/contacts.c: Applied patch #431950 which fixes bug with invisibility to a random set of buddies. > Just so you know it isn't you. When I use licq (on my PPC box, no choice can't > get kicq to work) I ocassionally have this problem. It comes and goes for no > apparent reason. > > On Sun, Jun 10, 2001 at 12:00:45PM -0700, Jeff Hughes wrote: > > I've recently been testing the latest CVS version of icqlib and I've been > > experiencing a weird problem. When I connect to the icq server I see (with a > > client with it's own icq implementation) that I go online for a brief second > > then go to offline. But as far as what icqlib is telling me I'm online and I > > still get contact notifications and messages from other users and i can send > > messages, I just appear offline though. I was wondering if anyone has been > > experiencing this problem or if I should keep looking through my code for a > > problem. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Ben R. <be...@re...> - 2001-06-12 08:48:53
|
Just so you know it isn't you. When I use licq (on my PPC box, no choice can't get kicq to work) I ocassionally have this problem. It comes and goes for no apparent reason. On Sun, Jun 10, 2001 at 12:00:45PM -0700, Jeff Hughes wrote: > I've recently been testing the latest CVS version of icqlib and I've been > experiencing a weird problem. When I connect to the icq server I see (with a > client with it's own icq implementation) that I go online for a brief second > then go to offline. But as far as what icqlib is telling me I'm online and I > still get contact notifications and messages from other users and i can send > messages, I just appear offline though. I was wondering if anyone has been > experiencing this problem or if I should keep looking through my code for a > problem. > > As far as how I use icqlib, I create a link with icq_LinkNew, set all the > appropriate call backs, add all my contacts to the internal list. Then when > I want to connect I call icq_Connect, icq_Login then wait for > link->icq_Logged to be called at which I change my status to ONLINE again > just to make sure the server is getting it. > > Jeff Hughes > va...@nw... > > _______________________________________________ > icqlib-dev mailing list > icq...@li... > http://lists.sourceforge.net/lists/listinfo/icqlib-dev > -- Ben Reser <be...@re...> http://ben.reser.org Wizard's First Rule - People are stupid, they will believe anything if they want it to be true or they fear it is true - Terry Goodkind |
|
From: Denis V. D. <de...@de...> - 2001-06-12 00:11:54
|
2001-06-11 Denis V. Dmitrienko <de...@kd...> * icqlib/filesession.c: Applied patch #431942 which fixes Win32-specific typo. * icqlib/tcp.c: Applied patch #431945 which adds icq_TCPSendAwayMessageReq() function. * icqlib/contacts.c: Applied patch #431950 which fixes bug with invisibility to a random set of buddies. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Jeff H. <va...@nw...> - 2001-06-10 18:59:23
|
I've recently been testing the latest CVS version of icqlib and I've been experiencing a weird problem. When I connect to the icq server I see (with a client with it's own icq implementation) that I go online for a brief second then go to offline. But as far as what icqlib is telling me I'm online and I still get contact notifications and messages from other users and i can send messages, I just appear offline though. I was wondering if anyone has been experiencing this problem or if I should keep looking through my code for a problem. As far as how I use icqlib, I create a link with icq_LinkNew, set all the appropriate call backs, add all my contacts to the internal list. Then when I want to connect I call icq_Connect, icq_Login then wait for link->icq_Logged to be called at which I change my status to ONLINE again just to make sure the server is getting it. Jeff Hughes va...@nw... |
|
From: Denis V. D. <de...@de...> - 2001-06-09 00:51:05
|
2001-06-08 Denis V. Dmitrienko <de...@kd...> * admin/acinclude.m4.in, admin/config.guess, admin/config.sub, admin/install-sh, admin/libtool.m4.in, admin/ltcf-c.sh, admin/ltcf-cxx.sh, admin/ltcf-gcj.sh, admin/ltconfig, admin/ltmain.sh, admin/Makefile.am, admin/missing, admin/mkinstalldirs, configure.in: Updated autoconf/automake files from KDE to support autoconf 2.50 * doc/bindings/python/.cvsignore, doc/bindings/python/Makefile.am, doc/bindings/.cvsignore, doc/bindings/Makefile.am, doc/.cvsignore, doc/Makefile.am, bindings/python/.cvsignore, bindings/python/Makefile.am, bindings/cpp/.cvsignore, bindings/cpp/Makefile.am, bindings/.cvsignore, bindings/Makefile.am, admin/.cvsignore, admin/Makefile.am, configure.in, Makefile.am, README, VERSION: Version bumped to 1.2.0 * icqlib/icqpacket.c, icqlib/list.c: Fixed Alpha-specific warnings. * admin/icqlib.m4.in, icqlib.spec.in, icqlib-1.0.0.lsm, DEVEL, AUTHORS: Changed email address. * icqlib/icqlib.c: Added UpdateSuccess & UpdateFailure callacks initialization. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Lars C. <la...@cs...> - 2001-06-08 13:47:34
|
Hi,
Currently only some of the meta information value arrays are exported in
icq.h (Such as countries and genders), but not all.
I would like access to the rest from my icq client program. Just using
icq_Get*(code) (e.g. icq_GetMetaLanguageName) is not good enough because i
need to do both way lookups (code -> language and language -> code).
Should there be two lookup method for each array (Get*Name and Get*Code)?
or should we make a generic GetName(icq_Array* ary, short code) and
GetCode(icq_Array* ary, short code), and then remove the specific calls
such as GetMetaLanguageName()?
I would also like to get access to the entire array for listing them in my
client, which is not possible because i do not know the size. Currently, I
have added a { NULL, -1 } element to then end of each list so that i can
determine the end of the array, and modified the bsearch calls to handle
this.
Furthermore, some are not exported at the moment (icq_MetaOccupation,
icq_MetaPastBackgrounds[], icq_MetaAffiliations[], and
icq_MetaLanguages[])
--
Lars Christensen, la...@cs...
|
|
From: Lars C. <la...@cs...> - 2001-06-08 11:45:36
|
Oops, I forgot this part of the patch which initializes the callback pointers: diff -ru -x CVS /tmp/larsch-mpatch-12888/icqlib/icqlib.c icqlib/icqlib/icqlib.c --- /tmp/larsch-mpatch-12888/icqlib/icqlib.c Fri Jun 8 13:42:38 2001 +++ icqlib/icqlib/icqlib.c Fri Jun 8 13:24:28 2001 @@ -168,6 +168,8 @@ icqlink->icq_MetaUserInterests = 0L; icqlink->icq_MetaUserAffiliations = 0L; icqlink->icq_MetaUserHomePageCategory = 0L; + icqlink->icq_UpdateSuccess = 0L; + icqlink->icq_UpdateFailure = 0L; /* General stuff */ icqlink->icq_Uin = uin; -- Lars Christensen, la...@cs... |
|
From: Denis V. D. <de...@nu...> - 2001-06-07 18:02:23
|
"Peter M. Lemmen" <le...@ho...> writes: > I've been having an odd problem since using Icqlib 1.0.0 in my icq client. > I've added support for handling Timeouts which works on the following logic: > > When a icq_SetTimeout event is generated... > If the interval is -1, the current Timeout is cleared. > If the interval is 0, the current Timeout is cleared. > If the interval is larger then 0, the current Timeout is changed to Now() > + interval. > > When the Timeout passes... > icq_HandleTimeout is called. > And the Timeout is cleared. Everything is fine so far. > My login sequence is as follows: > > icq_Init is called to initialize the link. > Callbacks are registered with the link. > icq_Connect is called to create the UDP connection. > icq_Login is called to send the login information to the server. > The icq contacts are added to the link. > icq_SendContactList is called. > icq_SendVisibleList is called. And this is wrong. Move "The icq contacts are added to the link" step before "icq_Login is called to send the login information to the server" because icq_Login() sends all your contact information itself. It means you send your contact list twice, that's why you experience timeouts. In other words, you shouldn't call icq_SendContactList(), icq_SendVisibleList() & icq_SendInvisibleList() functions manually on login. Just populate those lists before calling icq_Login(). If you change your contact list after login (add new buddy), call icq_SendNewUser() function (subject to rename!!!). Call icq_SendVisibleList() & icq_SendInvisibleList() functions on any changes in those lists as usual - there is no special functions to send single new user added to them. > I believe the icq_Login and/or the contact list calls generate a (15 second) > Timeout event. Within those 15 seconds the user is logged in and all the > UserOnline events are received. > The timeout is not cleared however, and when the 15 seconds are up, > HandleTimeout is called. A few seconds after that we get the whole list of > UserOnline messages again, as if the contact list packets were resent. It happens because ICQ server has special "feature" to drop packets when they come too fast from the client, i.e. to prevent flood. Login procedure generates a lot of the packets and some of them could be lost, that's why we need Timeout manager - to resend unacknowledged (potentially lost) packets. > I think the Ack messages for the Contact list and Visible List get lost > somewhere so icqlib is unable to match them up with the original sent > packets. Or just there was no Ack packets from the server at all... > Is my handling logic of the Timeouts correct? Especially the double-clear > case with a zero interval. Yes, that is correct. > Why is the contact list not acknowledged properly? Would it help if I moved > the sending of the contact and visible lists into the icq_Logged event? (Ie, > after the login was properly handled.) Try to implement it like I said before. > ---------------------------------------------------------------- > Peter M. Lemmen Peter's ICQ Client > www.outreach.nl www.outreach.nl/picq > pe...@le... pi...@ou... > ---------------------------------------------------------------- As I already mentioned on the icqlib forum picq name is already taken: http://www.datanaut.com/picq -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Denis V. D. <de...@de...> - 2001-06-06 23:52:12
|
Hi. If you sent me any emails at my de...@nu... address in date range between May 24 and today, and I have not replied you back yet, please resend it at my other address de...@de... Sorry for any inconvenience, but you can believe that it hurts me even more... :( This is an explanation I've got from null.net (mail.com) Member Services department: Delayed delivery of new mail - We know there are delays in receiving new messages. This is a symptom of the heavy traffic going through our mail systems while we upgrade all accounts to the new version. This is a temporary problem and will be resolved as soon as possible - it is a top priority. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Richard H. <rc...@ca...> - 2001-06-06 12:49:39
|
> > Description: This patch clean up the byte order handling in icqlib. It > > removed the include of platform specific headers in icqbyteorder.h and > > bases the byte order decision on whether WORDS_ENDIAN is defined or not. > > The macro AC_C_BIGENDIAN should be included in configure.in, so that > > autoconf will detect the endianess in a platform independent way. > > Ok, lets give it a try... > Hope, it's more portable than our implementation :) > Not sure about Win32 though... No autoconf, of course, but as long as there's a #define that can be set it'll be fine. If some of the ugliness was put back in, and this was already set by a #ifdef _WIN32, that would be even nicer :-) I just got to thinking, however, what byte order is required for. It should only be needed for network<->host byte order translations, in which case the hton*() and ntoh*() functions could be used. It's a bit of work that needs to be put in to a function that already works fine anyway, but it's something to think about. Richard. |
|
From: Denis V. D. <de...@nu...> - 2001-06-06 01:45:10
|
2001-06-05 Denis V. Dmitrienko <de...@kd...> * icqlib/icqbyteorder.h, configure.in: Applied patch by Lars Christensen <la...@cs...> to use portable autoconf's endianness test. * icqlib/icq.h.in, icqlib/udp.h, icqlib/udphandle.c: Applied patch by Lars Christensen <la...@cs...> which adds 2 new callbacks - icq_UpdateSuccess & icq_UpdateFailure -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Denis V. D. <de...@nu...> - 2001-06-06 01:15:40
|
Lars Christensen <la...@cs...> writes: > Description: This patch clean up the byte order handling in icqlib. It > removed the include of platform specific headers in icqbyteorder.h and > bases the byte order decision on whether WORDS_ENDIAN is defined or not. > The macro AC_C_BIGENDIAN should be included in configure.in, so that > autoconf will detect the endianess in a platform independent way. Ok, lets give it a try... Hope, it's more portable than our implementation :) Not sure about Win32 though... BTW, applied. Thank you again. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Denis V. D. <de...@nu...> - 2001-06-06 00:59:04
|
Lars Christensen <la...@cs...> writes: > Description: This patch adds info update result notification (failure or > succes). Adds two callbacks, one for success and one for failure. Adds > one messagetype (UDP_SRV_UPDATE_FAIL). Please let me know if this is not > the right way to do it. It's clean enough... ;) Applied. Thank you. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Denis V. D. <de...@nu...> - 2001-06-06 00:55:26
|
Bill Soudan <we...@ri...> writes: > > Description: This patch fixes cast alignment bugs detected by using the > > -Wcast-align option for gcc. Although > > > > *((DWORD*)&buffer[5]) = value; > > > > may work on an intel processor, it is not portable because some > > architechtures (e.g. sparc) cannot copy DWORDS if they are not aligned on > > a multiple of 4 bytes. The attached patch fixes all occurences of such > > statements to: > > > > memcpy(buffer + 5, &value, sizeof(DWORD)); I understand the problem, but I am not sure this is the only way to fix it. > Why doesn't the compiler generate assembly code to just do the copy byte > by byte? Any ideas? :) Good question. > I'll apply the patch of course, just wondering for future reference. No. I'd like to test it first for myself. https://sourceforge.net/tracker/?func=detail&aid=427404&group_id=384&atid=100384 -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Lars C. <la...@cs...> - 2001-06-06 00:39:56
|
On Tue, 5 Jun 2001, Bill Soudan wrote: > > On Tue, 5 Jun 2001, Lars Christensen wrote: > > > Description: This patch fixes cast alignment bugs detected by using the > > -Wcast-align option for gcc. Although > > > > *((DWORD*)&buffer[5]) = value; > > > > may work on an intel processor, it is not portable because some > > architechtures (e.g. sparc) cannot copy DWORDS if they are not aligned on > > a multiple of 4 bytes. The attached patch fixes all occurences of such > > statements to: > > > > memcpy(buffer + 5, &value, sizeof(DWORD)); > > > > The patches is tested and icqlib works on Sparc Solaris with is (UDP > > communication at least. TCP code is also changed, but untested - it does > > compile though). icqlib would about with a "bus error" or "segmentation > > fault" without this patch. > > Interesting - I never realized you have to worry about alignment. > > Why doesn't the compiler generate assembly code to just do the copy byte > by byte? Any ideas? :) For efficieny. The dword copy is many times faster than byte-by-byte copy. If the compiler needed to generate safe code it would have to do this in any case, even when direct assignment to the adresses of the casted pointer is indeed possible, e.g. n = 8 *(DWORD*)&buffer[n] = 0 -- Lars Christensen, la...@cs... |
|
From: Bill S. <we...@ri...> - 2001-06-05 23:34:57
|
On Tue, 5 Jun 2001, Lars Christensen wrote: > Description: This patch fixes cast alignment bugs detected by using the > -Wcast-align option for gcc. Although > > *((DWORD*)&buffer[5]) = value; > > may work on an intel processor, it is not portable because some > architechtures (e.g. sparc) cannot copy DWORDS if they are not aligned on > a multiple of 4 bytes. The attached patch fixes all occurences of such > statements to: > > memcpy(buffer + 5, &value, sizeof(DWORD)); > > The patches is tested and icqlib works on Sparc Solaris with is (UDP > communication at least. TCP code is also changed, but untested - it does > compile though). icqlib would about with a "bus error" or "segmentation > fault" without this patch. Interesting - I never realized you have to worry about alignment. Why doesn't the compiler generate assembly code to just do the copy byte by byte? Any ideas? :) I'll apply the patch of course, just wondering for future reference. Bill |
|
From: Denis V. D. <de...@nu...> - 2001-06-05 22:34:29
|
2001-06-05 Denis V. Dmitrienko <de...@kd...> * icqlib/udphandle.c: Added code to send invisible list on login. * AUTHORS: Added Michael Hudson. * CHANGES_SINCE_0.1.3: Added 0.1.3 -> 1.0.0 migration comments by Peter M. Lemmen <pml...@us...> * icqlib/icq.h.in, icqlib/contacts.c: Changed parameter's name for readability. * icqlib/icqlib.c, icqlib/tcp.c: Cleanups. * CHANGES_SINCE_1.0: Spell-checked. 2001-06-05 Michael Hudson <mw...@ca...> * bindings/python/icqlibmodule.c: Whitespace prettyification; no functional changes. These have been sitting around here for weeks! Oops. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Lars C. <la...@cs...> - 2001-06-05 17:33:37
|
Description: This patch fixes cast alignment bugs detected by using the -Wcast-align option for gcc. Although *((DWORD*)&buffer[5]) = value; may work on an intel processor, it is not portable because some architechtures (e.g. sparc) cannot copy DWORDS if they are not aligned on a multiple of 4 bytes. The attached patch fixes all occurences of such statements to: memcpy(buffer + 5, &value, sizeof(DWORD)); The patches is tested and icqlib works on Sparc Solaris with is (UDP communication at least. TCP code is also changed, but untested - it does compile though). icqlib would about with a "bus error" or "segmentation fault" without this patch. -- Lars Christensen, la...@cs... |
|
From: Lars C. <la...@cs...> - 2001-06-05 16:18:56
|
Description: This patch adds info update result notification (failure or succes). Adds two callbacks, one for success and one for failure. Adds one messagetype (UDP_SRV_UPDATE_FAIL). Please let me know if this is not the right way to do it. -- Lars Christensen, la...@cs... |
|
From: Lars C. <la...@cs...> - 2001-06-05 16:13:19
|
Description: This patch clean up the byte order handling in icqlib. It removed the include of platform specific headers in icqbyteorder.h and bases the byte order decision on whether WORDS_ENDIAN is defined or not. The macro AC_C_BIGENDIAN should be included in configure.in, so that autoconf will detect the endianess in a platform independent way. -- Lars Christensen, la...@cs... |
3 messages has been excluded from this view by a project administrator.
