It could be the cider talking, but I'm giving up on regex or attempting my
own reworking in Javascript of what inet_pton/uv_inet_pton already does. So
instead, my cider swimming brain has decided to take his first steps into
C. Probably not his best idea, but so far the code is compiling...may not
have hit the source files yet though.
>From my POV, this should make things way faster or at the very least
provide the most accurate validation the genius minds behind
inet_pton/uv_inet_pton could come up with.
//in src/cares_wrap.cc
static Handle<Value> Inet_PToN(const Arguments&* args) {
HandleScope scope;
//int length, family;
char address_buffer[sizeof(struct in6_addr)];
char ip = new char[strlen(args[0])];
ip = strcpy(ip, args[0]);
if (uv_inet_pton(AF_INET, ip, &address_buffer).code == UV_OK) {
//length = sizeof(struct in_addr);
//family = AF_INET;
delete ip;
return scope.Close(4);
} else if (uv_inet_pton(AF_INET6, ip, &address_buffer).code == UV_OK) {
//length = sizeof(struct in6_addr);
//family = AF_INET;
delete ip;
return scope.Close(6);
} else {
delete ip;
return scope.Close(0);
}
delete ip;
return scope.Close(0);
}
//in static void Initialize()
NODE_SET_METHOD(target, "inet_pton", Inet_PToN);
On Friday, October 5, 2012 12:16:43 AM UTC-5, snoj wrote:
>
> Hmm, looks like I forgot to account for :a:b:c: addresses now. I'm
> beginning to think a non-regex will be simpler in the long run.
>
> On Thursday, October 4, 2012 11:14:38 PM UTC-5, snoj wrote:
>>
>> Thanks guys! I didn't know that about split operations.
>>
>> Jonny, do you have benchmarks handy on your django port? If not, I'll
>> hack something together and get them myself. If it is faster, I'd just
>> rather it be brought into node itself then me stumble around in the dark
>> anymore.
>>
>> This past day I've done some more thinking on how regex might be done
>> differently so as to not use splits and less lines. The result is the code
>> below. The additions to the regex currently found in node fix the :: prefix
>> issue as well as a::b::c and a:b:c situations. The trade off is that in
>> some cases the tests can 3-5 times slower than the old net.isIP. I still
>> think that's okay if better results are given. Still though, I want to
>> believe this could be faster. I do have some code laying around for
>> converting an IPv6 string to Buffer object.
>>
>> It's also ran though the test-net-isip.js unit without issue, which is
>> more than I could have said for my last set of code.
>>
>> Beyond these, perhaps delving into some C and sending data straight to
>> inet_pton and letting it success or fail would bring the speed up.
>>
>> isIP = function(input) {
>> if (!input) {
>> return 0;
>> } else if
>> (/^(\d?\d?\d)\.(\d?\d?\d)\.(\d?\d?\d)\.(\d?\d?\d)$/.test(input)) {
>> var parts = input.split('.');
>> for (var i = 0; i < parts.length; i++) {
>> var part = parseInt(parts[i]);
>> if (part < 0 || 255 < part) {
>> return 0;
>> }
>> }
>> return 4;
>> } else if
>> (/^::$|^::1$|^([a-fA-F0-9]{0,4}::?){1,7}([a-fA-F0-9]{0,4})$/.test(input) &&
>> !(/::.+::/.test(input))) {
>> if (input.match(/:/g).length < 7 && !(/::/.test(input))) {
>> return 0;
>> }
>> return 6;
>> } else {
>> return 0;
>> }
>> };
>>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
