Hi,

You guessed it: I've applied another patch :-), rev 4823.

I've reverted the 'enable {$T+} for fpc/objfpc modes' bit. So now all your sources will compile as they previously did. Enabling did catch a bug here and there, but also caused at least one (typinfo).

I propose to enable it for 2.3/2.9, i.e. after 2.2, because, as Jonas said, it breaks semantics for arithmetic on non-typecasted pointers that point to something that is not size 1.

To that end, the compiler will now warn you of possible {$T+}-breaking code: when you do arithmetic on an untyped pointer. Tests tbf/tb0182, tbf/tb0183, and tbs/tb0504 test the proper working of this warning.

Micha

Micha Nelissen wrote

I propose to enable it for 2.3/2.9, i.e. after 2.2, because, as Jonas said, it breaks semantics for arithmetic on non-typecasted pointers that point to something that is not size 1.

How will this change after 2.2?

To that end, the compiler will now warn you of possible {$T+}-breaking code: when you do arithmetic on an untyped pointer. Tests tbf/tb0182, tbf/tb0183, and tbs/tb0504 test the proper working of this warning.

I don't like this. There is nothing wrong with pointer arithmetic on untyped pointers. At most it should be a hint, although even that is doubtful in my eyes since there really is no error. It's a bit similar to giving hints/warning for discarding function results in {$x +} mode, because doesn't work in {$x-} mode (but worse, since pointer arithmetic on untyped pointers in {$t-} mode is by no means always wrong in {$t+} mode and it forces people to add useless typecasts whenever they declare a plain variable as pointer and perform calculations on it).

Jonas

Op Sun, 8 Oct 2006, schreef Jonas Maebe:

Just my opinion, but I think there is. You don't know the size of the object it is pointing to, so you should not be able to do arithmetic on it.

Daniël

I think the construct
@var+1
is dangerous because
- its pointer magic (always not good ;))
- its behaviour depends on T+/-

Making it pointer(@var)+1 clarifies things.

That's true. I did not look at the code changes in the compiler, only at the log message:

add warning for arithmetic on untyped pointers

As far as I can see, what's been done is actually:

add warning for arithmetic on non-typecasted @-expressions

I don't have a problem with that. One thing which still should be changed about the patch is that nf_typedaddr should also be included for nf_internal type conversions (and the code style should conform to the one used in the rest of the modified units, i.e. "end" and "else" should be on a different line).

Jonas

My reasoning was that a typecasted pointer is always a typed pointer, since you have given it a type explicitly.

I don't have a problem with that. One thing which still should be changed about the patch is that nf_typedaddr should also be included for nf_internal type conversions (and the code style should conform to the

Yes, was not sure about when implicit type conversions are done and whether it would be appropriate to 'tag' them with typedaddr flag.

one used in the rest of the modified units, i.e. "end" and "else" should be on a different line).

The indenting is by no means consistent anyway :P. But I'll try to keep it in mind for the future.

Micha

Hmm? I think it's a good idea to enable {$T+} for fpc and objfpc mode somewhere in the future, since it also caught some bugs in our code. However, enabling it now may mean bugs, so we allow some 'grace-time' in which people can fix their code, so that it will work as expected in {$T+}; typically 1 major version.

Micha

nf_internal typecasts are explicit typecasts inserted by the parser. They are basically even more explicit than user-explicit typecasts, and also allowed in more cases.

The indenting is by no means consistent anyway :P.

I think it is quite consistent in most main units on which many people work (including the parser, scanner and type checking).

Jonas

Jonas Maebe wrote

nf_internal typecasts are explicit typecasts inserted by the parser. They are basically even more explicit than user-explicit typecasts, and also allowed in more cases.

Can you give a typical example ? It's probably very logical, but I'm not sure what typecasts are so explicitly implicitly allowed ;-).

Micha