[fpc-pascal] locale solution for unix systems
Marco van de Voort
marcov at stack.nl
Fri Mar 20 15:51:55 CET 2009
In our previous episode, Bart said:
> > Note that a bulky "read externally" alternative won't be enabled by default
> > in FPC anyway, so it doesn't even alleviate the "need to include clocale"
> > issue. The point is if in this case it is worth the trouble if most people then
> > happily link to X or Lazarus.
> Personally I would like to see the formatsettings being localised by
> default (by SysUtils), since on Windows it is (Delphi compatibility)
> and I'd expect it ot be the same on all platforms.
> For this reason a "bulky read external" alternative might be useful if
> we do not want SysUtils be dependent on libc.
It's really doubtful it would be done that way. It just adds a possible reason
for breakage to (in practice) each binary. The timezone stuff didn't really
make me happy. Since it is only a global (and not per unit) decision, Delphi
compatibility doesn't say much, since project-wide information is not Delphi
compatible in the first place.
A plugin is the more logical route, for the ones that want to remain libc
free, but want to risk maintainance problems.
> In that case I'd opt for parsing the text-based versions, since the
> compiled ones are libc dependent (their format changes).
Are they guaranteed default installed on most OSes ? It's pretty hard to
parse something that is not there. Also start inventorizing all possible
solutions on all possible distro's and OSes.
> Anyone who links his app to libc (like a standard Lazarus app) can the
> hapilly include clocale (because the text-based parsing might not be
> 100% accurate).
But has an unneeded size penalty (and breakage, since it is always run!).
More information about the fpc-pascal