some ntdll functions (2) - part 1: functions

[thomas.mertes at gmx.at]

Alexandre Julliard <julliard at winehq.com> writes:

> This is silly. It's just a gratuitous incompatibility that will break
> code for no good reason.

The point is: It does not break existing code. Existing code which
uses NULL as "string" parameter for _ultoa just does crash.

> Do you seriously think that people are going
> to give up running on Windows so that they can have _ultoa allocate
> memory for them?

This is the decision of the people using the _ultoa function.
All extensions (think of GNU extensions to programming languages and
librarys) work this way. There is a long history of language / library
extensions. The story is always the same: If you use an extension
you lose portability (therefore it must be documented).
The _ultoa function itself is an extension over the standard C library
functions. If you use _ultoa it does not run under unix (surprise).
In standard C you would use printf (and friends) for that functionality.

> The whole point of coding to the Windows API is to
> run on Windows; if your app is not going to run on Windows there are
> dozens of much better APIs to choose from.

Yes

> If the ReactOS guys want to add incompatible extensions that's their
> choice; but it's a mistake IMO, and it's definitely not something we
> are going to do in Wine.

In your opinion all the GNU people doing extensions are just making
mistakes (BTW Linux is an extension over the Unix API).
Ok, I can live with your decision (although I still have a different
position).
And I will send a new version of the patch.

The borderline when an extension begins is not always simple to draw.
Just 2 examples:

The native _itow fuction does crash when the string is longer than 19 chars.
The native _itoa function does not have this problem. I decided that our
_itow function should not crash (like the native _itoa function) in this
case.
Instead it just works when the string is longer than 19 chars.

The native RtlLargeIntegerToChar function does produce garbage or
STATUS_BUFFER_OVERFLOW for base 2, 8 and 16 when the value is
larger than 0xFFFFFFFF. Here I decided also against "bug for bug"
compatibility.

IMHO doing something senseful instead of crashing or producing garbage
is "The right thing to do" ((C) Linus Torvalds).

This decisions are not done lightly. I do a lot of testing and reasoning.

My _ultoa extension is just one step more (and nobody is forced to use this
extension).

When you do extensions you tell the user: Our interface is better and more
modern than the original. We do not crash and we have more functionality.
I think (good) extensions would attract windows users. And some of them
would help developing.

But aggain:
I can live with your decision (although I still have a different position).
And I will send a new version of the patch.

Greetings
Thomas Mertes

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!