bpa wrote: > My own preference would be to use strtod_l and then make sure it only > uses the "C" locale - using strtod with different untested locales may > still have surprises. > > Windows Flac.exe was built with VS so I'm trying to setup it up so I can > rebuild flac with extra message to be sure it is behaving OK on Windows > - but MS makes setting up VS2019 for simple command line C applications > painful. I have an old system with VS2015 setup for socketwrapper which > is the fallback.
Well, I've been having a further look at this. I think I do prefer your -strtod_l + C locale - approach, in principle, together with my own predilection of a fallback to the system's locale in case of failure. The coding is much sweeter and shorter, at least on macOS, which pleasingly accepts a 'NULL' locale as meaning the C locale, and only requires an extra -# include <xlocale.h>-. And I think FreeBSD follows the same pattern. But, as far as I can see, both GNU C and VS will require the creation of a 'C locale' object to be passed to -strtod_l-, twice, meaning more lines of code. And neither want the -# include <xlocale.h>-. Oh, and VS calls it -_strtod_l-. So while we can get a much nicer bit of code actually doing the job, there is a certain amount of infernal platform dependent setup required to achieve it that might, in reality, over-complicate matters. MinGW apparently doesn't implement it at all. At least not according to a 2017 reference that I found. I shall sleep on it. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=110871 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
