Re: [RFC] get rid of inconsistent -1 values

Alexander  Malysh <[email protected]> wrote:
> Hi List,
> 
> at first I would like to know from Bruno anything about this _mess_:
> Msg *msg_create(enum msg_type type)
> {
> ----------
>    if(type == sms) { /* reset */
>        msg->sms.sender = msg->sms.receiver = msg->sms.udhdata =
>            msg->sms.msgdata = msg->sms.smsc_id = msg->sms.service =
>            msg->sms.account = msg->sms.dlr_url = msg->sms.charset =
>            msg->sms.boxc_id = msg->sms.auth_code = msg->sms.hplmn = NULL;
>        msg->sms.time = (time_t) -1;


>        msg->sms.id = msg->sms.mclass = msg->sms.mwi = msg->sms.coding =
>            msg->sms.compress = msg->sms.validity = msg->sms.deferred =
>            msg->sms.dlr_mask = msg->sms.pid = msg->sms.alt_dcs =
>            msg->sms.rpi = -1;

I've done this msg initialization hack because I had problems with mt_reply 
messages with errors, where mt_reply would inherit values from mo messsage 
(think reply-* messages). 


> (if we start to _hack_ the code in such order, then we doesn't need 
> msg-decl.h at all. I see this sniplet as: I want that UNDEF values are -1, 
> but it doesn't work as I want, so I do simple hack rather as: heh I must fix 
> all other messages types too and do it)

parse error


> And now to these '-1' values. At first it's inconsistent to have -1 values 
> only for sms values. If we want to have '-1' == UNDEF then _all_ message 
> types should use it and not only sms and I do not see any goal to have these? 
> am I wrong? 

Is it really required to be consistent with other message types (are you
talking about wap messages ?)


> then please explain why -1 should be better as 0 (zero)?

If you have a specification (etsi 03.38 and 03.40) that talks about 0-x,
it was getting difficult to explain that etsi's message class 0-3 would
be kannel's 1-4. Another example is that you want to set pid=0 and
pid=undef (no pid value at all in smsc pdu).


> Only one thing I can see is: sendsms interface can use sms values (e.g. 
> mclass) as is (0-3).

As long as they are consistent in sendsms requests in and out and log
files...

> So (imo) we have 2 options:
>        1) make all message types consistent, means using -1 as UNDEF values

Really required ?


>        2) get rid of -1 UNDEF values for sms message type.

I'm -0 for getting rid internally, -1 for getting rid in external
interfaces


> Comments and votes please....