Re: [ECOS] Re: casts to a type other than an integral or enumerationtype in a constant-expression

[Jonathan Larmour <jifl at eCosCentric dot com>]

Andreas Schwab wrote:
> Fred Fish <fnf@public.ninemoons.com> writes:
>
> |> The latest eCos sources no longer build with the latest gcc.  The
> |> problem can be tracked down to C++ code like the following in eCos:
> |> 
> |>   #include <signal.h>
> |> 
> |>   void foo (__sighandler_t __sighdl)
> |>   {
> |>     switch ((int) __sighdl)
> |>       {
> |>       case (int) SIG_DFL:
> |>         ;
> |>       case (int) SIG_IGN:
> |>         ;
> |>       }
> |>   }
>
> This code is completely bogus anyway, even if it might be valid.  Casting
> a pointer to int is dubious at best and will fail miserably if sizeof
> (__sighandler_t) > sizeof (int).
Assuming I'm thinking of the right bit of code, Fred was paraphrasing the 
code. The "int" is actually an eCos typedef set by the hardware 
abstraction layer so _will_ be correct for the hardware.

The warning is certainly misleading at best as an int is certainly an 
integral type ;-). From a quick read of the C++ standard, I can't see any 
problem with this code.

I will change the eCos code to use if/else instead because I'd rather it 
was compatible with the release of gcc since that isn't going to start 
working for a while. But you gcc folks can fix the problem anyway :-).

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss