[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix error: array subscript has type 'char' [and 1 more messages]

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Wed, 27 Jan 2021 16:52:28 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WgdyDG90oeBXwUU/+HmgLD8LTuItN8BaVe5Im/WS/NA=; b=knsk/Rmyx2mxeY0vlFwFLujCcKpTVviSidz2XwGGdJT7wKCYYvdQVVivV/fX2nDbUwtOqjaIPyzb0WITrbQ2+gT/BL80GssxnL7Hy8HIremGUMfIIEmeTNJYkEV5BMRT6EmO++T3us7hLCVKFCV7iHEiN5AWNKlAOGIEy1XVLSW0ToUO+vHkXFK09nUsQYVMj2CuO5geatihDAWAUNd9a9l5V4lp27nOeaGhrPk1TEUR89wJJOVZwEJct8T4l/GrjJCVOJSHbJ/Dd4h222g2x/mYDnqHm4fz7NNl8wxKmkbdS2WYjNnWT0FuD4tlUI6b7HFKCMzIlQsaukmXxyn8Lw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VhoODZRTKr76O0yCIw44ZhlYTqowh8AFfA8mFMbaKhm1yaUH4izjb7qBA8WEAW2hyA+mv3cao+JLreUddB78rUKR2iHxTteRLRoPbH4yyiq+CwRt+UPLRsbI0hHG/p8a4N2pdT8S2EAupd21nYU0tJdCzK3NzXjfHQk3Gc9L0/eJ755q7kPeI74/XSq2DSx/yYA1xHEHtihkBOJ7AfCKuUUVG0nKcyoVYthpCmV4bhlmAObCAeCzIlltpK8o6ioqU+c/tGtIzQWbnMY58PegHcH7H7vGdW1/4Ikgcm0B6sKpB4fCJm5NV6UCH7YzeE5qODhZOOuJn7gsVTZ0L5crSw==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Manuel Bouyer" <bouyer@xxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 27 Jan 2021 16:52:34 +0000
  • Ironport-sdr: LAgSsF5QRFnB9TgASM9wwVOXFV+KVt8dI/ZaFpesEQqyTueJS69BkHQ4IlAFl/l3ZgqCnC4RmH s0xK0M2G+oOJ00vqmZjp/FOEbvQxhYFZi5+l85fgtr9fXdWMS0Xu6RBNZoP5lyJU/yk19KB2BZ /tN/nHxS7Uvwa4I8uAwT+KMv0aLwsdtIJJxOWhsC1fIdyh/0bUeZnQyQeay/KVxwNKyFerZF6/ y9yIUtrrneD4gtuec0TqWHxzIBf3ZlMGz8ys4D+9opxipbszAvjFVBMMdIgm7M2d6SqlBn0U2e ffs=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHW9LPLLE/yNMSfZ0ieExDVLla+Qqo7iUyAgAAeRYCAAAL2gIAABaeA
  • Thread-topic: [PATCH] Fix error: array subscript has type 'char' [and 1 more messages]

> On Jan 27, 2021, at 4:32 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> On 27.01.2021 17:21, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char' 
>> [and 1 more messages]"):
>>> I don't think I've ever come across that part of a platform
>>> API/ABI spec. Instead my understanding so far was that good
>>> platform headers would be ignorant of the user's choice of
>>> char's signed-ness (wherever compilers offer such a choice,
>>> but I think all that I've ever worked with did). At the very
>>> least gcc's doc doesn't warn about any possible
>>> incompatibilities resulting from use of -fsigned-char or
>>> -funsigned-char (or their bitfield equivalents, for that
>>> matter).
>> Well, I've considered this and I still don't think changing to
>> -funsigned-char is good idea.
>> Are you OK with me checking in the current patch or should I ask the
>> other committers for a second opinion ?
> For the changes to tools/ it's really up to you. For the change
> to xen/tools/symbols.c I could live with it (for being user
> space code), but I still think adding casts in such a place is
> not necessarily setting a good precedent. So for this one I'd
> indeed appreciate getting another opinion.

My thoughts:

* On the whole, the risk of an incompatibility with system headers does seem 
higher than the risk of casting a value which is known not to be EOF

* Such a change doesn’t seem like the kind of thing we should ask Manuel to do, 
when a simpler change will do the trick

* At any rate it doesn’t seem like a good thing to experiment with in the week 
before the feature freeze.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.