On Dec 15, 2007 12:22 PM, John W. Krahn <[EMAIL PROTECTED]> wrote: snip > > That depends on the version of C you are using. Given the lack of > > other syntax in this short program I cannot tell if it is K&R C, ANSI > > C, or C99. If he is using K&R C, that is a perfectly fine main > > definition (int return type is assumed for functions that don't > > specify). > > I *DARE* you ... no, wait ... I DOUBLE DAWG DARE YOU to post that > opinion on comp.lang.c and/or comp.programming. Go on, I'll wait. :-) snip
That would be foolhardy indeed since comp.lang.c is an ANSI/ISO/C99 newsgroup. Posting K&R C statements and questions to it would be roughly equivalent to posting about Perl 4 here. snip > > I agree with this whole heartedly. All versions of C are loaded > > guns. Anyone can pick one up, but that doesn't mean I want to stand > > next to that person. But I think Jeff's main point was, since it is > > possible, how should we handle it? > > Why don't we all just ignore standards, join the Microsoft Borg and do > anything we want? (Vote for Ron Paul!!!!) Since anything is possible > why don't we just ignore anything the program has to say? How do we > even know that the "data" it spews out is valid? > > ;-) snip Well, yes, we have to deal with bad, buggy, standards violating software everyday. The question isn't "should we violate standards", it is "what should our response be". Mine is (metaphorical) violence aimed at the author of the bad program if he or she can be found, rewriting the offending code if he or she can't be found, and workarounds when they can't found and we are still forced to use it. Let me give you a scenario: You are a contractor at a firm. The company has just bought FooBar version 2007.99.1. It is a piece of hardware that plugs into the USB port of a server and provides ISO FLECIDOODLE compliance. You are tasked to port some of their code to use this new FLECIDOODLE compliant hardware. In order to initialize the system for a transaction the manual says you must run "/usr/bin/foobar start task". The foobar program returns 0 on failure, -1 on warnings, and a 1 on success. On success or warnings, it writes a transaction id to STDOUT. On warning or failure it writes one or more messages to STDERR. To close a transaction you must call "/usr/bin/foobar end $transactionid". After snooping on the data the program sends to the device, it appears as if the communication is encrypted. There are currently no modles on CPAN that deal with FooBar 2007.99.1 or FLECIDOODLE. Your boss wants a solution by the end of the week, what do you do? A few (but not necessarily all) options are 1. whine and moan about how the return codes are not POSIX/SUS compliant 2. attempt to reverse-engineer FooBar version 2007.99.1's communication protocol and hope that once you have done that it won't change in a future release and that your implementation is good enough for FLECIDOODLE compliance (i.e. foobar isn't doing something you don't know about from the manual) 3. Purchase the FLECIDOODLE spec and try to implement a compliant Perl version from scratch 4. Quit 5. Write a quick Perl module for the other code to use and document the heck out it Personally, I would do number 5 and start investigating number 3 without much hope (once a company has bought bad software they tend to be dead set on using it). -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
