Search the Community

I found myself down the rabbit hole of IEEE 754 standard on Floating-Point numbers (which Delphi follows), specifically the different values of NaN.... There are multiple potential internal values for NaN, all which evaluate as fsNaN. I found what I believe to be a bug, but I'm curious if anyone else has any thoughts on it. (As I was writing this up I discovered the behavior is only on Win32, so I've decided it must be a bug (RSS-1831), but sharing here anyway because I find the details interesting.) In short: IEEE 754 distinguishes between Signaling NaN and Quiet NaN. Delphi defaults to Quiet NaN, but you can make it signaling manually. Unfortunately, when a float is returned from a function in the Win32 compiler, the quiet flag is set. I was testing to see if Delphi converted it into an exception, which would be understandable, but instead it just silently sets the quiet flag, suppressing the signaling state. Testing in FPC, Delphi Win64, or Delphi Linux64, and the flag value doesn't change, which is what I would expect. Detailed explanation and background IEEE 754 divides a float into 3 parts Sign Exponent Fraction For a NaN the Exponent bits are all set ($FF in Single), any value for sign (Delphi's default NaN has it set, making it a negative NaN, which doesn't carry any specific significance), and the Fraction is anything but all 0. This allows for quiet a few different values that all are treated as NaN. What may distinguish the different values of NaN is signaling vs. quiet NaN. The Quiet flag is usually the first bit of the fraction. When the quiet flag isn't set, then it is considered a signaling NaN. The internal the internal representation of a NaN is typically displayed as follows (notice this is reversed from how Delphi stores the value in memory to put the most significant bit first.) S Exponent Fraction 1 | 11111111 | 10000000000000000000000 ^ The quiet flag So a signaling NaN is has an value for Faction without that first bit set. What I found in Delphi Win32 is it handles all these values correctly, except that if the quiet flag is missing (making it a signaling NaN), then when the value is returned from a function the quiet flag is set. Before returning from function: (Notice that the debugger recognizes it as negative NaN. Very nice!) This is 1 | 11111111 | 00000000000000000000001 in binary, which doesn't have the Quiet flag set 1 | 11111111 | 10000000000000000000001 After return it isn't the Default NaN, but it is the previous value with the Quiet flag set. Here is some sample code that demonstrates the behavior // The Delphi Win32 (tested in Delphi 12.1 and 12.2) sets NaN's quiet flag when are returning from a function // More information on IEEE 754 NaN https://en.wikipedia.org/wiki/NaN#Quiet_NaN // More information on this code: https://gist.github.com/jimmckeeth/2b4f017917afbae88ee7a3deb75b4ef7 program NaNSignalBug; {$APPTYPE CONSOLE} uses System.SysUtils;//, SingleUtils in 'SingleUtils.pas'; function is_Signaling(const NaN: Single): Boolean; begin Result := NaN.IsNan and (NaN.Frac and $400000 = 0); end; function NaNDetails(const Value: Single): string; begin if value.IsNan then begin if is_Signaling(value) then Result := 'NaN is Signaling' else Result := 'NaN is Quiet'; end else Result := 'Not a NaN'; end; procedure MakeSignaling(var NaN: Single); begin NaN.Exp := 255; NaN.Frac := NaN.Frac and not (1 shl 22); Assert(is_Signaling(NaN)); Writeln('Manipulated: ',NaNDetails(NaN),#9, '// Line 33'); end; // When a NaN is returned from a function the Signal bit is set function SignalingNaN: Single; begin Result := Single.NaN; Result.Frac := 1; MakeSignaling(Result); Assert(is_Signaling(Result)); Writeln(#9,'SignalingNaN Returning',#9'// Line 43'); end; function NestedNaN: Single; begin var NaN : Single := SignalingNaN; // The quiet bit was set Writeln('Returned: ',NaNDetails(NaN),#9, '// Line 50'); // without returning it from a function it works fine MakeSignaling(NaN); Writeln('Manipulated: ',NaNDetails(NaN),#9, '// Line 53'); Assert(is_Signaling(NaN)); Writeln(#9,'NestedNaN Returning ',#9,'// Line 55'); Exit(NaN); end; begin try Writeln(TOSVersion.ToString); Writeln('Used: ',SizeOf(NativeInt)*8,'-bit compiler'); var NaN : Single := NestedNaN; // The quiet bit was set Writeln('Returned: ', NaNDetails(NaN),#9,'// Line 66'); //Assert(is_Signaling(NaN)); // Fails on Win32 // without returning it from a function it works fine MakeSignaling(NaN); Writeln('Manipulated: ', NaNDetails(NaN),#9,'// Line 70'); Assert(is_Signaling(NaN)); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; readln; end. and here is the output Windows 11 (Version 23H2, OS Build 22631.4169, 64-bit Edition) Used: 32-bit compiler Manipulated: NaN is Signaling // Line 33 SignalingNaN Returning // Line 43 Returned: NaN is Quiet // Line 50 Manipulated: NaN is Signaling // Line 33 Manipulated: NaN is Signaling // Line 53 NestedNaN Returning // Line 55 Returned: NaN is Quiet // Line 66 Manipulated: NaN is Signaling // Line 33 Manipulated: NaN is Signaling // Line 70 and a more detailed look at the NaN values Default NaN Value of : Nan Special : fsNaN Sign : TRUE Exponent : 255 Fraction : 4194304 Size : 4 InvertHex: $FFC00000 1 | 11111111 | 10000000000000000000000 ----------------- Singnaling NaN Value of : Nan Special : fsNaN Sign : TRUE Exponent : 255 Fraction : 1 Size : 4 InvertHex: $FF800001 1 | 11111111 | 00000000000000000000001 ----------------- Returned from Function Value of : Nan Special : fsNaN Sign : TRUE Exponent : 255 Fraction : 4194305 Size : 4 InvertHex: $FFC00001 1 | 11111111 | 10000000000000000000001 @David Heffernan it was suggested I tag you on this... NaNSignalBug.dpr

