Re: [fpc-devel] Wrong docs: not initialized global variables

On 05.04.2018 8:35, Michael Van Canneyt wrote: Now, it is also correct that the compiler developers are aware that many people rely on this implementation detail. Since when is documented behavior considered as "implementation detail"? This is not an implementation detail. It is in official

Re: [fpc-devel] Wrong docs: not initialized global variables

On 05.04.2018 0:34, Michael Van Canneyt wrote: What, because you do not agree ? No, because I didn't get any arguments against. Now, it is also correct that the compiler developers are aware that many people rely on this implementation detail. Since when is documented behavior considered

Re: [fpc-devel] Wrong docs: not initialized global variables

On 04.04.2018 21:51, Jonas Maebe wrote: On 04/04/18 20:26, Ondrej Pokorny wrote: The compiler initializes the variable implicitely for myself - this is documented and I know it. There cannot be "wrong code behaviour" (as you stated) and thus I cannot have an error. This is si

Re: [fpc-devel] Wrong docs: not initialized global variables

On 04.04.2018 20:03, Jonas Maebe wrote: On 04/04/18 19:32, Ondrej Pokorny wrote: On 04.04.2018 18:53, Jonas Maebe wrote: On 04/04/18 18:44, Ondrej Pokorny wrote: I want to stress that the compiler emits a warning on code that does not have (and also cannot have) an error An error is wrong

Re: [fpc-devel] Wrong docs: not initialized global variables

On 04.04.2018 18:53, Jonas Maebe wrote: On 04/04/18 18:44, Ondrej Pokorny wrote: I want to stress that the compiler emits a warning on code that does not have (and also cannot have) an error An error is wrong code behaviour. If you do not initialise a variable with the correct value

Re: [fpc-devel] Wrong docs: not initialized global variables

On 04.04.2018 17:49, Jonas Maebe wrote: On 04/04/18 10:47, Ondrej Pokorny wrote: I would lower the level of notification for "trivial: string" to a hint. It is nonsense to emit the same level of notification (warning) for dangerous code ("serious: integer") and valid cod

Re: [fpc-devel] Wrong docs: not initialized global variables

On 25.03.2018 16:28, Jonas Maebe wrote: On 2018-03-25 00:09, Ondrej Pokorny wrote: Why do I get the compiler warning when the variable is indeed guaranteed to be initialized to nil/empty string? https://bugs.freepascal.org/view.php?id=24601 Very good bug report. I would lower the level

Re: [fpc-devel] Multiple variable initialization

On 31.03.2018 11:34, Anton Shepelev wrote: Initialisation is a special and redundant way to assign a value to a variable. Is this mixing of declaration and action a good idea? Why not keep them separate? LOL, I am not the one who wants to introduce initialisation of variables to Pascal. For

[fpc-devel] Redundant compiler hints

Yesterday I updated FPC to current trunk (r38623) and now I get a lot of redundant compiler hints. E.g.: program Test; uses SysUtils; var   FS: TFormatSettings; begin   FS := DefaultFormatSettings; end. Test.lpr(6,3) Hint: Call to subroutine "procedure

Re: [fpc-devel] Wrong docs: not initialized global variables

On 24.03.2018 23:33, Ondrej Pokorny wrote: Another question about this sentence in FPC docs: "Managed types are always initialized: in general this means setting the reference count to zero, or setting the pointer value of the type to Nil." Does it mean I can assu

Re: [fpc-devel] Wrong docs: not initialized global variables

On 24.03.2018 23:00, Sven Barth via fpc-devel wrote: Ondrej Pokorny <laza...@kluug.net <mailto:laza...@kluug.net>> schrieb am Sa., 24. März 2018, 20:49: This is not correct. Global simple variables are always initialized. At least in Delphi it is

[fpc-devel] Wrong docs: not initialized global variables

Due to the "Multiple variable initialization" thread I took a look into FPC documentation: https://www.freepascal.org/docs-html/ref/refse24.html There it says: By default, simple variables in Pascal are not initialized after their declaration. Any assumption that they contain 0 or any other

Re: [fpc-devel] Multiple variable initialization

