Re: [fpc-devel] Re: compiler bug?

2004-12-31 Thread Peter Vreman
 How about this one:


 program problem;
 begin
   Write('Test One: ');
   if ( boolean(255) ) then WriteLn(True) else WriteLn(False);
   Write('Test Two: ');
   WriteLn( boolean(255) );
 end.


 FPC 1.9.4 output:
   Test One: FALSE
   Test Two: TRUE

 Kylix 1.0 output:
   Test One: TRUE
   Test Two: Segmentation fault



 Looks like *somebody* has a compiler bug, anyway ;-)


We know this issue. There is even a comment in the RTL what can go wrong:

{ Can't use array[boolean] because b can be 0 ! }
  if b then
Write_Str(Len,t,'TRUE')
  else
Write_Str(Len,t,'FALSE');




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


Re: [fpc-devel] compiler bug?

2004-12-31 Thread DrDiettrich
Nico Aragón wrote:

 IIRC, any non-zero value is evaluated as True for a Boolean variable.

You should not guess about any implementation. Forcing out-of-range
values into strictly typed variables is a user bug, at the full risk of
(and shame on) that user.

Who's to blame when somebody applies FillChar on a pointer variable, and
the program consequently crashes?

  else
 WriteLn('Other');

This better should read:
WriteLn('corrupt data space!!!'); Panic;

DoDi



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


Re: [fpc-devel] Interface to compressed files and archives

2004-12-31 Thread DrDiettrich
Marco van de Voort wrote:

 Better have a separate way. Otherwise you can't set e.g. a compressionlevel
 for that stream, _or_ you have to have lots of different constructors.

Compressors can require any kind and number of arguments, that must be
reflected somewhere, e.g. in the specific constructor. It's not
guaranteed that a compressor will have usable defaults for all
parameters.

For now only decompression will be supported by a general function,
where the decompressor (class) can be selected from the file extension
or header, and the decompressor then should be able to determine the
appropriate parameters from the concrete data source.

 One other thing to keep in mind (iirc) is that some algo's require the
 uncompressed size to unpack, and some the compressed size. So probably
 your interface has to support both.

Good to know. But the uncompressed size cannot be known in the general
case, so that such information must be supplied together with the
compressed data. The wrapper processor then must know how to retrieve
the unpacked size and the data from its own input stream.

 And use a 64-bit size and an endianness indicator if possible.

The 64 bit issue should be handled by the basic TStream class, where
also the according data types for size_t, off_t (or equivalent) should
be defined appropriately. The endianness of the target system also can
be selected at compile time - how?


 Search for zfs (zip filesystem). It was FPC compat for a while.

Can you be a bit more specific? I have traditional problems in searching
:-(
My first search resulted in 6000 hits, almost related to zip drives. My
second search retrieved two messages about errors in a StarKit...
package.

  I already
  decided to replace my own stdc unit by the FPC libc unit, with
  hopefully no changes to that unit.
 
 Then change them again to use BaseUnix/Unix :-)

I could locate 2 BaseUnix.pp units, for Linux and BSD. But I'm
developing under Windows :-(

What I really need is a unit with commonly used type names, so that all
modules ported from C to Pascal share the same types. The module
specific types are less important, because these are not shared with
other modules; nonetheless even these types should be defined based on
common types, like cUInt8.

 The libc unit is not a base unit of FPC, but exists merely for Kylix
 porting purposes, since it is pretty much only a direct x86 glibc
 translation, and not a general POSIX abstraction. It is only supported for
 Linux/x86.

Good to know. I already wondered how the implementation could work on
Windows.

 As said, a portable subset is available in units baseunix/unix

Where? I couldn't find any such directory and unit in the FPC sources
:-(

A related question: which (source...) directories must I add to the
search path, for using FPC and (primarily) Lazarus on Windows?

 See http://www.freepascal.org/docs-html/rtl/  for some docs
 http://www.stack.nl/~marcov/unixrtl.pdf

Just downloaded, but I couldn't find neither on the server nor in the
expanded docs-html.zip a /rtl directory.

DoDi


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


Re: [fpc-devel] Interface to compressed files and archives

2004-12-31 Thread DrDiettrich
[EMAIL PROTECTED] wrote:

 Naming a unit with 'u' standard does not seem useful to me, but this is
 a matter of taste.
...
 All other files are assumed to be units.
 (projects/packages have distinct extensions anyway)

No problem at the directory level, but how to distinguish names of
units, types, variables etc. in qualified references?
E.g.: gzip.xyz, is this based on a gzip unit or a gzip variable or...

DoDi



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


Re: [fpc-devel] Interface to compressed files and archives

2004-12-31 Thread Michael . VanCanneyt


On Fri, 31 Dec 2004, DrDiettrich wrote:

 [EMAIL PROTECTED] wrote:
 
  Naming a unit with 'u' standard does not seem useful to me, but this is
  a matter of taste.
 ...
  All other files are assumed to be units.
  (projects/packages have distinct extensions anyway)
 
 No problem at the directory level, but how to distinguish names of
 units, types, variables etc. in qualified references?

- Types should always be prepended with T. 
- One should avoid the use of globally visible variables. 
  They are inherently evil.  Specially when doing multithread programming.

 E.g.: gzip.xyz, is this based on a gzip unit or a gzip variable or...

Does this matter to you ? 

Normally one never uses a fully qualified identifier. 
Only when a possible name conflict exists, which 
- Should be very rare, and avoided in the first place.
- In such cases it will be obvious from the context.

Michael.

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


Re: [fpc-devel] compiler bug?

2004-12-31 Thread Florian Klaempfl
Nico Aragón wrote:
El Viernes, 31 de Diciembre de 2004 14:58, Florian Klaempfl escribiste:
type boolean = (false,true);
is how boolean is defined/declared
so assigning anything else than true or false to a boolean might cause
problems :)

That's great! But why do you tell it *to me*? 
I only cross read the thread and wanted to clarify things :)
I didn't start this thread and I've only tried to find an explanation why it 
doesn't work and refered Jesús to the documentation. 


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


Re: [fpc-devel] compiler bug?

2004-12-31 Thread Nico Aragón
El Viernes, 31 de Diciembre de 2004 17:18, Florian Klaempfl escribiste:
  That's great! But why do you tell it *to me*?

 I only cross read the thread and wanted to clarify things :)

