Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Pike 7.4
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 21 Jun '10

21 Jun '10

I'm trying to compile 7.4 and get some include problems. Anyone directly knows the issue? Outputting result files... Updating GTK/time_stamp Updating GTK/pgtk.c Total time spent... 1.6s make[5]: Entering directory `/home/nilsson/Pike/7.4/build/linux-2.6.24-27-gener\ ic-i686/post_modules/GTK' Makefile:274: warning: overriding commands for target `depend' Makefile:197: warning: ignoring old commands for target `depend' Compiling pgtk.c In file included from /home/nilsson/Pike/7.4/src/program.h:12, from /home/nilsson/Pike/7.4/src/post_modules/GTK/pgtk.h:13, from pgtk.c:2: /home/nilsson/Pike/7.4/src/global.h:58:21: error: machine.h: No such file or di\ rectory /home/nilsson/Pike/7.4/src/global.h:219:2: error: #error Unsupported type chose\ n for native pike integers. /home/nilsson/Pike/7.4/src/global.h:231:2: error: #error Unsupported type chose\ n for pike floats. (machine.h is in /home/nilsson/Pike/7.4/build/linux-2.6.24-27-generic-i686/)

2 2

Re: Crypto.CRC
by Marc Dirix 18 Jun '10

18 Jun '10

> Btw, it looks rather odd to me that you inherit the hash state class > into the base algorithm class. The hash state is supposed to contain > the context for a specific hashing while the algorithm class has the > static data (e.g. the polynomial). And the algorithm class (which is a > module and hence just a single instance) cannot return itself as > state, because then several hashings running in parallell would > clobber each other. I don't quite understand? In Martin Nilsson's email he stated it should look like below, so `() returns CRCState. Isn't this achieved by inheriting? What do you mean by Clobbering? Isn't by inheriting for every new instance of CRC16 also a new instance of CRCState created? The class CRCState is complete, except for the polynom. Should I create a CRCState object in the _CRC16 class and return it for `() ? class CRC { string name(); int digest_size(); int block_size(); CRCState `() string hash(string data); } class CRCState { string name(); int digest_size(); int block_size(); string hash(string data); CRCState update(string data); string digest(void|int length); }

2 1

Re: Crypto.CRC
by Marc Dirix 18 Jun '10

18 Jun '10

It doesn't seem to work that way. Attached is the patch to Crypto.pmod/module.pmod (this one is not complete just for testing purpose) If try to use it: >object a = Crypto.CRC16(); /usr/local/pike/7.8.447/lib/modules/Crypto.pmod/module.pmod:118:Illegal program pointer. Compiler Error: 1: Index 'CRC16' not present in module Crypto. Compiler Error: 1: Indexed module was: master()->joinnode(({ /* 1 element */ master()->dirnode("/usr/local/pike/7.8.447/lib/modules/Crypto.pmod":0) })). Compiler Error: 1: Attempt to call a non function value `() (function call). Compiler Error: 1: Expected: function. Compiler Error: 1: Got : zero. If I create a file "CRC16.pmod" like attached in a previous email. I can use CRC16(); > > protected class _MySubModule > { > ... > } > > _MySubModule MySubModule = _MySubModule(); >

2 1

Re: Crypto.CRC
by Marc Dirix 17 Jun '10

17 Jun '10

Ok. So if I see things right, these mentioned classes should go into "Crypto.pmod/module.pmod" and for each CRC type, I create a module, ie "Crypto.pmod/CRC16X.pmod" ? On 06/15/2010 09:40 PM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote: > The hash API basically works looks like this > > class CRC > { > string name(); > int digest_size(); > int block_size(); > CRCState `() > string hash(string data); > } > > class CRCState > { > string name(); > int digest_size(); > int block_size(); > string hash(string data); > CRCState update(string data); > string digest(void|int length); > } -- Dipl.-Ing. Marc Dirix Electronics Design Schmeddingstraat 24 6361AZ Nuth Tel.: +31(45)7440744 E-Mail: marc(a)electronics-design.nl Internet: www.electronics-design.nl

2 1

Re: Crypto.CRC
by Marc Dirix 16 Jun '10

16 Jun '10

I hope this is somewhat in the right direction? What should "digest_size" and "block_size" return? Wouldn't it for the CRC function be better if "digest" and "hash" return the integer value, instead of a string? Best regards, Marc

1 0

Re: Crypto.CRC
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 15 Jun '10

15 Jun '10

The hash API basically works looks like this class CRC { string name(); int digest_size(); int block_size(); CRCState `() string hash(string data); } class CRCState { string name(); int digest_size(); int block_size(); string hash(string data); CRCState update(string data); string digest(void|int length); }

1 0

Re: Crypto.CRC
by Marc Dirix 15 Jun '10

15 Jun '10

> > But if they are to be added to the Crypto module, they should be fixed > to follow the same API as the other hash functions though. I think > that'd be preferable regardless where in Pike they're added, as well. > Besides, the naming convention for functions in Pike is_like_this, and > notthisway. If there is a consensus about adding the module to Crypto I'd happily adapt the module to be more like other hash functions, and follow naming conventions better.

3 2

SO_REUSEADDR
by Stephen R. van den Berg 15 Jun '10

15 Jun '10

Browsing the source, I see the Stdio/file module is littered with SO_REUSEADDR setsockopts of which *all* of them are bogus (i.e. they either have no effect, or have an effect which is detrimental to the socket's operation and could cause the socket to receive unexpected errors because the network is still delivering lingering packets to a newly reused socket). It looks like they were scattered into the code by someone who either does not fully understand its semantics, or in a futile attempt to camouflage certain network problems (but were never removed again because it was uncertain if they helped or not (they do not help!)). I've already noticed this while fixing the network-tests from the test-suite. Can anybody either explain what the excessive use of SO_REUSEADDR was supposed to accomplish? Grubba? (it seems like you added or at least touched some of them), or does anybody object to me cleaning up this mess? The reason why I actually touch the subject is because I currently happen to have one of the two only valid reasons to actually use SO_REUSEADDR (I want to bind two Roxens to the same port on the same IP-address for load balancing), and it turns out that I cannot activate the option from Pike (ironically, the code is littered with these SO_REUSEADDR options, except for the one spot where it actually matters). It should/will become a separate setsockopt kind of interface at the Pike level. -- Stephen. "Tomorrow will be cancelled due to lack of interest."

1 0

Crypto.CRC
by Marc Dirix 13 Jun '10

13 Jun '10

Hi, I've found the python CrcMoose library. The CRC algorithm I seemed to need CRC16X was different from CCITT and CRC16IBM or modbus. I've converted the CrcMoose library to pike and attached it to this email. The original module (python) can be found here: http://www.nightmare.com/~ryb/ I'd like to opt to get this module into Crypto if possible. I'm not sure how this works with his license in the original file. /Marc

8 15

pad/unpad
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 06 Jun '10

06 Jun '10

It appears that we have a bug in the pad/unpad methods of the Crypto.Buffer object. Where all padding standards (ANSI X.923, ISO 10126, PKCS7) have the last byte of the last block be the number of padded bytes, Pike sets it to 1 less than that (i.e. the number of padded bytes in addition to the length byte). I think these functions are used directly in SSL. However fixing it may create a bit of a compatibility issue in other places.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel