On Sat, Jun 20, 2009 at 9:22 PM, Przemyslaw Czerpak wrote:
>
> On Sat, 20 Jun 2009, Szak�ts Viktor wrote:
> > I wanted to suggest that, as current code makes LOTS OF
> > otherwise valid code prone to such errors and unexpected
> > behaviour.
> > Please do.
>
> Fine, I'll commit it in a while.
Tha
On Sat, 20 Jun 2009, Szak�ts Viktor wrote:
> I wanted to suggest that, as current code makes LOTS OF
> otherwise valid code prone to such errors and unexpected
> behaviour.
> Please do.
Fine, I'll commit it in a while.
> As a next step we will have to convert all our codebase to
> use the new API
Hi April,
Viktor Szakáts wrote:
..turns out it's not that easy, so I'm rather waiting :)
IIRC from my quick scan of source and contrib I could not see where
any program used this, but I am probably mistaken.
This can be a problem everywhere where there is
no HB_IS*() call before reading va
Viktor Szakáts wrote:
..turns out it's not that easy, so I'm rather waiting :)
IIRC from my quick scan of source and contrib I could not see where any
program used this, but I am probably mistaken.
When I used this feature it worked but at a terrible performance cost so
I've reverted to a
..turns out it's not that easy, so I'm rather waiting :)
Brgds,
Viktor
On Sat, Jun 20, 2009 at 3:42 PM, Viktor Szakáts wrote:
> Of course, but I'm waiting for Przemek for the proper fix in VM.
> Just hang on until this works out. There are a high number of
> places in Harbour code where we have t
Of course, but I'm waiting for Przemek for the proper fix in VM.
Just hang on until this works out. There are a high number of
places in Harbour code where we have the similar problem.
Until then you can use a local version.
Back to the proper fix, I'm thinking of the solution below:
In include/
vszak...@users.sourceforge.net wrote:
Revision: 11444
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11444&view=rev
Author: vszakats
Date: 2009-06-20 02:28:33 + (Sat, 20 Jun 2009)
Log Message:
---
2009-06-20 04:22 UTC+0200 Viktor Szakats (harbour.01
> Not true. They can return non empty value for arrays.
> hb_par*() functions accept variable number of parameters which
> are used as indexes if corresponding parameter is an array and
> exactly in this case it can be array so the behavior of the code
> after your modification is unpredictable. Wh
On Sat, 20 Jun 2009, Szak�ts Viktor wrote:
> I wonder how though.
> hb_parclen() is only > 0 (and also is hb_parc() != NULL only)
> if HB_ISCHAR() is true, so what is the difference?
Not true. They can return non empty value for arrays.
hb_par*() functions accept variable number of parameters whic
I wonder how though.
hb_parclen() is only > 0 (and also is hb_parc() != NULL only)
if HB_ISCHAR() is true, so what is the difference?
AFAICS the major problem fixed was that a misplaced iEOLs = 0 caused
the PHB_EOL_INFO not be allocated properly.
Brgds,
Viktor
On Sat, Jun 20, 2009 at 12:21 PM,
On Sat, 20 Jun 2009, vszak...@users.sourceforge.net wrote:
> 2009-06-20 04:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
> * source/rtl/mlcfunc.c
> % Minor optimization to EOL parameter handling.
> Please review.
It broke the code by reverting April fix.
best regards,
Przemek
Revision: 11444
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11444&view=rev
Author: vszakats
Date: 2009-06-20 02:28:33 + (Sat, 20 Jun 2009)
Log Message:
---
2009-06-20 04:22 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
* source/rtl/mlcfunc.c
12 matches
Mail list logo
