[fpc-devel] Unreachable code warnings

2007-10-14 Thread 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 accident guarantees that this is
true; this is fine, the compiler might optimize the check away. The
compiler should not give a warning though IMHO, because the check is
necessary according to spec, and it might become necessary if someone
decides to change the type of the variable being checked to have a wider
range. Furthermore, the warning is not suppressible.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Daniël Mantione


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 accident guarantees that this is
 true; this is fine, the compiler might optimize the check away. The
 compiler should not give a warning though IMHO, because the check is
 necessary according to spec, and it might become necessary if someone
 decides to change the type of the variable being checked to have a wider
 range. Furthermore, the warning is not suppressible.

You mean this:

var b:byte;
f:file;

begin
  {...}
  blockread(f,b,sizeof(b))l
  if (b0) or (b255) then
begin
  writeln('Error: Invalid value');
  halt(255);
end;
  {...}
end;

IMO the compiler in the case above totally correct to let you know the 
error condition can never occur. Even if a specification says 255 is the 
maximum, the code is totally bogus.

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.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] New BeOS patchs

2007-10-14 Thread Olivier Coursiere

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 critical fpc 2.2.0 release rush :-)
It should be apply too as there is some missing files (available here : 
http://olivier.coursiere.free.fr/diff/beos_r8398.diff).


Here is the content of this older patch :
- rtl/beos/i386/sighnd.inc
- packages/base/pthreads/pthrbeos.inc (basically a verbatim copy of the 
bsd one, just to compile as pthread support is limited under BeOS)

- utils/fppkg/Makefile.fpc

Olivier
Index: i_beos.pas
===
--- i_beos.pas	(revision 8756)
+++ i_beos.pas	(working copy)
@@ -33,7 +33,7 @@
 name : 'Beos for i386';
 shortname: 'Beos';
 flags: [tf_under_development,tf_needs_symbol_size,tf_files_case_sensitive,tf_use_function_relative_addresses,
-tf_smartlink_library];
+tf_smartlink_sections, tf_smartlink_library];
 cpu  : cpu_i386;
 unit_env : 'BEOSUNITS';
 extradefines : 'UNIX;HASUNIX';
Index: t_beos.pas
===
--- t_beos.pas	(revision 8756)
+++ t_beos.pas	(working copy)
@@ -279,8 +279,8 @@
  if prtobj'' then
   LinkRes.AddFileName(FindObjectFile(prtobj,'',false));
 
- if isdll then
-  LinkRes.AddFileName(FindObjectFile('func.o','',false));
+// if isdll then
+//  LinkRes.AddFileName(FindObjectFile('func.o','',false));
 
  if librarysearchpath.FindFile('init_term_dyn.o',false,s) then
   LinkRes.AddFileName(s);
@@ -361,9 +361,10 @@
 function TLinkerBeOS.MakeExecutable:boolean;
 var
   binstr,
-  cmdstr  : TCmdStr;
+  cmdstr : TCmdStr;
   success : boolean;
   DynLinkStr : string[60];
+  GCSectionsStr,
   StaticStr,
   StripStr   : string[40];
 begin
@@ -374,10 +375,16 @@
   StaticStr:='';
   StripStr:='';
   DynLinkStr:='';
+  GCSectionsStr:='';
   if (cs_link_staticflag in current_settings.globalswitches) then
StaticStr:='-static';
   if (cs_link_strip in current_settings.globalswitches) then
StripStr:='-s';
+
+  if (cs_link_smart in current_settings.globalswitches) and
+ (tf_smartlink_sections in target_info.flags) then
+  GCSectionsStr:='--gc-sections';
+
   If (cs_profile in current_settings.moduleswitches) or
  ((Info.DynamicLinker'') and (not SharedLibFiles.Empty)) then
begin
@@ -398,6 +405,7 @@
   Replace(cmdstr,'$RES',maybequoted(outputexedir+Info.ResName));
   Replace(cmdstr,'$STATIC',StaticStr);
   Replace(cmdstr,'$STRIP',StripStr);
