RE: [fpc-devel] compiler bug?
I think the old saying goes garbage in garbage out. range checking should probablly catch this sort of stuff but that has a high performance penalty and is therefore usually disabled. At the end of the day if you force out of range data into your booleans then its your problem. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes > Sent: 30 December 2004 21:49 > To: FPC developers' list > Subject: RE: [fpc-devel] compiler bug? > > > --- peter green <[EMAIL PROTECTED]> escribió: > > you are forciblly putting an out of range value in a variable what > > do you > > expect to happen? > > > > > > > > Of course the program was made to do that evident, but what happen > when you find a procedure, for example: > > procedure doAorB(value: boolean); > begin > case value of > true: doA; > false: doB; > end; > end; > > one might think either doA or doB will executed, but the reality is > that sometimes neither doA or doB will do. > > > > > _ > Do You Yahoo!? > La mejor conexión a internet y 25MB extra a tu correo por $100 al > mes. http://net.yahoo.com.mx > > ___ > 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?
El Jueves, 30 de Diciembre de 2004 22:01, peter green escribiste:
> you are forciblly putting an out of range value in a variable what do you
> expect to happen?
I think it's slightly subtler. I guess that this code:
if not b then
WriteLn('False')
else if b then
WriteLn('True')
else
WriteLn('Other');
...could throw a different result.
IIRC, any non-zero value is evaluated as "True" for a Boolean variable. The
problem with the case statement is that Jesús is asking the compiler which
specific value it chooses for assignements... and getting surprised because
it's not what he expected. I guess the compiler uses 1 instead of 255. But
it's surely documented anyway.
--
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?
El Jueves, 30 de Diciembre de 2004 22:48, Jesus Reyes escribiste: > procedure doAorB(value: boolean); > begin > case value of > true: doA; > false: doB; > end; > end; if Value then DoA else BoB; -- 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?
--- peter green <[EMAIL PROTECTED]> escribió: > you are forciblly putting an out of range value in a variable what > do you > expect to happen? > > > Of course the program was made to do that evident, but what happen when you find a procedure, for example: procedure doAorB(value: boolean); begin case value of true: doA; false: doB; end; end; one might think either doA or doB will executed, but the reality is that sometimes neither doA or doB will do. _ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] compiler bug?
you are forciblly putting an out of range value in a variable what do you
expect to happen?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
> Sent: 30 December 2004 19:37
> To: lista de fpc-devel
> Subject: [fpc-devel] compiler bug?
>
>
> I have doubts about this so I made a small test, what I want to know
> is if a true boolean value be internally be represented by any value
> different from 0.
>
> program problem;
> var
> B: boolean;
> begin
> FillChar(B, SizeOf(B), 255);
> case b of
> true: WriteLn(True);
> false: WriteLn(False);
> else WriteLn('OTHER');
> end;
> end.
>
> I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for i386
> under linux.
>
> the program output: OTHER, it's a compiler bug?
>
> _
> Do You Yahoo!?
> La mejor conexión a internet y 25MB extra a tu correo por $100 al
> mes. http://net.yahoo.com.mx
>
> ___
> 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?
Never mind, I friend of mine confirmed that delphi does the same
output.
regards.
--- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> update: the following program output:
> TRUE
> OTHER
>
> program problem;
> var
> B: boolean;
> begin
>
> FillChar(B, SizeOf(B), 255);
> if b then WriteLn(TRUE)
> else WriteLn(FALSE);
> case b of
> true: WriteLn(True);
> false: WriteLn(False);
> else WriteLn('OTHER');
> end;
> end.
>
> this one tested with: Free Pascal Compiler version 1.0.10
> [2003/09/01] for i386 and Free Pascal Compiler version 1.9.5
> [2004/12/29] for i386
>
> --- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> > I have doubts about this so I made a small test, what I want to
> > know
> > is if a true boolean value be internally be represented by any
> > value
> > different from 0.
> >
> > program problem;
> > var
> > B: boolean;
> > begin
> > FillChar(B, SizeOf(B), 255);
> > case b of
> > true: WriteLn(True);
> > false: WriteLn(False);
> > else WriteLn('OTHER');
> > end;
> > end.
> >
> > I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for
> > i386
> > under linux.
> >
> > the program output: OTHER, it's a compiler bug?
> >
> > _
> > Do You Yahoo!?
> > La mejor conexión a internet y 25MB extra a tu correo por $100 al
> > mes. http://net.yahoo.com.mx
> >
> > ___
> > fpc-devel maillist - fpc-devel@lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-devel
> >
>
> _
> Do You Yahoo!?
> La mejor conexión a internet y 25MB extra a tu correo por $100 al
> mes. http://net.yahoo.com.mx
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
_
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
update: the following program output:
TRUE
OTHER
program problem;
var
B: boolean;
begin
FillChar(B, SizeOf(B), 255);
if b then WriteLn(TRUE)
else WriteLn(FALSE);
case b of
true: WriteLn(True);
false: WriteLn(False);
else WriteLn('OTHER');
end;
end.
this one tested with: Free Pascal Compiler version 1.0.10
[2003/09/01] for i386 and Free Pascal Compiler version 1.9.5
[2004/12/29] for i386
--- Jesus Reyes <[EMAIL PROTECTED]> escribió:
> I have doubts about this so I made a small test, what I want to
> know
> is if a true boolean value be internally be represented by any
> value
> different from 0.
>
> program problem;
> var
> B: boolean;
> begin
> FillChar(B, SizeOf(B), 255);
> case b of
> true: WriteLn(True);
> false: WriteLn(False);
> else WriteLn('OTHER');
> end;
> end.
>
> I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for
> i386
> under linux.
>
> the program output: OTHER, it's a compiler bug?
>
> _
> Do You Yahoo!?
> La mejor conexión a internet y 25MB extra a tu correo por $100 al
> mes. http://net.yahoo.com.mx
>
> ___
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
_
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] compiler bug?
I have doubts about this so I made a small test, what I want to know
is if a true boolean value be internally be represented by any value
different from 0.
program problem;
var
B: boolean;
begin
FillChar(B, SizeOf(B), 255);
case b of
true: WriteLn(True);
false: WriteLn(False);
else WriteLn('OTHER');
end;
end.
I'm using : Free Pascal Compiler version 1.9.5 [2004/12/29] for i386
under linux.
the program output: OTHER, it's a compiler bug?
_
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes.
http://net.yahoo.com.mx
___
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
On Thu, 30 Dec 2004, Marco van de Voort wrote: > > Just don't use anything conflicting with other prefixes: lib, z, db, im, > > sys. > > > > If we can agree on an implementation for archive handling that can be > > considered a standard implementation for FPC (i.e. distributed with the > > FCL), 'fp' can (and should) be used. > > > > Naming a unit with 'u' standard does not seem useful to me, but this is > > a matter of taste. In general, in Delphi, I use only 4 fixed prefixes: > > > > fra for Frames > > frm for Forms > > dm for DataModules > > mgr for Manager classes. > > Only additional general one i use is > > dlg for dialog In my view, dialog=form, the only 'dialogs' are the windows stock dialogs. But we have some forms that qualify. Thanks for the idea!! :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
> > Talking about TList slowness: > > In the last years TList and TStringList became slower and slower. > > Are there any alternatives in classes.pp? A simple TList providing only > > the very basics, less checks, no notifications, less virtuals, reordered > > IFs ... ? > > TList has almost no virtuals, so I doubt you will find anything to > change there. The notifications can be optimized, Dean Zobec wanted to > try this. This is as far as I'm concerned the biggest showstopper. unnecessary things have been added to TList to accomodate descendants (very bad OOP design decision IMHO), like the notification to be used in the only descendant, TObjectList, that transformed the Clear operation from an O(1) to an O(n) operation. Here is what Delphi designer Danny Thorpe says about TList in his book Delphi component design (1997): "You'll almost always wind up using a TList in a component, but you'll never create descendants of TList. TList is a worker drone, not a promiscuous ancestor class." Unfortunately the programmers of Delphi 5 seem not to have read his book :-) another explanation from Danny: "If you want to create a list of a particular kind of item and that list is used only in the private or protected sections of your component implementation, then just use a plain TList and typecast the list's raw pointers into the type you put into the list to begin with. If the list is exposed in the public interface of your component, typecasting is not an option. You cannot require a component user to typecast a list item appropriately in order to access it. You should create a simple wrapper class (derived from TObject, not TList) that exposes only the property and function equivalents of TList that you need and whose function and whose function return types and method parameter types match the type of data that the list contains. The wrapper class then contains a TList instance internally and uses that for actual storage." So TObjectList should have been designed as a wrapper around TList, with no need to add the notification mechanisms in TList. I've began writing a tutorial for fpcunit and have chosen this refactoring of TList and TObjectList as a subject of unit testing for my tutorial. Hope to finish it in the next two weeks. >> Are there >> any alternatives in classes.pp? A simple TList providing only the very >> basics, less checks, no notifications, less virtuals, reordered IFs ... ? >> If this TBaseList (or TSimpleList or TQuickList or THumbleList) would be >> the ancestor of TList, see above, composition is a better solution then inheritance in this case IMHO Ciao, Dean ___ 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
> Just don't use anything conflicting with other prefixes: lib, z, db, im, sys. > > If we can agree on an implementation for archive handling that can be > considered a standard implementation for FPC (i.e. distributed with the > FCL), 'fp' can (and should) be used. > > Naming a unit with 'u' standard does not seem useful to me, but this is > a matter of taste. In general, in Delphi, I use only 4 fixed prefixes: > > fra for Frames > frm for Forms > dm for DataModules > mgr for Manager classes. Only additional general one i use is dlg for dialog ___ 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
On Thu, 30 Dec 2004, DrDiettrich wrote: I split up my answers to your mail, because the topics are a bit different. > Now you should have gotten the big picture of my intended activities. > Many more questions will arise when I proceed with my work. I already > decided to replace my own "stdc" unit by the FPC "libc" unit, with > hopefully no changes to that unit. None other than bugfixes will be accepted: libc is the interface to the real C library (glibc) on Linux. The interface is therefore fixed and not subject to change, unless libc changes. You must explain what you want: + An interface to libc - then the libc is OK for you. + An imitation of libc (on unix) - then you should do as marco implied: use Unix/BaseUnix + An imitation of libc (general) - then you must implement a new unit, the above ones are for Unices only. + A cross-platform uniform pascal API - Then you should stick to sysutils/strutils/dateutils etc. > For further compatibility it will be > necessary to find compromises between my coding style, and the style > used by the FPC community. E.g. I prefer to prefix all my units with an > "u", so that the base names remain available for procedures or > variables. I also use upper case characters in the unit names, what may > not be appreciated by users from the Unix world. As a compromise it may > be possible to use a "lib" prefix, but this may conflict with existing > library names (libz...). Any ideas? You can name the unit identifier with uppercase characters, but not the filename. Filenames lowercase only, please. As for prefixes: for a compression/decompression set of units, I would use dc or cd as prefix. If it is 'archiving' in general, 'ar' seems best suited. And if you want a 'virtual file system', use vfs. Just don't use anything conflicting with other prefixes: lib, z, db, im, sys. If we can agree on an implementation for archive handling that can be considered a standard implementation for FPC (i.e. distributed with the FCL), 'fp' can (and should) be used. Naming a unit with 'u' standard does not seem useful to me, but this is a matter of taste. In general, in Delphi, I use only 4 fixed prefixes: fra for Frames frm for Forms dm for DataModules mgr for Manager classes. All other files are assumed to be units. (projects/packages have distinct extensions anyway) Michael. ___ 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
On Thu, 30 Dec 2004, DrDiettrich wrote: > Hi there, > > I'm new to this list and want to introduce myself and my intended > contributions to FreePascal. > > My name is Dr. Hans-Peter Diettrich, and I live in Flensburg (Germany). > For brevity I use to sign my messages as DoDi. My main interests are > decompilers and (tools for) porting code. Usually I work with Delphi, > but this behaviour may change ;-) > > Recently I came across some interesting library modules of FPC, that I > want to use in my own projects. Some of these modules deserve updates, > in general and for use with Delphi, and I want to contribute my > according work to the FPC community. > > Currently I'm implementing an RPM clone for Windows, which in detail > should support source rpm's, better than the original RPM. Hereby I have > to deal with compressed files in various formats (gzip, bzip2), and > archive files (cpio, tar...). I've already update or implemented some > of these modules, now I want to define a common interface and API for > compressed and archive streams, based on TStreams. The zstream unit is > dedicated to a single compressor, but it has an handy name. How should I > name a more general unit, would "zstreams" be acceptable? > > My idea of a general (de-)compression interface is as follows: > Your idea is already implemented in Abbrevia from TurboPower. Abbrevia is open source, and is maintained on SourceForge. Free Pascal has a copy of it that compiles in CVS, check out contrib/abbrevia Michael. ___ 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
> I'm new to this list and want to introduce myself and my intended > contributions to FreePascal. You are not new to everybody:-) > archive files (cpio, tar...). I've already update or implemented some > of these modules, now I want to define a common interface and API for > compressed and archive streams, based on TStreams. The zstream unit is > dedicated to a single compressor, but it has an handy name. How should I > name a more general unit, would "zstreams" be acceptable? Maybe just streams. I also have a encryption stream (Rijndael) based on a PD unit that I could try to adapt. Of course that depends on how specific the interface is for compression (compres//decompress crypt/decrypt are similar) > Then a general Open or Decompress procedure can determine which > decompressor to use for an given stream, and can create the appropriate > decompressor object. For compressors it may be better to create the > according object directly, according to the desired compression format, > in which case the according arguments also can be passed to the > constructor of that class in the appropriate form. 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. 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. And use a 64-bit size and an endianness indicator if possible. > Archive files deserve a more elaborate API, so that the files in an > archive can be extracted to individual files or streams. There was > already a suggestion, to define something like a virtual file system > interface for archive files. I suspect that something like this already > exists for use in the GUI browsers of both Linux and Windows. This may > deserve some research, before an accordingly compatible interface can be > defined. Now I'm waiting for according contributions from the OS gurus > before proceeding with this approach. Search for "zfs" (zip filesystem). It was FPC compat for a while. > Now you should have gotten the big picture of my intended activities. > Many more questions will arise when I proceed with my work. 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 :-) 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. As said, a portable subset is available in units baseunix/unix, with threadsafe errno and most calls have "fp" prefixed to avoid nameclashes with older FPC unix units (oldlinux) and Kylix' libc. See http://www.freepascal.org/docs-html/rtl/ for some docs, and http://www.stack.nl/~marcov/unixrtl.pdf > For further compatibility it will be > necessary to find compromises between my coding style, and the style > used by the FPC community. E.g. I prefer to prefix all my units with an > "u", so that the base names remain available for procedures or > variables. I also use upper case characters in the unit names, what may > not be appreciated by users from the Unix world. As a compromise it may > be possible to use a "lib" prefix, but this may conflict with existing > library names (libz...). Any ideas? unit prefixes for units belonging together are not uncommon (see e.g. the image and db routines), but I would avoid the uppercase unitnames and don't use already taken prefixes like "lib", "db", "unix" and "fp" ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
