On Mon, Jun 18, 2012 at 6:22 PM, Bruce Korb <bruce.k...@gmail.com> wrote: > On 06/18/12 10:57, Dave Hart wrote: >> >> On Mon, Jun 18, 2012 at 5:38 PM, Bruce Korb<bruce.k...@gmail.com> wrote: >>> >>> On 06/17/12 23:26, Harlan Stenn wrote: >>>> >>>> On pogo, after fixing the zNotStr instance: > > > I have not seen Harlan's message about zNotStr, > so I don't know what the issue is. > >>> That does not build: > > >>> But that message is completely bogus: >> >> >> It doesn't seem bogus to me. See below. >> >>>> #define SPN_WHITESPACE_CHARS(_s) spn_ag_char_map_chars((char *)_s, >>>> 11) >>>> static inline char * >>>> spn_ag_char_map_chars(char * p, unsigned int mask_ix) > > >>>> char const * pzArgType; >>>> pzArgType = SPN_WHITESPACE_CHARS(pzArgType); >>> >>> >>> the SPN_WHITESPACE_CHARS macro casts the pointer to "char *", stripping >>> the qualifier. >> >> >> Right, stripping the "const" qualifier triggers the warning. No idea >> why you didn't see it with gcc 4.5.2, but again what really broke the >> build? As Harlan mentioned he had to update a zNotStr reference to >> the new identifier. > > > When I build it for myself, I use -Wall -Werror and I do not see a failure, > or even a warning. Since spn_ag_char_map_chars does not care if the > input is char const * or not, but the caller cares whether the result > can be assigned to a char* pointer, I use the cast in the macro wrapper. > I've been using this paradigm for decades and never seen a burp before. > Why would gcc 4.5.2 be happy on psp-os1 and gcc 4.2 whack my knuckles on > pogo? > I suppose I can use a "void *" cast, but all I really want to do is > strip the const-ness, not the underlying type. A cudgel should not be > required.
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--you are breaking the contract with the compiler to not allow writes through pointers to const declared as such. My understanding is const char * and char const * are equivalent, so spell it how you prefer. It is quite feasible to honor const throughout AutoGen/AutoOpts, if you so choose, but that means giving on up on the theory const is for you to control your users but does not control you. At worst, you'll need to play dirty with const at the boundary to third party code that gets it wrong. 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). Cheers, Dave Hart ------------------------------------------------------------------------------ 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