+  Replace(cmdstr,'$GCSECTIONS',GCSectionsStr);
   Replace(cmdstr,'$DYNLINK',DynLinkStr);
   success:=DoExec(FindUtil(utilsprefix+BinStr),CmdStr,true,true);
 
@@ -412,7 +420,8 @@
 Function TLinkerBeOS.MakeSharedLibrary:boolean;
 var
   binstr,
-  cmdstr  : TCmdStr;
+  cmdstr,
+  SoNameStr : TCmdStr;
   success : boolean;
   DynLinkStr : string[60];
   StaticStr,
@@ -443,14 +452,18 @@
 { Write used files and libraries }
   WriteResponseFile(true,true);
 
+  SoNameStr:='-soname '+ExtractFileName(current_module.sharedlibfilename^);
+
 { Call linker }
   SplitBinCmd(Info.DllCmd[1],binstr,cmdstr);
-  Replace(cmdstr,'$EXE',maybequoted(current_module.exefilename^));
+  Replace(cmdstr,'$EXE',maybequoted(current_module.sharedlibfilename^));
   Replace(cmdstr,'$OPT',Info.ExtraOptions);
   Replace(cmdstr,'$RES',maybequoted(outputexedir+Info.ResName));
   Replace(cmdstr,'$STATIC',StaticStr);
   Replace(cmdstr,'$STRIP',StripStr);
   Replace(cmdstr,'$DYNLINK',DynLinkStr);
+  Replace(cmdstr,'$SONAME',SoNameStr);
+
   success:=DoExec(FindUtil(utilsprefix+binstr),cmdstr,true,true);
 
 { Strip the library ? }
Index: ptypes.inc
===
--- ptypes.inc	(revision 8793)
+++ ptypes.inc	(working copy)
@@ -45,6 +45,7 @@
 gid_t= cuint32; { used for group IDs   }
 TGid = gid_t;
 pGid = ^gid_t;
+TIOCtlRequest = cuLong;
 
 ino_t= clonglong;   { used for file serial numbers }
 TIno = ino_t;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread 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 superfluous check.

Sigh. That's my point. If you were using smallint before, and someone
changes the type to integer, then a bug is introduced; so you don't want
to remove the check but the compiler can of course optimize it away.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Daniël Mantione


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 superfluous check.
 
 Sigh. That's my point. If you were using smallint before, and someone
 changes the type to integer, then a bug is introduced; so you don't want
 to remove the check but the compiler can of course optimize it away.

A solution is to make a dedicated type, and write down comments near its 
declaration.

If you remove the warning, code like:

if ahigh(a) then

... no longer warns, which results in dead code in many situations.

I can follow your reasoning why you want the dead code, but on the other 
hand the warning is there with good reason.

Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Jonas Maebe


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@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Florian Klaempfl
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. Instead of
if one usually uses asserts to check certain conditions.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Jonas Maebe


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 reasoning you could make every warning a hint.


I don't think so. While there may be false uninitialised warnings  
(because the compiler simply missed the initialisation somehow),  
every use of an uninitialised variable is an error.


However, not every case of an if-expression which can evaluated at  
compile time is an error. I even don't think the majority is.



Instead of
if one usually uses asserts to check certain conditions.


These constructions can also be used instead of ifdefs, even though  
ifdefs are probably also more often used. Using if's instead is   
however not wrong imho.



Jonas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Micha Nelissen
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 'override;' or 'reintroduce;'.

Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Micha Nelissen
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
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Florian Klaempfl
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;
 begin
   testresult;
 end.
 
 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Micha Nelissen
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/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Joao Morais

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  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Joao Morais

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;
  vmethod: function: string of object;
begin
  vobj := tobject;
  vmethod := @vobj.classname;
  writeln(vmethod);
end.

Remove the comment and the note is also removed.

--
Joao Morais
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Unreachable code warnings

2007-10-14 Thread Joao Morais

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