Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 06:44:25PM +0100, Phil Lanch said: On Thu, Sep 04, 2003 at 03:40:18PM +0100, David Cantrell wrote: It's just this sort of thing that makes me lurve perl. you mistyped C++. Without getting into a flamewar, and whilst appreciating the benefits of compile time generic object type checking, I thought you couldn't rely on a given C++ implementation to do auto-destruction. On the other hand, IIRC, you can rely ona destructor being called. But I think Dave's point was that he loves how Perl just does all that for you (and therefore, I supoose, also likes that feature of Python, PHP, Java and many more). On a tangentially related note, I'm very rapidly starting to come to the opinion that there are far too many applications that are written in C/C++ which don't need to. Simon -- the illusion of knowledge without any of the difficult bits
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Simon Wistow [EMAIL PROTECTED] wrote: On a tangentially related note, I'm very rapidly starting to come to the opinion that there are far too many applications that are written in C/C++ which don't need to. I heartily agree. I think that the combination of a scripting language plus some backend libraries in C/C++ can do the job much better. And they're probably easier to test too. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Fri, Sep 05, 2003 at 09:46:47AM +0100, Simon Wistow wrote: On Thu, Sep 04, 2003 at 06:44:25PM +0100, Phil Lanch said: On Thu, Sep 04, 2003 at 03:40:18PM +0100, David Cantrell wrote: It's just this sort of thing that makes me lurve perl. you mistyped C++. Without getting into a flamewar, and whilst appreciating the benefits of compile time generic object type checking, I thought you couldn't rely on a given C++ implementation to do auto-destruction. It's personal preference, of course, but I prefer using C to C++ for a lot of things because well, I know and understand C's edge cases well enough to either use and abuse them a bit or stay away from them. C++ seems to me to have a much larger number of edge cases - which I suppose is almost inevitable given the relative complexity of the languages. I am also probably somewhat jaded by having recently spent a large chunk of time resurrecting a large C++ application that has been slowly being written since the early 90s. It's been interesting in a lot of ways. One of them is how obvious it is that the language has changed in subtle (and not so subtle ways) in the last twelve years. The app was originally written for Sparc Solaris. I'm making it run on Intel Linux. I have neither a Sparc Solaris box, or any kind of Sun compiler. Fun. On the other hand, IIRC, you can rely ona destructor being called. But I think Dave's point was that he loves how Perl just does all that for you (and therefore, I supoose, also likes that feature of Python, PHP, Java and many more). Indeed, although the issue of *when* and *how* a destructor ends up being called depends sensitively on the garbage collection scheme, etc that a given language uses - in perl it's easy - a destructor is called immediately after it goes out of scope, because it is known to no longer have any live references to it, so this timely destruction is a pretty quick win. Java basically skives the issue with a It'll get called. Don't know when, don't ask and you shouldn't worry about how it'll be called. I'm given to understand that this is quite a relevant issue to Parrot, which will be using a GC scheme which is a lot more like Java's On a tangentially related note, I'm very rapidly starting to come to the opinion that there are far too many applications that are written in C/C++ which don't need to. Well, that is true, but I'm also seeing some of the problems caused by not having a (strict | anal | strong | paranoid | batshit ) type system. Certain types of bugs persist for far longer than they should in 10 line Perl applications whereas a less laissez-faire type system would flush them out basically trivially. Whether this occupies more or less programmer time than beating your skull against a timorous typecast or other pointer pedantry will, of course, Depend. Ben
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Fri, Sep 05, 2003 at 10:59:31AM +0100, Ben wrote: Well, that is true, but I'm also seeing some of the problems caused by not having a (strict | anal | strong | paranoid | batshit ) type system. Certain types of bugs persist for far longer than they should in 10 line Perl applications whereas a less laissez-faire type system would flush them out basically trivially. Which is why my subroutines and methods check that they have been called with the right parameters, and that those parameters have sane values. Generally, I don't need to do that much validation, because I'm passing objects around and can rely on their constructors to have already validated the data, so just use isa() to check that my parameters are the right type. If you need to sanity-check values as well as types, you should invite Params::Validate into your life, and it can be your personal and special friend. -- David Cantrell | Reprobate | http://www.cantrell.org.uk/david If a job's worth doing, it's worth dieing for
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Ben was also seeing: ... some of the problems caused by not having a (strict | anal | strong | paranoid | batshit ) type system. Certain types of bugs persist for far longer than they should in 10 line Perl applications whereas a less laissez-faire type system would flush them out basically trivially. Yup. How many OO Perl programmers does it take to change a light bulb? HASH(0x804e054) Whether this occupies more or less programmer time than beating your skull against a timorous typecast or other pointer pedantry will, of course, Depend. soapbox design-by-contract exaggeration really-means=might helpwill solve every conceievable problem/exaggeration. /soapbox Cheers ti'
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Wed, Sep 03, 2003 at 11:48:19AM +0100, Simon Wistow wrote:
I have to admit, I like gotos in C. This is not a winning testimonial
though. I've been told that my C is like Object Orientated assembler
which is fair enough because I learnt C after I'd learnt 68k.
Hmmm, I like gotos too, but mainly for freeing.
[deliberately not snipped for context]
My code typically looks something like ...
quirka_t *
foo (foo_context * context, int * error)
{
/* malloc bar and if that fails set error and goto FAIL */
/* malloc quirka and if that fails set error and goto FAIL1 */
/* do something with quirka and if that fails, set error, goto FAIL2 */
SUCESS:
return quirka;
FAIL2:
/* free quirka */
FAIL1:
/* free bar */
FAIL0:
return NULL;
}
apparently people ahve been known to be sick.
That is pretty ugly. The thing to remember is that in ANSI, free(NULL); is
a) valid, and b) a NOOP. So I'd write that as:
| quirka_t *foo (foo_context *context, int *error) {
| bar_t *bar=NULL;
| quirka_t *quirka=NULL;
|
| bar=(bar_t *)malloc(sizeof(bar_t));
| if(!bar) goto error;
|
| quirka=(quirka_t *)malloc(sizeof(quirka_t));
| if(!quirka) goto error;
|
| /* do stuff */
|
| end:
| free(bar);
| return(quirka);
| error:
| free(bar);
| free(quirka);
| return(NULL);
| }
This has several advantages, IMO:
1) it's easy to check that you've free()d or dealt with everything that
you've set up.
2) goto error is a very nice way of saying this is an error condition,
and you don't (yet) have to go and look at what the error condition
handling is. Conversely, the error: label means that you can see what
this function should return on error and normal return very quickly
and easily.
3) You don't have to be able to work out what you've allocated and free()d,
as long as you free or return all the stuff you *might* have allocated
at the end.
4) it's always goto error; so you don't have to try and work out what
state you might be in for some complicated state machine.
Of course, it goes without saying that if you want to free something in the
middle of the function, you have to do free(foo); foo=NULL;, but that's
a minor disadvantage. The real disadvantage comes with the C99 concept of
scope, because you can't easily deal with the variables that only exist
within a scope, only within the scope of all of the function. You also need
to remember that you need #include stdio.h for NULL to be defined, but
since you're using the standard library functions, I'm going to assume that
you probably have stdio.h.
--
Lusercop.net - LARTing Lusers everywhere since 2002
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 01:03:16PM +0100, Lusercop wrote:
On Wed, Sep 03, 2003 at 11:48:19AM +0100, Simon Wistow wrote:
I have to admit, I like gotos in C. This is not a winning testimonial
though. I've been told that my C is like Object Orientated assembler
which is fair enough because I learnt C after I'd learnt 68k.
Hmmm, I like gotos too, but mainly for freeing.
[deliberately not snipped for context]
My code typically looks something like ...
quirka_t *
foo (foo_context * context, int * error)
{
/* malloc bar and if that fails set error and goto FAIL */
/* malloc quirka and if that fails set error and goto FAIL1 */
/* do something with quirka and if that fails, set error, goto FAIL2 */
SUCESS:
return quirka;
FAIL2:
/* free quirka */
FAIL1:
/* free bar */
FAIL0:
return NULL;
}
apparently people ahve been known to be sick.
That is pretty ugly. The thing to remember is that in ANSI, free(NULL); is
a) valid, and b) a NOOP. So I'd write that as:
| quirka_t *foo (foo_context *context, int *error) {
| bar_t *bar=NULL;
| quirka_t *quirka=NULL;
|
| bar=(bar_t *)malloc(sizeof(bar_t));
| if(!bar) goto error;
|
| quirka=(quirka_t *)malloc(sizeof(quirka_t));
| if(!quirka) goto error;
|
| /* do stuff */
|
| end:
| free(bar);
| return(quirka);
| error:
| free(bar);
| free(quirka);
| return(NULL);
| }
This has the problem that if you're calloc'ing and initialising a complex
structure then the free's aren't necessarily that simple. Eg:
miner_t *smith (surbiton_context * context, int * error) {
miner_t * foo = NULL;
if ((foo = (miner_t *) calloc(1, sizeof(miner_t))) == NULL) {
*error = ENDORIAN;
goto FAIL1;
}
if ((foo-quirka = (quirka_t *) calloc(1, sizeof(quirka_t))) == NULL) {
*error = ENDORIAN;
goto FAIL2;
}
if ((foo-quirka-fleeg = (fleeg_t *) calloc(1, sizeof(fleeg_t))) == NULL) {
*error = ENDORIAN;
goto FAIL3;
}
.
return foo;
FAIL3:
free(foo-quirka-fleeg);
return NULL;
FAIL2:
free(foo-quirka);
return NULL;
FAIL1:
free(foo);
return NULL;
}
With nested structures like these, this structured approach just seems
cleaner to me than all those temporaries kicking about.
Ben
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 01:40:08PM +0100, Ben wrote:
return foo;
FAIL3:
free(foo-quirka-fleeg);
return NULL;
FAIL2:
free(foo-quirka);
return NULL;
FAIL1:
free(foo);
return NULL;
}
With nested structures like these, this structured approach just seems
cleaner to me than all those temporaries kicking about.
what's wrong with:
| if(foo) {
| if(foo-quirka) {
| free(foo-quirka-fleeg);
| }
| free(foo-quirka);
| }
| free(foo);
In the error condition?
or even just:
| free_foo(foo);
( :-) )
If you make sure your structures don't have dangling pointers, then that has
got to be a good thing in my opinion.
Still neater (IMO) than the FAIL1: FAIL2: FAIL3: approach.
--
Lusercop.net - LARTing Lusers everywhere since 2002
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 03:07:08PM +0100, Lusercop wrote:
what's wrong with:
| if(foo) {
| if(foo-quirka) {
| free(foo-quirka-fleeg);
| }
| free(foo-quirka);
| }
| free(foo);
In the error condition?
Gets a bit unweildy if you have foo-quirka-fleeg-miner-willy-...
It's just this sort of thing that makes me lurve perl.
--
Lord Protector David Cantrell | http://www.cantrell.org.uk/david
Any technology distinguishable from magic is insufficiently advanced
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 03:07:08PM +0100, Lusercop wrote:
On Thu, Sep 04, 2003 at 01:40:08PM +0100, Ben wrote:
return foo;
FAIL3:
free(foo-quirka-fleeg);
return NULL;
FAIL2:
free(foo-quirka);
return NULL;
FAIL1:
free(foo);
return NULL;
}
With nested structures like these, this structured approach just seems
cleaner to me than all those temporaries kicking about.
what's wrong with:
| if(foo) {
| if(foo-quirka) {
| free(foo-quirka-fleeg);
| }
| free(foo-quirka);
| }
| free(foo);
In the error condition?
or even just:
| free_foo(foo);
( :-) )
If you make sure your structures don't have dangling pointers, then that has
got to be a good thing in my opinion.
Still neater (IMO) than the FAIL1: FAIL2: FAIL3: approach.
Foxen for boxen. We've had variants of this conversation before. You know I
like to write my code on the assumption that the people reading it
(assuming such beasts exist) may be more inexperienced or more junior
than I am. To my mind, FAIL1: 2: 3: helps to hammer the message home.
Given that this is a fairly structured style of writing a language which
enforces so little, I don't consider this a Bad Thing.
It doesn't really matter and beyond a certain level it's a matter of
personal preference, feeling and aesthetic anyway.
Ben
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 03:40:18PM +0100, David Cantrell wrote:
It's just this sort of thing that makes me lurve perl.
you mistyped C++.
class fleeg {
};
class quirka {
public:
quirka () { f = auto_ptrfleeg (new fleeg); }
private:
auto_ptrfleeg f;
};
class miner {
public:
miner () { q = auto_ptrquirka (new quirka); }
private:
auto_ptrquirka q;
};
auto_ptrminer smith (surbiton_context * context, int * error) {
auto_ptrminer foo;
try {
foo = auto_ptrminer (new miner);
} catch (bad_alloc e) {
*error = ENDORIAN;
return foo;
}
.
return foo;
}
HTH. HAND.
--
Phil Lanch0xD78D598DA6635CF32AB24593C98994B7D95B33E3
(i even know the passphrase: http://www.subtle.clara.co.uk/rephrase )
If you tell a lie big enough and keep repeating it, people
will eventually come to believe it. -- Joseph Göbbels
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, 4 Sep 2003, Phil Lanch wrote:
On Thu, Sep 04, 2003 at 03:40:18PM +0100, David Cantrell wrote:
It's just this sort of thing that makes me lurve perl.
you mistyped C++.
I consider myself to be a programmer. Having read this code, my only
possible response is, You what?
AICMFP.
S.
class fleeg {
};
class quirka {
public:
quirka () { f = auto_ptrfleeg (new fleeg); }
private:
auto_ptrfleeg f;
};
class miner {
public:
miner () { q = auto_ptrquirka (new quirka); }
private:
auto_ptrquirka q;
};
auto_ptrminer smith (surbiton_context * context, int * error) {
auto_ptrminer foo;
try {
foo = auto_ptrminer (new miner);
} catch (bad_alloc e) {
*error = ENDORIAN;
return foo;
}
.
return foo;
}
HTH. HAND.
--
Shevekhttp://www.anarres.org/
I am the Borg. http://www.gothnicity.org/
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Thu, Sep 04, 2003 at 06:57:41PM +0100, Shevek wrote: On Thu, 4 Sep 2003, Phil Lanch wrote: you mistyped C++. I consider myself to be a programmer. Having read this code, my only possible response is, You what? AICMFP. sorry, i forgot to say: #include YHBT HTH. HAND. though it's just resource acquisition is initialization - it's not entirely devoid of logic ... /me looks for a bridge to hide under -- Phil Lanch0xD78D598DA6635CF32AB24593C98994B7D95B33E3 (i even know the passphrase: http://www.subtle.clara.co.uk/rephrase ) Daddy, why are we hiding? We use vi, son. They use emacs.
Re: DOS/WIN archivers of the mid 1990s (was Re: gzipping your websites WINRAR 40 days trial)
On Tue, Sep 02, 2003 at 10:05:02PM +0100, Barbie [home] wrote: On 02 September 2003 09:43 Roger Burton West wrote: (All of this only applies to the Windows world, obviously; I think the parallels in Unix, or at least Linux, would be .tar.bz2, .tar.gz, and dodgy commercial software with auto-extracting installers like the JRE.) Why obviously? RAR, ACE, ZIP, GZIP, BZIP formats are all available on both Windows and many Unix variants. On Unix, RAR and ACE are only available as binaries, which puts off a lot of people; and neither those nor ZIP preserves file ownership or permission information. So while I'm able to extract most files under Unix, I wouldn't choose those formats for something that I'm originating and plan to share primarily with other Unix users. Roger
Re: DOS/WIN archivers of the mid 1990s (was Re: gzipping your websites WINRAR 40 days trial)
Roger Burton West [EMAIL PROTECTED] wrote: On Unix, RAR and ACE are only available as binaries, which puts off a lot of people; and neither those nor ZIP preserves file ownership or permission information. So while I'm able to extract most files under Unix, I wouldn't choose those formats for something that I'm originating and plan to share primarily with other Unix users. You can get unrar as source code. I posted the link yesterday. http://files10.rarlab.com/rar/unrarsrc-3.2.3.tar.gz -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Nicholas Clark [EMAIL PROTECTED] wrote: On Tue, Sep 02, 2003 at 07:16:40AM +, Dominic Mitchell wrote: For the benefit of people likely to come up against Yet Another Compression Format, though: http://files10.rarlab.com/rar/unrarsrc-3.2.3.tar.gz The code in there is a lot cleaner than the last time I looked at it. (I presume I was looking at the same official unrar source; previous was in C, not C++). The old version was a liturgy of bad style tips. For example, using #include to pull in lots of other .c files, and IIRC #define BEL 007 printf (... %c ..., BEL) when the escape \a has been in C for a couple of decades now Yuck. I didn't actually look at it, just let the ports compile it for me. When it comes to bad C source code though, I don't think I've been more offended by anything other than procmail. It was (last I looked) a rats nest of gotos and other horrors. Hmmm, I've just had a look and it's still remarkably unpleasant to wade through. Good C source can be a pleasure to read, though. It's one of the reasons I always keep a BSD source tree handy. It's usually very easy to work out what's going on. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: DOS/WIN archivers of the mid 1990s (was Re: gzipping your websites WINRAR 40 days trial)
On Wed, Sep 03, 2003 at 09:49:28AM +, Dominic Mitchell wrote: You can get unrar as source code. I posted the link yesterday. Yes, but not the compressor. Ditto for ACE and ARJ. So there's no way to originate a RAR file under Linux without using binary-only software, and any other Unix will have to use Linux or Windows emulation to run even that. That makes quite a lot of people look for something else. Roger
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Wed, Sep 03, 2003 at 09:53:21AM +, Dominic Mitchell wrote: Yuck. I didn't actually look at it, just let the ports compile it for me. I didn't inspect it too far, but it seems that the current source is safe to look at. I seems to have benefited from a complete re-write When it comes to bad C source code though, I don't think I've been more offended by anything other than procmail. It was (last I looked) a rats nest of gotos and other horrors. Hmmm, I've just had a look and it's still remarkably unpleasant to wade through. At the risk of going off topic, the Perl 5 source isn't exactly pleasant. And contains gotos. IIRC I added 2 between 5.6.0 and 5.8.0, but the alternative was a big mess of if()s and braces. C doesn't have all the nice loop labelling features of a certain other language. Parrot has much cleaner source than Perl 5. However, to maintain the balance of good and evil^Wgoto, Perl 6 will compile down to parrot bytecode, which quite definitely does have gotos. So even the nicest, most clean award winning code from the purest best intentioned authors will be automatically corrupted by the Perl 6 compiler. (Eventually.) Nicholas Clark
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Nicholas Clark wrote: At the risk of going off topic, the Perl 5 source isn't exactly pleasant. And contains gotos. IIRC I added 2 between 5.6.0 and 5.8.0, but the alternative was a big mess of if()s and braces. C doesn't have all the nice loop labelling features of a certain other language. In bleadperl : $ perl -lne 'print if /\bgoto\b/' *.[ch] | wc -l 605 This is a rough metric, there are probably less actual gotos than this (because of comments and because goto is a perl keyword -- not forgetting the yacc-generated code, that contains gotos as well). However most of gotos appear to be in the tokenizer and in the regular expression engine. Thoee are based on state machines, and IMHO gotos are legitimate in state machines.
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Nicholas Clark said: At the risk of going off topic, the Perl 5 source isn't exactly pleasant. And contains gotos. IIRC I added 2 between 5.6.0 and 5.8.0, but the alternative was a big mess of if()s and braces. C doesn't have all the nice loop labelling features of a certain other language. I think I wrote my first ever goto code in C yesterday. It was a part of a rewrite of the runops function in Devel::Cover, so I justified it on performance grounds and it felt quite invigorating. I wonder whether I could find a way to justify some self modifying code? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Wed, Sep 03, 2003 at 11:13:35AM +0100, Nicholas Clark said:
At the risk of going off topic, the Perl 5 source isn't exactly pleasant.
And contains gotos. IIRC I added 2 between 5.6.0 and 5.8.0, but the
alternative was a big mess of if()s and braces. C doesn't have all the
nice loop labelling features of a certain other language.
I have to admit, I like gotos in C. This is not a winning testimonial
though. I've been told that my C is like Object Orientated assembler
which is fair enough because I learnt C after I'd learnt 68k.
My code typically looks something like ...
quirka_t *
foo (foo_context * context, int * error)
{
/* malloc bar and if that fails set error and goto FAIL */
/* malloc quirka and if that fails set error and goto FAIL1 */
/* do something with quirka and if that fails, set error, goto FAIL2 */
SUCESS:
return quirka;
FAIL2:
/* free quirka */
FAIL1:
/* free bar */
FAIL0:
return NULL;
}
apparently people ahve been known to be sick.
--
the illusion of knowledge without any of the difficult bits
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Wed, 03 Sep 2003 11:17, Rafael Garcia-Suarez wrote; However most of gotos appear to be in the tokenizer and in the regular expression engine. Thoee are based on state machines, and IMHO gotos are legitimate in state machines. Right, and we all know that every program can be considered a state machine, as it has a set of states and means of transitioning between those states. So, therefore goto is valid everywhere! :-) -- Sam Vilain, [EMAIL PROTECTED] The pursuit of truth and beauty is a sphere of activity in which we are permitted to remain children all our lives. ALBERT EINSTEIN
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: In bleadperl : $ perl -lne 'print if /\bgoto\b/' *.[ch] | wc -l 605 This is a rough metric, there are probably less actual gotos than this (because of comments and because goto is a perl keyword -- not forgetting the yacc-generated code, that contains gotos as well). However most of gotos appear to be in the tokenizer and in the regular expression engine. Thoee are based on state machines, and IMHO gotos are legitimate in state machines. This is correct. Outlawing goto's entirely is a bad idea, but they are only needed in very specific circumstances. I seem to recall that the TCP/IP source in BSD is another case... Ah yes, the bottom question of: http://www.kohala.com/start/rstevensfaq.html Which reminds me, I must purchase a copy TCP/IP Illustrated vol 2. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Paul Johnson wrote: I think I wrote my first ever goto code in C yesterday. Way back when I was a teen-geek, I played around writing a few games, mostly in C, with the odd bit of assembler thrown in for bad taste. One of these was a rip-off of the classic Tron light-cycle game. I got myself in an almighty mess trying to write a structured control loop that would handle 2 player input or 1 player and computer. I had to read keyboard scan codes to detect multiple keys being pressed simultaneously. This made it particularly gnarly, although I forget the precise details. Whichever way I carved it up it got ugly. The code resisted all attempts at being structured. After hacking on this same chunk of code for days and getting no further, I suddenly realised that a simple goto made the problem collapse into thin air. I was enlightened. The use of goto is not always considered harmful. A
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
Nicholas Clark said: Parrot has much cleaner source than Perl 5. However, to maintain the balance of good and evil^Wgoto, Perl 6 will compile down to parrot bytecode, which quite definitely does have gotos. So even the nicest, most clean award winning code from the purest best intentioned authors will be automatically corrupted by the Perl 6 compiler. (Eventually.) but even beautifully goto-less C++ code gets compiled into assembler which contains nothing *but* gotos and if then gotos, because that's all the machine understands. goto is not inherently evil, it has earned the evil reputation because people use it for evil. don't bash perl for its use of goto, if anything chastise it for its use of longjmp(), which causes nightmarish maintainability problems in C programs in general. but then, without longjmp(), we wouldn't have a working eval and die, so we can hardly say don't use longjmp... in fact, C++'s try/throw/catch is just a grown-up version of setjmp()/longjmp(), which itself is goto on steroids. in 95% of cases a jump of any kind is the wrong thing to do, but in that other 5% of cases, not jumping is the worst thing you could do. you even said yourself that you added two gotos to perl5 because the alternative was a twisty and nasty ratsnest of if() trees. stop the wrongful slander of goto! :-) -- muppet scott at asofyet dot org
Re: Bad C Source (Re: gzipping your websites WINRAR 40 days trial)
On Wed, 3 Sep 2003, muppet wrote: stop the wrongful slander of goto! Man, what a muppet this guy is... Look, goto's are just bad, mmmkay? -- Chris Devers[EMAIL PROTECTED] channeling http://www.askoxford.com/pressroom/archive/odelaunch/
Re: gzipping your websites WINRAR 40 days trial
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I used to be annoyed when someone zipped and the rared. Winzip cannot even handle this yet. Nowadays I can just say that RAR is more universial the Zip. That seem unlikely at best. I'd never even heard of winrar until somebody at work pointed it out to me... It's certainly not what I'd call anywhere close to being standard or universal. For the benefit of people likely to come up against Yet Another Compression Format, though: http://files10.rarlab.com/rar/unrarsrc-3.2.3.tar.gz -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: gzipping your websites WINRAR 40 days trial
On 2 Sep 2003 at 7:16, Dominic Mitchell wrote: It's certainly not what I'd call anywhere close to being standard or universal. I'm told it's fairly popular in (some?) Usenet binary newsgroups as a standard way of distributing warez and moviez. From what I gather, it supports multi-volume archives natively (which are a bit of a hack with the ZIP format); there also exists a PAR scheme which gives parity information so if you miss up to 'n' segments of a multi-segment file, you can recreate them from the parity data. Compression is also sometimes better than with ZIP, possibly because of one or both of (a) it's said to have a special multimedia mode that is tuned to compressing audio and/or video (no idea how that works, though) and (b) it can create solid archives (things .tar.gz - compress the files as one rather than compressing each file individually as in .zip, hence you can take advantage of redundancy across files). I've very rarely come across a file I wanted that was in .RAR format, though. When I started computing in the 90's on PCs, it was LZH at the beginning, replaced by ARJ shortly after I started; now it's ZIP. (And, of course, the perennial .tar.Z / .tar.gz in the *nix world, though .tar.bz2 are starting to show up in a couple of places.) So, as far as I'm concerned, .RAR isn't standard, either, but apparently there are such for whom it is. This is probably not relevant for whoever started the thread, though. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: gzipping your websites WINRAR 40 days trial
On Tue, 2 Sep 2003, Philip Newton wrote: On 2 Sep 2003 at 7:16, Dominic Mitchell wrote: It's certainly not what I'd call anywhere close to being standard or universal. I'm told it's fairly popular in (some?) Usenet binary newsgroups as a standard way of distributing warez and moviez. Certainly a majority of warez that show up on our network are rars (and they tend to be single large files, so they're not directly taken from multipart usenet posts) the hatter
Re: gzipping your websites WINRAR 40 days trial
On Tue, 2 Sep 2003, the hatter wrote: It's certainly not what I'd call anywhere close to being standard or universal. I'm told it's fairly popular in (some?) Usenet binary newsgroups as a standard way of distributing warez and moviez. Certainly a majority of warez that show up on our network are rars (and they tend to be single large files, so they're not directly taken from multipart usenet posts) They might have been. The .rar file is what you get after recombining the multipart messages. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Broadband available now
DOS/WIN archivers of the mid 1990s (was Re: gzipping your websites WINRAR 40 days trial)
On Tue, Sep 02, 2003 at 09:24:11AM +0200, Philip Newton wrote: [re RAR] I'm told it's fairly popular in (some?) Usenet binary newsgroups as a standard way of distributing warez and moviez. ACE is another format that I understand is used in that context. From what I gather, it supports multi-volume archives natively (which are a bit of a hack with the ZIP format); there also exists a PAR scheme which gives parity information so if you miss up to 'n' segments of a multi-segment file, you can recreate them from the parity data. Both correct, though I've never seen PAR actually produce a result. Actually, I've probably known about RAR for longer than most people; in 1994 I translated the documentation for RAR 1.40 from Russian to English, and uploaded it to Garbo. (Three weeks later, Yevgeniy Roshal brought out a new version with his own English translation, which was rather less comprehensible than mine, and didn't bother to answer my email.) Compression is also sometimes better than with ZIP, possibly because of one or both of (a) it's said to have a special multimedia mode that is tuned to compressing audio and/or video (no idea how that works, though) and (b) it can create solid archives (things .tar.gz - compress the files as one rather than compressing each file individually as in .zip, hence you can take advantage of redundancy across files). Also both correct. Multimedia mode, AFAIR, looks for shorter repeated sequences than in text, because there's already been some compression done. RAR used to be practically guaranteed to be smaller than ZIP, but the format has got a bit bulky of late. Basically, it started as state-of-the-art compression code of 1994 and has been updated somewhat since, whereas ZIP is state-of-the-art for early 1992 and basically hasn't changed at all (RAR has now had four or five changes to the file format). In my experience, people who really care about compressed file size and are moderately technically savvy tend to use RAR or ACE; people who want their files to be readable by everybody use ZIP; people who are catering for virus-prone fools use self-installing EXE. (All of this only applies to the Windows world, obviously; I think the parallels in Unix, or at least Linux, would be .tar.bz2, .tar.gz, and dodgy commercial software with auto-extracting installers like the JRE.) Incidentally, I can highly recommend PowerArchiver, even though it's now gone shareware. It's the only archive extractor I use on Windows. I've very rarely come across a file I wanted that was in .RAR format, though. When I started computing in the 90's on PCs, it was LZH at the beginning, replaced by ARJ shortly after I started; now it's ZIP. (And, of course, the perennial .tar.Z / .tar.gz in the *nix world, though .tar.bz2 are starting to show up in a couple of places.) For a while, ARJ was looking set to displace ZIP v2; it was producing consistently smaller files, and had just grown a solid mode (which originated with HPack, but that's another story entirely). But Rob Jung insisted on keeping the source entirely closed, which meant that instead of competing with ZIP as the universal and featureful format it was competing with RAR as the small format, at which it failed. This is probably not relevant for whoever started the thread, though. Neither is anything I've said here. R
Re: DOS/WIN archivers of the mid 1990s (was Re: gzipping your websites WINRAR 40 days trial)
Roger Burton West [EMAIL PROTECTED] wrote: In my experience, people who really care about compressed file size and are moderately technically savvy tend to use RAR or ACE; people who want their files to be readable by everybody use ZIP; people who are catering for virus-prone fools use self-installing EXE. I don't actually mind .EXE files so long as I don't have to run them. If you can just extract from them using the standard unzip program, I don't have a problem with that. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: gzipping your websites WINRAR 40 days trial
On Tue, Sep 02, 2003 at 07:16:40AM +, Dominic Mitchell wrote: For the benefit of people likely to come up against Yet Another Compression Format, though: http://files10.rarlab.com/rar/unrarsrc-3.2.3.tar.gz The code in there is a lot cleaner than the last time I looked at it. (I presume I was looking at the same official unrar source; previous was in C, not C++). The old version was a liturgy of bad style tips. For example, using #include to pull in lots of other .c files, and IIRC #define BEL 007 printf (... %c ..., BEL) when the escape \a has been in C for a couple of decades now Nicholas Clark
Re: gzipping your websites WINRAR 40 days trial
I used to be annoyed when someone zipped and the rared. Winzip cannot even handle this yet. Nowadays I can just say that RAR is more universial the Zip. Marcus Original Message: - From: Chris Devers [EMAIL PROTECTED] Date: Mon, 1 Sep 2003 12:35:45 -0400 (EDT) To: [EMAIL PROTECTED] Subject: Re: gzipping your websites On Mon, 1 Sep 2003, David Cantrell wrote: Oh I don't care if the browser doesn't support it, just whether there is common Doze software to uncompress it later like there is for tarballs. Well, everyone using Windows is likely to be using either a copy of WinZip (unpaid for, of course) or if they're using XP the system has *finally* added capabilities for dealing with compressed formats. Poking around WinZip's site, I can't find any mention of bzip / bzip2. asking Google about winzip bzip2 turns up phrases such as Unfortunately WinZip does not unzip bzip2 [trolltech.com] Of course, some day WinZip will add bzip2 [redhat.com] etc. The most fruitful links seem to point to Cygwin, which while appreciated is about as likely as saying just install Linux. Actually, that pretty much *is* what they're saying... :) Searching for windows xp bzip2 turns up a link for PowerArchiver, which while apparently nicer than WinZip, isn't a program that most people seem to be running (or, arguably, will ever see a need for, as long as WinZip does .zip and .zip is all they're interested in). A poke around MS's techpubs site suggests that Win-Me-Oh-God-NO was the first version to support the .zip format natively (that only took them 15 years -- impressive), but apparently it's the only compression format that MS has any interest in. I see no mention of bzip, gzip, sit, hqx, etc. So... no, bzip file support is unlikely unless they're savvy enough to have installed Cygwin, PowerArchiver, or similar tools. Which most Windows users probably haven't probably never will. Their loss. -- Chris Devers [EMAIL PROTECTED] http://devers.homeip.net:8080/blog/ massively parallel, adj. 1 Hypergeometry (Of two right lines) nonintersecting and many megaparsecs apart even at the point at infinity. 2 (Of a computer architecture) employing 2^N microprocessors where N depends on Intel's current discount structure; esp. of a system massively searching for parallel advances in the programming arts. Compare MASSIVELY SERIAL. -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995 mail2web - Check your email from the web at http://mail2web.com/ .
