[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Intel icc finds too many errors in guile 1.8.8 to compile
From: |
Ludovic Courtès |
Subject: |
Re: Intel icc finds too many errors in guile 1.8.8 to compile |
Date: |
Sun, 04 Oct 2009 14:26:38 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
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’.