I want to share my disappointment with you. I work with Delphi 11.3 (Patch 1) and every day I see amazing things. Starting with Code Insight, which works 1 out of 3 times. Then, when it stops working, there is no way to reactivate it. The new feature that allows you to highlight the selected words in the code works badly, often when I select a word with a double click the document is moved and becomes unreadable until I scroll through the document, this thing makes me waste a LOT of TIME. It is also dangerous because you risk to write in another part of the code! (it happened to me...) When I am working on the graphical interface of a form, it can happen that the IDE freezes completely and I have to force the PID to close! Sometimes the compiler goes "out of memory" and in the best case you can save and close Delphi, in the worst case Delphi crashes and you lose the work you've done if you haven't saved it. And those are just the biggest problems, I'll leave the rest out. Now I learn that Delphi 12 is being released, but how can Embarcadero offer me a new version of Delphi? And the Delphi 11 bugs, WHO CAN SOLVE THEM? The last update to Delphi 11 was in APRIL!!!! This means that I should update to Delphi 12, which will certainly have NEW BUGS and will not have fixed the bugs of version 11 (as happened to me every time I changed versions...). When do you think we will be able to go on like this? Visual Studio is updated EVERY WEEK. I have to work every day with an IDE that slows me down and most of all with an IDE that NO ONE MAINTAINS! I would like someone like Marco Cantù to explain to me why Embarcadero is destroying the trust of their customers in this way, why they are neglecting the essentials to continue blowing smoke in our faces. Sorry for the outburst, but it's really frustrating to work like this.

I did discovered a bug i guess by accident. I wanted to expand my own .inc file to support FreePascal but compiler did not let me. {$IF Defined(FPC)} {$IF Declared(FPC_VERSION)} {$IF FPC_VERSION >= 3} // [Pascal Error] kz.inc(80): E2026 Constant expression expected {$DEFINE UNICODE} {$IFEND FPC_VERSION} {$IFEND FPC_VERSION} {$IFEND FPC} A fix was to do it like this, himitsu from german Delphi-Praxis came up with: {$IF Defined(FPC) and Declared(FPC_VERSION) and (FPC_VERSION >= 3)} {$DEFINE UniCode} { FreePascal UniCode support } {$IFEND} I did open a Report -> Conditional Compiling dont work as expect If you think i was wrong, please correct me.

