[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shouldn't we be developing with TYPING_STRICTNESS=2?
From: |
Dirk Herrmann |
Subject: |
Re: Shouldn't we be developing with TYPING_STRICTNESS=2? |
Date: |
Thu, 13 Sep 2001 23:10:31 +0200 (MEST) |
On Thu, 13 Sep 2001, Rob Browning wrote:
> (or at least testing regularly?)
The point is, that you can't generate actual code with
TYPING_STRICTNESS=2. See below for an explanation.
> And as an orthogonal question, is guile supposed to work on 64 bit
> archs right now?
I don't know. However, I think there is a lot of code in guile that is
not very strict with respect to typing.
> While trying to check up on the ia64 bug, I turned typing strictness
> up to 2, and I notice a lot of suspicious code. For example, in
> backtrace.c, there are lots of
>
> (foo == *bar)
>
> where foo and *bar are SCM's.
I will fix these.
> Also, there's a call like this
>
> if (SCM_EQ_P (SCM_SHOW_FILE_NAME, sym_base))
>
> which fails because SCM_SHOW_FILE_NAME grabbs a scm_t_option's val,
> but that's unconditionally defined to be an "unsigned long", rather
> than an SCM.
That is a problem with the implementation of the options. We could
probably add some hacks to macros like SCM_SHOW_FILE_NAME as a workaround,
but I would prefer the options implementation to be revised. We should,
however, don't add hacks for the compilation with TYPING_STRICTNESS=2,
since (as I will explain below) you can't generate code for it anyway.
> We've also got some "pointer fits in int" assumptions... i.e.
>
> in error.c:
>
> int error = (int) pos;
>
> causes a warning -- pos is a cptr. You can fix it with ((int) (long)
> pos), but isn't there something more portable, or is long always
> guaranteed to be large enough for a ptr?
Hmmm. Isn't intptr_t meant to fulfill that requirement?
> and in eval.c, some bigger problems (though they may be known):
>
> eval.c:1291: case label does not reduce to an integer constant
> eval.c:1294: case label does not reduce to an integer constant
> eval.c:1297: case label does not reduce to an integer constant
These error messages are the reason why the generation of code with
TYPING_STRICTNESS=2 is not possible. The trick with TYPING_STRICTNESS set
to 2 is to define SCM as a struct. This makes all of C's implicit type
conversions impossible and is the reason why this mode allows the best
possible type checking by the compiler. However, if SCM is a struct this
means that constants like SCM_BOOL_T are also structs. And, you can't use
structs as case labels. There are some other places in which C does not
allow structs - initializations are a problem as well. You can't declare
a variable as " SCM foo = SCM_BOOL_F " if SCM_BOOL_F is a struct.
(This is, simplified, the explanation.) However, why to we have
TYPING_STRICTNESS=2 then? The point is, that this mode detects a lot of
potential problems with typing in ordinary code. We have to live with the
fact that other code will not compile in that mode.
> Presuming our tests in tags.h actually do some good, it might be wise
> for people to develop with typing strictness set to 2, and then turn
> it down for the release. I also believe that developing with
> --enable-error-on-warning would be wise.
Well, for normal development typing strictness set to 1 should be
sufficient. However, from time to time a compilation with
TYPING_STRICTNESS=2 should be done, especially with an upcoming release.
Best regards
Dirk Herrmann