Re: [fpc-pascal] [fcl-web] [jsonrpc] [fpjsonrpc.pp] DoCheckParamArray in TCustomJSONRPCHandler
On Thu, 22 Feb 2024, Michael Anochin via fpc-pascal wrote: Hello, the TCustomJSONRPCHandler.DoCheckParamArray in fpjsonrpc.pp causes an exception with the message "List index (0) out of bounds". This happens, for example, if ParamArray is empty and there are not required parameter in ParamDef (required not set). In that case ParamArray[i] not exists, so Param:=ParamArray[i] raises "index out of bounds" exception. I would like to check this before assignment, may be like this procedure TCustomJSONRPCHandler.DoCheckParamArray(const ParamArray: TJSONArray); var I : Integer; Param: TJSONData; Def : TJSONParamDef; begin for I:=0 to ParamDefs.Count-1 do begin Def:=ParamDefs[i]; if I>=ParamArray.Count then if ParamDefs[i].Required then JSONRPCParamError(SErrParamsRequiredParamNotFound,[def.Name]); //Check ParamArray.Count first if (IjtUnknown) and not (Param.JSONType=def.DataType) then JSONRPCParamError(SErrParamsDataTypeMismatch,[def.Name,JSONTypeName(def.DataType),JSONTypeName(Param.JSONType)]); As it happens, I was working on adding some things to fpjsonrpc, so I fixed this issue by putting the code in an else branch. I pushed that change. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] [fcl-web] [jsonrpc] [fpjsonrpc.pp] DoCheckParamArray in TCustomJSONRPCHandler
Hello, the TCustomJSONRPCHandler.DoCheckParamArray in fpjsonrpc.pp causes an exception with the message "List index (0) out of bounds". This happens, for example, if ParamArray is empty and there are not required parameter in ParamDef (required not set). In that case ParamArray[i] not exists, so Param:=ParamArray[i] raises "index out of bounds" exception. I would like to check this before assignment, may be like this procedure TCustomJSONRPCHandler.DoCheckParamArray(const ParamArray: TJSONArray); var I : Integer; Param: TJSONData; Def : TJSONParamDef; begin for I:=0 to ParamDefs.Count-1 do begin Def:=ParamDefs[i]; if I>=ParamArray.Count then if ParamDefs[i].Required then JSONRPCParamError(SErrParamsRequiredParamNotFound,[def.Name]); //Check ParamArray.Count first if (IjtUnknown) and not (Param.JSONType=def.DataType) then JSONRPCParamError(SErrParamsDataTypeMismatch,[def.Name,JSONTypeName(def.DataType),JSONTypeName(Param.JSONType)]); end; end; //<< added end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
On 22/02/2024 14:22, Jean SUZINEAU via fpc-pascal wrote: As far as I know Extended is not supported on Linux. This is wrong, sorry. I'm using Extended on Linux and it works just fine. Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
Op 22-2-2024 om 15:08 schreef Thomas Kurz via fpc-pascal: If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in runtime will ever calculate anything with that precision. That's another thing I've never understood. How can it depend on the OS? It's the CPU which does math, and I don't understand what the OS has to do with that? If amd64 architecture didn't support the extended-type at all, I'd say "ok". But it's supported on Linux but not on Windows? Huh? The problem is not that it is only Extended that is deprecated on win64, but the whole of x87. To replace it, the Windows 64-bit ABI points to SSE2 floating point math which only goes up to 64-bit Double. I.e. it is not that Microsoft might not in time save the few extra bits of an extended in a x87 context save, but more that it won't save the x87 state at all, and only save the SSE2 state. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
I seem to recall there is some way to get 80 Bit Extended on 64 Bit Windows, but it involved compiling a 64bit version of FPC myself somehow, and I can't remember what it was all about, I'm pretty sure I was doing that for a while, but then I wanted to upgrade and couldn't remember how it was all done, so I went back to Win32, just to get 80 Bit Extended. It's something to do with the cross compiler to 64 bit makes extended a double on 64bit, but if you weren't cross compiling and had just a native 64bit compiler then Extended is 80 bits again. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
I see that Wikipedia is not very clear on this, you just find "x86" mentioned, but for Pascal: "this Extended type is available on 16, 32 and 64-bit platforms, possibly with padding" https://en.wikipedia.org/wiki/Extended_precision ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> For constants, the compiler will choose a type and consequently the
> precision.
> Jonas and others have explained the rules that the compiler uses.
>
> If you don't like the rules that the compiler uses, you can set a type for
> your
> constants. When you explicitly set a type, you are also specifying the
> precision of the > calculation.
If the ruleset won't change - and from what I've read from the developers, it
won't change - could we please have the compiler issue a warning (or a hint) if
a loss in precision happens.
E.g. "Warning: constant reduced to single precision. Use {$MINFPCONSTPREC} or
Double() to keep full precision."
I am aware about this behavior now, but nevertheless I'd like to get warned if
I forget about either of those.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
Aaaah, ok. Thank you very much for alrifying this long-standing question! - Original Message - From: Tomas Hajny via fpc-pascal To: FPC-Pascal users discussions Sent: Thursday, February 22, 2024, 15:25:34 Subject: [fpc-pascal] Floating point question On 2024-02-22 15:08, Thomas Kurz via fpc-pascal wrote: >> If you're using Win64, then the answer is simple: x86_64-win64 unlike >> any >> other x86 target does not support Extended, so neither the compiler >> nor the >> code in runtime will ever calculate anything with that precision. > That's another thing I've never understood. How can it depend on the > OS? It's the CPU which does math, and I don't understand what the OS > has to do with that? If amd64 architecture didn't support the > extended-type at all, I'd say "ok". But it's supported on Linux but > not on Windows? Huh? The reason is that the operating system is among others responsible for controlling the multitasking. That includes saving the context of the originally active task and restoring the context of the new task to the original state before it was interrupted. If Win64 doesn't guarantee restoring FPU registers specific to the extended type, using this type would get you into troubles despite its support in the FPU. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> for example, here on Earth, (7 decimal places) 0.001 degree latitude is > ""only"" 1cm... (8 decimal places) 0.0001 degree latitude is ""only"" > 1mm... > longitude, on the other hand, is variable such that 7 decimal places at the > equator is the same as latitude but as you move toward the poles, it changes > such that 4 decimal places is 20cm... My initial problem (i.e. why I asked the original question -- which I do regret meanwhile *g*) was that we do use floating-point numbers for date and time operations. (TDateTime = Double) And I had discrepancies of about 40 seconds when converting between astronomical dates and TDateTime. This was how it all started... We need approx. 5 decimals to represent one second (because the non-fractional part is considered being the day number). So "single" precision isn't acceptable here. If TDateTime were Unix-timestamp, it wouldn't matter. But since TDateTime is Julian day number (maybe with an offset, but that's irrelevant here), it unfortunately does matter. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
On 2024-02-22 15:08, Thomas Kurz via fpc-pascal wrote: If you're using Win64, then the answer is simple: x86_64-win64 unlike any other x86 target does not support Extended, so neither the compiler nor the code in runtime will ever calculate anything with that precision. That's another thing I've never understood. How can it depend on the OS? It's the CPU which does math, and I don't understand what the OS has to do with that? If amd64 architecture didn't support the extended-type at all, I'd say "ok". But it's supported on Linux but not on Windows? Huh? The reason is that the operating system is among others responsible for controlling the multitasking. That includes saving the context of the originally active task and restoring the context of the new task to the original state before it was interrupted. If Win64 doesn't guarantee restoring FPU registers specific to the extended type, using this type would get you into troubles despite its support in the FPU. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
Le 22/02/2024 à 15:08, Thomas Kurz via fpc-pascal a écrit : But it's supported on Linux but not on Windows? Huh? As far as I know Extended is not supported on Linux.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> If you're using Win64, then the answer is simple: x86_64-win64 unlike any > other x86 target does not support Extended, so neither the compiler nor the > code in runtime will ever calculate anything with that precision. That's another thing I've never understood. How can it depend on the OS? It's the CPU which does math, and I don't understand what the OS has to do with that? If amd64 architecture didn't support the extended-type at all, I'd say "ok". But it's supported on Linux but not on Windows? Huh? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