Whenever a new Delphi version is out, there is this small tedious job I do of customizing the Toolbar. I add some speedbuttons (Exit, Close All, Compile project, Project Options and a few more), and I delete a few others that I don't use. (I never found a smart way to copy the settings from a previous Delphi version to a new version. The Migration Tool never works. This time I tried migrating from 10.4 to 10.5. Version 11 wasn't listed, so I guessed 10.5 actually stands for 11. Anyway. no luck there). So I added some and removed some. Then restarted Delphi. The result, in short: removal works, but adding does not. So removing for once is removing forever. Well, actually, adding speedbuttons to the toolbar works during a session. Restart and they are gone again. Anyone else seeing this? (shall i submit a bug report to QC?) Is there a solution or workaround?

Hi Folks, I have a strange bug when a VCL styled application is maximized in a dual monitor configuration. Steps to reproduce: 1. Set your windows task bar position to "top" 2. Create a minimal application and activate a VCL style (add a main menu if you like) 3. Run the application and: * maximize it on the primary monitor (fine) * maximize it on the secondary monitor (The top part of the application, probably the height of the windows task bar, becomes transparent) left: maximized on primary monitor right: maximized on secondary monitor Additional Info: * My two monitors have different resolutions and they have a vertical offset * This bug doesn't seem to affect many people (no customer has reported it so far ;-)) * This is not a new bug. I've seen for years (three to four) it in several Delphi versions, but I can't put a date on it Today I tried to find out if it is a problem with our main form's settings, but since it also happens with a minimal application, it probably isn't. Has anybody encountered this as well? Does anyone know how to fix it? Do I have to wait for Emba to fix it? Cheers & thanks Lübbe

The function declarations for f_EVP_PKEY_get_raw_private_key() and f_EVP_PKEY_get_raw_public_key() each have a wrong parameter type: outlen: Integer. The correct type is outlen: size_t. On 64-bit, this can lead to memory overwrite if the 64-bit size_t is written to the 32-bit Integer. Reference: https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_get_raw_private_key.html Ralf

From a Github issue description for our SynPDF Open Source project: Generating a PDF via VLCCanvas and TPdfDocumentGDI causes access violation when compiled with Delphi 10.4.1 with record field alignment compiler option set to "byte" or "off". When this option is set to either of "word", "double word" or "quad word", the PDF gets created without errors. The same exact code works fine when compiled with Delphi 10.4 (patch 3), regardless of the field alignment flag. We added {$A+} and it seemed to fix the problem. https://blog.synopse.info/?post/2020/09/09/Record-Alignement-and-Delphi-10.4.1 Sadly, I don't have access to Delphi 10.4.1 since I don't have any commercial licence, and I am waiting for the Community Edition - which is still 10.3 IIRC. So I couldn't debug the root cause and fill a JIRA ticket to EMB. Perhaps some people from Delphi-Praxis may have encountered this issue, and found the root cause... Maybe it is was a real fix introduced in 10.4.1, and the previous behavior was incorrect: perhaps an explicit {$A+} is required when working with records... but at least, it breaks existing code, so spreading the info may help...

