EFnet Paralyzed By Vulnerability

← Back to Stories (view on slashdot.org)

EFnet Paralyzed By Vulnerability

Posted by Unknown on Monday December 31, 2012 @11:15AM from the blame-c dept.

An anonymous reader writes "EFnet member Fionn 'Fudge' Kelleher reported several vulnerabilities in the IRC daemons charybdis, ircd-ratbox, and other derivative IRCds. The vulnerability was subsequently used to bring down large portions of the EFnet IRC network." By crafting a particular message, you can cause the IRC daemon to call strlen(NULL) and game over, core dumped.

156 comments

Min score:

Reason:

Sort:

Sigh... by MightyMartian · 2012-12-31 11:18 · Score: 5, Funny

1998 called and want their attack vector back.

--
The world's burning. Moped Jesus spotted on I50. Details at 11.
1. Re:Sigh... by skovnymfe · 2012-12-31 11:20 · Score: 4, Funny
  
  It's retro cracking. Old is the new new, y'know?
2. Re:Sigh... by Anonymous Coward · 2012-12-31 11:39 · Score: 0
  
  +1 Funny But Sad, like the tears of a clown.
3. Re:Sigh... by faedle · 2012-12-31 12:08 · Score: 2
  
  A 1998 attack vector for a 1992 network.
4. Re:Sigh... by NotQuiteReal · 2012-12-31 13:46 · Score: 1
  
  You can still do this in a modern language... like C#/.NET
  
  string s;
  
  if (s.Length....
  
  blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!
  
  --
  This issue is a bit more complicated than you think.
5. Re:Sigh... by waspleg · 2012-12-31 14:00 · Score: 2
  
  You're laughing but I had to tell the developers of a small indie MMO, with-in the last year, that their ircd was vulnerable to remote exploits and it was running on the same thing that hosted the game itself, true story.
6. Re:Sigh... by Anonymous Coward · 2012-12-31 14:32 · Score: 0
  
  I hate that song. I always think they're talking about me when it comes on.
7. Re:Sigh... by Anonymous Coward · 2012-12-31 14:41 · Score: 0
  
  Actually, trying to compile code like that will result a compiler error in C#.NET (at least using the MS compiler)
  There are a lot of improvements to avoid obvious stupidity like that.
8. Re:Sigh... by Anonymous Coward · 2012-12-31 15:26 · Score: 0
  
  Or use stuff like Java's @NotNull / @Nullable assertions (obviously putting the emphasis on @NotNull instead of the other ; )
  Since JetBrains started including these in IntelliJ IDEA, with real-time checking (even on incomplete ASTs), I've probably eliminated about 99% of all the NullPointerException I got in Java. (great thing is: in a team with a mixed dev environment it can work transparently --it appears in the source code, but not in the .java source file--, giving me a gigantic edge but not my non-IDEA co-workers ; )
  So in an "even more modern" language the very concept of null can be replaced very often, by objects which you can guarantee can never ever be null. It may not work *all* the time, but in my experience it works in 99% of the cases.
  @NotNull is not exactly new btw... It's quite a few years old.
  And of course there are languages which have an even saner concept of null / nil (or both, like Clojure, in which you have lots of nil but can still get an occasional Java NPE).
9. Re:Sigh... by Anonymous Coward · 2012-12-31 19:02 · Score: 0
  
  You and me both. *brohug*
10. Re:Sigh... by petermgreen · 2013-01-01 02:41 · Score: 1
  
  Yeah, he screwed up his example, i'm pretty sure it would compile if he set s to null explicitly.
  Despite his mistake though his point stands, the problem of you (or a library you use) using null to represent "not known", "not present", "not found" or whatever and then passing the variable to a routine that assumes it will not be null impacts many languages that are far more "modern" than C.
  
  --
  note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
11. Re:Sigh... by pod · 2013-01-01 07:14 · Score: 1
  
  blammo - you should have checked if s was null first... Oh, and use that fancy try/catch stuff, all the cool kids do!
  The solution is *obvious* (duh), but the problem is not. You can't be putting an exception handler around every function call.
  What most likely happened, is by the time the string got to the strlen function, it was either assumed to have been security checked and data validated, or, the set of validations run was not complete.
  Shit happens.
  
  --
  "Hot lesbian witches! It's fucking genius!"
12. Re:Sigh... by Hentes · 2013-01-01 10:34 · Score: 1
  
  The difference is, you can't catch a segfault in C++.
13. Re:Sigh... by WhatAreYouDoingHere · 2013-01-01 11:42 · Score: 1
  
  1998 Called?!! Did you WARN them???!
  
  --
  "What are you doing here, Elijah?"
What the EF? by Anonymous Coward · 2012-12-31 11:21 · Score: 0

How did this happen?
1. Re:What the EF? by X0563511 · 2012-12-31 16:01 · Score: 1, Funny
  
  EFnet is some crappy IRC network people go to for help until they find out about freenode.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
C strings strike again! by cheesybagel · 2012-12-31 11:21 · Score: 3, Insightful

This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
1. Re:C strings strike again! by cheesybagel · 2012-12-31 11:22 · Score: 2, Insightful
  
  Not to mention the whole C issue where pointers to something and arrays of something are sort of the same but not really.
2. Re:C strings strike again! by ls671 · 2012-12-31 11:34 · Score: 2, Informative
  
  An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.
  http://stackoverflow.com/questions/5796103/strlen-not-checking-for-null
  
  --
  Everything I write is lies, read between the lines.
3. Re:C strings strike again! by nenolod · 2012-12-31 11:45 · Score: 1, Interesting
  
  This was a NULL-pointer exception, not a buffer issue. But I do agree that it makes more sense to invest in building IRCd software which is written in string-safe and pointer-safe languages. Mozilla's rust language, for example looks promising for use in IRCd. The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.
  However, it is easier for most people hacking on IRCd to just pick up a 2.8-derivative.
4. Re:C strings strike again! by cheekyboy · 2012-12-31 12:48 · Score: 1
  
  Yes too much management needed in C.
  Even if you had a *ptr holding the data type. You have to check.
  Pitty intel didnt implement string functions in the CPU.
  But damn, the libc guys should check input pointers themselves.
  
  --
  Liberty freedom are no1, not dicks in suits.
5. Re:C strings strike again! by Anonymous Coward · 2012-12-31 12:56 · Score: 1
  
  This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
  I would have to say that is an outright falsehood and misunderstanding of the language.
  This is the problem you get when the programmer makes a serious error, who is the one and ONLY one who should be keeping track of the size of strings.
  The entire C language is based around the idea that the programmer knows best. That's why it doesn't do unneeded things for you a bunch of times for each call.
  So of course when the programmer does something stupid like not keep track of the size of strings, and pass what the docs out right claim is an invalid parameter, then stupid things like this result.
  The language not only did nothing wrong, but did exactly what it claims it would do if you screw up and pass invalid arguments such as null when only a string pointer is valid.
  If you are a programmer that doesn't know and doesn't want to know what you're doing, don't use C. There are plenty of other languages that will treat you that way, which you should be using instead.
6. Re:C strings strike again! by Lunix+Nutcase · 2012-12-31 12:58 · Score: 3, Informative
  
  Pitty intel didnt implement string functions in the CPU.
  They did. Welcome to decades ago.
7. Re:C strings strike again! by cheekyboy · 2012-12-31 13:02 · Score: 0, Flamebait
  
  Hmm
  Option 1 : 50 dozen try/catches every where making java slower, and coding more manual.
  Option 2 : If length() returned zero even on a null object, it still is sort of correct, the string is zero sized.
  Coding should be made easier not bloated.
  Should there be 100000000 instances of checking for pointer before calling strlen(), or should strlen() it self check for ptr?
  This is where libc sucks, so just make your own strlen() from libc, as a static strlen(), which behaves nicer. A length of a 'NULL' object, well... yes, it is zero. Its length is not known or undefined which is bloody zero.
  I personally think that the responsibility on checking input args goes to the function, not the caller parent. You cannot delegate that to the caller which can make mistakes, prevent all mistakes in the library itself.
  We are not on a 286 any more. And besides either way, there is a check for the pointer, but as I said its better in the 'black box function'
  LIBC - you fail.
  
  --
  Liberty freedom are no1, not dicks in suits.
8. Re:C strings strike again! by BitZtream · 2012-12-31 13:03 · Score: 1
  
  Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.
  Guess what, exploits happen in languages with managed arrays too!
  Languages can't fix shitty programmers or mistakes, deal with it and stop blaming the language.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
9. Re:C strings strike again! by Teckla · 2012-12-31 13:03 · Score: 1
  
  An uncaugh NullPointerException on a call to aString.length() in java would have the same effect and kill the running Thread, the program if it is the main Thread.
  The JVM would continue running as long as there are running non-daemon threads. Whether or not it is the main thread is irrelevant.
  You are correct, however, that calling .length() on an object of type String that is null will throw a NullPointerException; however, it may or may not kill the current thread. It depends on whether or not the exception is caught, which is often the case, especially in servers where robustness is important.
10. Re:C strings strike again! by Rockoon · 2012-12-31 13:26 · Score: 1
  
  Yea, adding unneeded checks to every operation because of lazy/shitty programmers is a much better idea.
  I think the point that you are missing is that those checks are needed because the majority of programmers are both lazy and shitty once they are dealing with a large codebase. Here we have an obscure input causing the problem because its not obvious (lazy, shitty) that a variable might be null.
  
  --
  "His name was James Damore."
11. Re:C strings strike again! by VGPowerlord · 2012-12-31 14:08 · Score: 2
  
  Option 2 : If length() returned zero even on a null object, it still is sort of correct, the string is zero sized.
  null isn't an object in Java, which is where the problem is coming from.
  
  --
  GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
12. Re:C strings strike again! by the+eric+conspiracy · 2012-12-31 14:37 · Score: 1
  
  It isn't a matter of checking every object.
  Just the ones that come from outside.
  That takes lazy^stupid to miss, not just lazy/stupid.
13. Re:C strings strike again! by Anonymous Coward · 2012-12-31 16:09 · Score: 0
  
  FYI try/catch doesn't make the execution slower. Each try/catch adds info to a lookup table in the class file and ONLY when an exception is thrown is that table inspected for a try/catch that would handle the thrown exception.
14. Re:C strings strike again! by nedlohs · 2012-12-31 16:29 · Score: 2
  
  But damn, the libc guys should check input pointers themselves.
  And do what? Return a clearly wrong value so the caller can blindly continue? Burn some cpu on every call so that a broken caller can run a little longer and mysteriously crash later on or maybe just produce garbage output?
  That said, undefined behavior is undefined, if I was writing a libc it'd have to return 97 just for the heck of it.
15. Re:C strings strike again! by muridae · 2012-12-31 16:33 · Score: 1
  
  So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?
16. Re:C strings strike again! by Sulphur · 2012-12-31 16:34 · Score: 1
  
  This is the problem you get when your strings don't know their allocated size like in that ghastly language Pascal.
  At least in the case of Turbo Pascal, there is an allocated size and an actual size (length) for string variables.
17. Re:C strings strike again! by isorox · 2012-12-31 16:48 · Score: 0
  
  So, you have a pointer to string S, and you want *S.length() to check whether S is null? Do you propose that all functions on null pointers return 0? If so, how would you determine if it's a null pointer, or if the answer really was 0?
  If (s==null)
18. Re:C strings strike again! by oursland · 2012-12-31 18:45 · Score: 1
  
  The Intel 8086 included string instructions. It was released in 1978, which puts these instructions back at 34 years ago. Decades? A third of a century ago!!!
19. Re:C strings strike again! by hedleyroos · 2012-12-31 20:13 · Score: 1
  
  Pascal is still a great language to learn how to code. I will never knock it.
20. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:52 · Score: 1
  
  Return 0, or -1? The fault isn't that of the libc developers, of course, it's the fault of the specification writers, who wanted to make it possible to save a few bytes. The other one that always irritates me is strcmp(), where it should be trivial to say that two NULL inputs are the same, but otherwise NULL comes before any other input and then you wouldn't need to bracket every single call in a NULL check. And since it's not part of the standard, even if one libc did do something sensible, you couldn't rely on it and so you'd end up with NULL checks before and after the call, so that libc would seem slower.
  
  --
  I am TheRaven on Soylent News
21. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:55 · Score: 2
  
  That is very implementation dependent. What you say is true for C++ (on most modern systems, which use the 'zero-cost' exception model. I think iOS is the only exception, which uses setjmp() / longjmp() and so has expensive exceptions, unless they've fixed it recently). In Java, because exceptions are so common, this is often significantly slower and so functions return two values and the call is followed by a (statically hinted as not taken) branch on the 'an exception was thrown' value, which then jumps into the catch / finally block and checks what the exception was.
  
  --
  I am TheRaven on Soylent News
22. Re:C strings strike again! by TheRaven64 · 2012-12-31 20:57 · Score: 2
  
  This is exactly what Objective-C does. The method lookup function (objc_msgSend() and friends) contain a short-circuit path that returns 0 if the receiver is nil.
  
  --
  I am TheRaven on Soylent News
23. Re:C strings strike again! by voidphoenix · 2012-12-31 22:19 · Score: 1
  
  1978! That's so last millenium!
  
  --
  Excuse me, wtf r u doin?
24. Re:C strings strike again! by Anonymous Coward · 2012-12-31 23:36 · Score: 0
  
  Problem is that other people like that strcmp detect invalid input by seqfault
25. Re:C strings strike again! by Anonymous Coward · 2013-01-01 01:07 · Score: 0
  
  Indeed that's probably the problem. Rather than returning EINVAL for strlen(NULL) it's probably mapped directly to the CPU instruction for speed.
  Returning EINVAL could cause its own problems though - strlen is often used for pointer calculations, and I've never seen code checking for a negative return value... so implementing -1/EINVAL you could potentially be trading a coredump for a buffer overflow attack. In theory anyway.
26. Re:C strings strike again! by Anonymous Coward · 2013-01-01 01:11 · Score: 0
  
  where it should be trivial to say that two NULL inputs are the same
  But are they the same? In some use cases they may be, in others they may be very different. And hiding it within the function call would stop you having the choice.
  Database analogy: SELECT NULL=NULL returns NULL. It's neither True (1) nor False (0). Why? Because they're undefined values and they might not mean the same thing.
  C macros are your friend here - you can make your own wrapper that checks for NULL=NULL too, if you want that behaviour.
27. Re:C strings strike again! by ThePhilips · 2013-01-01 01:45 · Score: 1
  
  especially in servers where robustness is important.
  Ditto for C/C++ applications "where robustness is important". Implementation looks different, but same in the essence.
  Some memory debuggers and code analyzers (Insure for example) can even catch the error during compilation (IIRC so called "wild pointers" in the Insure speak).
  Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
  What I'm getting here to. If robustness is expected from the software, to customer, it doesn't matter how it fails - crashes or denies service - what matters is that the problem can be quickly localized and fixed. Trivial problems like missing null pointer check in C can be localized from core dump within seconds. Trivial problems like missing null pointer check in Java occasionally cause high level fsckups, thanks to the blank exception handling one often has to resort to. So from practical point of view, the languages unfortunately are very close.
  
  --
  All hope abandon ye who enter here.
28. Re:C strings strike again! by Anonymous Coward · 2013-01-01 01:51 · Score: 0
  
  Most operating systems catch NULL pointers, and end your program without crashing the OS or any other programs running on it. libc could also check for NULL pointers, and could end your program before the OS does it, but how is that an improvement?
29. Re:C strings strike again! by ThePhilips · 2013-01-01 01:58 · Score: 1
  
  The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.
  Are you CTO per chance? VP of tech? You talk like one.
  But if you want it to be addressed in a programming language.
  Until language developers suck it up and start making languages that allow for opposite concepts in the same language, it would remain the same.
  For example.
  Most stupid errors in strict typed languages are in the code for some type weakness - because, duh, strictly typed languages provide zero standard facilities to implement weak typing when you need it. So you have to roll out your own.
  Most stupid errors in weak-typed languages are related to wrong intermixing of types - because, duh, weakly typed languages provide zero standard facilities to implement strict typing when you need it. So you have to roll out your own.
  And it goes on.
  
  --
  All hope abandon ye who enter here.
30. Re:C strings strike again! by Anonymous Coward · 2013-01-01 02:22 · Score: 0
  
  pointed out long ago already here http://tech.slashdot.org/comments.pl?sid=3350243&cid=42437411
31. Re:C strings strike again! by nedlohs · 2013-01-01 02:50 · Score: 2
  
  0 would be terrible, since it isn't a zero length string and that's lying to the caller. Crashing is a better option, at least you stop the damage there and then rather than the program generating garbage output. An exception is better still, but C doesn't have those - segfaulting sort of works as one if you squint.
  -1 isn't an option because the return value is a size_t which is unsigned.
  Sure it's far from an ideal setup, but C is language built on a philosophy that the compiler and libc should be relatively simple to implement. And if that complicates programs written in C then that's the trade off that was chosen - there are other languages that made the opposite trade off.
32. Re:C strings strike again! by fatphil · 2013-01-01 03:24 · Score: 1
  
  -1? *snigger*.
  
  And strcmp compares strings. NULL does not point to a string, therefore you shouldn't expect string functions to work.
  
  C expects the programmer to know what he's doing, that's all.
  
  --
  Also FatPhil on SoylentNews, id 863
33. Re:C strings strike again! by Teckla · 2013-01-01 05:16 · Score: 1
  
  Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
  That's interesting. My experience has actually been the opposite. I spent a few decades programming in C, and about a decade ago switched to Java.
  In my experience -- which is, of course, just anecdotal -- C presented more difficulties. Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
  In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened. In addition, it should just kill the one thread. Though typically, we'd wrap threads with catch-all-log-all-and-restart-thread logic, which is just a few lines of code.
  However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
34. Re:C strings strike again! by ThePhilips · 2013-01-01 07:13 · Score: 1
  
  Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
  We allow to start several instances of the same process: if one goes down, others are still there.
  
  However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
  In all fairness, I'm not a specialist in Java. Probably your experience is more relevant than mine.
  But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
  
  In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened.
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
  
  --
  All hope abandon ye who enter here.
35. Re:C strings strike again! by Teckla · 2013-01-01 07:54 · Score: 1
  
  But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
  Easier/safer languages are a double edged sword. In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?". But, at the same time, it makes programming more accessible to people who really shouldn't be doing software development.
  I like to think I'm a good software developer and that using Java makes me more productive, but I readily admit that your average C developer is probably more talented than your average Java developer, possibly by a wide margin.
  
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
  
  Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
  I believe it. I wonder if it's because all the less talented programmers have moved onto easier/safer languages, as I suggested above. In fact, that's one of my pet theories why your average iOS application is better than your average Android application. It takes a certain determination and skill to master Objective-C, while Java is a lot more "accessible" to less talented developers.
  In many ways, I very much miss doing regular C development, though I do wish they would have added a few language features that I consider "must have" for modern development these days, such as "real strings" -- but that opens a whole other can of worms. :-)
36. Re:C strings strike again! by ThePhilips · 2013-01-01 08:25 · Score: 1
  
  [...] In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?".
  Bad example.
  A good sign of a non-master is attempt at concatenating string. Think of it, even Java *cannot* concatenate strings. :)
  Contemporary C master wouldn't even think about it. Far cry from StringBuilder, but all the functions for safe string handling are already there - one only has to use them. (Although some thought might go into defining the limits for the buffers.)
  
  Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
  This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
  A link/name for the idiom I can pass to our Java people?
  
  --
  All hope abandon ye who enter here.
37. Re:C strings strike again! by Teckla · 2013-01-01 09:19 · Score: 1
  
  A link/name for the idiom I can pass to our Java people?
  I think I would just point them to the Java API documentation and point out these constructors for java.lang.Exception:
  Exception(String message, Throwable cause)
  Constructs a new exception with the specified detail message and cause.
  Exception(Throwable cause)
  Constructs a new exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).
  These two additional constructors were added to Java 1.4 (so, a good long time ago) precisely because of the issue of catching and re-throwing exceptions and losing the underlying stack trace. These constructors solve that issue. (It does, however, make the stack trace that much longer, so it's pretty noisy!)
  All that being said, I'm not really a fan of exceptions. I like old fashioned return codes myself.
38. Re:C strings strike again! by MakerDusk · 2013-01-02 02:37 · Score: 1
  
  Are you CTO per chance? VP of tech? You talk like one.
  
  nenolod is the current head of the atheme project. He can be found on irc.staticbox.net #atheme. He's a good knowledgable guy (for the most part).
39. Re:C strings strike again! by g00ey · 2013-01-03 19:28 · Score: 1
  
  TheRaven64: A few years ago you wrote this:
  
  Possible, but nowhere near as easy. I've read most of volume 3A of Intel's architecture reference while doing background reading for my Xen book, but the complete architecture reference is well over 3,000 pages. The GPU reference - if you can get it - is a similar length, and that's before you get to the OS. The Design and Implementation of the FreeBSD Operating System is 720 pages. It's a good book, but it skips over a lot of details. The copy of the X11 protocol reference that I read was several hundred pages, and it's a few revisions old. The OpenGL reference was a similar length. But now you can do 2D and 3D graphics and, once you've read the C spec (not so bad, only a couple of hundred pages) and spent some time familiarising yourself with your C compiler and standard library you can draw things.
  
  To get the level of understanding that the original poster is talking about, on a modern computer, means reading and remembering around 10,000 pages of reference books, and gaining familiarity with the source code that they mention. And that's just going to give you one CPU architecture and the core bits of the OS.
  
  as a reply to a guy who basically said that a modern PC is essentially no more than a faster C64 with more memory and expandability options...
  
  Now, my question to you is; what would you say about the ARM platform and Arduino? Would you say that e.g. a Raspberry Pi system is as simple to program as a C64 or Amiga?
40. Re:C strings strike again! by TheRaven64 · 2013-01-03 23:34 · Score: 1
  
  Wow, that's a crazy tangent.
  I don't know much about the Arduino, but my understanding is that it's basically a microcontroller with the I/O pins wired to something that it's easy to connect stuff to. As such, the CPU is probably on the same order of complexity as a 6502, so about as easy to program, although the tools have improved a lot. It also doesn't have any of the coprocessors (e.g. for sound and video) that a C64-era machine typically had. Note, however, that I was talking about fully understanding the machine, not about programming it. One of the major developments in computing over the past couple of decades is that it is now easy to program computers while only having a very abstract idea of how they work.
  A modern ARM system, even an oldish one like the RPi (which, by the way, is designed two floors up from me) is vastly more complicated. In the middle of the RPi, there's an ARM11 CPU. This is pretty old by computing standards, but still fairly modern. It's about the only ARMv6 implementation still shipped (everything else is ARMv7, with ARMv8 just about to appear), and lacks the atomic operations and some of the nicer FPU support of the newer CPUs, but you still have a basic CPU design that supports multiple nested interrupt levels, virtual memory, write-through or write-back caching. The ARM ARM is a lot shorter than the IA32 manual, but it's still a pretty hefty book. By itself, it's longer than the manual that came with my BBC Model B, which included an explanation of the BASIC dialect, full descriptions of the video modes (including text and teletext modes), a complete description of the 6502 instruction set, and diagrams of the circuit boards. The RPi also has a fairly nice GPU, which is not even publicly documented, so good luck understanding how that works, and a few other coprocessors. The video output is DVI, which is a fairly complicated specification: quite understandable, but a lot more complex than the unmodulated analogue video out of TV-connected microcomputers from the '80s. You couldn't, for example, build a light pen for the RPi (even if you did connect it to a CRT), because the position of the photon beam is not exposed. You could for the BBC, and it was quite easy.
  And that's ignoring all of the other hardware on the RPi's SoC, such as the UARTs, programmable interrupt controller and the DMA engines, each of which is of the same order of complexity as a 6502.
  The main difference between ARM and x86 is ARM's willingness to phase out legacy cruft. The PC comes with a BIOS (or EFI that can emulate a BIOS), implementing the same set of BIOS interrupts (effectively system calls) that the original IBM PC implemented and all of the integrated peripherals that had analogs in the IBM PC support this interface (e.g. keyboard, mouse, text-based video console). It comes with a CPU that supports a protection model that is 100% backwards compatible with real-mode 16-bit code, and also with protected mode 32-bit code for the 80386. In contrast, an ARMv6 implementation can run any user-mode ARM code, but it won't boot an OS written for ARMv5 and will need new drivers for things like the console, display, USB, and so on (ARMv6 didn't even specify the interrupt controller. Neither does ARMv7, but the Cortex-A9 and newer all do).
  
  --
  I am TheRaven on Soylent News
EFnet is already paralyzed by Plombo · 2012-12-31 11:25 · Score: 1

Who needs security vulnerability when you have a complete lack of services and modern IRC features?
1. Re:EFnet is already paralyzed by jones_supa · 2012-12-31 11:33 · Score: 4, Interesting
  
  I wonder if the whole ancient IRC standard needs a steamrolling anyway. A lot of the new services are implemented by ugly hacks, bubblegum or bots. Things like registering a nickname, maintaining the administrators of a channel or handling netsplits, these could all be handled much more nicely. IRC needs a redesign from scratch...
2. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 11:36 · Score: 0
  
  Yeah, and we could move it to the web, too! It needs a catchy name though... maybe something like Twitter?
3. Re:EFnet is already paralyzed by nenolod · 2012-12-31 11:41 · Score: 3, Informative
  
  There has been a lot of work in this area with a few projects now... Microsoft's IRCX, then IRCNEXT, IRCPLUS and now atheme.org's IRCv3. IRCv3 is becoming the defacto standard at this point, supplanting the traditional IRC protocol, as almost all vendors that are noteworthy have adopted support for revision 3.1 of the protocol already.
  Both Atheme and Anope can be interacted with via RPC from scripts allowing for web integrations. Also, there are immersive web clients which provide a lot of useful metadata to clients.
4. Re:EFnet is already paralyzed by ls671 · 2012-12-31 11:43 · Score: 1
  
  Well, I still like the distributed design of it so keep it please. See picture here:
  http://en.wikipedia.org/wiki/Internet_Relay_Chat#Client_software
  
  --
  Everything I write is lies, read between the lines.
5. Re:EFnet is already paralyzed by Gaygirlie · 2012-12-31 11:44 · Score: 1
  
  Who needs security vulnerability when you have a complete lack of services and modern IRC features?
  Lack of services and IRC-features? Like what?
6. Re:EFnet is already paralyzed by nenolod · 2012-12-31 11:47 · Score: 1
  
  EFnet does not provide NickServ or ChanServ, which is a common criticism of the network. Due to not providing centralized authentication or channel ownership services, the other aspects of the modern IRC protocol mostly do not apply.
7. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 11:48 · Score: 2, Funny
  
  Google wave?
8. Re:EFnet is already paralyzed by Vermyndax · 2012-12-31 11:49 · Score: 5, Funny
  
  While you're at it, please redesign SMTP.
9. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 12:00 · Score: 0
  
  EFnet does not provide NickServ or ChanServ, which is a common criticism of the network.
  It's also why some people use EFNet instead of other networks which do provide those services.
10. Re:EFnet is already paralyzed by Bengie · 2012-12-31 12:07 · Score: 1
  
  EFNet is where I used to get my warez and anime... that took forever on a 14.4k modem.
11. Re:EFnet is already paralyzed by mysidia · 2012-12-31 12:14 · Score: 2
  
  IRC needs a redesign from scratch...
  Sounds like a great idea... I even have an idea of what we could call the redesign: Jabber / Conference Room.
12. Re:EFnet is already paralyzed by nenolod · 2012-12-31 12:16 · Score: 1
  
  MUC is extremely inefficient though. There is no multicast notion in XMPP, so MUC works around this by sending duplicate messages to each user directly.
13. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 12:17 · Score: 1
  
  Can we shorten the amount of text to about 40 or 20 characters? Better artificial limits can improve the quality of our chat content. Besides, it can help us achieve web-scale!
14. Re:EFnet is already paralyzed by Anrego · 2012-12-31 12:54 · Score: 2
  
  Yeah, but redesigning something that has been around forever is hard (see: IPv4). Way too much legacy stuff out there dependant on the messed up way IRC works.
  That said, gradual introduction of saner behavior is possible (see: Atheme/IRCv3).
  If you build something from scratch you'll just end up with a potentially technically improved (or just broken in different ways) but largely ignored solution (and for this, see: jabber conference!)
15. Re:EFnet is already paralyzed by mysidia · 2012-12-31 13:33 · Score: 2
  
  Jabber + PSYC
16. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 13:49 · Score: 0
  
  EFnet does not provide NickServ or ChanServ, which is a common criticism of the network.
  It's also why some people use EFNet instead of other networks which do provide those services.
  There's channel services now; albeit a crappy, gelded system. ChanFix has been in place for a few years now.
17. Re:EFnet is already paralyzed by nenolod · 2012-12-31 14:48 · Score: 1
  
  PSYC suffers the same issue as MUC.
18. Re:EFnet is already paralyzed by Krakhan · 2012-12-31 15:33 · Score: 1
  
  Also when I checked there a year or so ago they still don't cloak the ip address on your hostmask like a lot of modern irc networks do now by default as well.
19. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 18:45 · Score: 0
  
  Retroshare is the wave of the future. irc is a dying service.
20. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 19:06 · Score: 0
  
  Redesigning IRC is actually a hard problem.
  An IRC network is essentially a distributed database and clients are applications connecting to that distributed database and submit a message to the database server to have a message relayed to another client, update the database or query the database's state.
  So now that I've outlined the base problem to solve, come up with a database design that allows for 100 different database servers scattered around the globe to maintain a coherent global view. As a hint to the difficulty, most distributed databases exist in a cluster where transactional delays are minimal thanks to transports such as Infiniband (and a distributed database is not a trivial piece of technology in itself.)
  The services such as nickname registration and channel administration are deliberately add-on services.
21. Re:EFnet is already paralyzed by IllusionalForce · 2012-12-31 20:07 · Score: 3, Interesting
  
  "Anope can be interacted with via RPC"... Yes, Anope 1.9. That's the development release, though. As much as I'd like to share your idealized view of IRC becoming a better place (except for the fact that I definitely wouldn't want to create an IRCd from scratch these days -- linking protocol and especially these goddamn CAP negotiations are just as bad as doing SSL from scratch. Who had the idea of message intents anyway?), fact is that the majority of networks that use Anope (and there are, due to the fact that quite a number of admins believe that levels are easier/better in some way or that Atheme is too much work to set up) use the stable 1.8 version.
  Unlike the 1.7 dev version, 1.9 has not been widely adopted. This is mainly due to the fact that Anope 1.8 does just nearly enough out of the box to be still considered modern services, it's more hackable due to being coded in C (writing a module in 1.8 is definitely easier than in the C++ using 1.9 version. It's also easier to make it a complete fucking hackjob in 1.8) and has a bigger modding community (see http://modules.anope.org/ for pretty simple proof of that).
  Additionally, it's still a mystery to me how IRCv3 works as an organization. It's described as a "meritocracy", but who is calling the shots in the end? You, nenolod? If so, then I'm not sure if the description shouldn't be rather "oligocracy" but that's pretty bad for the image of anything these days.
  Furthermore, I would like to point out that, while four major IRCds are part of IRCv3/implement it, a big part of the implementations (especially so in UnrealIRCd) have actually come from people in the working group (namely you). While that in and of itself can hardly be considered a bad thing, it does lower the bus factor for future changes to the protocol to... precisely 1.
  I do, however, agree with your belief that IRC needs a change, but I believe this is heading in the wrong direction. This is just cleaning the protocol up a bit. What we actually need are radical changes, which you'd need to discard all the old diehard IRC brigade for. Analyze what is currently popular: Xat, Facebook, IMs. Observe how two of those are web-based. Does IRC have a web-based client? Yes, it does. Mibbit, qwebirc and KiwiIRC (as well as IRCCloud, but they are absolutely uncooperative with any network). Mibbit sucks downright and is missing the oh-so-important colors to today's generation for the most part. qwebirc is tied to a network each. While that might simplify the handing on the user's part (one website for one network), it still sucks as a client (same color issue as Mibbit, even) and the entire concept of a network just rapes the minds of users. Users today don't know and they do not WANT to know that there are multiple IRC networks. They just want a chat room. Centralization is key. You can't talk of "a Xat chat" or "the Facebook chat" or "ICQ" or "MSN (Messenger)" in the same way you talk about IRC because the decentralized nature is included in none of them (though, if Jabber had found broader adoption amongst non-techies, which will not happen because of this precise very same argument, that would be a basis to work off). KiwiIRC looks promising, but no network has webirc blocks for them yet. Facebook wins because everybody else is already there, not because their chat technology (or anything else for that matter) is particularly innovative or good. Speaking of centralization, having multiple clients and networks is just even more confusion for new users. There is no "the IRC client" and there is no "the IRC network". That is not what users want. Janus links are a step in the right direction (as ugly as they may be), but not a solution.
  On the topic of webirc blocks, banning people on IRC is an ordeal. It is a brutal pain in the neck. Other systems may require and enforce registration, so banning is very easy: Right click -> Ban. Or at least they abstract the banning itself away in some manner. You can't do that on IRC. You'll first spend
22. Re:EFnet is already paralyzed by Anonymous Coward · 2012-12-31 21:06 · Score: 0
  
  I propose we use the extensions provided by MS Comic Chat as a basis for this new IRC protocol.
23. Re:EFnet is already paralyzed by dkf · 2013-01-01 03:27 · Score: 1
  
  MUC is extremely inefficient though. There is no multicast notion in XMPP, so MUC works around this by sending duplicate messages to each user directly.
  That's also pretty much how IRC works (though the message formatting is rather different). For real efficient multicast, you need to implement it at the network level so that messages are sent directly to the other listening parties by the hardware, but IP multicasting is complex and full of all sorts of "interesting" problems when you use it at larger scales than the LAN. Re-transmitting messages (even with updated IDs and other such info) is far simpler in practice. Really.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
24. Re:EFnet is already paralyzed by someones · 2013-01-01 08:32 · Score: 1
  
  and HTTP.
Full disclosure takes a hit by Bizzeh · 2012-12-31 11:25 · Score: 1

which projects are now going to close their doors to full disclosure? this was posted on the ircd's own bug reporting systems and was publicly visible. if it were not, and only the developers and higher level users (such as the nodes of efnet or freenode) should be able to see reports of this nature, this sort of attack may not have happened and the ircd's could have been silently patched without anyone knowing.
on the other hand, if you close your doors, you obviously have something that requires hiding, drawing more attention.
what will projects do next?

--
portfolio
1. Re:Full disclosure takes a hit by nenolod · 2012-12-31 11:32 · Score: 2
  
  you do not know what you are talking about. the actual bug was disclosed in the IRC channel for charybdis. there was no "bug report."
2. Re:Full disclosure takes a hit by Anonymous Coward · 2012-12-31 11:35 · Score: 1
  
  You cannot "close your doors" to full disclosure, that doesn't make any sense. If someone wants to publicly announce a problem, they will always be able to do that. If someone wants to privately bring something to the attention of devs, they can always do that too. You cannot force people to use a disclosure method that they don't want to use.
3. Re:Full disclosure takes a hit by AndroSyn · 2012-12-31 11:46 · Score: 1
  
  I don't see any reason to hide from bugs like this, people make mistake, code suffers from bitrot, etc. It's sure as shit embarrassing when a mistake in your code ends up on /. though.
4. Re:Full disclosure takes a hit by Kaenneth · 2012-12-31 12:26 · Score: 3, Interesting
  
  Disclosed how? by example?
  Sounds like when I found that if you put %s in a CounterStrike player name, the client would crash when showing the scoreboard, I tried %s after I noticed "%dxxxxxxx%" became "32401xxxxxxx%".
  I reported it to Valve as soon as I figured out what it was, but it was a fun few days until they fixed it, "Hey look at that guys name!", server empties as people hit tab to show the scoreboard. I was server admin anyway, but it still was fun.
5. Re:Full disclosure takes a hit by Anonymous Coward · 2012-12-31 13:01 · Score: 0
  
  what are you doing to trigger the crash
  socket.write("CAPAB \r\n"); ...wow
6. Re:Full disclosure takes a hit by BitZtream · 2012-12-31 13:07 · Score: 1
  
  Because EFNet is more or less non-functional since it was publicly disclosed?
  Because no thousands of people pretty much can't chat, because someone else like you was too short sided to understand that some actions have larger overall consequences?
  Because its fucking stupid to tell the world how to break something until its been fixed and thats only left for fucking jackasses to do.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
7. Re:Full disclosure takes a hit by nenolod · 2012-12-31 14:55 · Score: 1
  
  He did not disclose it, the person who disclosed the vulnerability did so in a public space for development discussion on charybdis. Once it was out in the open, we quickly jumped into action to start mitigating it across all fronts including EFnet. The ratbox developers were notified at least an hour before the exploit was unleashed, with a patch to deploy and everything, so really we did everything we could possibly do to mitigate the possibility of fallout.
  Once people started running the exploit on EFnet servers, there was not much we could do, other than get the ratbox devs and admins regrouped elsewhere to coordinate getting things patched. I would say that things mostly went down as well as could be expected given the situation...
8. Re:Full disclosure takes a hit by BitZtream · 2012-12-31 19:08 · Score: 1
  
  1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.
  The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.
  Do you have any idea what its like running a network like EFNet and coordinating upgrades across all servers? Do you think there are admins awake and ready to be your bitch and patch their servers on your command in all time zones? Currently showing 44 servers linked ... Yea, an hour was plenty of time to deal with the issue ...
  You're a douche for even saying what you're saying.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
9. Re:Full disclosure takes a hit by Anonymous Coward · 2012-12-31 22:05 · Score: 0
  
  Take a look at nenolod's IRCv3 project contributor list, and notice the lack of Efnet in it, assuming any of the named are actual contributors. Also can't help but notice he added his name to a 2005 IRC CAP draft someone else wrote, and adopted it into his project. Likewise with multi-prefix, which has been around for just as long, courtesy of UnrealIRCd.
10. Re:Full disclosure takes a hit by AndroSyn · 2013-01-01 03:38 · Score: 2
  
  1 hour? Give me a fucking break. Doing it in public is as good as launching the attack yourself.
  EFnet was fixed within an hour or two for the most part. More importantly the hub servers were not impacted which helped with getting things working sooner.
  
  The patch could have been discussed behind closed doors. If you wanted to get someones attention about the real threat, you could have popped a single server ONCE without making it public.
  Indeed the patch could have been discussed behind closed doors, but sometimes zero day things happen. The real question is how do you deal with it when it happens.
  
  Do you have any idea what its like running a network like EFNet and coordinating upgrades across all servers? Do you think there are admins awake and ready to be your bitch and patch their servers on your command in all time zones? Currently showing 44 servers linked ... Yea, an hour was plenty of time to deal with the issue ...
  You're a douche for even saying what you're saying.
  I personally fixed 4 or 5 efnet servers directly and got patches out to the efnet admin community pretty quickly. Neonlod also had patches out pretty quickly as well, sooner than I did actually.
  TBH I'm surprised that it didn't happen sooner seeing that the bug had been there since 2004. The bug itself was a combination of errors. First was a code change that was supposed to do parameter count checking for the called function, however zero was put in for the parameter count that was required.
  This didn't matter for a while though as the rest of the code didn't rely on that parameter count checking code. However when some additional code was added, it wasn't protected by the old code that didn't care about parameter count, but it expected that the new parameter count code was working(which it wasn't) thus a command with an empty parameter caused the core dump. Fail.
Great! by lemur3 · 2012-12-31 11:38 · Score: 4, Funny

Now I can finally get that nickname I have been wanting since 1999 !!
1. Re:Great! by oursland · 2012-12-31 18:46 · Score: 1
  
  That really dirty one? You know, THAT one!
the cause was bitrot... by AndroSyn · 2012-12-31 11:42 · Score: 2

This is a good case of bitrot here, code that had made assumptions about what the other parts of the code were doing..and fail. Brown paper bag day for me on EFnet :P
1. Re:the cause was bitrot... by Mashiki · 2012-12-31 13:42 · Score: 0
  
  Hey now, I'd call it closer to a flaming brown paper bag day, filled with dog crap.
  
  --
  Om, nomnomnom...
2. Re:the cause was bitrot... by AndroSyn · 2013-01-01 05:12 · Score: 1
  
  So it was you who left that on my doorstep this morning!!! :D
Well, one bad programmer learned a lesson by Anonymous Coward · 2012-12-31 11:43 · Score: 0

Validate your fucking inputs, you moron.
1. Re:Well, one bad programmer learned a lesson by Anonymous Coward · 2012-12-31 11:51 · Score: 0
  
  Posts like this make me miss the efnet atmosphere in a Stockholm Syndrome kind of way.
2. Re:Well, one bad programmer learned a lesson by PlusFiveTroll · 2012-12-31 15:04 · Score: 1
  
  Validate your fucking inputs, you moron.
  That's the short version, the full version is
  Validate all possible valid combinations of inputs are valid in all subroutines.
Huh... really? by Anonymous Coward · 2012-12-31 11:47 · Score: 0

People still use IRC?
Fuck that place got stupid when the aol generation showed up. I can't imagine how bad it is now this many years later.
Er... Well... From this story. yes. yes i can. Full on 'this is why we can't have nice things' mode.
Glad i don't go there anymore.
1. Re:Huh... really? by Anonymous Coward · 2012-12-31 11:55 · Score: 0
  
  People still use IRC?
  Fuck that place got stupid when the aol generation showed up. I can't imagine how bad it is now this many years later. Er... Well... From this story. yes. yes i can. Full on 'this is why we can't have nice things' mode.
  Glad i don't go there anymore.
  Actually most of the aol morons moved on to other places, like facebook, so there's not as many idiots as there used to be back in the 90's. And yes, people still do use IRC.
2. Re:Huh... really? by aztracker1 · 2012-12-31 12:25 · Score: 1
  
  I haven't used efnet much in years... but am pretty active in a few channels on freenode.. Most active development platforms/projects have freenode channels these days.
  
  --
  Michael J. Ryan - tracker1.info
3. Re:Huh... really? by Anonymous Coward · 2012-12-31 15:39 · Score: 0
  
  Yep, I am on quite a few Freenode channels as well. Also, in Finland IRCnet is quite popular among the tech crowd, and outside as well. (and at least on my tech university every IT student at least gets introduced to it, and most are active there, via screen sessions running irssi on the school servers - also most IT courses have their IRC channels).
Theoretical way to get size of C string by Anonymous Coward · 2012-12-31 12:04 · Score: 2, Interesting

Using error handlers, & two pointers (this goes for ANY array, & strings are just arrays of characters/array of char):
---
1.) You send two pointers into/@ the array/string buffer allocated, as follows:
2.) 2nd "double-sized" one (positionally) is ALWAYS double the size (position) of the 1st.
3.) When the 2nd "double size of the first" FAILS (& the err handler catches it, ala try-catch/try-except type constructs)?
4.) The error handler passes back the size of the 1st "half-size pointer" location, & doubling it gives you the size of the array/string!
---
* THIS COULD BE USED TO TEST THE SIZE OF THE ALLOCATED SPACE FOR THE STRING BEFORE WRITING TO IT, first!
** ONLY PROBLEM IS, original C & Pascal implementations DON'T HAVE ERROR HANDLERS like Try-Catch/Try-Except/On Error GoTo etc./et al that C++ &/or Object Pascal do!
BUT YOU CAN "RIG IT" for error handling ala -> http://blog.staila.com/?p=114
(@ least afaik - I haven't worked with THOSE languages in almost 20 yrs. & certainly not ALL implementations, more modern ones MAY... I don't even remember if there is a way of "rigging" that into them vs. structured error handling built into their compilers).
---
However - Delphi Object Pascal has this (but not sure on original pascal implementations though, been DECADES since I did Turbo Pascal for DOS even).
Then - Even C has strlen... & that could be used to check this "hole" they are having a problem with, don't ya think?
* Any takers on that? Should work, in theory @ least, on C strings & their size... because it does on arrays you don't know the length of!
Lastly?
STRAIGHT Pascal, for lack of a better expression here (not Delphi, that's Object Pascal) could be done the same since it has pointers & can do the same type of testing the string array buffer, & it too, by the by - since it has a LENGTH function that can determine the size of a string as well...
You can "bust my balls" on this one IF I am off, I didn't read the article, but... it's an idea here, that *MAY* work!
APK
P.S.=> And, there you are... & not that THIS really matters, but, ONCE YOU HAVE THAT - you can "Trim" function the string chopping off the rest of it leading or trailing: There's examples of that in C & PASCAL all over online!
(I know for a fact Delphi Object Pascal has trim/rtrim/ltrim type functions built in, and C++ has functions you can find even online for it, since I don't recall it being part of the "std. string library of functions" but it may be in diff. dialects of it though, like C++ Builder) if its blanks etc./et al...
... apk
1. Re:Theoretical way to get size of C string by Anonymous Coward · 2012-12-31 12:11 · Score: 2, Funny
  
  Can these solutions be used in a Hosts file?
2. Re:Theoretical way to get size of C string by ls671 · 2012-12-31 12:42 · Score: 1
  
  From your link:
  "It makes the function look complicated as it has multiple exit points (return statements)."
  hmm... you mix up 2 things. It is more like you add complexity by introducing multiple exit points.
  There is ways around it you know... Beginning your fucntion with a temporary variable set to NULL and returning that temporary variable in one exit point at the end of your function is one.
  
  --
  Everything I write is lies, read between the lines.
3. Re:Theoretical way to get size of C string by webmistressrachel · 2012-12-31 17:00 · Score: 1
  
  That's not sporting at all. He actually posts something informative about something else and you troll him? OK, I'm known for teasing apk, but he does something positive and you try to pull him down? Not fair. Rachel. Not bloody Barbie or whatever, Rachel.
  
  --
  This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
4. Re:Theoretical way to get size of C string by JonySuede · 2012-12-31 17:48 · Score: 1
  
  Where are my mod points now that your posts are on topic....
  
  --
  Jehovah be praised, Oracle was not selected
5. Re:Theoretical way to get size of C string by Anonymous Coward · 2013-01-01 02:17 · Score: 0
  
  it was you trolling so who're you attempting to deceive here? you're into politics from what I hear and his upward moderations couldn't be taken out since his solution has potential so you do the politicians trick of can't beat em, then try lead em. go away. you're a known troll that even admits trolling apk in your reply now. you aren't intelligent enough to attempt to deceive us so not even a nice try to you troll.
6. Re:Theoretical way to get size of C string by Anonymous Coward · 2013-01-01 05:53 · Score: 0
  
  You need to remember to take your meds, this makes even less sense than your regular posts. It's extremely difficult to parse, because you clearly don't understand how memory is organized.
  
  Then - Even C has strlen... & that could be used to check this "hole" they are having a problem with, don't ya think?
  Umm, this isn't a buffer overflow, this is a missing check for NULL. i.e. they tried to call strlen(NULL), which crashes.
  Is your bizarre description attempting to implement strlen?!
  
  1.) You send two pointers into/@ the array/string buffer allocated, as follows:
  What does "send" mean? you mean pass as parameters to string apis?
  
  2.) 2nd "double-sized" one (positionally) is ALWAYS double the size (position) of the 1st.
  Are you suggesting you have one buffer that is double the length required, and the second pointer points to the end of the string?
  If you already know the size of the string, so you can double it's size and get a pointer to it, why are you wasting your time with this silliness?
  Show us in code, because your english is terrible.
  
  3.) When the 2nd "double size of the first" FAILS (& the err handler catches it, ala try-catch/try-except type constructs)?
  What does "FAILS" mean? This does not map onto any behaviour defined in C, I think what you were probably trying to describe is a well known trick where you align strings on page boundaries and then mprotect the second page to PROT_NONE, but this is nothing to do with C.
  I suppose in theory you could use this to figure out the length of a string, but this is the dumbest way to do it possible.
  
  4.) The error handler passes back the size of the 1st "half-size pointer" location, & doubling it gives you the size of the array/string!
  This doesn't make any sense.
Stop writing things in C/C++ by Anonymous Coward · 2012-12-31 12:09 · Score: 0, Flamebait

Stop writing massive projects in languages that don't protect against this shit. It's been how many decades and people still haven't learned this.
There are dozens, if not hundreds, of languages with array bounds checking (and also garbage collection, for you shitwits who are prone to memory leaks). Lisp, Java, C# are three you can look at.
"B-b-but, MUH PERFORMANCE!". No, shut the fuck up, if you're a programmer worth your weight in salt then you'll structure your program not to make unnecessary heap allocations.
1. Re:Stop writing things in C/C++ by nenolod · 2012-12-31 12:19 · Score: 1
  
  The problem isn't performance as much as it is accessibility. Almost every UNIX system has a C/C++ toolchain installed, not so much with Lisp, Java or C#. Also, C and C++ are generally the lowest common denominator for contributors. Almost everyone knows a little bit about C, not so many people know about Lisp (which is a travesty in and of itself, but not my problem).
2. Re:Stop writing things in C/C++ by countach74 · 2012-12-31 12:26 · Score: 2
  
  Throwing C++ into the same category as C is a bit retarded, is it not?
3. Re:Stop writing things in C/C++ by Anonymous Coward · 2012-12-31 12:39 · Score: 1
  
  Throwing C++ into the same category as C is a bit retarded, is it not?
  It's a lot retarded. But that never stopped anyone before.
4. Re:Stop writing things in C/C++ by Anonymous Coward · 2012-12-31 14:43 · Score: 0
  
  Throwing C++ into the same category as C is a bit retarded, is it not?
  Yes, it is. It fascinates the crap out of me that anyone still bothers with C, considering how much better C++ is.
5. Re:Stop writing things in C/C++ by mark-t · 2012-12-31 15:32 · Score: 2
  
  What language would you advocate, exactly?
  The *EXACT* same problem (abrupt program termination) would have plagued the software if had been written in either C# or Java unless exception-handling code was in place to prevent it. Not so coincidentally, the effort spent writing such exception handling code in C# or Java could just as easily be spent on a simple null pointer check before passing a value to strlen in C. Not to mention the fact that neither C# nor Java even existed when ircd was invented.
  This was a flaw that exploited nothing more technical than programmer oversight, which can happen just as easily in software written in *ANY* language.
  
  --
  File under 'M' for 'Manic ranting'
6. Re:Stop writing things in C/C++ by cstacy · 2012-12-31 15:43 · Score: 1
  
  What language would you advocate, exactly?
  Lisp
7. Re:Stop writing things in C/C++ by mark-t · 2012-12-31 16:05 · Score: 1
  
  Interesting call... Lisp existed back then.
  Granted, this particular crash would not have occurred had it been written in Lisp, but the failure on the part of the programmers to anticipate the kind of input that might produce a crash in C could just as likely to cause catastrophic failure in a program written in any language, even Lisp. Ultimately, the problem was not programming language choice - which is my whole point.
  
  --
  File under 'M' for 'Manic ranting'
8. Re:Stop writing things in C/C++ by mark-t · 2012-12-31 17:30 · Score: 1
  
  Haskell didn't exist in 1992 either.
  
  --
  File under 'M' for 'Manic ranting'
