Re: Intel icc finds too many errors in guile 1.8.8 to compile

[Ludovic Courtès]

Hello,

Neil Jerram <address@hidden> writes:

> Thanks for your comments below.  I should have posted this change for
> review first, so apologies for not doing that.

No problem.  :-)

> Maybe yes.  But on the other hand (and arguing from common sense instead
> of from the standards) there surely has to be some point - in terms of
> allowing the compiler to spot mistakes - of using an enum instead of
> plain constants?

I agree.  Adding a named constant for 0 is one way to help the compiler
spot such mistakes.

>> I think having disjoint ‘scm_t_wind_flags’ and ‘scm_t_dynwind_flags’
>> types was helpful to indicate which flags are valid for which function.
>> Thus, I’d rather have fixed it by adding a named enumeration constant
>> for 0 in each of these types.
>
> The use of an enum for combinable bit flags is actually new to me,

We had:

  typedef enum {
    SCM_F_DYNWIND_REWINDABLE = (1 << 0)
  } scm_t_dynwind_flags;

  typedef enum {
    SCM_F_WIND_EXPLICITLY = (1 << 0)
  } scm_t_wind_flags;

There’s only one value for each type, so these flags are not combinable
in practice.

So these could become, say:

  enum scm_dynwind_flags
  {
    SCM_F_DYNWIND_NOT_REWINDABLE = 0,
    SCM_F_DYNWIND_NOT_REWINDABLE
  };

  typedef enum scm_dynwind_flags scm_t_dynwind_flags;

  enum scm_wind_flags
  {
    SCM_F_WIND_NON_LOCAL_EXIT = 0,
    SCM_F_WIND_EXPLICITLY
  };

  typedef enum scm_wind_flags scm_t_wind_flags;

Does it make sense?

Thanks,
Ludo’.