On Sun, 10 Mar 2019, Bart wrote:
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
I don't ever use the registry, so in that sense you are right it is indeed
not sexy enough to worry about it :-)
Neither do I use it...
Long time ago I wrote a patch for some other part of the
If I may add my two pence...
I'm all for speed and efficiency in library code, but conformance is more
important - if a correct input (even if somewhat extreme) results in a bad
output, then it's something that should be fixed. If you try to feed the
unit malformed input and it predictably
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
> I don't ever use the registry, so in that sense you are right it is indeed
> not sexy enough to worry about it :-)
Neither do I use it...
Long time ago I wrote a patch for some other part of the RTL.
The old behaviour was plain wrong
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
> It does not resolve a regression.
Yes, it does and I showed it here.
> The current behaviour is a bugfix for a reported bug.
And it did that the wrong way.
Calling Utf8Decode on a string without checking it is indeed Utf8
encoded is
Here’s what I have so far with some some tests included now. It’s complete in
it’s current form but I see what you mean about extending tcallcandidates. I
looked over everything again but right now I don’t see exactly how to achieve
that. I took the approach to take the dummy type sym and parse
On Sun, 10 Mar 2019, Bart wrote:
No.
Please, a single patch with full solution for unicode & ansistring.
You misundersdtand me here, I think.
The patch I mentioned does not concern the Unicode issue at hand.
The patch file however has a chunk of unaltered code in it, and in
_that_ code
> No.
>
> Please, a single patch with full solution for unicode & ansistring.
You misundersdtand me here, I think.
The patch I mentioned does not concern the Unicode issue at hand.
The patch file however has a chunk of unaltered code in it, and in
_that_ code there is one Utf8Encode.
If the
Am 10.03.2019 um 11:43 schrieb Anton Shepelev:
Michael Van Canneyt to Anton Shepelev:
Thank you, but how do I translate the return value of
GetLastOSError into a value of InOutRes? The
translation functions are privately implemented in
sysos.inc .
You can copy them. It is open source, after
On 3/9/19 1:06 PM, Anton Shepelev wrote:
Whenever the programmer grows annoyed of jumping to the declaration section
and back to code, he knows it is time to cut his spaghetti into more
manageable parts.
BINGO! give this man a cigar!
FWIW: this annoyance at jumping back and forth is also a
On Sun, 10 Mar 2019, Bart wrote:
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
The utf8encode should go, just like the utf8decode's that we fixed already.
Regards,
Joost.
I posted a patch in https://bugs.freepascal.org/view.php?id=35213.
Again: please first aplply the patch
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
> The utf8encode should go, just like the utf8decode's that we fixed already.
>
> Regards,
>
> Joost.
I posted a patch in https://bugs.freepascal.org/view.php?id=35213.
Again: please first aplply the patch from
Michael Van Canneyt to Anton Shepelev:
> > Thank you, but how do I translate the return value of
> > GetLastOSError into a value of InOutRes? The
> > translation functions are privately implemented in
> > sysos.inc .
>
> You can copy them. It is open source, after all.
Which brings us back to
12 matches
Mail list logo
