On 25 Jun 2002 at 7:41, Earnie Boyd wrote:
> "Paul G." wrote:
> > Picking a semi-random "code", STATUS_FLOAT_UNDERFLOW
> > I find it in <mingw>\include, <mingw>\include\win32api and <mingw>\include\mingw
> > (duplication?). Again, see above. MS PDK (and no I am not suggesting that anything be changed, I am
> > simply noting what is true given the most recent data where the so-called error "codes"noted above are at
> > issue).
> > Again, original poster did not specify which "code" he was talking about. There are a number of
> > STATUS_* "codes", and they are scattered, and some are in fact "non-existent", within the latest releases
> > from Mingw project files page.
> The short of it:
> It is Paul's problem.
Nope. No problems here. Just observations.
I assume that most people who follow this m/l are intelligent enough to see those observations for what they
are and do not make the mistake of interpreting those observations, at least not from me, as some sort of policy or
other "empiracal" statement(s). That is, as it has been made quite clear, not my responsibility. I am not the only one
here nor have I ever been.
> The long of it:
> Your duplication is caused by your duplication of extracting files
> into differing directories.
Duplication on my hard drive, has no bearing to me or in terms of any aspects of Mingw. I could care less
about the duplication. That duplication, afaiac, is of no consequence and makes no difference in terms of the Mingw
If duplication seems like a problem to someone, then that is their problem, not mine. I am happy to address
such things if asked. However, since I really don't have a problem with duplication of header files I have no reason to
address such things. By the same token, if no one cares to ask me to address such things (or any issues for that
matter) I can see no good reason to do so.
If, there is listed somewhere, how the distribution should be organized on the disk, then that needs to be
made clear. Most especially if it is a matter of policy in terms of archive distribution, etc. Again, as some have made
quite clear, I should not care about policy or anything that might remotely address such things. Fine by me. Doesn't
change the fact that I do care about Mingw and the future of Mingw.
Original post was about one persons inability to find certain STATUS_* codes, nothing else. It is clear, that
in nine out of ten cases, I am asked to proove something here. Long documented steps and answers are just one
way to do that. Short answers, at least mine, usually leave, at least some people, wondering, "what the heck is he
talking about". I am happy to answer those questions as well, either off-list or on. Doesn't matter to me one way or
the other where they are answered. It is clear that some simply do not (or choose not to) accept any answer from
me, even if they do ask.
If there are problems with me giving a long and well-researched answer (including all that is discovered in my
investigations of certain aspects of Mingw runtime, win32api, binutils, etc.), then that needs to be made clear.
If there are problems folks are having with the way I approach something, then it is probably better to take it
up with me offlist.
If, on the other hand, the folks here simply do not understand (not at all out of the question) or are confused
by a response (again, not at all out of the question), then that needs to be made clear as well.
If I know that something confuses or is not understandable to some I will revise that answer to suit the
person who is asking for more clarity or more understanding. However, increasing clarity and/or understanding
invariably requires a "longer and more indepth answer" as the "short of it" is, in such cases, insufficient.