Mark Glines schrieb:
* Fix up the indentation problems caused by the above bullet point.
(TODO: why does t/codingstd/c_indent.t require indentation for #if
and #ifdef, but not for #ifndef?)
As far as I understand c_indent.t, #ifndef is also covered
Except that it isn't. If you apply the attached patch, you will see
that t/codingstd/c_indent.t starts failing. C_indent.t will not be
happy until you reindent everything else, inside of it. (This patch
should not be checked in, it only exhibits the problem, it does not
solve anything.)
After applying c_indent_doesnt_recognise_ifndef.diff
I got no complaints from c_indent.t.
Could you check again?
In r18452 I checked in a small beautification of c_indent.t, which shouldn't
have chaned the algorithm.
On Sat, 05 May 2007 07:58:45 -0700
"Bernhard Schmalhofer via RT" <[EMAIL PROTECTED]> wrote:
I'd like to write some tests for this stuff, and then fix up the
rest of the cases (I know I've missed a bunch). How would the list
feel about a patch to PDD07 specifying the above for header files,
and a codingstd test to enforce it?
My feeling is that we need to differentiate two cases:
i. header files that define an interfaces for e.g. a subsystem
ii. Convenience headers, that contain declaration of internal
functions
Case i. might need stricter checks than ii.
Thanks for your input. I have written a test case for this,
t/codingstd/c_header_guards.t (attached), which checks the following:
* The existence of an #ifndef PARROT_*_GUARD
* That each header file only contains one #ifndef PARROT_*_GUARD
* The existence of a matching #define (this caught a few misspells)
* The existence of an #endif /* PARROT_*_GUARD */
* That the PARROT_*_GUARD macro is unique (doesn't stomp on any other
files)
I patched up another large set of headers, to pass this test. But
before I send in another big patch with some changes to type ii
("convenience") headers, can you please tell me if there's a clean,
programmatic way to determine which headers it should perform strict
checks on? That way I can fix the test to only run on the
non-"convenience" subset of headers.
IMHO the above tests looks quite sane for all header files.
For API defining headers I was vaguely pondering a check like.
"Make sure that the API does not change, unless there has been a
deprecation cycle."
This might be along the lined of 'tools/dev/parrot_api.pl'.
Also, should any of the above tests be applied to type ii headers, or
should they only apply to type i headers? (Should type ii headers be
ignored completely, or only subjected to a subset of the tests?)
Checking for header guards in all *.h files sounds good to me.
Regards,
Bernhard
