Checking the validity of Format and friends at compile-time

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Checking the validity of Format and friends at compile-time

Michalis Kamburelis-3
Hi,

I'm wondering if there is a tool that checks the correctness of calls
to Format and friends (like Exception.CreateFmt) in your code. Or does
someone plan to write one, as an external tool (like a "lint") or
inside the FPC compiler:)

For example, the call

  Format('%s', [123])

is guaranteed to result in an EConvertError at runtime. But nothing at
compile-time detects or warns about it.

Sure, it's not possible to check all cases of Format usage, as you can
construct the Format pattern (or list of arguments) at runtime. You
can also replace resourcestrings at runtime. Still, such tool would be
useful since (at least in my code) the majority or Format calls have
constant strings and could be checked at parse time.

The tool would have to know which routines have Format-like parameters
(and at which positions), to capture Format, and Exception.CreateFmt
(and I have a couple of more in my own units). They could be marked in
the source code, by some special directive or a special comment, or
the checking tool should just know their names.

Such tool seems useful for me. It would at least catch *some* blatant
errors, that otherwise sleep undetected until runtime. E.g. today I
have a bugreport that user observed an EConvertError in my program
(unfortunately, he cannot write more exactly what is the message, or
send a screenshot...). I suspect the bug is in one of my Format or
EXxx.CreateFmt calls, but I have a lot of them. Most of them have
constant pattern (and a list of arguments with size and types known at
compile-time), so it should be possible to run some kind of "lint" on
my code... except I don't have any:)

Does anyone know of such a tool?

If you don't have a good answer, I may implement it myself:) I'd like
to use fcl-passrc for it, but so far it fails to parse my real-life
code in Castle Game Engine:) I submitted a couple of bugreports about
it today.

Regards,
Michalis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Sven Barth-2

Am 05.10.2016 04:33 schrieb "Michalis Kamburelis" <[hidden email]>:
>
> Hi,
>
> I'm wondering if there is a tool that checks the correctness of calls
> to Format and friends (like Exception.CreateFmt) in your code. Or does
> someone plan to write one, as an external tool (like a "lint") or
> inside the FPC compiler:)

I don't know of any tool, but something like this definitely wouldn't become part of the compiler as that would mean an unnecessarily tight coupling between compiler and RTL not to mention that user code that uses "array of const" wouldn't necessarily benefit from it.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Maciej Izak
In reply to this post by Michalis Kamburelis-3

2016-10-05 4:32 GMT+02:00 Michalis Kamburelis <[hidden email]>:
For example, the call

  Format('%s', [123])

I have a small hint (instead of answer). We have in mORMot / NewPascal in SynCommons module nice function which works perfect in most of cases:

FormatUTF8('%', [123], []); // same string '%' works for both: integer and string values
FormatUTF8('%', ['123'], []);

Documentation: 

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Michael Schnell
In reply to this post by Sven Barth-2
On 05.10.2016 07:59, Sven Barth wrote:
> something like this definitely wouldn't become part of the compiler as
> that would mean an unnecessarily tight coupling between compiler and
> RTL not to mention that user code that uses "array of const" wouldn't
> necessarily benefit from it.
GNU C does check this when using printf() and friends, and rather
obviously the "array of const" is modeled after the C ellipse notation.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Michalis Kamburelis-3
In reply to this post by Maciej Izak
2016-10-05 9:00 GMT+02:00 Maciej Izak <[hidden email]>:

>
> 2016-10-05 4:32 GMT+02:00 Michalis Kamburelis <[hidden email]>:
>>
>> For example, the call
>>
>>   Format('%s', [123])
>
>
> I have a small hint (instead of answer). We have in mORMot / NewPascal in
> SynCommons module nice function which works perfect in most of cases:
>
> FormatUTF8('%', [123], []); // same string '%' works for both: integer and
> string values
> FormatUTF8('%', ['123'], []);
>

That's a cool improvement. No need to write the type, so one less
thing that can go wrong:) I seldom use non-standard formats anyway
(like %g instead of %f for floats).

Still, you can use an invalid number of arguments for FormatUTF8. So
you still have this uncomfortable feeling that "it's only checked at
runtime, while it could be checked earlier at lint / compile phase" :)

I'm leaning toward implementing a simple pascal-lint tool myself,
using the fcl-passrc. But to make it really useful on my real code,
I'll need some fixes to fcl-passrc first:)

Regards,
Michalis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Marco van de Voort
In reply to this post by Michael Schnell
In our previous episode, Michael Schnell said:
> > RTL not to mention that user code that uses "array of const" wouldn't
> > necessarily benefit from it.
> GNU C does check this when using printf() and friends, and rather
> obviously the "array of const" is modeled after the C ellipse notation.

But array of const is safe, and C's isn't, which is why C compilers routinely
check it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Checking the validity of Format and friends at compile-time

Santiago A.
In reply to this post by Michalis Kamburelis-3
El 05/10/2016 a las 19:47, Michalis Kamburelis escribió:

> 2016-10-05 9:00 GMT+02:00 Maciej Izak <[hidden email]>:
>> 2016-10-05 4:32 GMT+02:00 Michalis Kamburelis <[hidden email]>:
>>> For example, the call
>>>
>>>   Format('%s', [123])
>>
>> I have a small hint (instead of answer). We have in mORMot / NewPascal in
>> SynCommons module nice function which works perfect in most of cases:
>>
>> FormatUTF8('%', [123], []); // same string '%' works for both: integer and
>> string values
>> FormatUTF8('%', ['123'], []);
>>
> That's a cool improvement. No need to write the type, so one less
> thing that can go wrong:) I seldom use non-standard formats anyway
> (like %g instead of %f for floats).

I don't agree. You are asking for a compile time check, but now you
accept skipping run time type check doing a automatic type conversion.
Things can go as wrong as with classic format but, without runtime error
or exception, hunting bugs is more difficult.  I support your first
idea: Compile time check.

I haven't understand very well whether Sven Barth's reluctance is a
matter of taste or whether there are serious technical reasons. If there
are not severe design drawbacks, I would go for it. I love compile time
checks. The more, the better.

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal