Hello FPC-Pascal,
Tuesday, November 17, 2009, 8:47:03 PM, you wrote:
c> Can the Fill... functions be changed to have the first parameter "out"
c> instead of "var" ? Surely they don't use it as an input parameter.
Write your own "fillchar" like function and inline it, something like:
procedure M
On 17 Nov 2009, at 20:47, cobines wrote:
> Can the Fill... functions be changed to have the first parameter "out"
> instead of "var"
No: http://lists.freepascal.org/lists/fpc-devel/2009-November/018532.html
Jonas
___
fpc-pascal maillist - fpc-pasc
>> In my humble opinion, there are no problems with the FillChar declaration.
>> But the way you wrote your _absolutely correct_ code produced a hint. You
>> shold use $HINTS OFF, for amendment to the FillChar declaration seems to be
>> done unlikely.
> But there is a reason for the hints. It shou
Can the Fill... functions be changed to have the first parameter "out"
instead of "var" ? Surely they don't use it as an input parameter.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/
Am Tuesday 17 November 2009 19:34:19 schrieb Bruce Bauman:
> I am using the FpTimes function from the BaseUnix package. The
> documentation says it returns -1 on an error, otherwise the number of
> clock ticks since boot time.
What does clock ticks exactly mean?
I am searching for an equivalent to
On 17 Nov 2009, at 19:34, Bruce Bauman wrote:
> I am using the FpTimes function from the BaseUnix package. The
> documentation says it returns -1 on an error, otherwise the number of
> clock ticks since boot time. However, the return type of this function
> is TClock, which is unsigned.
From "ma
I am using the FpTimes function from the BaseUnix package. The
documentation says it returns -1 on an error, otherwise the number of
clock ticks since boot time. However, the return type of this function
is TClock, which is unsigned.
This, if I say:
X := BaseUnix.FpTimes(T);
if (X <> -1) then ..
Hi,
Wahono activated a web interface with search function for
public.mseide-msegui.talk:
http://msegui.org/fudforum/index.php?t=thread&frm_id=2&S=a0f13320c71aa14a269ca8b4d05f4631
Martin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://
In my humble opinion, there are no problems with the FillChar declaration. But
the way you wrote your _absolutely correct_ code produced a hint. You shold use
$HINTS OFF, for amendment to the FillChar declaration seems to be done unlikely.
But there is a reason for the hints. It should point you
On Tue, 2009-11-17 at 06:48 +0700, Paul Ishenin wrote:
> Juha Manninen wrote:
> > I am planning to use this svn version for Lazarus experiments.
> > Is it a good idea?
> >
> not bad. use also lazarus trunk for experiments.
> > I selected the compiler and executable there but Lazarus complained a
Hello, Graeme!
Tuesday, November 17, 2009, 2:20:18 PM, you wrote:
> That you. I agree with JoshyFun though. It seems like it is actually a
> problem in the FillChar() definition and that should be fixed, instead of
> simply ignoring the hint.
> I raised this issue in the fpc-devel mailing list.
Fantomas wrote:
>
> That compiler hint appears because you have not assigned a value to the
> variable
> Temp before passing it to a function as a parameter. You can pay no attention
> to
> that hint or switch off hints in your code where the hint is produced, if it
> really bothers you.
That y
Hello, Graeme!
Tuesday, November 17, 2009, 1:03:22 PM, you wrote:
> And how do I solve this compiler hint? Normally I use FillChar(), but here it
> made no difference. The hint no simply moved to the line containing FillChar()
> call. :-(
> /home/graemeg/programming/3rdParty/DCPcrypt/dcpblockc
Hello Graeme,
Tuesday, November 17, 2009, 11:15:09 AM, you wrote:
GG> [...not that I fully understand the DCPCrypt code...]
GG> Looking at your code and the rest of DCPCrypt code, it seems it already
GG> optimized the calls to xorblock(), instead of inside xorblock()
[...]
That's not an "op
Hello Graeme,
Tuesday, November 17, 2009, 11:03:22 AM, you wrote:
GG> /home/graemeg/programming/3rdParty/DCPcrypt/dcpblockciphers.pas(229,16)
GG> Hint: Local variable "Temp" does not seem to be initialized
[...]
GG> raise EDCP_blockcipher.Create('Cipher not initialized');
GG> p1:= @Indata;
dmitry boyarintsev wrote:
> Seems like {$mode delphi} is used.
Indeed it is. :)
> here's faster version of xorblock
[...not that I fully understand the DCPCrypt code...]
Looking at your code and the rest of DCPCrypt code, it seems it already
optimized the calls to xorblock(), instead of insid
Hi,
And how do I solve this compiler hint? Normally I use FillChar(), but
here it made no difference. The hint no simply moved to the line
containing FillChar() call. :-(
/home/graemeg/programming/3rdParty/DCPcrypt/dcpblockciphers.pas(229,16)
Hint: Local variable "Temp" does not seem to be init
On Tue, Nov 17, 2009 at 12:48 PM, Graeme Geldenhuys
wrote:
> Changing those declarations to PByteArray type solves the compiler error
> in FPC.
Seems like {$mode delphi} is used.
here's faster version of xorblock
procedure XorBlockEx(var InData1, InData2; Size: longword);
var
l1 : PIntegerArra
dmitry boyarintsev wrote:
>
> But, since we're using 32-bit processors it's more effective to use
> 32-bit xor (where possible)!
Out of interest... Could you explain "use 32-bit xor"? How does that
differ to the code I posted?
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI to
dmitry boyarintsev wrote:
>
> procedure XorBlock(var InData1, InData2; Size: longword);
> var
> b1 : PByte;
> b2 ; PByte;
Changing those declarations to PByteArray type solves the compiler error
in FPC.
var
b1: PByteArray;
b2: PByteArray;
Regards,
- Graeme -
--
fpGUI Toolkit - a
Jonas Maebe wrote:
>
> Indeed. In general, I'd recommend to always add a pointer typecast
> though, to avoid problems in case the declared type should ever
> change.
Rather safe than sorry. I'll amend the code as such. Thanks for your help.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-p
dmitry boyarintsev wrote:
> Graeme, why don't you use power of the FPC (and it's pointer maths)?
> Pascal is language of readable code :)
The original code is not mine, I'm simply making it 64-bit friendly and
removing some compiler warnings where possible.
>
> procedure XorBlock(var InData1, In
On 17 Nov 2009, at 10:38, Graeme Geldenhuys wrote:
> So in that case because a untyped parameters are treated like generic
> Pointer types whereby arithmetic increments in byte size, I don't
> actually need any type casts the parameters at all?
Indeed. In general, I'd recommend to always add a p
Jonas Maebe wrote:
>> How to I solve this compiler hint?
>
> Don't cast ordinals to pointers.
:-)
> Replace the PtrUInt types casts with PByte (or Pointer) type casts.
So in that case because a untyped parameters are treated like generic
Pointer types whereby arithmetic increments in byte siz
Aleksa Todorovic wrote:
>
> Does that mean that (PByte(p) + N) = (Pointer(p) + N) for
> pointer-castable p and integer N?
I believe it does. I read in the ref.pdf document that when you
increment a generic Pointer type, it increments by 1 (equal to 1 byte).
Regards,
- Graeme -
--
fpGUI Too
On 17 Nov 2009, at 10:17, Aleksa Todorovic wrote:
> On Tue, Nov 17, 2009 at 10:05, Jonas Maebe wrote:
>>
>> Replace the PtrUInt types casts with PByte (or Pointer) type casts.
>>
>
> Does that mean that (PByte(p) + N) = (Pointer(p) + N) for
> pointer-castable p and integer N?
Yes. The genera
Graeme, why don't you use power of the FPC (and it's pointer maths)?
Pascal is language of readable code :)
procedure XorBlock(var InData1, InData2; Size: longword);
var
b1 : PByte; // in Delphi i'd use PByteArray
b2 ; PByte;
i: longword;
begin
b1:=...@indata1;
b2:=...@indata2;
for i:=
On Tue, Nov 17, 2009 at 10:05, Jonas Maebe wrote:
>
> Replace the PtrUInt types casts with PByte (or Pointer) type casts.
>
Does that mean that (PByte(p) + N) = (Pointer(p) + N) for
pointer-castable p and integer N?
___
fpc-pascal maillist - fpc-pasca
On 17 Nov 2009, at 10:02, Graeme Geldenhuys wrote:
> How to I solve this compiler hint?
Don't cast ordinals to pointers.
> -
> procedure XorBlock(var InData1, InData2; Size: longword);
> var
> i: longword;
> begin
> for i:= 1 to Size do
>Pbyte(PtrUInt(@InDa
Hi,
How to I solve this compiler hint? I've managed to get DCPCrypt
compiled and running successfully (with my current tests) under 64-bit
FPC & Linux.
But I still have many compiler hints as listed below. Can I simply
ignore them, or is there a way I can fix the code to remove the compiler
warn
30 matches
Mail list logo
