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
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,
Here are two little patchs for the BeOS port of FPC :
- compiler_systems_r8756.diff reenable creating shared object using the
libc based rtl. I have also added gc-sections support.
- rtl_beos_ptypes.inc fix a compilation error since a recent change.
A previous one was forgotten in the crit
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
Olivier Coursiere schrieb:
> Hi,
>
> Here are two little patchs for the BeOS port of FPC :
Thanks, applied.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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:
>> 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:
> >> 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
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
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: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
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
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
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
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
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
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
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;
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
Hi!
As some know.. CompactSysutils contains many functions for embedded or CGI
programmers to use when they don't wish to use full sysutils unit. i.e. anyone
looking for smaller footprint executable.
I've partly described it here:
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=CompactUtils-and-Compa
>> 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
Op Mon, 15 Oct 2007, schreef L:
> Hi!
>
> As some know.. CompactSysutils contains many functions for embedded or CGI
> programmers to use when they don't wish to use full sysutils unit. i.e. anyone
> looking for smaller footprint executable.
> I've partly described it here:
> http://z505.com
22 matches
Mail list logo