Hi Dave, You missed the point. I do not want two functions: char const * fnc(char const * in) as well as char * fnnc(char * in) any more than libc wants two flavors of strstr(), for example. So strstr() returns char * and it is up to the caller to be careful. Perhaps the right thing is to pound the const-ness out of the pointer inside the function instead of the wrapper, but that is not the way I grew up all those years ago.
Instead, I'll cast it thus, beit in the function or macro: (char *)(uintptr_t)const_str_ptr On Mon, Jun 18, 2012 at 11:39 AM, Dave Hart <davehart_gmail_exchange_...@davehart.net> wrote: > A void * cast would suffer the same warning. If > spn_ag_char_map_chars() accepts both const char * and char * > arguments, the correct argument prototype is const char *. It is safe > to cast char * to const char *, but the reverse is not true The returned result must be assignment compatible with the provided argument. If the provided argument is not const, then the result is not const. > I wish I understood why newer gcc isn't warning in the same situation > -- but I believe it's wrong, as any stripping of const potentially > violates the const contract (potentially because the consumers of > de-consted pointers may not in fact write). Then a convenient solution for the strstr class of functions needs to be considered. (Where the attribute of the result matches whatever was provided.) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Autogen-users mailing list Autogen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/autogen-users