On 24.03.2018 18:40, Jonas Maebe wrote: The C-syntax is indeed consequent, and that is what I referred to: the assignments work the same way as elsewhere in the program, so multiple initialisations are just as clear as single initialisations there. In Pascal, you have a special syntax for

Re: [fpc-devel] Multiple variable initialization

On 24.03.2018 16:51, Florian Klaempfl wrote: Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny: Is there a reason why multiple variable initialization is forbidden? program Test; var   A: Integer = 0;    // allowed   B, C: Integer = 0; // not allowed begin end. Will a patch be applied

Re: [fpc-devel] Multiple variable initialization

On 24.03.2018 16:53, Jonas Maebe wrote: > You'd also have to support it at least for record field initialisers and default parameters. Oh yes, I'd also love to write procedure Test(const A, B, C, D: Integer = 0); instead of procedure Test(const A: Integer = 0; const B: Integer = 0; const C:

Re: [fpc-devel] Multiple variable initialization

On 24.03.2018 15:46, Alexander Grotewohl wrote: The patch is to put them on separate lines. Preferably with meaningful comments for each. If FPC was changed at the whim of every programmer we'd end up with a huge mess that no longer resembles pascal. Please tell me who decides about the

Re: [fpc-devel] Multiple variable initialization

On 24.03.2018 15:41, Michael Van Canneyt wrote: On Sat, 24 Mar 2018, Ondrej Pokorny wrote: Is there a reason why multiple variable initialization is forbidden? program Test; var   A: Integer = 0;    // allowed   B, C: Integer = 0; // not allowed I think this is confusing to read. Are B

[fpc-devel] Multiple variable initialization

Is there a reason why multiple variable initialization is forbidden? program Test; var   A: Integer = 0;    // allowed   B, C: Integer = 0; // not allowed begin end. Will a patch be applied that allows it? Ondrej ___ fpc-devel maillist -

Re: [fpc-devel] Request for applying patch #33124

On 22.03.2018 18:47, Jonas Maebe wrote: On 22/03/18 16:14, Ondrej Pokorny wrote: it's nothing serious, only a missing Cocoa header definition. Those headers have been generated automatically. They should never be manually patched. Updated versions are indeed needed, but that will probably

[fpc-devel] Request for applying patch #33124

Can somebody apply the patch at https://bugs.freepascal.org/view.php?id=33124 it's nothing serious, only a missing Cocoa header definition. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Fix CamelCase in unit and method names

On 22.03.2018 12:42, Michael Van Canneyt wrote: Code completion will benefit from it, I suppose. Yes, my only motivation is code completion. I uploaded the patch here: https://bugs.freepascal.org/view.php?id=33481 Thanks Ondrej ___ fpc-devel

[fpc-devel] Fix CamelCase in unit and method names

Hello, will a patch be applied that fixes CamelCase in unit and method names and other identifiers? Example: dateutils -> DateUtils sysutils -> SysUtils typinfo -> TypInfo contnrs -> Contnrs strutils -> StrUtils EnterCriticalsection -> EnterCriticalSection DoneCriticalsection ->

Re: [fpc-devel] FPProfiler

You still didn't convince me that the two features aren't similar :) But no problem. I am glad you wanted to implement a built-in profiler yourself. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FPProfiler

On 19.02.2018 10:25, Anton Shepelev wrote: Simon Ameis: However I think, FPC should generate the profiling code itself. Then there is no need to modify the code before and after the compilation. Not, I think, for the naive light-weight profiling that FPProfiler offers. Its

