[email protected] (Ludovic Courtès) writes:
>> But wouldn't this approach break as soon as we added another flag, in
>> the way that I described in my previous email?
>
> Yes it would.
>
> But the underlying question is: is the set of flags likely to change?
> If the answer is “no” (which I think it is), it’s probably safe to go
> for an ‘enum’, as these flags cannot be combined anyway.
Hmm. I think that's quite inelegant, to use a representation of flags
that would break if there was ever more than one flag (!).
I was going to conclude "So I'll revert my change and just add the zero
value instead", but then I wondered if we have any clear reason to
believe that that would help ICC. There are several occurrences in
libguile of scm_dynwind_begin (0), and ICC could still complain, and
only be happy with scm_dynwind_begin (SCM_F_DYNWIND_NO_FLAGS).
So instead I'll just revert my change, and wait until we get more data
that a possible solution actually works for ICC.
Inge, if you're following this, can you try changing the enum
definitions to
typedef enum {
SCM_F_DYNWIND_NO_FLAGS = 0,
SCM_F_DYNWIND_REWINDABLE = (1 << 0)
} scm_t_dynwind_flags;
typedef enum {
SCM_F_WIND_NO_FLAGS = 0,
SCM_F_WIND_EXPLICITLY = (1 << 0)
} scm_t_wind_flags;
and report if that removes the related ICC errors?
Thanks,
Neil
