[fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread Reinier Olislagers 
On 2-4-2013 5:13, Noah Silva wrote:
> Actually I think on OS X and Linux it makes sense to depend on OpenSSL,
> but not for the reasons you mentioned so much as one more: Security. 

That's probably why the previous poster wrote robust etc. Sounds like
security attributes to me.

> If
> you are using doing encryption, then it's better to use a library that
> is updated more often for bug fixes, and to have the updates be applied
> to your program automatically.  If you static-link it in, it will never
> be updated until you update it and ship a new version of your program
> and everyone installs it.  If you dynamically link to it, then then the
> operating system updates it, you get the updates "for free".  


If you feel so strongly about it, why not submit a patch that uses
OpenSSL on platforms that are sure to have it and use Silvio's native
code for others?

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread Noah Silva 
Hi Reinier,

2013/4/2 Reinier Olislagers 

> ...
>
> be updated until you update it and ship a new version of your program
> > and everyone installs it.  If you dynamically link to it, then then the
> > operating system updates it, you get the updates "for free".
>
> If you feel so strongly about it, why not submit a patch that uses
> OpenSSL on platforms that are sure to have it and use Silvio's native
> code for others?
>

Haha I was just mentioning one positive benefit.  Also, I am pretty sure
Synapse can use the OpenSSL DLLs.

I am much more likely to submit some patches to the OS X GUI for Lazarus
that I have been fixing in the last week or so.  We'll see.

Thank you,
Noah Silva

p.s.: I don't see a big deal in pulling in something like Synapse so long
as it compiles easily for your platform.  You don't have to use all the
units, and the linker shouldn't even include all of the code from the units
you do use.  If you only use one function that is mostly contained (like
HMAC), then it shouldn't add much to your program's size in the scheme of
things.  I don't like when people use things that aren't really needed
mainly because you have to then download them and pray they compile on your
setup.  (And in some cases, recompile Lazarus!).  For more common things
that "just work", I have no issue.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread Mark Morgan Lloyd 

Reinier Olislagers wrote:

On 2-4-2013 5:13, Noah Silva wrote:

Actually I think on OS X and Linux it makes sense to depend on OpenSSL,
but not for the reasons you mentioned so much as one more: Security. 


That's probably why the previous poster wrote robust etc. Sounds like
security attributes to me.


If
you are using doing encryption, then it's better to use a library that
is updated more often for bug fixes, and to have the updates be applied
to your program automatically.  If you static-link it in, it will never
be updated until you update it and ship a new version of your program
and everyone installs it.  If you dynamically link to it, then then the
operating system updates it, you get the updates "for free".  


Depends. If you're using (say) a hash function to store a token in lieu 
of a password then the important thing is that this behaves consistently 
across platforms and program versions. If an external library eliminated 
a potential security flaw (the most common case being when null text was 
processed) that might be significant in the case of key scheduling for 
data transfer over an insecure channel, but not for purely local storage.


As usual, there's little substitute for the original programmer knowing 
what he's doing, and for him documenting what he's done so that 
maintainers know what sort of external event can cause an issue.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread Reinier Olislagers 
On 2-4-2013 10:04, Noah Silva wrote:
> 2013/4/2 Reinier Olislagers  >
> If you feel so strongly about it, why not submit a patch that uses
> OpenSSL on platforms that are sure to have it and use Silvio's native
> code for others?
> 
> 
> Haha I was just mentioning one positive benefit.  Also, I am pretty sure
> Synapse can use the OpenSSL DLLs.

Yep.

> I am much more likely to submit some patches to the OS X GUI for Lazarus
> that I have been fixing in the last week or so.  We'll see.

That does seem like a more worthwhile area, yes
> 
> Thank you,
> Noah Silva

No worries,
Reinier

> p.s.: I don't see a big deal in pulling in something like Synapse so
> long as it compiles easily for your platform.  You don't have to use all
> the units, and the linker shouldn't even include all of the code from
> the units you do use.  If you only use one function that is mostly
> contained (like HMAC), then it shouldn't add much to your program's size
> in the scheme of things.  I don't like when people use things that
> aren't really needed mainly because you have to then download them and
> pray they compile on your setup.  (And in some cases, recompile
> Lazarus!).  For more common things that "just work", I have no issue.

Agreed - Synapse is nicely self-contained and modular.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread Reinier Olislagers 
On 2-4-2013 10:08, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
>> On 2-4-2013 5:13, Noah Silva wrote:
> Depends. If you're using (say) a hash function to store a token in lieu
> of a password then the important thing is that this behaves consistently
> across platforms and program versions. If an external library eliminated
> a potential security flaw (the most common case being when null text was
> processed) that might be significant in the case of key scheduling for
> data transfer over an insecure channel, but not for purely local storage.

Well, yes. But you can hardly limit use of the function to local storage
only.

> As usual, there's little substitute for the original programmer knowing
> what he's doing, and for him documenting what he's done so that
> maintainers know what sort of external event can cause an issue.

... and prove it works/interoperates by including a test set, as I think
Silvio has done.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: a proposal about "with" syntax

2013-04-02 Thread Noah Silva 
Hi,

Actually, this sort-of makes sense.  I find "as" or something similar to be
more aesthetically pleasing, but @ seems to make it clear that the
identifier is just an alias (pointer address), and not a real temporary
variable.

Of course I would be happy for any keyword or syntax that actually allows
this to be done.  Theoretically you could already use "absolute" instead,
but...

Thank you,
Noah Silva

2013/3/20 Lukasz Sokol 

> On 18/03/2013 03:11, Paul Ishenin wrote:
> > 18.03.13, 9:27, Xiangrong Fang пишет:
> >> I am sorry I didn't follow this thread although I am the "OP" :-).   If
> >> I understand correct, I would suggest NOT introduce the "absolute"
> >> keyword, instead, make it ALWAYS absolute. i.e.:
> >>
> >> with a = SomeObject, b = SomeRecord do begin
> >>... ...
> >> end;
> >>
> >> Both a and b are "reference" to the object or record, IMO there seems no
> >> need to do assignment in the with syntax. Thus, I suggest use = instead
> >> of :=
> >
> > '=' can't be used because it can be a part of expression. There is no
> big difference between
> > with (a = SomeObject) do
> > and
> > with a = SomeObject do
> >
> > After more thinking I see that ':=' as well as absolute keyword are also
> bad because they will complicate the parser (although it is possible to use
> them). Parser will need to read the first token and check if it is an
> identifier, read second token and compare with ':=' (or 'absolute') and if
> it is not ':=' (or 'absolute') return to expression parse.
> >
> > At the same time we will not complicate the parser if we place alias
> identifier after the with expression like:
> >
> > with expression1, expression2 => alias2, expression3, expression4 =>
> alias4 do
> >
> > begin
> >
> > end;
> >
> > Where '=>' is some token which can't be used in expressions.
> >
> For example '@' ?
>
> e.g.
> with alias1@SomeLongObject, alias2@SomeOtherLongObject, ... do
>
> rationale:
> it's sufficiently different, and as for its nominal usage, it does similar
> thing.
>
> ?
>
> > Best regards,
> > Paul Ishenin
> >
>
> Lukasz
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Feature proposal: function-based assignment operatorst

2013-04-02 Thread Lukasz Sokol 
On 29/03/2013 09:53, Jürgen Hestermann wrote:
[...]
> To program nowadays it
> already requires a lot of other things to learn (different OSs and
> interfaces). I see no need to add even more to that by adding
> features over and over again. Pascal was successful because it was
> easy and clear. Now it becomes complex and cluttered.
> 
I can't agree with you...

If it wasn't for 'things to learn', Pascal would still be stuck 
at Borland Turbo Pascal 6 level (that's the one I remember learning at school). 

And since the 'novelties' of classes, interfaces (which nb. I can't 
seem to bend my head round yet) do increase complexity, that make the 
language look cluttered, some features designed to simplify managing 
the clutter should be welcome...
(and no, CodeTools and Lazarus ain't always the answer for everybody)

[case in point: the try...[except]...[finally]...[except]...end; I wrote about 
some time before]

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Feature proposal: function-based assignment operators

2013-04-02 Thread Marc Weustink 

On 28-3-2013 17:52, Jonas Maebe wrote:



+= does *not* prevent re-evaluating the left side. It is internally
translated to "x:=x+y" and then evaluated like normal. So if "x"
contains a function call with side effects, these side effects are still
triggered twice.


Is evaluated as x := x + y or as x := x + (y)
(where Y can be any expression)

I usually tanslate C code like the first, but recently found out that is 
should be done like the last.


Marc

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Feature proposal: function-based assignment operators

2013-04-02 Thread Jonas Maebe 


On 02 Apr 2013, at 11:11, Marc Weustink wrote:


On 28-3-2013 17:52, Jonas Maebe wrote:



+= does *not* prevent re-evaluating the left side. It is internally
translated to "x:=x+y" and then evaluated like normal. So if "x"
contains a function call with side effects, these side effects are  
still

triggered twice.


Is evaluated as x := x + y or as x := x + (y)


FPC guarantees nothing about the order in which expressions are  
evaluated. FPC generally reorders expressions based on how many  
registers the compiler thinks it will need.



Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Feature proposal: function-based assignment operatorst

2013-04-02 Thread Sven Barth 

Am 02.04.2013 11:03, schrieb Lukasz Sokol:

[case in point: the try...[except]...[finally]...[except]...end; I wrote about 
some time before]
Which reminds me: would you please be so kind to create a feature 
request for this, so it won't be forgotten?


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Feature proposal: function-based assignment operatorst

2013-04-02 Thread Lukasz Sokol 
On 02/04/2013 13:18, Sven Barth wrote:
> Am 02.04.2013 11:03, schrieb Lukasz Sokol:
>> [case in point: the try...[except]...[finally]...[except]...end; I
>> wrote about some time before]
> Which reminds me: would you please be so kind to create a feature
> request for this, so it won't be forgotten?
> 
> Regards, Sven 

OK, signing up to mantis :)

L.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: Feature proposal: function-based assignment operatorst

2013-04-02 Thread Lukasz Sokol 
On 02/04/2013 13:32, Lukasz Sokol wrote:
> On 02/04/2013 13:18, Sven Barth wrote:
>> Am 02.04.2013 11:03, schrieb Lukasz Sokol:
>>> [case in point: the try...[except]...[finally]...[except]...end; I
>>> wrote about some time before]
>> Which reminds me: would you please be so kind to create a feature
>> request for this, so it won't be forgotten?
>>
>> Regards, Sven 
> 
> OK, signing up to mantis :)
> 
> L.

Issue #0024216 .

L.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Feature proposal: function-based assignment operatorst

2013-04-02 Thread Sven Barth 

Am 02.04.2013 15:14, schrieb Lukasz Sokol:

On 02/04/2013 13:32, Lukasz Sokol wrote:

On 02/04/2013 13:18, Sven Barth wrote:

Am 02.04.2013 11:03, schrieb Lukasz Sokol:

[case in point: the try...[except]...[finally]...[except]...end; I
wrote about some time before]

Which reminds me: would you please be so kind to create a feature
request for this, so it won't be forgotten?

Regards, Sven

OK, signing up to mantis :)

