git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] builtin/fsck.c: don't conflate "int" and "enum" in callback
Date: Tue, 01 Jun 2021 10:04:21 +0200	[thread overview]
Message-ID: <87k0ne0zx3.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <de9dea3a-6138-5e2f-7dc8-8a2ddf28bb84@kdbg.org>


On Tue, Jun 01 2021, Johannes Sixt wrote:

> Am 01.06.21 um 02:05 schrieb Ævar Arnfjörð Bjarmason:
>> Fix a warning on AIX's xlc compiler that's been emitted since my
>> a1aad71601a (fsck.h: use "enum object_type" instead of "int",
>> 2021-03-28):
>> 
>>     "builtin/fsck.c", line 805.32: 1506-068 (W) Operation between
>>     types "int(*)(struct object*,enum object_type,void*,struct
>>     fsck_options*)" and "int(*)(struct object*,int,void*,struct
>>     fsck_options*)" is not allowed.
>> 
>> I.e. it complains about us assigning a function with a prototype "int"
>> where we're expecting "enum object_type". Enums are just ints in C,
>> but it seems xlc is more picky than some about conflating them at the
>> source level.
>
> Is that true? I thought compilers were allowed to use whatever data type
> is sufficient to represent all enumeration values. For this reason, you
> sometimes see
>
>    enum X { A, B, X_MAX = 0x7fffffff };
>
> that ensures that an int must be used for representation of enum X. So,
> AFAICS, your patch is an actual fix, not just cosmetic.

	The identifiers in an enumerator list are declared as constants
	that have type int and may appear wherever such are
	permitted. [...] Each enumerated type shall be compatible with
	char,asigned integer type, or an unsigned integer type. The
	choice of type is implementation-defined,110) but shall be
	capable of representing the values of all the members of the
	enumeration [...] Thus, the identifiers of enumeration constants
	declared in the same scope shall all be distinct from each other
	and from other identifiers declared in ordinary declarators

	--C99, 6.7.2.2 @
          http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

My reading of that is that mixing the two (which we indeed, do all over
the place) is guaranteed to work, we've got plenty of places where
e.g. enum object_type is passed to something else as an "int".

This xlc warning in particular probably has nothing per-se to do with
enum v.s. int, but just that it's complaining that a function pointer
doesn't have exactly the expected type.
>> 
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>> 
>> This is new in v2.32.0, so sending this during the rc phase, just a
>> warning though, so unless you're using fatal warnings on that
>> OS/platform it won't impact anything, and even then it's just a minor
>> annoyance...
>> 
>>  builtin/fsck.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/builtin/fsck.c b/builtin/fsck.c
>> index 87a99b0108..b42b6fe21f 100644
>> --- a/builtin/fsck.c
>> +++ b/builtin/fsck.c
>> @@ -109,7 +109,8 @@ static int fsck_error_func(struct fsck_options *o,
>>  
>>  static struct object_array pending;
>>  
>> -static int mark_object(struct object *obj, int type, void *data, struct fsck_options *options)
>> +static int mark_object(struct object *obj, enum object_type type,
>> +		       void *data, struct fsck_options *options)
>>  {
>>  	struct object *parent = data;
>>  
>> 


  reply	other threads:[~2021-06-01  8:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01  0:05 [PATCH] builtin/fsck.c: don't conflate "int" and "enum" in callback Ævar Arnfjörð Bjarmason
2021-06-01  6:25 ` Johannes Sixt
2021-06-01  8:04   ` Ævar Arnfjörð Bjarmason [this message]
2021-06-01 17:56     ` René Scharfe
2021-06-01 21:04 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0ne0zx3.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).