[PATCH] score: _Objects_Build_name() signed/unsigned char

[Gedare Bloom]

On Tue, Feb 2, 2021 at 9:44 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 02/02/2021 17:22, Gedare Bloom wrote:
>
> > OK. This one surprised me (and I'm sure I'm not the only one.)
> >
> > On Tue, Feb 2, 2021 at 7:42 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >
> >     Change _Objects_Build_name() so that the result is independent of the
> >     signedness of char.
> >
> >     Close #4228.
> >
> I don't think it is practically an issue, however, if you want to
> specify this function, then it gets a problem. You would have to write
> something like: Where the char is signed, ...
>
>
Maybe. I wrote a simple program because I was curious about this behavior.
int main(int argc, char *argv[])
{
  unsigned char a = 0xff;
  signed char b = 0xff;

  printf("(uint32_t)a: %u\n(uint32_t)b %u\n", (uint32_t)a, (uint32_t)b);

  printf("(uint32_t)(uint8_t)a: %u\n(uint32_t)(uint8_t)b %u\n",
      (uint32_t)(uint8_t)a, (uint32_t)(uint8_t)b);

  return 0;
}

$ ./a.out
(uint32_t)a: 255
(uint32_t)b 4294967295
(uint32_t)(uint8_t)a: 255
(uint32_t)(uint8_t)b 255


So, you would get some maybe unpleasant behavior if you have a signed char
in the less-significant bytes that you end up sign-extending through the
more significant bytes.



> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210202/6b4faf26/attachment.html>