RE: [fpc-devel] compiler bug?
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 That's the point. :-) 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. So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant). JMR ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
El Sábado, 1 de Enero de 2005 09:06, Jose Manuel escribiste: So i think. I think Ord(TRUE), Succ(FALSE), etc. are valid Standard and Extended Pascal expressions, as well as the behaviour of a declarion of As far as I know: Ord(True) Ord(False) = True Succ(False) = True ...are not only legal but also mandatory in the standard. But that doesn't mean anything. You can implement Ord and Succ to return that values for booleans no matter how you implemented the type. type TBoolArray = array[boolean] of ... is neatly defined in the very language. (At least in Modula-2, that enumeration is part of the standard, so it's a language feature and not compiler implementation dependant). It's possible to implement the boolean type as an enumeration and still implement the boolean evaluation as 0. I'm pretty sure to have seen this in some specification, I just can't remember in which right now :-) -- 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] Interface to compressed files and archives
[EMAIL PROTECTED] wrote: 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. And that can become a problem, when a variable and a unit has the same name. That's why I do not only prefer to prefix type names with T, but also unit names with u, form (unit) names with f etc. As prefixes for specific kinds of units seem to be in use by other people as well, why not prefix all units? 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. Okay, name clashes between unit and variable names should be detectable easily. But then a decision has to be made, which of both names should stay unchanged, and which one to decorate. My preference then is to decorate the unit names, because these occur less frequently in source code, and almost only in obvious Uses clauses. I know that my private prefix style is a bit uncommon, as is my coding style (indentation...). In shareable contributions I'm willing to follow the more widely accepted standards, of course :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. I don't. Do I? Yes, you do. How can you know what bit pattern is stored in a boolean variable? Using typecasts may result in silent type conversion, returning something different from the really stored pattern. The boolean data type is distinct from other data types, so that it's wild guessing that every compiler and compiler version will treat boolean values and variables in the same way, as observed when using a specific version of an specific compiler. For completeness: Many people also consider ByteBool etc. as being boolean. These types have been made compatible with boolean *intentionally*, with the documented behaviour that any non-zero value will evaluate to True, under circumstances. But you may test yourself what will happen when you compare such a variable with an non-boolean value - it's not perfectly specified when the nonzero=true evaluation will be effective. Try this with various compilers: var b: ByteBool; ... case b of True: ... False: ... 42: ... else ... end; It's unspecified which compiler will accept the True and False constants here at all... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler bug?
[merged responses to two messages] El Sábado, 1 de Enero de 2005 06:54, DrDiettrich escribiste: ¡Serás melón! Could you please help me to improve my rudimentary Spanish? ;-) http://hotel.jp-guide.net/job/point/melon.jpg (Eierkopf? ;-) My rudimentary... I meant my non-existent... whatever :-) ¡Feliz año, torpedo! :-) (Blindgänger? ;-) It's the same in English. Feliz año, Bonne Année, Happy New Year, Gelukkige Nieuwe Jaar, und ein Gutes Neues Jahr allerseits! All of that! :-) * El Sábado, 1 de Enero de 2005 06:29, DrDiettrich escribiste: Nico Aragón wrote: IIRC, any non-zero value is evaluated as True for a Boolean variable. You should not guess about any implementation. I don't. Do I? Yes, you do. No, I don't. Maybe you're confusing me with Jesús? If you read my last answer to José Manuel, you'll see that I say exactly the opposite. So I can't agree more with the rest of your post. -- 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] Optimization error causes pyacc and plex to fail
Can't seem to get bug submission to work so I'm sending this here. The 1.9.x distributed binaries of plex and pyacc both fail, as well as any created from a 1.9.5 source snapshot. plex ends normally but only creates 2 states. pyacc fails with a RTE 216 on a move in procedure setunion of yaccbase. The makefile compiles these programs with the -OG2p3 option. Changing this to either -Og2p3 or -OG1p3 and they both work correctly. I am using unmodified versions of both programs so am only attaching the output of each scenario. Feel free to contact me if you need anything else. (* plex compiled with -OG2p3 *) plex -v -o xrlex.l TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... DFA construction ... DFA optimization ... code generation ... DONE 169 lines, 44 rules, 173/1200 p, 2/600 s, 0/1200 t. (see xrlex.lst for more information) (* plex compiled with -Og2p3 or -OG1p3 *) plex -v -o xrlex.l TP Lex Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... DFA construction ... DFA optimization ... code generation ... DONE 169 lines, 44 rules, 173/1200 p, 61/600 s, 102/1200 t. (see xrlex.lst for more information) (* pyacc compiled with -OG2p3 *) pyacc -v xrpars.y TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... sort ... closures ... Runtime error 216 at $0040CA1C $0040CA1C MOVE, line 76 of F:/FPCDevel/SrcCVS123104/fpc/rtl/i386/i386.inc $00407FA5 SETUNION, line 349 of YaccBase.pas $0040208B CLOSURES, line 94 of YaccClos.pas $00407452 GENERATE_PARSER, line 580 of YaccSem.pas $00409B20 YYACTION, line 250 of pyacc.pas $00409716 YYPARSE, line 2079 of pyacc.pas $0040B5F5 main, line 2479 of pyacc.pas (* pyacc compiled with -Og2p3 or -OG1p3 *) pyacc -v xrpars.y TP Yacc Version 4.1a [April 2000], Copyright (c) 1990-2000 Albert Graef parse ... sort ... closures ... first sets ... LR0 set ... lookaheads ... code generation ... DONE 1396 lines, 433/900 rules, 691/1200 s, 3334/9600 i, 3138/9600 t, 487/1200 r. 1 shift/reduce conflicts. (see xrpars.lst for more information) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
