Okay, thanks for your confirmation. I think we can
make this move, even in the non-optional way, in the
next release. This is very important for code quality
and security.
I also believe core code and the few top contribs
are fine, but it would be still great to get
this under control and get a real proof.
Let's wake up on an RC branch tomorrow :)
Good night for you and all.
Brgds,
Viktor
On 2008.06.04., at 0:44, Przemyslaw Czerpak wrote:
On Tue, 03 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
We have hb_parc()/hb_parcx()/hb_itemGetCPtr() to
return direct pointers to Harbour strings (maybe more).
I've stumbled into some C code (rddads, hbhpdf) directly
passing these buffers to C level functions _returning_
values in this buffer. This may corrupt HVM.
Such code is currently difficult to find.
Yes, it is.
Question: should we make the return value of these
functions 'const' ? (and maybe do some tricks to
stay compatible when user code is using _parc()).
I wanted to make it but I was afraid 3-rd party developers
reaction. For C mode it will cause only warnings but for C++
it will force code updating.
The trick for _parc() can be made by adding explicit char *
casting in this macro.
Or in general: Shouldn't we make better use of
'const' flag?
Yes we should and I'm trying to make it but so far in very
small steps.
Does these make any sense?
[ Few examples for possible HVM corruption, after
recompiling hbwhat32 with const flag:
GETCOMPUTERNAMEEX(), GETUSERNAME(), ACCEPT() ]
I think that at least our core code should be ready to cleanly
compile with hb_parc() and related functions declared as const.
IMHO it will be good to introduce it at least as an macro defined
option.
PS: I know this would cause an avalanche in 'const'-ing
various other function parameters and add casting,
and I also know of hb_itemUnShareString(), and I'm not
suggesting to solve it before 1.0.
If you look at changelog then you will find that for last years I've
been adding const flag systematically to different functions in places
which should not effect 3-rd party code. It means that for old
functions
I was changing only parameters and return value only for new once.
Anyhow without adding const to return value for functions return
constant strings is very slow process and does not help enough in
fixing exiting code.
I think it will be good to introduce HB_OPT_CONST or sth like that
with the following code in hbdefs.h:
#ifndef HB_OPT_CONST
#define HB_OPT_CONST
#endif
so at least core developers may use it to recompile Harbour with
C_USR=-DHB_OPT_CONST
to validate existing code. Of course after adding HB_OPT_CONST casting
in return value declaration for all functions which return constant
strings.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
