Re: mpz_set_str opinion

[Kevin Ryde]

"Barubary" <address@hidden> writes:
>
> I think you should not change the definition of mpz_set_str simply because
> there is existing code (however little) that uses that particular feature of
> mpz_set_str.

Yes.  We've had opinions against the current whitespace, but as you
say changing it would be incompatible.

> I think you should make mpz_set_str as deprecated and make a
> new function with a similar name that breaks at whitespace.  Personally, I
> think you should mimic the style of the strtol() series, with regards to the
> char **endp parameter (the way base is implemented now is exactly like
> strtol) and the whitespace handler (whitespace is ignored at the beginning
> at end, but once seen after digits, it terminates).

Yes, that might come about some day, parsing like C99 does.  There's
an entry in doc/tasks.html for it.

> I think you should also make a mpz_set_wcs that takes a wchar_t * on
> platforms that support wchar_t (in the case of Windows, Cygwin's libraries
> don't, but Win32 does).  Can never hurt to be Unicode compatible.  I could
> help with the processing of foreign digits if you like, but I doubt that
> that's necessary.

I'm not actually up with what advantages wchar_t would give.  We
probably wouldn't want a whole parallel set of wchar string routines
unless they were definitely going to be used by applications.