[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature request
From: |
Dirk Herrmann |
Subject: |
Re: feature request |
Date: |
Thu, 24 May 2001 12:14:07 +0200 (MEST) |
On Sun, 20 May 2001, Han-Wen Nienhuys wrote:
> Since you're planning a new release, can I pretty-please ask you to
> remove the comments around
>
> /* #define SCM_VOIDP_TEST */
>
> and change the definition for SCM from
>
> typedef void * SCM;
>
> to
>
> typedef struct SCM_UNUSED_STRUCT { } * SCM;
>
>
> The latter catches more errors (eg. implicit conversions from
> character strings.)
I like your suggestion, however, it would be better if we could write
typedef struct SCM_UNUSED_STRUCT * SCM;
(suggested by Marius) and never define SCM_UNUSED_STRUCT. Thus, you would
even catch implicit conversions from "struct { }" types. I have to admit,
though, that I don't know whether that would be legal ANSI C.
I just checked that guile compiles and links with
typedef struct SCM_UNUSED_STRUCT * SCM;
without ever defining SCM_UNUSED_STRUCT, but it would be nice if someone
could confirm that this is valid ANSI C.
If so, I will apply that patch, if not so, I will apply Han-Wen's original
suggestion. However, I intend to get rid of SCM_VOIDP_TEST and instead
distinguish between three possible values for SCM_DEBUG_TYPING_STRICTNESS:
2: typedef union { struct { scm_bits_t n; } n; } SCM;
(This one does not produce sensible code, but it catches _all_
type mismatches when using SCM.)
1: typedef struct scm_unused_struct * SCM;
(This or Han-Wen's original suggestion will be the default. It
catches most type mismatches, but does not compromise code
efficiency on any sane compiler.)
0: typedef scm_bits_t SCM;
(People having difficulties to get guile compiled with one of the
above values, or which encounter performance drawbacks can use this
setting.)
Best regards,
Dirk Herrmann
- feature request, Han-Wen Nienhuys, 2001/05/20
- Re: feature request,
Dirk Herrmann <=
- Re: feature request, Dirk Herrmann, 2001/05/27
- Re: feature request, Rob Browning, 2001/05/28
- Re: feature request, Lars J. Aas, 2001/05/28
- Re: feature request, Jacques A. Vidrine, 2001/05/28
- Re: feature request, Dirk Herrmann, 2001/05/28
- Re: feature request, Jacques A. Vidrine, 2001/05/28
- Re: feature request, Dirk Herrmann, 2001/05/29
- Re: feature request, Michael Livshin, 2001/05/29