Okey. I had a similar feeling about it. Let's leave it then, and update the code to use EMPTY().
(Notice that this also means that _application code_ directly using these MySQL API calls will also need to be updated, since we will have to break compatibility.) Brgds, Viktor On Wed, Jun 25, 2008 at 3:27 PM, Mindaugas Kavaliauskas <[EMAIL PROTECTED]> wrote: > Szakáts Viktor wrote: > >> One possible solution is to allow to compare >> pointers to zero using operators (p != 0, >> p = 0, p == 0, and even p > 0, p < 0). Comparison >> with any other values would return .F., also, >> maybe NIL should be also allowed in place of 0, >> and we may allow such construct too: IF p ; ? "not null" ; ENDIF >> >> This would mean that a non-NULL pointer would qualify >> as .T., non-0, non-NIL and a NULL as .F., 0, NIL on >> .prg level. >> > > Hi, > > > I do not think it's good idea at all. We will want > IF 0, > IF 1, > etc. soon. > > I would suggest to fix code: > IF EMPTY(p) > .... > > > Best regards, > Mindaugas > > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
