Stephen Lau wrote: > Nathan Bush wrote: >> Stephen Lau wrote: >>> Nathan Bush wrote: >>>> Stephen Lau wrote: >>>>> Nathan Bush wrote: >>>>>> Stephen Lau wrote: >>>>>>> 2) We throw a "Header guard does not match filename" on a header >>>>>>> guard that looks like: __FOO_H__ (for foo.h) or other things that >>>>>>> don't strictly match _FOO_H_ >>>>>>> Is this the best error message? Intuitively, I would think it >>>>>>> should be "Invalid or missing header guard" myself - but this is >>>>>>> the same behaviour as the gate's hdrchk.pl, so I'm curious what >>>>>>> other people think. >>>>>> >>>>>> I think the two messages are used differently. "Invalid or >>>>>> missing header >>>>>> guard" is already used earlier in the code to indicate that the >>>>>> "#ident" line >>>>>> marking the start of the guard wasn't found where it was >>>>>> expected. "Header >>>>>> guard does not match filename" is used to indicate that the >>>>>> constant value >>>>>> found in the header does not match what was expected based on >>>>>> hdrchk's >>>>>> application of cstyle rules. >>>>> >>>>> Yeah, I realise the different contexts of use. It just seems to me >>>>> that __FOO_H__ not matching _FOO_H_ is a 'formatting' issue, rather >>>>> than a 'filename' issue. It's minor, and not a huge deal to me >>>>> though. >>>> >>>> I see your point. Perhaps you could reword the message slightly, >>>> such as >>>> changing "does not match filename" to "name does not follow >>>> suggested style" >>>> or something similar. >>> >>> What about: >>> "Header guard does not match suggested style (_FILENAME_H_)" >>> >>> Or is that too nitty? >> >> No, not too nitty; it's helpful to state what is expected. But in your >> example, is "_FILENAME_H_" a static string, or would you actually print >> the real expected string based on the real filename? If so, in the case >> of files like <sys/zone.h> you would want to suggest "_SYS_ZONE_H_" yet >> you won't know about the "SYS_" part without looking at more than the >> header basename. :( > > I was going to just have it be a static string for that exact reason. > :) maybe _FILEPATH_H_ would be better (more suggestive that the path > should be incorporated)
That sounds good to me. --Nathan > >> I think that as long as the user gets a message that directs them to >> review the style guidelines that should be good enough. > > Yeah. > > cheers, > steve >