9. Re:Stop writing things in C/C++ by JonySuede · 2012-12-31 17:58 · Score: 2
  
  only if you use it ,pretty much like a null ceack or a try catch;
  
  --
  Jehovah be praised, Oracle was not selected
10. Re:Stop writing things in C/C++ by Kjella · 2013-01-01 08:18 · Score: 1
  
  The major difference between exceptions and null checks is the granularity. You can for example have a try/catch around the whole function parser that will kick in on any sort of failure and just say "whoops, something bad happened parsing this command" and it won't really matter what part inside that failed as long as you can recover, in that case probably by just ignoring that command and keep running. With null checks you must have one in every possible place you might call a null pointer. Particularly for a server then it can often happen that this client session is borked because it triggered some kind of "impossible" exception, you have to kill it but unless the entire server state is borked you don't need to kill the whole server. It's actually one of the things I hate the most with C/C++, without exceptions then one error means the whole application goes boom.
  
  --
  Live today, because you never know what tomorrow brings
11. Re:Stop writing things in C/C++ by mark-t · 2013-01-01 12:54 · Score: 1
  
  Only if simply ignoring errors and continuing in the program's main event loop is adequate. This can be the case with many programs, but can very easily cause side effects resulting from incomplete operations.
  
  --
  File under 'M' for 'Manic ranting'
LOL, Ok read by Anonymous Coward · 2012-12-31 12:18 · Score: 0

I don't even *KNOW* if this method will work on straight (original) implementations of classical C or PASCAL to be honest!
* It's been AGES since I worked with either (favoring C++ &/or Object Pascal over C & Pascal)...
Fact is - I may be COMPLETELY off, & what I am putting out, for C & PASCAL (original implementations that is, ala Bell Labs/AT&T + Kernighan & Ritchie OR Niklaus Wirth, respectively) will even work here...
(Being honest here - it's New Year's Eve, & LOL, I have been 'tipping a few' already with my neighbors, & stopped back home for more beer to bring over to their get together, & am NOT "@ my best" right now, if you know what i mean!)
LOL, gotta jet...
APK
P.S.=> Just 'putting out' / "bouncing ideas off others" here is all... I liked IRC in my day is why (Dalnet where I was an admin on their "official Windows help channel" endorsed by K. Marden Bey, creator of MIRC in fact, circa 1994-2000)...
... apk
Rename idea by 93+Escort+Wagon · 2012-12-31 12:56 · Score: 1

They should change the name from EFnet to EFFYOUnet.

--
#DeleteChrome
Objective-C nil by tepples · 2012-12-31 13:57 · Score: 1

blammo - you should have checked if s was null first
Unless you're using Objective-C, where the "nil" is a special object that implements all messages (that is, methods) as a no-op that returns a nil.
1. Re:Objective-C nil by Anonymous Coward · 2013-01-01 01:00 · Score: 0
  
  Except nil and NULL are different and both are present in Objective-C. You can still use NULL in Objective-C and therefore still get the same kind of coredump.
2. Re:Objective-C nil by TyFoN · 2013-01-01 03:19 · Score: 1
  
  Ugh, this really sounds like the way SAS responds when you try to access a field that doesn't exist. It will just create it and initialize it to missing value.
  I'm sure the objc solution is creating a _lot_ more bugs than it "fixes".
3. Re:Objective-C nil by thePowerOfGrayskull · 2013-01-01 04:35 · Score: 1
  
  Ugh, seriously? Nothing like forced non-failure of software instead of a failure that could prevent more serious consequences...
4. Re:Objective-C nil by v1 · 2013-01-01 09:04 · Score: 1
  
  it's better to react to an error than try to ignore it. Though I think I'd prefer a log entry to a core dump. I prefer to write bulletproof code, and I frequently benefit from it. Just this morning in fact I got a warning email that a directory create failed on a script. It wasn't a shell crash, it was an authentic "assertion failed" routine of mine getting called to fire off an email, when an rm -d returned nonzero.
  It was something that "should never fail". ("so why bother testing the return code?") Unless someone (like um... me) changes a folder name up a few levels. (oops) But instead of a crash in flames, or a "why the heck isn't the script updating those files??" (half hour later, find "because it's ignoring an error") I get a warning, and I fix it. and all is well.
  
  --
  I work for the Department of Redundancy Department.
5. Re:Objective-C nil by Anonymous Coward · 2013-01-02 02:43 · Score: 0
  
  You are the only kind of programmer worth hiring. The rest of them cause more work than they accomplish, in the long run.
Submitter not that anonymous... by Anonymous Coward · 2012-12-31 14:09 · Score: 0

When the link to twitter has them posting via their twitter handle that they "anonymously" submitted the story/link on Slashdot...
I didn't write it (you must be drunk too, lol) by Anonymous Coward · 2012-12-31 14:14 · Score: 0