L.

Issue #0024216 .


Thank you.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: HMAC_SHA1 and FPC

2013-04-02 Thread waldo kitty 

On 4/2/2013 03:04, Noah Silva wrote:

Haha I was just mentioning one positive benefit.  Also, I am pretty sure Synapse
can use the OpenSSL DLLs.


it does... and on at least three platforms, too... winwhatever, *nix and OS2...

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Stack traces under Win64

2013-04-02 Thread denisgolovan 
Hi all

I am trying to get stack traces for Win64 for exception, but BackTraceStrFunc 
still returns only hex representation.
My stack dumper is called via ExceptProc global variable.
Basically the procedure dumping exception stack follows below.

procedure TLogger.DumpExceptionBackTrace;
var
  FrameNumber,
  FrameCount   : longint;
  Frames   : PPointer;
begin
  if RaiseList=nil then
exit;
  Log(BackTraceStrFunc(RaiseList^.Addr));
  FrameCount:=RaiseList^.Framecount;
  Frames:=RaiseList^.Frames;
  for FrameNumber := 0 to FrameCount-1 do
Log(BackTraceStrFunc(Frames[FrameNumber]));
end;

Some info:
Actually I am doing cross-compilation from Linux x64 if it matters.
Linux version of the same application works fine.
I added both -gh and -gl parameters for compiler.

Am I doing something wrong?
Should I force the compiler to save debug info in some specific format on Win64?
Please comment.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] DBF components are maintained now

2013-04-02 Thread Reinier Olislagers 
Hi lists,

Just wanted to let you know about
http://wiki.lazarus.freepascal.org/User_Changes_Trunk#TDBF_unit_deprecation_removed

Currently I'm adding test cases to dbtestframework and verifying if
other existing tests apply to the dbf units, so the dbase units can be
regression tested. New unit tests are welcome:
$(fpcdir)\packages\fcl-db\tests\testspecifictdbf.pas

I'm also investigating open dbf bugs, as well as the fact that FoxPro
(table level 25) output doesn't seem to give valid FoxPro files.

I'll also be working with the new Sourceforge TDBF maintainer to
synchronize the FPC and Sourceforge versions.

Thanks,

Reinier
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal