Could the warning not simply be switched off and on (or set to some kind of
level) by a {$... line ?
It is on the to-do list already. However, I don't think it'll be the end
of the discussions; there will always be tension between the compiler
being helpfull to signal dubious code, and
Op Thu, 18 Oct 2007, schreef Adriaan van Os:
> Daniël Mantione wrote:
> >
> > Op Mon, 15 Oct 2007, schreef Michael Schnell:
> >
> > > > So I guess the warning stays. We can discuss some extensions
> > > > which makes
> > > > it easier to code such restrictions like merging parts of the tue
> >
So I guess the warning stays. We can discuss some extensions which makes
it easier to code such restrictions like merging parts of the tue branch.
>>> Could the warning not simply be switched off and on (or set to some kind of
>>> level) by a {$... line ?
>>
>> It is on the to-do lis
Daniël Mantione wrote:
Op Mon, 15 Oct 2007, schreef Michael Schnell:
So I guess the warning stays. We can discuss some extensions which makes
it easier to code such restrictions like merging parts of the tue branch.
Could the warning not simply be switched off and on (or set to some kind of
Op Mon, 15 Oct 2007, schreef Michael Schnell:
>
> > So I guess the warning stays. We can discuss some extensions which makes
> > it easier to code such restrictions like merging parts of the tue branch.
> >
> Could the warning not simply be switched off and on (or set to some kind of
> level)
So I guess the warning stays. We can discuss some extensions which makes
it easier to code such restrictions like merging parts of the tue branch.
Could the warning not simply be switched off and on (or set to some kind
of level) by a {$... line ?
-Michael
_
Florian Klaempfl wrote:
~> gcc -c test.c
test.c: In function ‘f’:
test.c:3: warning: comparison is always false due to limited range of
data type
test.c:3: warning: comparison is always false due to limited range of
data type
Yes, very annoying in gcc as well. It also warns when a variable is
Micha Nelissen schrieb:
> Peter Vreman wrote:
>> There is a good reason for that the unreachable code is a warning: The
>> compiler _changes_ your
>> code by removing the if-branch. When it is a hint the compiler only
>> has recognized a pattern, but
>> it does not modify anything.
>
> It "changes
Peter Vreman wrote:
There is a good reason for that the unreachable code is a warning: The compiler
_changes_ your
code by removing the if-branch. When it is a hint the compiler only has
recognized a pattern, but
it does not modify anything.
It "changes" it, but semantically it's the same rig
>> Maybe it would better be a hint.
>
> Seems reasonable to me.
>
> The unused parameter hint is likewise also unavoidable with function
> callback implementations sometimes.
There is a good reason for that the unreachable code is a warning: The compiler
_changes_ your
code by removing the if-bra
Joao Morais wrote:
Remove the comment and the note is also removed.
sed 's/^Remove.*//'
--
Joao Morais
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Florian Klaempfl wrote:
Joao Morais schrieb:
The compiler warns that the result wasn't assigned, but that function's
result simply cannot be reached.
Fixed in trunk when compiled with -Oodfa which will be probably a
default in 2.4.0.
Thanks. Now a note:
{$mode objfpc}
var
vobj: tclass;
Micha Nelissen wrote:
Joao Morais wrote:
The compiler warns that the result wasn't assigned, but that function's
result simply cannot be reached.
Why not make it a procedure ?
Because it is an abstract method.
--
Joao Morais
___
fpc-devel maillist
Joao Morais wrote:
> The compiler warns that the result wasn't assigned, but that function's
> result simply cannot be reached.
Why not make it a procedure ?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mai
Joao Morais schrieb:
> Daniël Mantione wrote:
>> The warning is fixable: Remove the superfluous check.
>
> All,
>
> a new contribution to this theme. What about this warning:
>
> {$mode objfpc}
> uses sysutils;
> function testresult: boolean;
> begin
> raise exception.create('foo');
> end;
> b
Jonas Maebe wrote:
>
> Maybe it would better be a hint.
Seems reasonable to me.
The unused parameter hint is likewise also unavoidable with function
callback implementations sometimes.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
Daniël Mantione wrote:
The warning is fixable: Remove the superfluous check.
All,
a new contribution to this theme. What about this warning:
{$mode objfpc}
uses sysutils;
function testresult: boolean;
begin
raise exception.create('foo');
end;
begin
testresult;
end.
The compiler warns tha
Florian Klaempfl wrote:
>> Maybe it would better be a hint.
>
> With the same reasoning you could make every warning a hint. Instead of
> if one usually uses asserts to check certain conditions.
Most are about bad code, that can be made better, AFAIK. E.g. 'an
inherited method is hidden' needs a
On 14 Oct 2007, at 22:25, Florian Klaempfl wrote:
Jonas Maebe schrieb:
On 14 Oct 2007, at 22:06, Daniël Mantione wrote:
I can follow your reasoning why you want the dead code, but on
the other
hand the warning is there with good reason.
Maybe it would better be a hint.
With the same r
Jonas Maebe schrieb:
>
> On 14 Oct 2007, at 22:06, Daniël Mantione wrote:
>
>> I can follow your reasoning why you want the dead code, but on the other
>> hand the warning is there with good reason.
>
> Maybe it would better be a hint.
With the same reasoning you could make every warning a hint
On 14 Oct 2007, at 22:06, Daniël Mantione wrote:
I can follow your reasoning why you want the dead code, but on the
other
hand the warning is there with good reason.
Maybe it would better be a hint.
Jonas___
fpc-devel maillist - fpc-devel@list
Op Sun, 14 Oct 2007, schreef Micha Nelissen:
> Daniël Mantione wrote:
> >> A warning should always be fixable and doing so, turning it into correct
> >> code. The compiler is simply wrong here; my code is correct, so it
> >> should not complain.
> >
> > The warning is fixable: Remove the superf
Daniël Mantione wrote:
>> A warning should always be fixable and doing so, turning it into correct
>> code. The compiler is simply wrong here; my code is correct, so it
>> should not complain.
>
> The warning is fixable: Remove the superfluous check.
Sigh. That's my point. If you were using small
Op Sun, 14 Oct 2007, schreef Micha Nelissen:
> Daniël Mantione wrote:
> > It is justified to warn, since in some cases an error situation can occur
> > but the way the check is written causes a dead code check. We found a few
> > of these in the compiler sources.
>
> A warning should always b
Daniël Mantione wrote:
> It is justified to warn, since in some cases an error situation can occur
> but the way the check is written causes a dead code check. We found a few
> of these in the compiler sources.
A warning should always be fixable and doing so, turning it into correct
code. The co
Op Sun, 14 Oct 2007, schreef Micha Nelissen:
> Hi,
>
> I want to bring up the warning of unreachable code. If one is
> implementing code according to some spec, e.g. RFC, or what else, it
> occurs that that requires a sanity check on user input. If it now
> happens that the type of variable by
Hi,
I want to bring up the warning of unreachable code. If one is
implementing code according to some spec, e.g. RFC, or what else, it
occurs that that requires a sanity check on user input. If it now
happens that the type of variable by accident guarantees that this is
true; this is fine, the com
27 matches
Mail list logo
