181–190 of 214 posts
IF(.NOT.CHECK()) STOP 'xxx'
Anyway, somebody (not me) got into trouble when Very Serious Customers were offended by seeing the occasional STOP DAMN message at link time.
Using github to search like this reminds me of how a CS professor of mine would show the "best commit messages of the year" (homework was submitted via git) by looking for various patterns like all caps, all symbols, etc. http://www.slideshare.net/bsotomay/uchicago-cmsc-23300-the-b...
https://github.com/odbol/Reddit-Scheduler/commits/master
People definitely gave me flac for that.
/ * This should never happen exception. Use in situation that really shouldn't happen...NEVER * * */ public class NeverHappenException extends RuntimeException {
Earlier quoted context omitted.
It's also for cases when you know it can't happen. For example, Java's String class has a method public byte[] getBytes(String charsetName) throws UnsupportedEncodingException Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case: someString.getBytes("UTF-8"); This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do so…
getBytes is poorly designed. In a safety-oriented language like Haskell or Rust, the set of encodings would be represented as an ADT (which forms a closed set) or s Typeclass (open set). All possible type-correct encoding arguments would be safe.
xs = if p x then concat [[x, "bar"], foos] else "baz" : foos
ys = tail xs
Earlier quoted context omitted.
How do you do that? I get on bootup you could do a little diddy, but how would you know if random bits are getting flipped? Seems tricky for an embedded device...
Not quite for memory _corruption_ but back when I was writing API code in C, I would place 'sentinels' at each end of my structs. struct somestruct { int s1; int data; char * moreData; int s2; } When the caller of the API needed to call my code, it had to first call a function to get an instance of the struct. This constructor like code would allocate the memory for the struct, and then set s1 and s2 to 0xDEADBEEF; T…
Earlier quoted context omitted.
It's a sub-pattern of "ain't got time for dat". Developer knows that condition should never happen, but is not inclined to prove it (as represented by coding type checking or other handling) yet realizes it shouldn't be ignored outright (if only to document the unproven condition in code, or to shut the compiler up about incompleteness warnings).
It's also for cases when you know it can't happen. For example, Java's String class has a method public byte[] getBytes(String charsetName) throws UnsupportedEncodingException Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case: someString.getBytes("UTF-8"); This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do so…
Earlier quoted context omitted.
How do you do that? I get on bootup you could do a little diddy, but how would you know if random bits are getting flipped? Seems tricky for an embedded device...
Not quite for memory _corruption_ but back when I was writing API code in C, I would place 'sentinels' at each end of my structs. struct somestruct { int s1; int data; char * moreData; int s2; } When the caller of the API needed to call my code, it had to first call a function to get an instance of the struct. This constructor like code would allocate the memory for the struct, and then set s1 and s2 to 0xDEADBEEF; T…
However this might not have caught the error condition described upthread. That condition might have overwritten data or moreData without touching s1 or s2.
Otherwise, great!
Earlier quoted context omitted.
It's a sub-pattern of "ain't got time for dat". Developer knows that condition should never happen, but is not inclined to prove it (as represented by coding type checking or other handling) yet realizes it shouldn't be ignored outright (if only to document the unproven condition in code, or to shut the compiler up about incompleteness warnings).
It's also for cases when you know it can't happen. For example, Java's String class has a method public byte[] getBytes(String charsetName) throws UnsupportedEncodingException Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case: someString.getBytes("UTF-8"); This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do so…
BTW I made a (almost religious) habit out of ensuring that everything I touch is encoded UTF-8 or can be converted to that as I have been bitten several times hard by unexpected encoding stuff. Therefore, the above problem catches me pretty often.
Earlier quoted context omitted.
It's also for cases when you know it can't happen. For example, Java's String class has a method public byte[] getBytes(String charsetName) throws UnsupportedEncodingException Since it can throw a checked exception you have to catch it, which generally is fine, but consider this case: someString.getBytes("UTF-8"); This call can never fail (support for UTF-8 encoding is required in Java) but in my case I have to do so…
getBytes is poorly designed. In a safety-oriented language like Haskell or Rust, the set of encodings would be represented as an ADT (which forms a closed set) or s Typeclass (open set). All possible type-correct encoding arguments would be safe.
Earlier quoted context omitted.
Hahaha, I went through the masters of comp sci program there. Those commits mentioning Borja cracked me up, and I swear "i love the smell of segfaults in the morning" was written on the wall in the big lecture room in the physical sciences building. Gives me flashbacks - that program was brutal (though really good).
Just looking at this one course and the projects... This is night and day harder than anything I had to do in my CS program. We just dicked around in Java for most of it, no C, and definitely no low level socket programming or reproducing an RFC. I mean it sounds awesome, but really hard.
In the masters program you can somewhat build your own degree after taking their core classes, so you can at least study what you're really interested in (or avoid the hard stuff like a lot of people did). Most of the profs had real industry experience too. A C++ class for example was taught by a guy who sold his company, now is a research fellow at a huge lab, and sits on the standards board. We got to bounce questions off Bjarne Stroustrup. Was pretty cool.