Re: [GSoC][PATCH v5 01/12] fsck: rename "fsck_options" to "fsck_objects_options"

shejialuo <shejialuo@gmail.com> writes:

It is curious that the addition/renaming of fsck_objects_options is presumably to allow fsck_${xyzzy}_options to be added for different $xyzzy (the first one being "refs"), and this function is only about fsck_objects_options. What name would the corresponding error function, called by checkers that take fsck_${xyzzy}_options, be given? fsck_${xyzzy}_error_func()? Shouldn't this be then become fsck_objects_error_func() or something?

Having said that.

Do we really need such a parallel system between "objects" and other kinds of things being checked that you are introducing with this step? What benefit are we getting from this additional complexity?

I would have expected that adding ref-related new members that object consistency checkers has no interest in to the fsck_options structure would be sufficient for the purpose of this series. Or if we really wanted to prepare for more complex future, use of the "union of variants, switched with a tag" pattern to arrange the data this way:

	struct fsck_options {
		enum fsck_type {
			FSCK_OBJECTS,
			FSCK_REFS,
			...
		} t;
		union {
			struct fsck_objects_options objects;
			struct fsck_refs_options refs;
		} u;
	};

would still allow functions like fsck_error_func(), and fsck_set_msg_types(), etc. to work on the common "fsck_options".

I dunno.