Hi Przemek,
Well, for me it's not a problem.
Notice however that by using -q/-q0 the whole problem disappears,
as none of these messages would appear on any outputs, and
this is what I expect to happen in most "advanced" build environments
(I may be wrong though). So, IMO, -q is what you need, rather than
relying on this specific detail.
What do you think?
For me it looks strange when on stderr I've got different messages.
I very like that nearly all tools I'm using clearly divide output
messages. I can use tools with can merge stdout/stderr and show both
in different colors, I can create separated files with error and
standard
messages, etc. So far developers tools designed for other compilers
were working perfectly also with harbour and I would like to keep it.
If you really want to change it then I rather suggest to add compiler
switch for _strictly_ clipper compatible output.
I'll revert it and leave this exercise for now.
I'm still confused about what rule to follow here in general
in the future. I take compatibility first, but that doesn't
seem to be in sync with general opinion. Usefulness is difficult
to oversee in such minor details. [ I personally don't have any
preference in this case. ]
It was Clipper CT3 compatible behavior implemented in a why
which was not breaking any existing Clipper code. This modification
broke my CT3 DOS code which uses CTWIN. Please revert it too because
it breaks existing Clipper code which uses CTWIN form CT3.
How is this implemented in Clipper + CT3 DOS?
As far as I could see MaxRow() passes down the call
to _gtMaxRow(), which returns the value without any
special tricks in Clipper.
I can only guess that CTIII overloads some standard clipper functions.
I haven't decompiled it to check the exact implementation. Probably
inside CTUS.OBJ is new MaxCol()/MaxRow() implementation. Unfortunately
Yes, that's happening, I've now checked.
Overloading functions in such way is not fully portable. It depends
on platform, used linker (and even compiler and compiler switches if
we are talking about C code) type of linking (static vs dynamic), etc.
F.e. even in MS-WIN it will not work as you may expect from DOS days
if you are using DLLs because internal bindings inside DLL are not
overloaded by functions in linked .obj modules. The previous
implementation
was IMHO good compromise to be Clipper and CT3 compatible without any
side effects for pure Clipper code which was fully controlled by
programmer and working on all platforms. And to be clear. It was
never an xHarbour extension. xHarbour has it's own modifications
to maxrow()/maxcol() which were never ported to Harbour.
Well, okey, but it's still not very good practice.
Basically the problem is that CT3 does a shameful
thing here (one we actually try to avoid here),
and to be compatible we're replicating this by
extending a core function with a lib specific feature.
I'll restore it anyway, but I think it could only
do good if even Clipper programs are updated to use
hb_ScrMax*() instead of Max*(.T.). Implementing
them in Clipper takes only a few seconds.
Question: I've just now discovered that Harbour already
has this functionality via hb_gtInfo() functions.
Should we still keep hb_ScrMax*()?
Based on my own code, my vote is a definite yes,
since I'm using similar calls very often.
Another mental note: Maybe your function redirection
idea should be reconsidered for such situations.
We need to solve the security implications though,
like you cannot overload a function at runtime, only
in a specific phase of the startup, or something similar.
There may be other issues as well.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