Oh, I see. 

Happy new year! :-)

-- 
saludos,

Nico Aragón
http://espira.net/nico/

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


RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel

else
   WriteLn('Other');
 
  This better should read:
  WriteLn('corrupt data space!!!'); Panic;

 Much more useful :-

(AFAIK) you do.
You're programing, the C way.

You can't expect that -1 equals True, and any other value equals false, (I
really dunno, but I think I  could remember that) in Visual Basic is 1
instead of -1). As far as I can know Boolean type is in Pascal, that, a
type. I think there's no specifation how the compiler (ANSI PASCAL, ANSI
PASCAL 2) should implement that. (IMHO bad programming pratice)

If anyone goes on wild (and explicity) casting integer, enumerated, etc..
types into booleans, of course, many things may happen. But I reiterate, as
far as I can know, that is compiler implementation dependent, and one can't
depend on it.

Hower, should my opinion serve to anybody, I think that Kylix, Borland anf
FPC (according to contionals Delphi, ObjFpc, etc) should share the same
behoviour. As long as compatibility is broken between Delphy and Kylix, it's
up to you.

But, and I beg everyone's pardon if I' too dork, This is Pacal, Not C. I
can't really find out why I would need ro cast Boolean(Integer(255)= into a
boolean, and I guess that if I knew, I would surely programming in C.



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


Re: [fpc-devel] compiler bug?

2004-12-31 Thread Nico Aragón
El Viernes, 31 de Diciembre de 2004 18:40, Jose Manuel escribiste:
 else
WriteLn('Other');
  
   This better should read:
 WriteLn('corrupt data space!!!'); Panic;
 
  Much more useful :-

 (AFAIK) you do.

¡Serás melón! ¿A qué se supone que estás respondiendo ahí? X'D

 You're programing, the C way.

 You can't expect that -1 equals True, and any other value equals false, (I

You can expect whatever it's documented equals true and sometimes you must 
know what's the internal representation of the data, i.e. when you're linking 
with code written in different languages or writing inline assembler.

¡Feliz año, torpedo! :-)

-- 
saludos,

Nico Aragón
http://espira.net/nico/

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


RE: [fpc-devel] compiler bug?

2004-12-31 Thread Jose Manuel
[]
  You're programing, the C way.
[]

  You can't expect that -1 equals True, and any other value
 equals false, (I

 You can expect whatever it's documented equals true and
 sometimes you must

That's right. I can expect whatever is documented. In C there's no boolean
type. In Pascal (as in C++), boolean type is on its own.
If you typecast an integer to a boolean you are on you own, Maybe I'm wrong
but AFAIK there's no documented way how a Pascal Compiler ought to implement
Boolean Types. (Not to say Windows 1,2,4 bytes Booleans)

 know what's the internal representation of the data, i.e. when
 you're linking
 with code written in different languages or writing inline assembler.

¡Chapuzas!
You can't depend on the internal representation of any data. Maybe a quick
and dirty fix, but no further
Pascal is Pascal. Clearity and type safe. Anyway Pascal allows that
(explicit, it's gotta be explicit) conversion, try it in ADA.
I'm afraid your a C(ecer).
And assembler ... Well! We all have to resort to assembler some time or
later. But I see no relation.


 ¡Feliz año, torpedo! :-)
Posdepué d'aberhablaó contigo estoy un pelín disgustaó
Recuerdo2 patiytuhijo


 --
 saludos,

 Nico Aragón
 http://espira.net/nico/

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




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


RE: [fpc-devel] compiler bug?

2004-12-31 Thread peter green
Different languages approach boolean operations in different ways.

1: the C way
  false=0 true=anything else seperate logical and bitwise operators.
2: the BASIC way (also used by the access database)
  false=0 true=-1 logical and bitwise operations therefore equivilent
(though it should be noted that vbs if statement accepts anything nonzero as
true)
3: the PASCAL way
  boolean is a totally seperate type from integer types so the compiler
knows whether you mean logial or bitwise operations. I don't know if false
and true having ordinal values of 0 and 1 is part of a standard or a
borlandism but im pretty sure its what all pascal compilers anyone cares
about do.



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