Re: [PATCH] smsc modules directory

Hi Harrie and everyone I saw that smsc.c was moved to the smsc module directory (which I don't think is write - as this is just the API implementation, not a module in itself), but the smsc.h file was left in the gw directory. you have to decide were to put these two files, but they should be

[PATCH] SMPP panic when sender or receiver address longer then 20 characters.

Hi list We encountered a bug that causes SMPP to panic when creating the PDU if the receiver or sender address is longer then 20 characters. the panic occures in smpp_pdu.c in smpp_pdu_pack which asserts on the length of the source Octstr before packing it into the PDU. I don't want to change

Re: [PATCH] smsc modules directory

--On Sunday, August 11, 2002 12:20 PM +0300 Oded Arbel [EMAIL PROTECTED] wrote: Hi Harrie and everyone I saw that smsc.c was moved to the smsc module directory (which I don't think is write - as this is just the API implementation, not a module in itself), but the smsc.h file was left in

Re: [PATCH] SMPP panic when sender or receiver address longer then20 characters.

Hi Oded, Good catch. Forgive if I sound stupid, but regarding the length of an address. If it is really bigger then 20 can one just discard the part of the address that is longer?? That sounds weird to me, or is the address only used internal in the smpp part as some indication?? On top of

[PATCH] AT2 DLR : new revision.

Hi list. Here's a new revision of the AT2 DLR support patch : - changed to patch cleanly against current CVS - changed TP-ST handling to be more correct (still not 100%) and better documented (in the code comments).

[PATCH] AT2 DLR: new revision

Hi list. Here's a new revision of the AT2 DLR support patch : - changed to patch cleanly against current CVS - changed TP-ST handling to be more correct (still not 100%) and better documented (in the code comments). sorry about the previous email - sent to early.. -- Oded Arbel m-Wise mobile

RE: [PATCH] SMPP panic when sender or receiver address longer then20 characters.

-Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Hi Oded, Good catch. Forgive if I sound stupid, but regarding the length of an address. If it is really bigger then 20 can one just discard the part of the address that is longer?? I don't know - I don't

RE: [PATCH] SMPP panic when sender or receiver address longerthen20 characters.

--On Sunday, August 11, 2002 2:46 PM +0300 Oded Arbel [EMAIL PROTECTED] wrote: -Original Message- From: Oded Arbel in some #define and use that?? Then changing the length is done in one place only. it is - in the smpp_pdu.def : hm. my bad - this is not what you meant.

RE: [PATCH] SMPP panic when sender or receiver address longerthen20 characters.

--On Sunday, August 11, 2002 2:32 PM +0300 Oded Arbel [EMAIL PROTECTED] wrote: -Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Hi Oded, Good catch. Forgive if I sound stupid, but regarding the length of an address. If it is really bigger then 20 can one

[RFC] delivery reports for concatenated messages.

Hi list. Wanted to ask your opinion about how we should handle DLRs on a message that get split to multiple concatenated messages. Currently - the dlr_url is only saved for the first message, so the originator will only receive a single DLR on the first part of the message. while this is an

Re: [RFC] delivery reports for concatenated messages.

Hi list. Wanted to ask your opinion about how we should handle DLRs on a message that get split to multiple concatenated messages. Currently - the dlr_url is only saved for the first message, so the originator will only receive a single DLR on the first part of the message. while this is an

RE: [RFC] delivery reports for concatenated messages.

-Original Message- From: Andreas Fink [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 11, 2002 3:41 PM To: Oded Arbel Cc: [EMAIL PROTECTED] Subject: Re: [RFC] delivery reports for concatenated messages. My suggestion is to do something like this - since the message ids on

RE: [PATCH] SMPP panic when sender or receiver address longerthen20characters.

--On Sunday, August 11, 2002 4:14 PM +0300 Oded Arbel [EMAIL PROTECTED] wrote: -Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] I admit these .def files are difficult, but I believe we need to make a define and use that define +1 in the .def file to allcate

CVS and cygwin

HI to all those working and committing from CYGWIN to CVS, I just fixed some file with the '^M' problem. This is caused in most cases by people who use cygwin and CVS. Those need to use a native CVS and not the standard cygwin cvs. The cygwin cvs lets the CVS server think it is a UNIX system,

Re: [PATCH] SMPP panic when sender or receiver address longerthen20characters.

Harrie, Oded, Cool. I am commiting this. can you please check my solution for this problem which I'm posting in a couple of minutes. I'd like to take my solution in favour of Oded's patch that has been just commited to cvs. See the mail for benefits. Stipe [EMAIL PROTECTED]

Re: [PATCH] Octstr function call sometime barf when called with NULL data

While some Octstr functions handle NULLs gracefully, others (especially the formating ones) do not behave so gentlemen-like. this patch will cause NULLs received instead of Octstr* in some cases not to panic the box but instead be handled in a predictable manner. again -1 for this, sorry

Re: [PATCH] Octstr function call sometime barf when called withNULL data

This will be in my next commit today. I also noticed some other things like ^M' at the end of lines in the ChangeLog and so on. I am going thru all this. this has been commited already. I have to veto against this and would like to request a revision step-back. Stipe [EMAIL PROTECTED]

RE: [PATCH] Octstr function call sometime barf when called with NULL data

-Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 11, 2002 6:38 PM To: Oded Arbel Cc: Kannel-devel (E-mail) Subject: Re: [PATCH] Octstr function call sometime barf when called with NULL data While some Octstr functions handle NULLs

Re: [PATCH] SMPP octstr to long handling

Yes - your solution is better. I'd vote +1 on Stipe's and removing my patch. btw - what happened to unified diff format ? ehhmm, ok, you got me. I just snipped this out of WinCVS window. One drink goes to Oded on our next meeting from me :)) Stipe [EMAIL PROTECTED]

Re: [PATCH] Octstr function call sometime barf when called with NULL data

Ok - you are correct here too :-). how about using (NULL) or [NULL] instead ? Hmm, what is exactly the problem with it now (or revision backed) is? I don't got the point I guess. Stipe [EMAIL PROTECTED] --- Wapme Systems AG

Re: [PATCH] SMPP octstr to long handling

Yes - your solution is better. I'd vote +1 on Stipe's and removing my patch. btw - what happened to unified diff format ? Ok, thanks. Harrie are you going to turn the revision wheel back or should I? Stipe [EMAIL PROTECTED] ---

Re: [PATCH] Octstr function call sometime barf when calledwithNULL data

--On Sunday, August 11, 2002 6:40 PM +0200 Stipe Tolj [EMAIL PROTECTED] wrote: This will be in my next commit today. I also noticed some other things like ^M' at the end of lines in the ChangeLog and so on. I am going thru all this. this has been commited already. I have to veto against

RE: [PATCH] Octstr function call sometime barf when called with NULL data

-Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Ok - you are correct here too :-). how about using (NULL) or [NULL] instead ? Hmm, what is exactly the problem with it now (or revision backed) is? I don't got the point I guess. this part :

Re: [PATCH] SMPP octstr to long handling

--On Sunday, August 11, 2002 6:31 PM +0200 Stipe Tolj [EMAIL PROTECTED] wrote: BTW, we should not #define constants of SMPP that are explicitely 'defined' by the .def file anyway. So the 21 length for source and destination number is already a #define in this semantical way and hence we

Re: [PATCH] Octstr function call sometime barf when called withNULL data

--On Sunday, August 11, 2002 6:38 PM +0200 Stipe Tolj [EMAIL PROTECTED] wrote: While some Octstr functions handle NULLs gracefully, others (especially the formating ones) do not behave so gentlemen-like. this patch will cause NULLs received instead of Octstr* in some cases not to panic the

[PATCH]

Hi all, here's a small patch for smsc_cimd2.c It's remove memory leak warning on exit. smsc-sender_prefix is allocated in cimd2_open() Dariusz Markowicz RCS file: /home/cvs/gateway/gw/smsc/smsc_cimd2.c,v retrieving revision 1.1 diff -u -r1.1 smsc_cimd2.c --- gw/smsc/smsc_cimd2.c8 Aug

Re: [PATCH]

Dariusz Markowicz wrote: Hi all, here's a small patch for smsc_cimd2.c It's remove memory leak warning on exit. smsc-sender_prefix is allocated in cimd2_open() thanks Dariusz for the patch. Can anyone of the developers who use CIMD2 confirm the patch with a positive vote for commitment?