From: "Curtis" <[EMAIL PROTECTED]> > Chris Tutty wrote: > > Often this is a sign of memory corruption, unitialised > > pointers, use of freed memory, etc. > > (snip) I have a string pointer declared as "char *s", then use it like this: > > s = CtlGetLabel(GetObjectPtr(ReadyButton)); > > This has always given me a warning "assignment discards qualifiers > from pointer target type", which I've simply ignored, and thought I > was getting away with it. > This will (probably) only cause a problem if you try to assign a value to that string location. In theory you should be able to declare that variable as 'const char * s' since you shouldn't be doing anything with that variable will produce another warning, but in practice this use of const tends to cascade in an annoying manner. The other approach is to comment that you're ignoring the const and use a pragma to suppress the warning for that line of code, but only if you're absolutely sure that your use of that variable is read-only through-out (and you accept that you're introducing a weakness into your code that might bite you at a later date).
Aside from that there's no such thing as 'getting away with it' with C coding. Coding with all warnings turned on and aiming for clean compiles (no warnings) as you develop will produce fewer problems later in the development cycle (and problems close to release are usually much nastier to deal with simply because of time pressures so they're worth avoiding). Aside from the well-documented danger of writing a longer string to FrmCopyLabel than was originally declared, remembering the null terminator, this shouldn't be an issue. That sort of problem is likely to produce problems in a debug environment anyway. The really nasty thing is that is this *is* a memory corruption problem then the bug might have nothing to do with these lines of code at all. That's what makes memory corruption so evil - it can silently cause a side-effect that won't appear as a run-time problem until some unrelated time later. This is the reason for being so particular about 'const', null pointers, checking return values, etc. The problem you originally quoted was that the label was having crap copied into it. Identifying where that crap comes from is your first task in debugging the problem. Chris Tutty -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
