Re: [lopsa-tech] C coding
On 2010-10-08 at 08:07 -0700, Andrew Hume wrote: now i would have just said hour = t/(3600 * 1000); // remember t is in milliseconds // if i wanted hr in 00..23 range: hour = hour%24; bill said xx = t/1000 strncpy(hr_str, (ctime(xx)[11]), 2); hr_str[2] = 0; hour = atoi(hr_str); ignoring logic errors (we really wanted hour from teh epoch, and not hour of teh day) and time errors (ctime does localtime, not UTC); my question is, where does someone learn this technique? i am gobsmacked. In his defence: if you had wanted hour of the day, it's far better to use system libraries, which are well debugged, than to roll your own date calculations and discover the need to deal with things like leap-seconds, etc. And for hour-of-the-day, in those cases where that's actually needed, localtime is normally what's wanted by non-sysadmins. Now, still better to just use localtime() and access the tm_hour field from the resulting struct tm, sure. But I've seen self-calculations snowball out of control as people just add a little bit here or there, until you end up with something almost as bad as the extraneous string intermediate steps that Bill came up with. So the logic errors are really communication failures at the requirements stage. Now, the string munging, that's another story entirely and someone who'd do that, I can believe that they just weren't paying attention to the requirements as they were specified, as they were off mentally solving the problem already. -Phil ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
Oh the pain! Make it stop!! -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
Andrew == Andrew Hume and...@research.att.com writes:
Andrew ignoring logic errors (we really wanted hour from teh epoch, and not
Andrew hour of teh day) and time errors (ctime does localtime, not UTC);
Andrew my question is, where does someone learn this technique?
They read thedailywtf.com, not realizing that it's about what *not* to
do. :)
enum boolean {
true,
false,
file_not_found,
};
One of my favorites.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Re: [lopsa-tech] C coding
That is just... special.
I mean, I've seen some funny comments before, but nothing that was
*that* awful...
// FIXME: what do we do here?
// FIXME: the following line is scary.
// FIXME: the following 2 functions totally suck, are useless and
should be replaced immediately.
// FIXME: Do we care about revision? We should.
// FIXME !!!
// FIXME: add comments
// FIXME: come _on_ coder's name deleted, you can do better than this ;-)
And a classic:
if(empty($unix_date)) {
return Bad date; // careful Indy!
}
On 8 October 2010 16:22, Randal L. Schwartz mer...@stonehenge.com wrote:
Andrew == Andrew Hume and...@research.att.com writes:
Andrew ignoring logic errors (we really wanted hour from teh epoch, and not
Andrew hour of teh day) and time errors (ctime does localtime, not UTC);
Andrew my question is, where does someone learn this technique?
They read thedailywtf.com, not realizing that it's about what *not* to
do. :)
enum boolean {
true,
false,
file_not_found,
};
One of my favorites.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
--
Mark Dennehy
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Re: [lopsa-tech] C coding
On Oct 8, 2010, at 11:22 AM, Randal L. Schwartz wrote:
enum boolean {
true,
false,
file_not_found,
};
I've always preferred:
enum boolean {
true,
false,
maybe,
};
-C
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Re: [lopsa-tech] C coding
I see this in code now and then: 116-1 Python and C interpret that as 1 (16 - 1), which is 32768. The programmer usually means (1 16) - 1, which is 65535. There's a big difference, especially if you are using these for bit masks: 32768 = 1000 65535 = Tom ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
- Tom Limoncelli t...@whatexit.org wrote: I see this in code now and then: 116-1 Being just a system geek and not a professional programmer, I don't understand why one would use that notation instead of the more obvious variations of 0x8000? I understand that the compiler, at compile time (not run time) will figure out that the programmer meant 0x8000 from that piece of code so the end result is the same but it seems that for documentation purposes it'd be more obvious to do it the other way. Am I missing something? Thanks for letting me ask. -- MCT Michael C Tiernan http://www.linkedin.com/in/mtiernan Non Impediti Ratione Cogatationis ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
There's always this one, which I ran into at some point and thought was
just lovely. No, I didn't do this, and no, I can't take credit for making
it up either...I can't even remember where I first saw it, and yes, I
could use Google to find it (waveHi, Tom! :)/wave).
typedef enum {
CODE_BLUE,
CODE_RED
} Code;
extern Code condition;
void check_condition() {
if (condition = CODE_RED) {
launch_missiles();
}
}
-Adam
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Re: [lopsa-tech] C coding
typedef enum {
CODE_BLUE,
CODE_RED
} Code;
extern Code condition;
void check_condition() {
if (condition = CODE_RED) {
launch_missiles();
}
}
:-)
I may have to go dust off my copy of _C Traps and Pitfalls_ by Andrew Koenig, a
volume I heartily recommend to anyone. (I still miss the Computer Literacy
Bookstore in San Jose, without which I would never have discovered half the
cool
shit I did. Cue argument about e-books here. :-)
___
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
Re: [lopsa-tech] C coding
Usually you see this in a data structure: x = [ 18-1, 116-1, 124-1, 132-1, ] That is a lot easier to read than 0x8000 (etc) Tom -- http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) http://www.TomOnTime.com -- my advice (more videos coming soon) ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/10 11:07 , Andrew Hume wrote: bill said (elided to preserve what sanity might be left in readers) My headache just got a *lot* worse - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyv5SIACgkQIn7hlCsL25VATQCgpUqdLcJqokdBoicasP3o1II/ KB8An2LT3WepS3nOl+ifMdrccR7K7htz =+X/3 -END PGP SIGNATURE- ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/10 13:48 , Michael Tiernan wrote: - Tom Limoncelli t...@whatexit.org wrote: I see this in code now and then: 116-1 Being just a system geek and not a professional programmer, I don't understand why one would use that notation instead of the more obvious variations of 0x8000? I understand that the compiler, at compile time (not run time) will figure out that the programmer meant 0x8000 from that piece of code so the end result is the same but it seems that for documentation purposes it'd be more obvious to do it the other way. Am I missing something? I see it as a matter of self-documentation; 0x8000 suggests a magic number of some kind, which is probably related to bits or to hardware control, whereas 1(mumble) explicitly says this is a bit. (The former might be a bit *mask*, or not linked to particular bits at all, for example a value written to a control register where the register isn't documented at the bit level but only the acceptable values.) Also, the 1n syntax helps when you are coding to a specification which describes things in terms of bit numbers (e.g. bit 0 controls the transmit register). - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyv52wACgkQIn7hlCsL25WN4wCghwyD0hLGLaV8P4UDUXtOj1S8 KCsAoK4S6h/DBs4G7pp/WDRKkds844wn =/va/ -END PGP SIGNATURE- ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
Re: [lopsa-tech] C coding
I see it as. If it's open to interpretation it's not that well self-documented :) On 10/8/2010 5:54 PM, Brandon S Allbery KF8NH wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/8/10 13:48 , Michael Tiernan wrote: - Tom Limoncellit...@whatexit.org wrote: I see this in code now and then: 116-1 Being just a system geek and not a professional programmer, I don't understand why one would use that notation instead of the more obvious variations of 0x8000? I understand that the compiler, at compile time (not run time) will figure out that the programmer meant 0x8000 from that piece of code so the end result is the same but it seems that for documentation purposes it'd be more obvious to do it the other way. Am I missing something? I see it as a matter of self-documentation; 0x8000 suggests a magic number of some kind, which is probably related to bits or to hardware control, whereas 1(mumble) explicitly says this is a bit. (The former might be a bit *mask*, or not linked to particular bits at all, for example a value written to a control register where the register isn't documented at the bit level but only the acceptable values.) Also, the 1n syntax helps when you are coding to a specification which describes things in terms of bit numbers (e.g. bit 0 controls the transmit register). - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyv52wACgkQIn7hlCsL25WN4wCghwyD0hLGLaV8P4UDUXtOj1S8 KCsAoK4S6h/DBs4G7pp/WDRKkds844wn =/va/ -END PGP SIGNATURE- ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/ ___ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
