Hi Andreas, Thanks for comments. Am I right that you are proposing to display only ascii part of text and save it also in sms.txt file instead of status messages like 'SMS was printed ...'? For all non-ascii SMSs this will looks like '??? ?? ?????' at VTY, is it ok? I'll wait for Holger's answer. Thanks, Pavel

Hi, Yes, they will be visible, but I'm talking about SMSs without ASCII chars except spaces/numbers/dots/commas/etc. In that case all words (in national language for example) will not be visible at VTY and user will see many '?' symbols if change non-ascii chars to '?' and spaces/comms/etc, and I think such representation of original text will be not very good (if I correctly understand your first comment). Thanks, Pavel

Ok, I'll prepare new patch and send it when ready. Thanks, Pavel

hi pavael, this looks good to me now. you can commit it as soon as the libosmocore patch is accepted and committed. best regards, andreas

Hi Pavel, sorry to be the party pooper, but I don't like the libosmocore patch for two reasons: 1) a popen to the locale command is really ugly. First of all, it will synchronously block the process issuing that command. Typical libosmocore-using processes are single-threaded and expect library calls to be non-blocking. Secondly, I really hate the idea of spawning other processes, executing other executables. It sounds lieke an ugly hack. Is there no way to get the information programmatically, e.g. by using localeconv(3) ? 2) the function "ucs2_to_utf8_decode" is cluttering the global namespace even further. Yes, it is in principle not a function related to gsm, but I'd still appreciate if it would start with osmo_ or gsm_ prefix in order to make sure we don't clash with applications or other libraries using the same symbol name. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Pavel, On Fri, Feb 08, 2013 at 01:55:52PM +0400, Pavel Baturko wrote: the locale setting is only for the current program. And as indicated, at least so far, most libosmocore users are single-threaded, i.e. nobody would notice if the locale was different for a very short amount of time. Furthermore, assuming that the code is not called all that often (i.e. only once at program startup) I wouldn't be worried about that so much. I am not an expert in locale.h matters, but it would somehow be strange to me if you cannot determine utf-8 support without having to actually change the locale. Is anyone on this list more familiar with it? yes, that would be appreciated, thanks. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Pavel, On Fri, Feb 08, 2013 at 02:29:17PM +0400, Pavel Baturko wrote: This sounds reasonable. Please make the global variable static and hide it to the caller. So only on the first call to the function it will do the setlocale() trick, then store the result in a variable. All further calls to the function will then retunr the variable instead of setlocale() and friends. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi Harald, Have you had a chance to look at last versions of patches? Thanks, Pavel On Sun, Feb 10, 2013 at 11:55 AM, Pavel Baturko <pabftk(a)gmail.com> wrote: