[Gdal-dev] locale handling in GDAL

[Pete Nagy]

Eew, yuck, isn't there some way to avoid locale hacks like a sprintf
workaround?  That kind of thing is really hard for someone new to the code
to grok, will probably be a source of bugs as people forget to use the
workaround, is ugly, etc.

There was some talk a while back about more multithreading improvements to
gdal.  How about killing both birds, where the calls the program makes
won't be sensitive to locale, and the threads that do the work will use
c locale?  Don't know if threads can have their own locale or if there'd
have to be interprocess stuff going on, but a multithreaded solution that
can distribute work to processes on other machines might be the best
anyway.  Just a thought.  Cheers,

-> Pete

--------------------------------------------------------------------

====================================================================
Pete Nagy                                        tel: (303) 583-0248
Vexcel Corporation                               fax: (303) 583-0246
http://www.vexcel.com                           home: (303) 823-2336
====================================================================


On Mon, 6 Mar 2006, Ray Gardener wrote:

> > I have tried implementing something like sprintf() before and it is
> > hard to do in an efficient (much less correct) manner.  How does other
> > software handle this?  It must come up all the time!
>
> The job might not be as hard as canonical sprintf() if GDAL is only
> using a subset of the possible features (e.g., printing only strings,
> chars, ints and floats).
>
> Another way is to use printf/sprintf only for strings, and make your own
> printing routines that return strings. This complicates the call syntax
> but can be implemented easier. e.g.:
>
> char* printnum(int n, char* psz)
> {
>     // go through digits of n and place into psz.
> }
>
> void foo(int n)
> {
>     char sz[30];
>     sprintf(pszMsg, "Answer is: %s", printnum(n, sz));
> }
>
>
> Ray
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>