Harrie Hazewinkel wrote:
>
> Hm, I am not so in favour of doing length definitions this hardcoded
> way. But it seems, that many thing get all the time done via
> MACROs and depending on the use the marco results in different code.
>
> This is more coding style, I guess.
I think Lars has made a
--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
> 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]
--
> 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]
-
> -Original Message-
> From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
> I'd suggest not to copy at the place Oded does, but in
> smpp_pdu.c:smpp_pdu_pack() by taking out the assertion check and
> throwing an error to the log and copy the Octstrs to the desired
> length, please see patch att
Hi all,
Oded is right here I guess. bearerbox should not panic if someone
injects data (via sendsms interface) that is out of SMPP specification
scope, which is 20 octets for the source and destination number.
I'd suggest not to copy at the place Oded does, but in
smpp_pdu.c:smpp_pdu_pack() by t