Hi, just for you guys to weigh in, we have located a bug in the Delphi 10.4 compiler, that removes a totally valid assign statement in RELEASE mode, believing, that the code will never be executed. The actual method is from the mORMot library in releases before last week (unit SynCommons.pas, method TSynAnsiFixedWidth.AnsiBufferToUTF8. A full discussion is available at the mORMot-Forum: https://synopse.info/forum/viewtopic.php?id=5520 . I have reported the bug to Embarcadero: https://quality.embarcadero.com/browse/RSP-30088 . Please check out my report and try to confirm and weigh in there. It should be reproducible. --- Note, the compiler will tell you (Hint H2077), that the value assigned is never used and thus, in RELEASE mode, with optimizations enabled, drop the code completely. Thanks for your time and support 👍

f_CRYPTO_get_ex_data should return Pointer, not Integer. The code in question is at OverbyteIcsLIBEAY.pas line 1847, SVN 1476: f_CRYPTO_get_ex_data: function(r: PCRYPTO_EX_DATA; idx: integer): integer; cdecl = Nil; The corresponding C declaration from OpenSSL's crypto.h: void *CRYPTO_get_ex_data(const CRYPTO_EX_DATA *ad, int idx); Suggested solution: f_CRYPTO_get_ex_data: function(r: PCRYPTO_EX_DATA; idx: integer): Pointer; cdecl = Nil; Reference: https://www.openssl.org/docs/man1.1.1/man3/CRYPTO_get_ex_data.html Ralf

EVP_PKEY_paramgen() pkey should be a double pointer parameter. OverbyteIcsLIBEAY.pas line 1752, SVN 2063: f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; pkey: PEVP_PKEY): Integer; cdecl = Nil; Notice the two ** asterisks in the OpenSSL's evp.h C declaration: int EVP_PKEY_paramgen(EVP_PKEY_CTX *ctx, EVP_PKEY **ppkey); Possible fixes: { More C like: Better if ppkey may be nil. } f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; ppkey: PPEVP_PKEY): Integer; cdecl = Nil; { More Pascal like. Notice that nil cannot be passed this way. } f_EVP_PKEY_paramgen: function(pctx: PEVP_PKEY_CTX; var pkey: PEVP_PKEY): Integer; cdecl = Nil; Reference: https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_paramgen.html Ralf

At the time of this writing, TCryptoExNewFunc is declared as a function while it should be a procedure. OverbyteIcsLIBEAY.pas line 1752, SVN 1476: TCryptoExNewFunc = function(parent: Pointer; ptr: Pointer; ad: PCRYPTO_EX_DATA; idx: integer; argl: DWord; argp: Pointer): Integer; cdecl; This is the corresponding C declaration from OpenSSL's crypto.h, documented here: https://www.openssl.org/docs/man1.1.1/man3/CRYPTO_EX_new.html typedef void CRYPTO_EX_new (void *parent, void *ptr, CRYPTO_EX_DATA *ad, int idx, long argl, void *argp); This is the Pascal translation matching the C declaration: TCryptoExNewFunc = procedure(parent: Pointer; ptr: Pointer; ad: PCRYPTO_EX_DATA; idx: integer; argl: DWord; argp: Pointer); cdecl; Ralf

