Przemek, are you working on this now? For a start, I'd like to change to these:
extern HB_EXPORT const char * hb_parc( int iParam ); extern HB_EXPORT const char * hb_parcx( int iParam ); extern HB_EXPORT const char * hb_itemGetCPtr( PHB_ITEM pItem ); After that we can in parallel fix warnings (and errors). Or, how to make this the most efficient? Brgds, Viktor On Wed, Jun 24, 2009 at 9:20 PM, Przemyslaw Czerpak<dru...@acn.waw.pl> wrote: > On Wed, 24 Jun 2009, Xavi wrote: > > Hi, > >>> with meory protection we will have GPF so the warnings are perfectly valid. >> Thank you very much Przemek, but this means that many of these codes must be >> rewritten. ;) > > Not so much. I cleaned core code long time ago and eliminated all places > where such literal strings were modified though in few places I have to > left (char*) casting due to interactions with some function prototypes. > Anyhow I strongly prefer to clean it too. Probably it's good time to make > some modifications now. > I cannot say too much about windows only contrib code. Pure casting > of literal strings to (char *) is not danger as long as such strings > are not modified. In such case it may only reduce a little bit performance > due to interaction with optimizer and of course it disables improtant > compiler warnings so compiler will not warn us that literal strings > are modified so we have to locate all danger places ourselves by manual > code scanning. It's much easier and safe to use proper declarations. > In Windows code there is also problem with UNICODE support and TCHAR > strings. Here castings only hides the bugs but not resolves any problems. > > best regards, > Przemek > _______________________________________________ > 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