Re: [fpc-devel] FloatHelper bugs (Issue #32837)

On 12.01.2018 13:54, Michael Van Canneyt wrote: I seem to have missed this bugreport. I assigned it to myself, will look at it this weekend. Thank you Michael, I highly appreciate your work! Ondrej ___ fpc-devel maillist -

Re: [fpc-devel] FloatHelper bugs (Issue #32837)

On 12.01.2018 5:13, Michael Van Canneyt wrote: On Thu, 11 Jan 2018, Bart wrote: Can I get some feedback from a devel please? Patience, please. When we are at this topic: could an FPC developer take a look at https://bugs.freepascal.org/view.php?id=31985 ? The issue has been ignored for

Re: [fpc-devel] FloatHelper bugs (Issue #32837)

On 12.01.2018 6:27, Bart wrote: On Thu, Jan 11, 2018 at 11:59 PM, Ondrej Pokorny <laza...@kluug.net> wrote: IIRC, the Delphi starter edition is free of charge. It should be sufficient for such simple tests. License for use until your individual revenue from Delphi applications or c

Re: [fpc-devel] FloatHelper bugs (Issue #32837)

On 12.01.2018 5:53, Bart wrote: Also, probably some more comparison against Delphi is needed, which I cannot do (I can't keep asking other people to build and run Delphi programs for me). IIRC, the Delphi starter edition is free of charge. It should be sufficient for such simple tests.

Re: [fpc-devel] TStringStream changes

On 21.07.2017 19:16, Michael Van Canneyt wrote: TStringStream now observes encoding. Are these changes going to be merged to fixes_3_0? What first stable version it is going to appear in? As it turned out, Lazarus sources are affected by this change too, so we need to get the correct {$IF

Re: [fpc-devel] Compiler for current function name

On 18.12.2017 10:54, Marco van de Voort wrote: {$i %CURRENTROUTINE%} Thank you! Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Compiler for current function name

Hello! I remember there should be a compiler macro in current FPC trunk to get the function name but I cannot find it: function TMyObject.DoSomething: Integer; begin   Writeln(_CLASSNAME_, '.', _FUNCTIONNAME_); end; Does anybody know the macros or do I remember it wrongly? Thanks Ondrej

Re: [fpc-devel] Quickly recompiling fpc

On 09.12.2017 16:57, Sven Barth via fpc-devel wrote: Am 09.12.2017 14:57 schrieb "Benito van der Zander" >: Hi, how do you recompile fpc after making a small change in the compiler, like enabling the debugmsg define in

Re: [fpc-devel] [PATCH][LCL] Fix BitBtn Kind property with ShowModal

On 12.11.2017 6:53, Tarnyko wrote: Please find attached a patch which fixes the following issue Thank you for the patch. Please send it to https://bugs.freepascal.org . fpc-devel mailing list is not the right place. Ondrej ___ fpc-devel maillist

Re: [fpc-devel] Can't compile FPC trunk x86_64-win64

On 30.09.2017 0:10, Sven Barth via fpc-devel wrote: Are you sure that you're compiling with the correct compiler? Cause that sounds quite like you're trying to compile the Win64 RTL with a i386 compiler. Also Jenkins reports no build errors, so that is probably indeed a problem on your

[fpc-devel] Can't compile FPC trunk x86_64-win64

Hello, I can't compile latest trunk for x86_64-win64: the first error message is: system.pp(136,18) Error: invalid register name i386-win32 compiles fine. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] TSQLScript doesn't execute last statement not terminated by '; ' (FTerminator)

Hello, if I run this script with TSQLScript: INSERT INTO A (ID) VALUES (1); INSERT INTO A (ID) VALUES (2) Only the first insert is executed. Not the second one - it's ignored because it lacks the terminating ';'. Furthermore, no exception is raised - so I even don't know about it! IMO it is

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 13.09.2017 22:08, Sven Barth via fpc-devel wrote: Anyway, I had looked at your patch last Friday, but after some thinking I came to the conclusion that I definitely don't want the typehelpers modeswitch to enable inheritance on record helpers in mode Delphi cause that would be some unexpected

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 01.09.2017 18:38, Sven Barth via fpc-devel wrote: What if I do the initial specialization in a unit that does not know about the helper? It can't just do speculative specialization once both the specialized generic and the generic helper are used in the same unit. And even if the compiler

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 01.09.2017 12:15, Maciej Izak wrote: 2017-09-01 11:41 GMT+02:00 Stefan Glienke >: Again you will cause unnecessary headaches because now your helper has the dependency of the builtin and the third party one. How would third party

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 01.09.2017 11:41, Stefan Glienke wrote: Again you will cause unnecessary headaches because now your helper has the dependency of the builtin and the third party one. Not really, if you want to use both helpers (builtin and 3rd party) in the same unit you have the dependencies already

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 01.09.2017 8:47, Stefan Glienke wrote: Inheritance seems like the obvious way but you just defer the "I cannot extend the builtin helpers" problem. If any third party code decides to do so you are at the same point again because now do you inherit from the third party helper or from the

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 31.08.2017 17:22, Sven Barth via fpc-devel wrote: > I remember a compiler bug in class destructor order call in Delphi: https://stackoverflow.com/questions/19332847/delphi-class-variable-going-out-of-scope-before-class-destructor-is-called That should get solved once I reworked the unit

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 31.08.2017 15:54, Ondrej Pokorny wrote: By the way, FPC is affected by the very same bug: https://mantis.freepascal.org/view.php?id=29334 . Sorry, wrong link: https://mantis.freepascal.org/view.php?id=24256 Ondrej ___ fpc-devel maillist - fpc

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 31.08.2017 14:55, Sven Barth via fpc-devel wrote: > Yeah, they might enable record helper inheritance for example :P (Record helper inheritance was documented to work for about 7 years since Delphi 2007 until XE6

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 22:30, Maciej Izak wrote: Btw. record helpers support inheritance in all modes but Delphi. It doesn't make sense to disallow it for record helpers but allow it for type helpers... Too overcomplicated without any plus value :/ what if Delphi will decide to introduce

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 22:06, Michael Van Canneyt wrote: And actually, duplication of effort has a good side: in a way, the IDE independently 'checks' the working of the compiler. Unfortunately the reality is the other way round: the compiler checks the working of CodeTools :) Positive is that

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 21:50, Maciej Izak wrote: 2017-08-29 20:24 GMT+02:00 Ondrej Pokorny <laza...@kluug.net <mailto:laza...@kluug.net>>: No - please not yet another undefined behavior :) It's perfectly defined: disabled without typehelpers, enabled with typehelpers. but

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 20:20, Maciej Izak wrote: IMO inheritance for record helpers in Delphi mode has no really meaning and may stay as undefined behavior No - please not yet another undefined behavior :) It's perfectly defined: disabled without typehelpers, enabled with typehelpers. Ondrej

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 18:54, Sven Barth via fpc-devel wrote: Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" <laza...@kluug.net <mailto:laza...@kluug.net>>: > So yes, your description of {$modeswitch typehelpers} makes sense for 3.0.0 but not for trunk any more. So what i

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 17:47, Anthony Walter wrote: Out of curiosity, is there any strategy that is or can be employed to ensure new language features and mode switches automatically work with codetools and by extension the Lazarus IDE? Or is duplication of effort the only way to get codetools

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

There is a difference between FPC 3.0.0 and current trunk (without my patch) regarding {$modeswitch typehelpers} and "TXYZHelper = type helper for TXYZ". In 3.0.0 it is obvious - it can be used only for primitive types. In trunk you can use type helper for everything (with {$modeswitch

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 12:44, Ondrej Pokorny wrote: {$modeswitch advancedrecords-} // it doesn't disable record helper for TRec Sorry, typo: "it disables record helper for TRec ". Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepasca

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 11:48, Sven Barth via fpc-devel wrote: The idea is okay as well, but I'd name it RecordHelperInheritance, cause if we'd allow "type helper" in mode Delphi (as Maciej asks) then those would support inheritance by default as they aren't Delphi compatible as a whole anyway.

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 10:43, Maciej Izak wrote: I prefer to have also "type helper for" also in Dlephi mode instead of "record helper for" for simple types. Different syntax for the same thing is very annoying especially when someone need to work in many modes. -,- I don't care about the syntax that

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 8:47, Michael Van Canneyt wrote: On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote: Suggested name is "NonDelphiExtensions". Why not simply allow $RECORDHELPERS or so ? Hmm yes. Reading https://www.freepascal.org/docs-html/3.0.2/prog/progsu105.html you can define other

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

On 29.08.2017 7:54, Sven Barth via fpc-devel wrote: patches welcome. Suggested name is "NonDelphiExtensions" Good to know, thanks. Luckily it wasn't that hard: https://mantis.freepascal.org/view.php?id=32355 Ondrej ___ fpc-devel maillist -

[fpc-devel] Allow record helper inheritance in Delphi mode

Hello! I find it unnecessary to disable record helper inheritance in Delphi mode. Due to this  artificial limitation I have to change unit mode from Delphi to ObjFPC. Reasons: 1.) It's a limitation of a feature that FPC already has. 2.) I write FPC-only code in Delphi mode. I don't care

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 13:22, Michael Van Canneyt wrote: I am asking, why do you think *this pattern* (of always returning self) should be inherently more efficient ? Benito didn't state it is more efficient (than something else). He said it is popular and not optimized in fpc. Ondrej

Re: [fpc-devel] Multiple inheritance

On 19.08.2017 9:27, Sven Barth via fpc-devel wrote: The designers of Object Pascal decided on purpose against multiple inheritance as they probably saw the problems that C++ has with them. Even Java and C#, both clearly influenced by C++ don't support multiple inheritance. Just think about

[fpc-devel] Multiple inheritance

Hello! Has anybody thought about multiple inheritance in object pascal? I am now working on a client-server service that entirely uses ORM. I have several patterns that repeat all over and some of them do not match into the direct inheritance schema. For now I solved multiple inheritance

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 16:42, Michael Van Canneyt wrote: Inserted this version, without the hcnUnknown. fpimage unit, rev. 36774. Thank you Bart & Michael! I am building FPC trunk right now :) Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 16:08, Ondrej Pokorny wrote: On 23.07.2017 15:25, Michael Van Canneyt wrote: I think the case statement is inefficient enough not to worry about an additional call. There is IdentToInt function in Classes that makes this more efficient. IdentToColor from Graphics.pas uses

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 15:25, Michael Van Canneyt wrote: I think the case statement is inefficient enough not to worry about an additional call. There is IdentToInt function in Classes that makes this more efficient. IdentToColor from Graphics.pas uses it as well. Ondrej

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 15:50, Bart wrote: On 7/23/17, Ondrej Pokorny <laza...@kluug.net> wrote: +Btw. there are much more name constants: https://www.w3schools.com/colors/colors_names.asp My set is W3C compliant ... Ah, I see you use only the W3C basic colors https://www.w3.org/wiki/CSS/Prop

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 14:39, Bart wrote: { Try to translate HTML color code into TFPColor Supports following formats '#rgb' '#rrggbb' W3C Html color name } function TryHtmlToFPColorDef(const S: String; out FPColor: TFPColor; Def: TFPColor): Boolean; Actually I wanted to use an

Re: [fpc-devel] HTML string to TFPColor

On 23.07.2017 12:51, Michael Van Canneyt wrote: Agreed. Feel free to submit a patch. Great, I will! Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] HTML string to TFPColor

Hello! I couldn't find a function that converts a #RRGGBB color to TFPColor in FPC sources. I only found HTMLToFPColor in Lazarus /trunk/components/tachart/tahtml.pas IMO it is a fairly general function and should be in FPC sources. What do you FPC developers think? Ondrej

Re: [fpc-devel] Closures / anonymous methods

On 05.12.2016 15:12, bla...@blaise.ru wrote: Otherwise, as I stated above, no help/answers is required for now; and I am working. What is the progress? Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 21:13, Florian Klaempfl wrote: Indeed. This proves the exactly point. Undefined behaviour. The code behaves randomly dependent on the compiler used and even the optimizer switches. OK, I see now: there is a difference between C enums and C++ enums. Your example was about C++

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 23:11, Florian Klämpfl wrote: Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: Am 16.07.2017 um 22:15 schrieb Martok: However: --- {$mode objfpc} type TExplEnum = (a=1, b=3, c=5, d=7); TSubEnum = a..d; TEnArr = array[TSubEnum] of Byte; begin

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 20:42, Florian Klämpfl wrote: "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid opcode (memory dump written). Why? Because it does not range check before entering the jump table. OK, I confess I am not a C guy (I hated it in the university even more than

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 11:07, Michael Van Canneyt wrote: You are missing the point of an enumerated. The whole point of using an enumerated is that range checking *is not necessary*, because the values are 'by definition' correct. If the compiler cannot assume this, you're just using an integer with

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 19:24, Martok wrote: The good thing about case statements is that they tell me of every other programmer error: missing elements (if used without else) Off-topic: how can I enable this compiler hint? When compiling: program Project1; type TEnum = (one, two); var A: TEnum;

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15.07.2017 21:39, Jonas Maebe wrote: On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables through the use of a.o. pointers (which is

Re: [fpc-devel] Dangerous optimization in CASE..OF

Btw, when compiling this program with default Lazarus Release build mode: program Project1; {$mode objfpc}{$H+} type TMyEnum = (zero); function MyFunc(const aEnum: TMyEnum): string; begin case aEnum of zero: Result := '0'; end; end; begin WriteLn(MyFunc(zero)); end. I get a

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 22:02, Florian Klämpfl wrote: Am 02.07.2017 um 21:40 schrieb Martok: Honestly, I still don't understand why we're even having this discussion. Because it is a fundamental question: if there is any defined behavior possible if a variable contains an invalid value. I consider a

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 20:23, Florian Klämpfl wrote: And the compiler writes no warning during compilation? It does indeed. On 02.07.2017 20:18, Florian Klämpfl wrote: Yes, undefined behavior. I think I got your point :) You are right, sorry for wasting your time. If we get a convenient way to

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 19:39, Florian Klämpfl wrote: So this means: var b : boolean; begin b:=boolean(3); if b then writeln(true) else if not(b) then writeln(false) else writeln(ord(b)); end. writes 3 in delphi? IMO you picked up a Delphi compiler bug/undocumented

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 19:29, Martok wrote: - Case statements execute*precisely one* of their branches: the statements of the matching case label, or the else block otherwise To support your argument, the current Delphi documentation says the same:

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:49, Jonas Maebe wrote: No, there is no built-in checked conversion from integer to arbitrary enumeration types. That's why I suggested in the bug report that started this thread to file a feature request for such a conversion. Very good :) Are there any disadvantages of the

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:28, Jonas Maebe wrote: On 02/07/17 18:26, Ondrej Pokorny wrote: Allow me a stupid question: how to convert an integer to enum with range checking? The current possibilities and possibly improvements have been mentioned elsewhere in this thread already * http

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:20, Jonas Maebe wrote: Range checking code is generated for operations involving enums if, according to the type system, the enum can be out of range. Just like with integer sub-range types. Allow me a stupid question: how to convert an integer to enum with range checking? A

Re: [fpc-devel] How to call virtual StoredProc from PropInfo

On 17.05.2017 18:13, Ondrej Pokorny wrote: My question is, how can I call a virtual stored procedure from PropInfo? Digging through the code, I found it: function GetStoredFunction(APropInfo: PPropInfo; AInstance: TPersistent): CodePointer; var StoredProcType: Byte; xT: Pointer; begin

[fpc-devel] How to call virtual StoredProc from PropInfo

Hello! For the Lazarus IDE I need to call the stored function from a property. I was able to get the pointer of a static procedure and call it: function GetStoredFunction(APropInfo: PPropInfo; AInstance: TPersistent): CodePointer; var StoredProcType: Byte; begin StoredProcType :=

Re: [fpc-devel] Console encoding on Windows, output to file with ">"

Michael, because I cannot comment on a closed issue report I post my answer to https://bugs.freepascal.org/view.php?id=31746#c100091 here: > I don't think what you write is correct. As far as I can see in the code of Delphi Berlin: Delphi uses always the defaultsystemcodepage for text files,

Re: [fpc-devel] Let's Encrypt cert and mantis.freepascal.org

On 02.05.2017 19:20, Michael Van Canneyt wrote: Changed the bugtraq:url. Revision 36062. Off-topic: I now switched from mantis.freepascal.org to bugs.freepascal.org and had to block the running cheetah icon again. Remember the good webpage designer (generally speaking UI designer) rule:

Re: [fpc-devel] Console encoding on Windows, output to file with ">"

On 03.05.2017 9:07, Petr Kristan wrote: Try: Writeln(UTF8ToSys('ÄäÖöÜüß')); No, it doesn't help. I debugged into the issue and found out that the exported file was in DOS-850 encoding (the same as the console lived in). Delphi changes the output encoding to "DefaultSystemCodePage" if

[fpc-devel] Console encoding on Windows, output to file with ">"

Hello, I have a simple FPC program: --- program GermanTest; {$codepage utf8} begin Writeln('ÄäÖöÜüß'); end. --- If I run it in the console, I see correct characters: BUT when I redirect the output to a file with ">" : GermanTest.exe > GermanTest.txt I get corrupted characters "Ž„™”š�á"

Re: [fpc-devel] Simple cast compiled as AS with -CR

On 30.12.2016 11:27, Jonas Maebe wrote: Yes, this is by design. The above code is invalid and relies on implementation details to work. E.g. with a JVM or CIL backend, the code would be rejected by the bytecode verifier too. Thank you Jonas for clarification. It may be worth to document it -

[fpc-devel] Simple cast compiled as AS with -CR

Hello, I have the following code program FPCcast; type TMyClass1 = class end; TMyClass2 = class(TMyClass1); var O: TMyClass1; begin O := TMyClass1.Create; TMyClass2(O).Free; // << 219-runtime error if compiled with -CR end. If I compile it with "-CR", I get a 219-runtime error

Re: [fpc-devel] FPC SetDynArrayProp

On 28.11.2016 17:37, Ondrej Pokorny wrote: Is SetObjectProp safe? OK, no it is not - it doesn't increment the reference count for properties without a setter: property Data: TBytes write FBytes; Ondrej ___ fpc-devel maillist - fpc-devel

[fpc-devel] FPC SetDynArrayProp

Hello! What is the correct way to set a published dynamic array property in FPC? In Delphi, you use SetDynArrayProp. Is SetObjectProp safe (packages\fcl-web\src\base\restbase.pp uses this approach)? See the attached project. Ondrej program TypInfoTBytes; uses Classes, SysUtils,

[fpc-devel] CriticalSection functions differ from Delphi

CriticalSection function names differ from Delphi: Delphi - FPC InitializeCriticalSection <> InitCriticalSection EnterCriticalSection "=" EnterCriticalsection LeaveCriticalSection "=" LeaveCriticalsection DeleteCriticalSection <> DoneCriticalsection Is there any reason for it? Is there a will

Re: [fpc-devel] NowUTC in FPC

On 21.07.2016 11:19, Denis Kozlov wrote: On 21 July 2016 at 10:04, Ondrej Pokorny <laza...@kluug.net <mailto:laza...@kluug.net>> wrote: Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?)

Re: [fpc-devel] NowUTC in FPC

On 21.07.2016 10:37, Denis Kozlov wrote: I've uploaded a patch to mantis: http://bugs.freepascal.org/view.php?id=30394 Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?) Ondrej

Re: [fpc-devel] Undefined symbol: SYSTEM_::=::\_DELETE compiler error

On 17.06.2016 14:27, Sven Barth wrote: Are you sure all units you use were rebuild? I did a clean and it helped! Thank you! Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] FPC 3.0.2 release target

On 31.05.2016 7:59, Marco van de Voort wrote: In our previous episode, Ondrej Pokorny said: Could you please include http://mantis.freepascal.org/view.php?id=28578 (r31434) into 3.0.2 as well? (Or confirm that it won't be merged.) Done. Thank you! Ondrej

Re: [fpc-devel] FPC 3.0.2 release target

On 20.05.2016 11:21, Ondrej Pokorny wrote: On 12.04.2016 9:22, Michael Van Canneyt wrote: I also think so, we've already been merging the necessary fixes to fixes_3_x Could you please include http://mantis.freepascal.org/view.php?id=28578 (r31434) into 3.0.2 as well? Could you please

Re: [fpc-devel] FPC 3.0.2 release target

On 29.05.2016 10:33, Michael Van Canneyt wrote: We're set to create the branch at the end of May, which is about now. The last merges have been performed. I assume Marco will tag somewhere this week, and then building starts. Great! Do you have a merge list on the net somewhere (like

Re: [fpc-devel] FPC 3.0.2 release target

On 12.04.2016 9:22, Michael Van Canneyt wrote: I also think so, we've already been merging the necessary fixes to fixes_3_x Could you please include http://mantis.freepascal.org/view.php?id=28578 (r31434) into 3.0.2 as well? Ondrej ___ fpc-devel

<    1   2   3   4   >