note: We have seen these issues with multiple versions of the OpenSSL binaries, including the ones bundled with ICS 8.64. Please consider the following code snippet: var s := TSslContext.Create(nil); try s.SslCALines.Text := sslRootCACertsBundle(); try s.InitContext(); except on e: exception do ShowMessage(e.Message); end; finally s.Free(); end; This snippet works on most machines, but we have a few machines at client sites, where this code raises an exception: 'Error reading info file "Lines"'. (We haven't figured out yet why these specific machines have this issue). This exception is raised on OverbyteIcsWSocket.pas:14667 (ICS 8.64). InfoStack := PStack(f_PEM_X509_INFO_read_bio(InBIO, nil, nil, nil)); if not Assigned(InfoStack) then raise ESslContextException.CreateFmt('Error reading info file "%s"', [FileName]); Apparently the call to f_PEM_X509_INFO_read_bio() failed, but no information is give why, so we've added some calls to f_ERR_get_error() to see what is going wrong, and then it turns out the call to f_PEM_X509_INFO_read_bio() sets the error code 151580774 (get_header_and_data). To find out which of the hard coded certificates returned by sslRootCACertsBundle() were making this error happening, we've passed each of the certificates (sslRootCACerts001, sslRootCACerts002, etc) one by one to an TSSLContext to see which ones failed. This showed 2 interesting things: There is a 'typo' in sslRootCACerts009 and sslRootCACerts011: 'AGAT/3B+XxFNSRuzFVJ7yVTav52Vr2ua2J7p8eRDjeIRRDq/r72DQnNSi6q7pynP' + #13#10 + '9WQcCk3RvKqsnyrQ/39/2n3qse0wJcGE2jTSW3iDVuycNsMm4hH2Z0kdkquM++v/' + #13#10 + 'eu6FSqdQgPCnXEqULl8FmTxSQeDNtGPPAUO6nIPcj2A781q0tHuu2guQOHXvgR1m' + #13#10 + '0vdXcDazv/wor3ElhVsT/h5/WrQ8' + #13#10; sslRootCACerts010 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + and 'S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb' + #13#10 + 'QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl' + #13#10 + '0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB' + #13#10 + 'NVOFBkpdn627G190' + #13#10; sslRootCACerts012 = '-----END CERTIFICATE-----' + #13#10 + '# X509 SSL Certificate' + #13#10 + (the END CERTIFICATE line is part of the wrong constant), which isn't a problem when you call sslRootCACertsBundle() since all constants are concatenated, but which shows up if you try to use these certificates separately. More interestingly, one these specific machines there seems to be an issue with sslRootCACerts033 and sslRootCACerts034. This is sslRootCACerts033: # X509 SSL Certificate # Subject Common Name: GlobalSign # Subject Organisation: GlobalSign # Subject Organisation Unit: GlobalSign Root CA - R2 # GlobalSign Root R2 SHA1 • RSA • 2048 # Issuer: Self Signed # Expires: 15/12/2021 -----BEGIN CERTIFICATE----- MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1 MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8 eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG 3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO 291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7 TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg== -----END CERTIFICATE----- When processing this certificate on these specific machines OpenSSL gives this error, unless: - I remove one of the • in the 5th line from the top. (As long as there is only 1 • in the file it's ok, as soon as I add a 2nd • anywhere in the header the error returns) - I add a CRLF at the bottom of the file The same thing applies to sslRootCACerts034. I realize that this is probably a bug in OpenSSL itself, but it might be wise to remove the •'s from the hard coded certificates to work around this issue. Curious if anyone can shed some light on the cause of this 🙂 Merijn

In OverbyteIcsWSocket.pas, PunyServerName is always filled with 8-bit data, even if it is a 16-bit UnicodeString on Unicode Delphis. This happens in OverbyteIcsWSocket.pas line 15916 (SVN 1469): Move(DataExt[5], Ws.FCliHelloData.PunyServerName[1], Slen); The line above works well with non Unicode Delphis, but copies incorrect data in Unicode enabled Delphis. Cause is the declaration of PunyServerName (line 3488): TClientHelloData = record ServerName: String; PunyServerName: String; // <-- Problem here. ... Later on, this results in incorrect conversion to ServerName. See that the OverbyteIcsSslWebServ demo outputs garbled SNI and Server Name instead of localhost: HTTPS Server is waiting for connections https://localhost/demo.html HTTP Server is waiting for connections http://localhost/demo.html [10:17:36 127.0.0.1] SNI "潬慣桬獯t Client Hello: Server Name: 潬慣桬獯t [10:18:15 127.0.0.1] SNI "潬慣桬獯t Client Hello: Server Name: 潬慣桬獯t A quick remedy is to declare PunyServerName as AnsiString and work around the warning "OverbyteIcsWSocket.pas(15968): W1057 Implicit string cast from 'AnsiString' to 'string'", possibly be adding a typecast. TClientHelloData = record ServerName: String; PunyServerName: AnsiString; // <-- 8-bit string, even in Unicode Delphis. ... Ralf

OverbyteIcsLIBEAY.pas line 1994 (SVN 1469) declares f_EVP_DigestSignInit() like this: f_EVP_DigestSignInit: function(ctx: PEVP_MD_CTX; pctx: PEVP_PKEY_CTX; etype: PEVP_MD; impl: PEngine; pkey: PEVP_PKEY): Integer; cdecl = Nil; In Pascal, pctx is a single pointer, but C declares pctx as a double pointer: int EVP_DigestSignInit(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, const EVP_MD *type, ENGINE *e, EVP_PKEY *pkey); Following nearby declarations, Pascal should probably change pctx to a var parameter. Reference: https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestSignInit.html Ralf

Samples\Delphi\SslInternet\OverbyteIcsHttpsServer1.pas line 415 has a reference to OverbyteIcsWSocket.SslWSocketCopyRight which does not exist: Display(' ' + Trim(OverbyteIcsWSocket.SslWSocketCopyRight)); As a result, the OverbyteIcsHttpsServer1.pas unit does not compile. Ralf

OverbyteIcsLIBEAY.pas line 2336 (SVN 1464) declares f_X509_check_ip_asc() like this: f_X509_check_ip_asc: function(Cert: PX509; Paddress: PAnsiChar; namelen: size_t; flags: Cardinal): Integer; cdecl = nil; This is different from the OpenSSL definition. The Pascal declaration has an extra namelen parameter not present in the C header: int X509_check_ip_asc(X509 *, const char *address, unsigned int flags); Reference: https://www.openssl.org/docs/man1.1.1/man3/X509_check_ip_asc.html Ralf

OverbyteIcsSSLEAY.pas line 2160 (SVN 1464) declares f_SSL_set_msg_callback() to use a TProto_msg_cb callback. TProto_msg_cb is defined in line 1270 as a function: TProto_msg_cb = function (write_p, version, content_type: integer; buf: PAnsiChar; size_t: integer; ssl: PSSL; arg: Pointer): Integer; cdecl; { V8.40 handshake protocol message callback } This is different from the OpenSSL definition. The C header declares the callback as a procedure which does not return a value (void): void SSL_CTX_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg)); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_set_msg_callback.html Ralf

