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 think that as long as the user gets a message that directs them to review the style guidelines that should be good enough. --Nathan
