> I believe these 4 pieces of code should result in a compile-time
> WARNING, because their effect is specified to be implementation-
> dependent and won't do what one probably wants across all
> implementations.
I don't. I think there's value for sbcl to distinguish some unportable
code scenarios, but "implementation-dependent" is a long, long way away
From "undefined consequences", which is what has normally triggered a
compile-time WARNING. Consider: what if you actually /want/ to write
this code? How do you tell the system "yes, I know what I'm doing?".
(This is in contrast with the "undefined consequences" situation, where
there is no way in fact that the writer of code causing undefined
consequences really knows what they are doing).
Jean-Philippe Paradis <email address hidden> writes:
> I believe these 4 pieces of code should result in a compile-time
> WARNING, because their effect is specified to be implementation-
> dependent and won't do what one probably wants across all
> implementations.
I don't. I think there's value for sbcl to distinguish some unportable -dependent" is a long, long way away
code scenarios, but "implementation
From "undefined consequences", which is what has normally triggered a
compile-time WARNING. Consider: what if you actually /want/ to write
this code? How do you tell the system "yes, I know what I'm doing?".
(This is in contrast with the "undefined consequences" situation, where
there is no way in fact that the writer of code causing undefined
consequences really knows what they are doing).
Christophe