OverbyteIcsSSLEAY.pas line 2097 (SVN 1464) declares f_SSL_clear() like this: f_SSL_clear: procedure(S: PSSL); cdecl = nil; This is different from the OpenSSL definition. The Pascal declaration is a procedure, but the C declaration a function with an Integer return value: int SSL_clear(SSL *ssl); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_clear.html Ralf

OverbyteIcsSSLEAY.pas line 2095 (SVN 1464) declares f_SSL_bytes_to_cipher_list() like this: f_SSL_bytes_to_cipher_list: function(s: PSSL; cbytes: PAnsiChar; len: size_t; isv2format: Boolean; sk, scvsvs: PSTACK_OF_SSL_CIPHER): LongInt; cdecl = nil; { V8.64 } This is different from the OpenSSL definition. The Pascal declaration passes sk and scvsvs as simple pointers, instead of pointer addresses or var parameters. In contrast, the C header uses a double pointer for both parameters: int SSL_bytes_to_cipher_list(SSL *s, const unsigned char *bytes, size_t len, int isv2format, STACK_OF(SSL_CIPHER) **sk, STACK_OF(SSL_CIPHER) **scsvs); Reference: https://www.openssl.org/docs/man1.1.1/man3/SSL_bytes_to_cipher_list.html Ralf

When selected option is on than two spaces before local procedure/function are missing. Tested on GExperts 1.3.15 build 84 version.

I finally got around to installing 10.3.3 and now I get this message every time I quit Delphi: --------------------------- Anwendungsfehler --------------------------- Exception EAssertionFailed in Modul GExpertsRS103.dll bei 00055131. Call DeactivateFontsInfo before calling this. (D:\source\_sourceforge\GExperts\externalsource\UniSynEdit\SynTextDrawer.pas, Zeile 475). --------------------------- OK --------------------------- I have been getting a more generic error ever since 10.2 but kind of got used to it. This now is more specific and I'll report it to the GExperts bug tracker as well.

Hi, I try to adopt outstanding and free Pas2js transpiler to Delphi language. My main development IDE is Delphi CE Rio, so I decided to try a new Delphi syntax: generic collections and inline variables. And stumbled upon a runtime error. The code (simplified): program TestInlineVarForDictionary; {$APPTYPE CONSOLE} {$R *.res} uses SysUtils, Generics.Collections; procedure TestDictErr; var Dict: TDictionary<string,TObject>; begin Dict := TDictionary<string,TObject>.Create; for var item in Dict do Writeln('Key = ', item.Key, 'Name = ', item.Value.ClassName); end; procedure TestDictOK; var Dict: TDictionary<string,TObject>; item: TPair<string,TObject>; begin Dict := TDictionary<string,TObject>.Create; for item in Dict do Writeln('Key = ', item.Key, 'Name = ', item.Value.ClassName); end; begin try //!!TestDictOK; TestDictErr; except on E: Exception do begin Writeln(E.ClassName, ': ', E.Message); Write('Press Enter to continue...'); Readln; end; end; end. This program causes Exception class $C0000005 with message 'access violation at 0x0040a86e: write of address 0x0040a29e'. Can you confirm it? Is it a bug in the compiler or/and RTL, or am I misusing the new syntax? It's interesting: if you uncomment TestDictOK that does enumeration in old-style, the exception will disappear!

I have the following code (Delphi Berlin): interface type TSliver = record public private case integer of 8: (Data8: int64); end; TSlice = record private FData: array [0..63] of byte; end; TSliverHelper = record helper for TSliver class function NS(const North, South: TSlice; out Changed: TSliverChanges): TSliver; static; inline; end; {$L 'C:\mydir\AVXGenerate.o'} //imported assembly generated by lazarus. procedure AVXGENERATE_TSLIVERHELPER_NS; external name 'AVXGENERATE_$$_TSLIVERHELPER_NS'; //no parameters for simplicity. implementation class function TSliverHelper.NS(const North, South: TSlice; out Changed: TSliverChanges): TSliver; {inline;} //RCX =North: PSlice //RDX =South: PSlice //R8 = Changed: PSliverChanges ((scUnchanged=0, scChanged=1, scInvalid=3)); //RAX = Result: TSliver (as Int64) begin AVXGENERATE_TSLIVERHELPER_NS; end; //asm // jmp AVXGENERATE_TSLIVERHELPER_NS; //end; The asm method works correctly, the inlined method does not. If we look at the generated code it's easy to see why this happens. a:= TSliver.NSTest(N,S,statusA); //a = -1 UnitTests.pas.877: b:= TSliver.NS(N,S, statusB); 00000000009A77CE 488D8C2480000000 lea rcx,[rsp+$0080] 00000000009A77D6 488D542440 lea rdx,[rsp+$40] 00000000009A77DB 4C8D44242E lea r8,[rsp+$2e] 00000000009A77E0 E82B5E0100 call TSliverHelper.NS 00000000009A77E5 4889442430 mov [rsp+$30],rax //b = 7 why? //Let's see what's happening in the inlined method. class function TSliverHelper.NS(const [ref] N,S: TBigRec; out status: TEnumRec): UInt64_Rec; Unit2.pas.4360: begin 00000000009BD610 55 push rbp 00000000009BD611 4883EC30 sub rsp,$30 00000000009BD615 488BEC mov rbp,rsp Unit2.pas.4361: AVXGENERATE_TSLIVERHELPER_NS; 00000000009BD618 E833350000 call AVXGENERATE_TSLIVERHELPER_NS //external asm procedure with no declared params. Unit2.pas.4362: end; //At this point RAX = result = -1, all OK 00000000009BD61D 488B4528 mov rax,[rbp+$28] //Oops, RAX gets overwritten, why? <<<<??????????????????????? 00000000009BD621 488D6530 lea rsp,[rbp+$30] 00000000009BD625 5D pop rbp 00000000009BD626 C3 ret Why does the compiler insert an assignment to RAX? I have not instructed it to do anything of the sort. Compiling this code also does not issue a warning that Result might be unassigned. Why does the compiler do this? (I know I can fix this by declaring the external proc as a function, but that's beside the point). EDIT When we redefine the external proc as a function and change the inline method as shown below, correct code gets generated. It also gives some insight what is going on: Unit2.pas.4360: begin 00000000009BD610 55 push rbp 00000000009BD611 4883EC30 sub rsp,$30 00000000009BD615 488BEC mov rbp,rsp Unit2.pas.4361: Result:= AVXGENERATE_TSLIVERHELPER_NS; 00000000009BD618 E833350000 call AVXGENERATE_TSLIVERHELPER_NS 00000000009BD61D 48894528 mov [rbp+$28],rax //pointless stack trashing Unit2.pas.4362: end; 00000000009BD621 488B4528 mov rax,[rbp+$28] //the exit code expects Result to be in the stackframe. 00000000009BD625 488D6530 lea rsp,[rbp+$30] 00000000009BD629 5D pop rbp 00000000009BD62A C3 ret The compiler is just copy pasting its exit code, regardless of the actual code in the body. Note that I've compiled the code with no stackframes