Compiling kannel with -Wall option
Hello, I added the -Wall option to CFLAGS, and I add a lot of warnings. I know this doesn't mean that there are errors, but it could hide some. Maybe it would be nice to enable this flag and to try to correct some of these warnings don't you think ? Regards, -- Colin Pitrat (Bull Services Telco) Bull, Architect of an Open World (TM) Tél : +33 (0) 1 30 80 72 93 www.bull.com begin:vcard fn:Colin Pitrat n:Pitrat;Colin org:Bull;Telco adr:;;rue Jean Jaures;Les Clayes sous Bois;;78340;France email;internet:[EMAIL PROTECTED] tel;work:+33 1 30 80 72 93 x-mozilla-html:FALSE url:http://www.bull.com version:2.1 end:vcard
Re: Compiling kannel with -Wall option
On Thu, 2006-10-12 at 10:03 +0200, Colin Pitrat wrote: I added the -Wall option to CFLAGS, and I add a lot of warnings. I know this doesn't mean that there are errors, but it could hide some. Maybe it would be nice to enable this flag and to try to correct some of these warnings don't you think ? I tried to pursue this a while ago with no luck. I guess at the time gwlib was developed, gcc wasn't this smart to notice pointer signedness issues. If you try it with gcc 3.x, you won't see many warnings but it will spit out quite a lot of them with gcc 4.x. I remember guessing about roots of the problem, somewhere around the octstr code or even deeper. I wonder why Kannel did not use glib in the first place and reinvented the wheel. Licensing issues, maybe? Hrm. -- .O. ..O Enver ALTIN | http://enveraltin.com/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ signature.asc Description: This is a digitally signed message part
Re: Compiling kannel with -Wall option
Great idea ! We are waiting such a patch from you! regards Vincent - Original Message - From: Colin Pitrat [EMAIL PROTECTED] To: devel@kannel.org Sent: Thursday, October 12, 2006 10:03 AM Subject: Compiling kannel with -Wall option Hello, I added the -Wall option to CFLAGS, and I add a lot of warnings. I know this doesn't mean that there are errors, but it could hide some. Maybe it would be nice to enable this flag and to try to correct some of these warnings don't you think ? Regards, -- Colin Pitrat (Bull Services Telco) Bull, Architect of an Open World (TM) Tél : +33 (0) 1 30 80 72 93 www.bull.com
Re: [PATH] convert internal charset to UTF-8
Alex, Your patch looks incomplete (ie smsbox part as you already knows) Actually we have a little compatibility breaker on charset I/O. Could you please complete this, and set the default as latin1 (or clearly indicates here a compatibility breaker) Also, the userguide need to be updated. Vincent. - Original Message - From: Vincent CHAVANIS [EMAIL PROTECTED] To: devel@kannel.org Sent: Monday, October 09, 2006 4:47 PM Subject: Re: [PATH] convert internal charset to UTF-8 Just a little warning, It also changes the sms-services when get-url is called. It will use %a in UTF-8 instead of latin-1 So we have here a little compatibility breaker. Also DLR, are affected. I'm in favor in normalizing all in UTF-8. That would be nice to see this feature in the userguide. (i mean returned string will be UTF-8 coded) Vincent. - Original Message - From: Alexander Malysh [EMAIL PROTECTED] To: devel@kannel.org Sent: Monday, October 09, 2006 1:03 PM Subject: Re: [PATH] convert internal charset to UTF-8 Hi Aarno, I don't see how internal charset could be related to toupper things. Internal charset just change msgdata encoding in sms structure to utf-8. Am 09.10.2006, 10:07 Uhr, schrieb Aarno Syvänen [EMAIL PROTECTED]: Hi List, When i am trying ro run test_ppg, I get: 2006-10-03 17:32:46 [13211] [14] WARNING: wap.mime: check_control_headers: Content-Type missingin SOAP part 2006-10-03 17:32:46 [13211] [14] WARNING: wap.mime: mime_parse: erroneous soap entity headers in the multipart This runs an version of MIME used for SOAP content, but checking Contant type is same as in Kannel. Check_control_headers does use toupper library functions, because headers are case insensitive. Do others have same problem, or is this one only specific to PPG ? (Is is, have toupper begun to act strangely after charset change ?) Aarno On 06 Oct 2006, at 17:26, Alexander Malysh wrote: Hi All, as no objections were here, commited to cvs. Am 13.07.2006, 21:35 Uhr, schrieb Alexander Malysh [EMAIL PROTECTED]: patch that converts internal kannel charset to UTF-8. Please note that I didn't add smsbox compatibility code, means smsbox expect text body to be encoded in UTF-8 as default also MOs will be forwarded in UTF-8. It could be workarounded with charset cgi variable. --Thanks, Alex -- Thanks, Alex
Re: Compiling kannel with -Wall option
We did that once for our own application which is using gwlib. Its just a lot of hand work and quite a few typecasts. One problem spotted while doing that is that gwlib is never sure if an octet from an octetstring should be considered a signed char or a unsigned char. My personal view is that it should be considered unsigned char as we often use raw bytes in octstr. This however means that whenever you do something like debug(xx,0,This is a string %s,octstr_get_cstr(xyz)); you have to typecast it to: debug(xx,0,This is a string %s,(char *)octstr_get_cstr(xyz)); One thing which is new in GCC is that we have now 3 types of chars. char(compiler default signedness) unsigned char signed char And if the compiler default is signed char, you still get an error when you assign a signed char to char. Thats where 99% of the errors come from. On 12.10.2006, at 10:03, Colin Pitrat wrote: Hello, I added the -Wall option to CFLAGS, and I add a lot of warnings. I know this doesn't mean that there are errors, but it could hide some. Maybe it would be nice to enable this flag and to try to correct some of these warnings don't you think ? Regards, -- Colin Pitrat (Bull Services Telco) Bull, Architect of an Open World (TM) Tél : +33 (0) 1 30 80 72 93 www.bull.com colin.pitrat.vcf
Re: [PATH] convert internal charset to UTF-8
Hi Vincent, I would like to keep UTF-8 as default charset. So we can send any charset we want w/o any troubles. I agree that we should document it in userguide. For users that want further send in latin1: they can use 'charset=LATIN1' cgi parameter for sendsms interface. What others think about it? Am 12.10.2006, 11:20 Uhr, schrieb Vincent CHAVANIS [EMAIL PROTECTED]: Alex, Your patch looks incomplete (ie smsbox part as you already knows) Actually we have a little compatibility breaker on charset I/O. Could you please complete this, and set the default as latin1 (or clearly indicates here a compatibility breaker) Also, the userguide need to be updated. Vincent. - Original Message - From: Vincent CHAVANIS [EMAIL PROTECTED] To: devel@kannel.org Sent: Monday, October 09, 2006 4:47 PM Subject: Re: [PATH] convert internal charset to UTF-8 Just a little warning, It also changes the sms-services when get-url is called. It will use %a in UTF-8 instead of latin-1 So we have here a little compatibility breaker. Also DLR, are affected. I'm in favor in normalizing all in UTF-8. That would be nice to see this feature in the userguide. (i mean returned string will be UTF-8 coded) Vincent. - Original Message - From: Alexander Malysh [EMAIL PROTECTED] To: devel@kannel.org Sent: Monday, October 09, 2006 1:03 PM Subject: Re: [PATH] convert internal charset to UTF-8 Hi Aarno, I don't see how internal charset could be related to toupper things. Internal charset just change msgdata encoding in sms structure to utf-8. Am 09.10.2006, 10:07 Uhr, schrieb Aarno Syvänen [EMAIL PROTECTED]: Hi List, When i am trying ro run test_ppg, I get: 2006-10-03 17:32:46 [13211] [14] WARNING: wap.mime: check_control_headers: Content-Type missingin SOAP part 2006-10-03 17:32:46 [13211] [14] WARNING: wap.mime: mime_parse: erroneous soap entity headers in the multipart This runs an version of MIME used for SOAP content, but checking Contant type is same as in Kannel. Check_control_headers does use toupper library functions, because headers are case insensitive. Do others have same problem, or is this one only specific to PPG ? (Is is, have toupper begun to act strangely after charset change ?) Aarno On 06 Oct 2006, at 17:26, Alexander Malysh wrote: Hi All, as no objections were here, commited to cvs. Am 13.07.2006, 21:35 Uhr, schrieb Alexander Malysh [EMAIL PROTECTED]: patch that converts internal kannel charset to UTF-8. Please note that I didn't add smsbox compatibility code, means smsbox expect text body to be encoded in UTF-8 as default also MOs will be forwarded in UTF-8. It could be workarounded with charset cgi variable. --Thanks, Alex -- Thanks, Alex -- Thanks, Alex
Re: [PATH] convert internal charset to UTF-8
On Thu, 2006-10-12 at 13:27 +0200, Alexander Malysh wrote: I would like to keep UTF-8 as default charset. So we can send any charset we want w/o any troubles. I agree that we should document it in userguide. For users that want further send in latin1: they can use 'charset=LATIN1' cgi parameter for sendsms interface. What others think about it? I'd support your approach, Alex. -- .O. ..O Enver ALTIN | http://enveraltin.com/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ signature.asc Description: This is a digitally signed message part
Re: [PATH] convert internal charset to UTF-8
Alexander Malysh wrote:
Hi Vincent,
I would like to keep UTF-8 as default charset. So we can send any
charset we want w/o any troubles. I agree that we should document it in
userguide. For users that want further send in latin1: they can use
'charset=LATIN1' cgi parameter for sendsms interface.
ok, I agree here with Alex... we want UTF-8 as default.
AFAIK, this means no change in sendsms calling since ASCII range is the first
128 bytesin UTF-8. How about the latin1?
Vinc, can you give an before/after utf-8 patch example of the beakers for
sms-service ger-url calls and DLR???
I' need this visual. Maybe others too ;)
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [PATH] convert internal charset to UTF-8
before (MO)
E50_NMSG
2852453A2950657572206465206D61207205616374696F6E2070617320726170706F7274207F2071756F693F
E50_AMSG(RE:)Peur de ma réaction pas rapport à quoi?
E50_TMSG(RE:)Peur de ma réaction pas rapport à quoi?
before (DLR)
E50_NMSG
534D53206E6F6E2072656D69732061752064657374696E617461697265203A20636F6D70746520057075697305
E50_AMSGSMS non remis au destinataire : compte épuisé
E50_TMSGSMS non remis au destinataire : compte épuisé
--
after (MO)
E50_NMSG
2852453A2950657572206465206D61207205616374696F6E2070617320726170706F7274207F2071756F693F
E50_AMSG(RE:)Peur de ma réaction pas rapport à quoi?
E50_TMSG(RE:)Peur de ma réaction pas rapport à quoi?
after (DLR)
E50_NMSG
534D53206E6F6E2072656D69732061752064657374696E617461697265203A20636F6D70746520057075697305
E50_AMSGSMS non remis au destinataire : compte épuisé
E50_TMSGSMS non remis au destinataire : compte épuisé
regards
Vincent.
- Original Message -
From: Stipe Tolj [EMAIL PROTECTED]
Cc: devel@kannel.org
Sent: Thursday, October 12, 2006 3:33 PM
Subject: Re: [PATH] convert internal charset to UTF-8
Alexander Malysh wrote:
Hi Vincent,
I would like to keep UTF-8 as default charset. So we can send any charset
we want w/o any troubles. I agree that we should document it in
userguide. For users that want further send in latin1: they can use
'charset=LATIN1' cgi parameter for sendsms interface.
ok, I agree here with Alex... we want UTF-8 as default.
AFAIK, this means no change in sendsms calling since ASCII range is the
first 128 bytesin UTF-8. How about the latin1?
Vinc, can you give an before/after utf-8 patch example of the beakers
for sms-service ger-url calls and DLR???
I' need this visual. Maybe others too ;)
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [PATH] convert internal charset to UTF-8
Vincent CHAVANIS wrote:
before (MO)
E50_NMSG
2852453A2950657572206465206D61207205616374696F6E2070617320726170706F7274207F2071756F693F
E50_AMSG(RE:)Peur de ma réaction pas rapport à quoi?
E50_TMSG(RE:)Peur de ma réaction pas rapport à quoi?
before (DLR)
E50_NMSG
534D53206E6F6E2072656D69732061752064657374696E617461697265203A20636F6D70746520057075697305
E50_AMSGSMS non remis au destinataire : compte épuisé
E50_TMSGSMS non remis au destinataire : compte épuisé
--
after (MO)
E50_NMSG
2852453A2950657572206465206D61207205616374696F6E2070617320726170706F7274207F2071756F693F
E50_AMSG(RE:)Peur de ma réaction pas rapport à quoi?
E50_TMSG(RE:)Peur de ma réaction pas rapport à quoi?
after (DLR)
E50_NMSG
534D53206E6F6E2072656D69732061752064657374696E617461697265203A20636F6D70746520057075697305
E50_AMSGSMS non remis au destinataire : compte épuisé
E50_TMSGSMS non remis au destinataire : compte épuisé
ok, this means:
a sms-service will get UTF-8'ed values for non ASCII chars rather then latin as
before, right?
Stipe
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [PATCH] Fix aliases in smsbox v2
Vincent CHAVANIS wrote:
Here is a new version in my devel cvs tree, a bit more verbose in debug
-logs for aliases and services names
-logs when executing get_matching_translations() and return an empty list
commited to cvs, but without he last debug() line, since this is an add-on...
2006-10-13 Stipe Tolj stolj at kannel.org
* gw/urltran.c: fxing alias support for sms-service in smsbox. Thanks to
Vincent for analysis and patch. Also removed debugging grp_dump() from
Alex' previous UTF-8 patch.
[Msg-Id: [EMAIL PROTECTED]]
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