It's only a link I referenced regarding error handling & how it can potentially be done in C or PASCAL (since the original Bell Labs/AT&T/Kernighan Ritchie C, &/or the original Niklaus Wirth PASCAL don't have try-catch/try-except built into them like JAVA, or Borland Object Pascal do, for example) & the IRC folks' hassle is their stuff's written in C (& I am not sure if the implementation/compiler they're using has err-handers/exception handlers, but classical C doesn't)...
* It's NEW YEAR'S 2013 THOUGH (12/31/2012), the world didn't end either per the Mayan Calendar b.s. on 12/21/2012, so I decided to take a drink with neighbors when I wrote up my original idea above (it can be done because of error handlers/exception handlers in C++ or Delphi though - they have them, above compiler structured error handling classes (C & PASCAL, again, don't)).
No, not *QUITE* drunk here, yet... lol, but close (3 hrs. to midnight, good chow @ neighbors is helping on that account... back to card game & brews now).
APK
P.S.=> Time to continue my drinking with my neighbors, we are having a good time/party there, & I have to bring the last case of beer I have over (it's pretty much "BYOB", but tons of good food too)... have a happy new year!
... apk
Assigned CVE-2012-6084 for this issue by seifried · 2012-12-31 19:12 · Score: 2

As per http://www.openwall.com/lists/oss-security/2013/01/01/3 this issue was assigned CVE-2012-6084. Remember folks, you can get your CVEs in advance which makes life easier for everyone. Please see http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html for details.
Server side only by Anonymous Coward · 2013-01-01 00:20 · Score: 0

The problem is server side. If you or the network can't trust to some degree your fellow admins, you have more serious problems.
FTFA:
"Topic: Charybdis: Improper assumptions in the server handshake code may lead to
a remote crash. (CAPAB module)"
For those of you too young to know anything about EFNet or IRC, while you may disapprove or condemn the lack of services that is why EFNet was and is popular. This idea that anyone owns a channel or god forbid a nick, is stupid.
To assign someone a uuid and force them to authenticate is too ripe for abuse. I would rather not appear online and everyone know I'm not online, then have those messages sitting in some queue somewhere. Doesn't take much to ssh from your phone, does take half a brain though.
Although several clients do have support (gaim for example), IRC was not meant to compete with ICQ or any other IM. It replaced talk.
Not bad for a guy on New Year's Eve, eh? LOL! by Anonymous Coward · 2013-01-01 02:07 · Score: 0

I was a 6 pack "into it" when I wrote the potential solution http://tech.slashdot.org/comments.pl?sid=3350243&cid=42437411 - &, it SHOULD work for the folks @ Efnet to solve their hassles...
What they're going through is a BIG part of the "why" of WHY I avoided C & PASCAL (vs. C++ &/or Object Pascal/Delphi) after I learned them, then discovered WHY the latter in parenthesis was created in part, as an "upgrade" to them (not just for OOP).
I also posted it, even though I was more of a fan of Dalnet since I was an admin there for YEARS on their "Official Help Channel for Windows Users" endorsed by K. Marden Bey no less, the creator of MIRC, because I liked IRC immensely in that timeframe (1994-2000)...
* On what you wrote? Hey - I'm also always on topic (unless attacked by trolls)!
APK
P.S.=>

"Where are my mod points now that your posts are on topic...." - by JonySuede (1908576) on Tuesday January 01, @12:48AM (#42439215)
Speaking of being on topic: Are you on topic now? Plus my initial post's already modded up to +2 interesting (it'll work is why in 1 or 2 of its parts vs. the hassle the C using IRC folks are seeing).
(It's ALSO the 2nd time you've done this kind of post directed my way too, this was one only a short while ago on VLC vs. Media Player Classic -> http://slashdot.org/comments.pl?sid=3336253&cid=42378957 so, "WTF?"
... apk
Pascal is STILL great (the best imo)... apk by Anonymous Coward · 2013-01-01 02:40 · Score: 0

Specifically Borland/Embarcadero Delphi (Object Pascal) -> http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 which THAT PROGRAM was created in!
E.G.-> If you look @ the list of what it can DO for an end user of it, listed there in the link, & from only a 600++k (32-bit version) or 800++k (64-bit version) of it, vs. its competitors like it that are 2-4 times its size no less & iirc, use things like SQLite, whereas I wrote all my functions by hand to do the same & MORE in a tinier single file multithreaded non-runtime interpreted 'stand-alone' executable?
You'll appreciate it more... perhaps even MORESO, for what's in my 'p.s.' below that I discovered 15++ yrs. ago & it became my FAVORITE tool to use for development (when I was a HUGE Microsoft Visual Studio guy (MSVC++ & MSVB before it)).
(Competitors were also created AFTER I wrote mine no less, years later that still don't do as much mind you)? You "get the picture"... it's a testimonial/testament of the POWER of Object-Pascal!)
* Especially since Borland Delphi 3/5/7 in the 32-bit world initially helped me create that program that has MYRIAD BENEFITS to end users of it, on many levels (builds I kept to myself in 32-bit, circa late 2003/2005/2008 iirc), & also NUMEROUS other apps I & others wrote too, did well using Pascal!
I have done others that have done well over time in commercially sold software, freeware/shareware, & things that helped me do well in trade shows in the art & science of computing (like MS Tech Ed) too - written in Pascal in Windows via Delphi - I only continued on using it in 64-bit above as well via RAD studio by Embarcadero (Delphi XE2 & C++ Builder) in the 64-bit world lately as well, since it's "all that" & THAT good (see below, again - you WILL find it useful perhaps in posts on Pascal & interesting as well, if not ENLIGHTENING - it was to me, & took me from other languages, as favorite at least)...
APK
P.S.=> I.E.-> It's the BEST of C++ & VB really, in 1 box... & early on, it was KNOWN as the "VB KILLER"... how/why?
This test resultset from (of all places) "VBPJ" (Visual Basic Programmer's Journal) issue Sept./Oct. 1997 "Inside the VB5 Compiler"...
Back circa 1997, I was a BIG fan of coding with Visual Studio... especially MSVC++ &/or VB.
I run into a review in VBPJ, of all places (Visual Basic Programmer's Journal) Sept./Oct. 1997 issue "Inside the VB Compiler", a competing trade rag no less & one that was QUITE respected!
Then?
There, I saw Borland Delphi LITERALLY "knock-the-chocolate" outta MS' offerings, overall, in performance...
How much so?
Ok (& this IS what I took to mgt.):
In the 6 tests given, Delphi won the majority (overwhelmingly in fact, in what ALL PROGRAMS DO, math & strings work)...
Specifics below (the most important, overall? Again - imo @ least - What they ALL do - math & strings!):
---
STRING SUITE:
Delphi = .275ms
MSVC++ = .500ms
MSVB = 4.091ms
---
MATH SUITE:
Delphi = 1.523ms
MSVC++ = 2.890ms
MSVB = 7.071ms
* AGAIN - note what I said above? Even while I was a HUGE fan of MS' Visual Studio?? I couldn't "argue with the numbers" here, & gravitated towards a BETTER coding environs in Delphi, by far, for performance alone!
---
API GRAPHICS METHODS SUITE:
Delphi = .269ms
MSVC++ = .293ms
MSVB = 292
---
TEXTBOX FORM LOADING SUITE:
MSVC++ = .012ms
Delphi
I put an idea(s) for folks to "BUILD ON" by Anonymous Coward · 2013-01-01 06:56 · Score: 0

During doing the parsing noted, you could check for NULLS, easily!
Or really, anything else at the location in the array of char the pointers are positionally at, including NULLS, in my description (which yes, is a check for string length too).
I did so, no less, while I was DRUNK no less & no, I said I didn't read the article either...
(Seems to have modded up well also - but of course, you're posting as AC and YOU will probably mod it down via your registered 'luser' account, & I honestly could care less if you do).
You asked a few questions, ok, here goes (so we can examine this further):

"What does "send" mean? you mean pass as parameters to string apis?" - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
No - By 'send' I mean 'vector thru' (using the term loosely) the array itself (which is a vector iirc vs things like linked lists which don't have to be contiguous memory), as in a loop & thru each position as I noted (which YOU don't seem to understand)!
---

"Are you suggesting you have one buffer that is double the length required, and the second pointer points to the end of the string?" - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
No, are you illiterate?
Again 0 I said how it is done, step by step in my FIRST post (modded up to +2 interesting no less vs. your b.s. here)
AND
I elucidated FURTHER above even!
(I had to - Since you're obviously quite 'thick' or illiterate - there, NOW - how do YOU like it, since you said my english is terrible you troll).
---

"What does "FAILS" mean?" - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
Errors out/abends - the meaning is explicit. You are illiterate obviously (or just trolling & nitpicking). The larger positioned pointer WILL 'fail out'... you could even use array indices since C strings are 'arrays of char' but no point (pun intended, best to use pointers).
---

"This does not map onto any behaviour defined in C" - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
Like Try-Catch or Try-Except don't? I pointed to ways to do that also... hairy ways, but ways above & beyond structured exception handlers in the compilers.
Needed, because both PASCAL & C (as implemented originally by Wirth + Kernighan & Ritchie respectively) DON'T HAVE THEM & to do this you'd need to do error handling.
---
I think what you were probably trying to describe is a well known trick where you align strings on page boundaries and then mprotect the second page to PROT_NONE, but this is nothing to do with C." - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
No, just what I stated above. I also don't just *think* you're a troll who isn't SURE of himself on your b.s., but also that you're going to downmod my post via your "registered 'luser'" account as well - it's why you're posting as AC now!
(In fac - I'd almost bank on it in fact - I know how you puny little trolls work, and think.)
APK
P.S.=> Lastly - I didn't read the article & said so since I was partying, & also QUITE drunk on the New Years Eve holiday - for that set of conditions, I did VERY WELL here, & lent some ideas that even others "hit on" similarly!
(Ugh... Man, I am still hungover in fact, but not badly)
I moved several times going from my home to a neighbor's a couple times that evening in a hurry, as well bringing "supplies" (beer) - but overall, the +2 INTERESTING upmod I got wasn't bad...
... apk
Arrays, vectors, & parsing + strlen code troll by Anonymous Coward · 2013-01-01 08:27 · Score: 0

"It's extremely difficult to parse, because you clearly don't understand how memory is organized." - by Anonymous Coward on Tuesday January 01, @12:53PM (#42442593)
WRONG - It's EASY for array of char = C strings so...Far from it as to difficult, & it is NOT hard (pointers work):
FIRST: You asked for code for this? I essentially implement strlen algorithmically, ala:
int strlen(const char s[])
{
int i = 0;
while (s[i] != '\0')
i++;
return i;
}
(Now - NOTE THE NULL CHECK ABOVE? It's using array indexed access but makes sense - it's ARRAY OF CHAR = STRING!)
---
SECOND - Arrays are like VECTORS constructed from CONTIGUOUS MEMORY on the heap vs. stack - you can push & pop elements outta them just like you can with array elements (sizing is the diff. partially).
On that note - There is a common mistake I've seen in research on this often stating arrays can't 'change size'!
Well... they can in JAVA or Delphi, or VB, but it's really changing pointers to a larger one from a smaller one, or vice-a-versa, copying elements to & fro as needed between them - (effectively RESIZING them dynamically!).
Hence, for example, VB redim preserve, or Delphi lists (really an array of sorts) & dynamic arrays it has.
---
THIRD - Arrays need contiguous memory, unlike linked lists, which makes linked lists superior in 1 respect:
They don't require contiguous memory locations, & thus, far better vs. memory fragmentation also!
(Which I've seen HALT exchange servers + I created a working program vs. it, that worked great, unfreezing them in fact - & that sold excellently for me in the mid 90's to early 21st century for in fact sold thru SERVER EXTRAS in Atlanta Ga., & firefox too, in the past also - should you required documentation for it? "Ask, & ye shall receive"), fool...
So don't even *TRY* to tell me I don't know how memory is organized, you trolling DOLT!
---
THIRD - I.E.-> They are EASY TO PARSE/vector thru in a loop, as my first post noted -> http://tech.slashdot.org/comments.pl?sid=3350243&cid=42437411 & the code shows above for strlen itself!
(Which was modded up +2 interesting no less in my init. post...).
* GRANTED - I omitted the NULL check, granted, but that's pretty obvious to check on also during said looping - & I would've 'hit on it' were I not intoxicated due to holiday celebrating & it IS in strlen (hence WHY I noted it).
(Which it also gives you strlen, & why I noted strlen (C) & length (PASCAL) functions as well)
Again - I was "loaded" or getting near it though, so I have an 'out' on that account, omitting it but I covered it to you here today in my 1st reply to you -> http://tech.slashdot.org/comments.pl?sid=3350243&cid=42443249
---
FOURTH:
Since C strings are just "arrays of char"?
Well - again: You could use array indices as I noted in my other reply to you as well, since it IS an 'array of char' in a string, but pointers ARE FASTER, fact! I would've done it, over array indexes personally & CERTAINLY OVER VECTORS USAGE!
As to the NULL checks part? Again:
The technique should work for checking on those as well, per my other reply to you here -> http://tech.slashdot.org/comments.pl?sid=3350243&cid=42443249 just an IF statement basically, & then your handler for it in THEN/else etc.-et al (generic coding speaking here) just checking the contents of the string used that
Now to "bury you"... apk by Anonymous Coward · 2013-01-01 09:54 · Score: 0

Since you won't show back up? Here's your funeral (regarding C array access via POINTERS & indirection):
---
PERTINENT QUOTE/EXCERPT:
"In C array access is always made through pointers and indirection operators. Whenever an expression such as X[k] appears in a program, the compiler interprets it to mean *(X + k). In other words, objects of an array are always accessed indirectly."
FROM -> http://www-ee.eng.hawaii.edu/~tep/EE160/Book/chap7/section2.1.3.html
---
* No small wonder you posted as AC since I know you 'trolls' that stalk me here & how you TRY to "think" & yes, act, using the term 'think' VERY loosely & sarcastically vs. "your kind" online, pure trash, in regards to YOU now!
(You're probably webmistressrachel, trolling STALKING online scumbag, extraordinaire, again -> http://slashdot.org/comments.pl?sid=3350243&cid=42444775 up to her USUAL scumbag troll tricks ):
Guess what?
YOU FAIL as always, vs. myself...
(Every single time you *try* to troll me by AC posts!)
I could definitely do pointers & loops thru the pointer to the string variable to do what I noted above, and yes, checks for nulls too (just like strlen does, & FASTER, because pointers work faster... less work to do, per the above, & FAR MORE "DIRECT").
APK
P.S.=> Yes, as I suspected here & you ADMITTED to webmistressrachel you trolling stalking scumbag -> http://slashdot.org/comments.pl?sid=3350243&cid=42438977
That's NO FIRST outta you... so, I must ask:
Are you mentally DERANGED, or what? There are LAWS against stalking online you know... & I certainly do NOT need a 'secret admirer' like YOU, trashbag
... apk
Re:You're a known DIRTY tricks troll, scumbag... a by webmistressrachel · 2013-01-01 13:01 · Score: 1

"Screw you, apk, and the horse you rode in on. If I ever see you post here again, I'll bomb you as AC from Tor, meaning I'll NEVER run out of posts because I can change endpoint."
You know damn well I posted this in anger because you were accusing me of doing it anyway, and of being "Barbie". You, and anyone else who can read this, will notice that I posted with my UID and when I do post I don't post AC. I have posted embarassing stuff about myself IRL to prove this incorrect but instead you used this against me, making assumptions about my gender makeup and whether I am who I say I am.
I extended an olive branch, and you abused it by ranting at Barbie telling him/her she was me or vice versa. So who's the troll, apk??
Here, another olive branch to prove I'm not Barbie, go do a whois on www.rachelwilson.net.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
No, I've got YOUR # down troll (& you KNOW it) by Anonymous Coward · 2013-01-01 13:44 · Score: 0

I extended an olive branch 3x and can show it... can you?
Face it - WE KNOW You ARE Barbara, not Barbie/Tomhudson, AND, because of your admitting it here now too, that you CERTAINLY TROLL& STALK ME TOO, admitting it (via nefarious tricks like using TOR).
Bottom-line: THERE ARE LAWS AGAINST STALKING ONLINE YOU KNOW! You're "outside your MIND" keeping it up, and admitting it as well, but there you are... it's you!
APK
P.S.=> I don't give a hoot on your domain... you are also trolltalk.com as far as I am concerned (gee, wonder who owns THAT domain) because of your admitting your bullshit here!
You are nuts... and for some odd reason, YOU ARE ALSO OBSESSED with STALKING & TROLLING ME why's that?
Cuz I wouldn't "bow" to you trolltalk.com scum and kicked your ASSES so many times on things technical, "barbie" took off (the cyclops diseased troll) which it is obvious you ARE He/She (tomhudson/barbara not barbie).??
Everyone KNOWS how you 'trolls' work (even deluded 'whitehat trolls' as you call it)!
HBGary and The Chinese Water Army are just BIGGER BADDER versions of YOUR KIND, lady (assuming you are even a lady that is).
Read Mr. Bruce Perens, he even KNOWS 'your kind' to a tee:

"It just takes one Ubuntu sympathizer or PR flack to minus-moderate any comment. Unfortunately, once PR agencies and so on started paying people to moderate online communities, and to have hundreds of accounts each, things changed." -

FROM -> http://linux.slashdot.org/comments.pl?sid=1738364&cid=33089192
and, so do I... to a tee, I've got your # down pat, especially after you ADMIT trolling me here... & YOU KNOW I've got Barbara, not Barbie/Tomhudson trapped in his/her words on stalking me as well... should I post that too? After all - you ARE her/him!
So please: DO YOURSELF A FAVOR - DON'T EVEN *TRY* MATCH WITS WITH ME WOMAN... you don't possess the skills in computing, OR the wits, or the information to back you -> http://tech.slashdot.org/comments.pl?sid=3350243&cid=42445065 as was seen there and in my 3 other posts supporting it.
I eat trolls like you, ALIVE in the computer sciences, just as I did to tomhudson/barbie MANY times... should I post those too? They number in the 100's... as it would go QUITE WELL with the time I caught her telling you & others to STALK & TROLL ME BY AC POSTS!
Lastly - See first line above, go for it...
... apk
Re:No, I've got YOUR # down troll (& you KNOW by webmistressrachel · 2013-01-01 14:06 · Score: 1

Bullshit, most of that. You're so wordy, and you've got it so wrong. Fortunately, I have an IRL to go back to that encourages me to contribute positive change around me (unlike this place and people like you).
Thanks for ruining my evening after I simply told someone it was bad form to drag you down to that level after you posted something positive.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
Re:Evasion, another "classic troll FAIL" by webmistressrachel · 2013-01-01 15:54 · Score: 1

This all started because I completely disagreed about the use of HOSTs as compared to Adblock or similar, and you started personally insulting someone I know. Now, you're doing the same to me.
Defend myself, I'm a stalker. Ignore you, people might think you were correct. What a dilemma. You're one evil, uncaring guy, apk. Security tools = positive change? Try www.timberrecycling.org for positive change. Or www.manchester.gov.uk/elections. Or call Greater Manchester Police and ask them about Rachel Wilson. If they say they've never heard about me, mention Operation Protector, or Operation Foot. They've heard of those, and will be able to look up my details quick enough.
I find you ego-centric list of challenges disturbing. How, as you quite rightly point out, could I have the experience you have when you were born first, went to what seems like decent schools and colleges, and actually had friends and good teachers as a child? You have taken no time or care at all to ensure what you are saying is relevent to me at all. Why should I care? I know I'm a good person, and admitting to teasing you about HOSTS (Which everyone here does, because it's a PLAIN STUPID solution to a common problem!) does not make me a stalker at all.
In fact, I'd welcome any investigation into such because it would simply prove that I'm not Tomhudson, and that you are assuming you're talking to me when I'm not even there. I checked the link and parent, and no, that's not me.

--
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
LMAO - you did it to YOURSELF admitting you troll by Anonymous Coward · 2013-01-01 16:46 · Score: 0

ME, in this very exchange... & I am not stupid lady! Nobody's THAT damn dumb!

"This all started because I completely disagreed about the use of HOSTs as compared to Adblock or similar, and you started personally insulting someone I know." - by webmistressrachel (903577) on Tuesday January 01, @10:54PM (#42447549)
Yea? She LIBELLED me in MANY ways (shall I post that too), trying to ruin my rep saying "I live with my mommy, and I never worked professinally in computing" hell... I've worked for MORE Fortune 100-500 than she has, I dusted her on TONS of computing tech debates, and I did not START IT... she, did!
She worked for SIEMENS? You tell her I think SHE is the reason they have been exploited so badly in SCADA then if you speak to her agian (lol). How's that? You like apples?? How do you like THEM apples???
Quoting a film hero of mine, an auto-didact in "Good Will Hunting" because he comes outta the same working class background, bogus violent neighborhoods I do, & more...we're MUCH alike.
Ah, anyhow/anyways:
(And unlike MOST of you fucking cowards, I don't "hide" behind some nickname/alias/handle, I put myself RIGHT OUT THERE, because hiding as you do? You will NEVER be able to prove you did anything worthwhile or attach it to your REAL NAME... but, first, you have to have DONE what I have... therein "lies the difference" and you certainly can't show you have either... fail, Fail, FAIL vs. me, everytime on every level).
Just like Barbara Hudson did... massively, 100's of times, despite her 'alleged technical guru' status here... lol, to that!
She's RAN & is gone with the dawn!
NOW, another challenge on that note to YOU again (you'll fail it, & I know it, hundreds here have... heck, even TenebrousEdge who is pretty well techincally versed, recently -> http://tech.slashdot.org/comments.pl?sid=3350243&cid=42445065 where I SHOT SO MANY "HOLES" into his rigged 'test'? He won't even answer & face it... he tried in email, but that backfired on him too, yet again).
GET THIS THRU YOUR HEAD: I've knocked KNOWN bigtime PhD's in the art & science of computing on their asses... think /. trolls can give me a run for my money? NOT SO FAR, for 8 yrs. now! Not a one... I am not to be "F'd with", or you will fail... everytime, to YOUR own dismay.
A man's MIGHT is judged by the strength of his enemies... I had better find BETTER enemies then.
Anyhow, disprove the points about hosts that my little program illustrates enumerated there -> http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
They're there, short & sweet, in summation... good luck - you'll NEED IT...
---

"You're one evil, uncaring guy, apk." -
Illogical off topic ad hominem attacks... oh, yes - the "last resort" of the stalking ac troll & all trolls, vs. facts & challenges they CANNOT meet or defeat.
Keep proving my points for me... you make ME, look GOOD (thanks!).
---

"Security tools = positive change?" - by webmistressrachel (903577) on Tuesday January 01, @10:54PM (#42447549)
In an art & science CHANGING THE WORLD? Absolutely... it's where I operate the BEST, since I have a good set of fundamentals, & DECADES around it... I can think of NO BETTER BATTLEGROUND for me, to fight on, for "positive change" that is of SERVICE TO OTHERS, & great aid vs. a very large threat (to your money & personal information).
That's all... have you done more on that VERY front? Have you done more on the other fronts
Whoops, edit (tenebrousedge on hosts FAIL) by Anonymous Coward · 2013-01-01 16:52 · Score: 0

His FAIL he shut the hell up on, on hosts -> http://slashdot.org/comments.pl?sid=3325045&cid=42336131
(AND I've told that kid, he is SHARP... made me THINK but I did outthink him & shot his 'rigged test' up SO BADLY? He won't argue it!)
* And, there you go... on /.. the "Show me State" of the internet? Let it NEVER be said APK doesn't back up his words...
APK
P.S.=> "Nuff Said" but you haven't met ANY of my challenges, & I certainly do NOT think you will do better disproving my points on hosts myriad values to users on a PLETHORA of multiple levels, to good effect... apk
Re:Evasion, another "classic troll FAIL" by Anonymous Coward · 2013-01-02 06:17 · Score: 0

We know it's you, apk. No one "IRL" would be so upset over slashdot posts or be trolled so easily.
Re:Evasion, another "classic troll FAIL" by Anonymous Coward · 2013-01-02 14:14 · Score: 0

You replied to webmistressrachel idiot.
This is not war: It's PEST CONTROL... apk by Anonymous Coward · 2013-01-03 00:48 · Score: 0

APK = Dalek, you & all /. trolls = Cybermen - Quoting Dr. Who episode "Doomsday" with video (lol):
"Open Visual Link" -> http://www.youtube.com/watch?v=ysvNOmDMVvk [youtube.com]
Especially see position 2.50 on the YouTube player control... & the quotes below in my p.s.!
---
That says it all about you webmistressrachel + other trolls like you via a "video analogy"... Especially vs. myself and it's from the BBC in Great Britain no less (just for YOU, 'white hat troll')... enjoy!
(ROTFLMAO!)
* Especially since you're "the inferior species known as cybermen" (trolls actually).
APK
P.S.=> Quoting the Daleks from said video, as to what applies in the links below, regarding YOU & all trolls, vs. myself? Ok:
"You are superior in only 1 respect - YOU ARE BETTER AT DYING", ala:
http://slashdot.org/comments.pl?sid=3350243&cid=42444775
http://slashdot.org/comments.pl?sid=3350243&cid=42446777
http://slashdot.org/comments.pl?sid=3350243&cid=42447057
http://slashdot.org/comments.pl?sid=3350243&cid=42447777 (with its addendum edit beneath it)
And of course, from the same video:
"WE WOULD DESTROY THE CYBERMEN (trolls & Pro-*NIX people) WITH ONLY 1 DALEK" (lol, me)
As my replies in the links above, to the troll webmistressrachel, clearly illustrates, point-by-point, in her COMPLETELY 'failing' challenges put to her vs. her words/claims!
AND
For webnistressrachel literally ADMITTING she trolls me here on this site (for YEARS now) -> http://slashdot.org/comments.pl?sid=3350243&cid=42438977
... apk
Re:You're a known DIRTY tricks troll, scumbag... a by Anonymous Coward · 2013-01-11 01:07 · Score: 0

webmistressrachel, downmods don't hide you troll by TOR you scumbag.