A Very Dangerous Worm in Windows Metafile Images (WMF)

To me, the two most important parts of code maintainability are

1. Comments

1. Ability to reproduce the tool chain

I've rarely seen C source that was very well commented. Most C code isn't commented at all. All my program listings include extensive comments and a table of contents, so this stuff is very easy to maintain. C code, of course, *should* be heavily commented, as C is fairly cryptic by design.

I can archive an entire project on a single floppy, including all the tools and a bootable OS (but not the FPGA stuff, which can be huge.) We do archive all the tools to our company library, so don't have to worry about losing the install CD for a monster C++/linker/debugger system.

John

A thread on comp.lang.c pointed me to here

Where we see the following gems:

============================================================ Duff's device

The famous "Duff's device" in C makes use of the fact that a case statement is still legal within a sub-block of its matching switch statement. Tom Duff used this for an optimised output loop:

. switch (count % 8) { . case 0: do { *to = *from++; . case 7: *to = *from++; . case 6: *to = *from++; . case 5: *to = *from++; . case 4: *to = *from++; . case 3: *to = *from++; . case 2: *to = *from++; . case 1: *to = *from++; . } while ((count -= 8) > 0); . }

We can put it to a slightly different use in the coroutine trick. Instead of using a switch statement to decide which goto statement to execute, we can use the switch statement to perform the jump itself:

.int function(void) { . static int i, state = 0; . switch (state) { . case 0: /* start of function */ . for (i = 0; i < 10; i++) { . state = 1; /* so we will come back to "case 1" */ . return i; . case 1: /* resume control straight after the return */ . } . } .} ============================================================

You say C is ugly, but sometimes you go right off the ugly scale and wrap back around to beautiful!

In article , Pooh Bear wrote: [...]

This why I've suggested that all software be written in APL. It is about as high of a level as you can get. Perhaps IDL or Octave could also be used.

Good coding practices can be done in ASM too. Make sure your assembler allows 32 character names and not just 8 character. Long routine names and code labels help a lot to understand someones code.

Some of the code I have to maintain is written in ASM with C used as comments. It is a real horror show because there is nothing telling me what the programmer thought he was doing just how he did it. That bit has a lot of bugs in it too so I have had to spend time figuring out what it is supposed to do and adding comments for the next poor sucker.

Lets say a C line count is a ";" count and an ASM count is an instruction count. It is about what I did.

There was no such line so the issue never came up.

If the line of code was written for the project it was counted.

The conversion was to make it into an "object that does that" instead of "some code that does that". The public variables were all bundled into the class definition and one of those was created when needed.

Yes that is a simple example.

Yes, if the code ends up truly the same. It can be the same if the programmer uses copy and paste to make two copies and then makes no changes. You still have to produce and maintain the lines of source.

Go back and look at the "C" code I put on the end of the posting and you'll see another example of what I mean.

/* C code to do that stuff */

R2 = 12; ACC = *DPTR; ACC *= B; B = ACC >> 8; ACC = ACC & 0xFF; *DPTR = ACC; ACC = B; DPTR++; *DPTR = ACC;

In article , John Larkin wrote: [....]

The famour "fall thru" comment is the mark of a good programmer :>

DoubleGormTheSnig: PushDPTR lcall GormTheSnig PopDPTR ;*** Fall thru **** GormTheSnig: lcall UnmapFoo ;** Fall thru *** StepAndSnortBar: inc DPTR ;*** Fall thru SnortBar: movx a,@dptr swap a inc a movx @dptr,a jnz SnortBar ret

In article , John Devereux wrote: [...]

Unfortunately it then goes to ugly again:

Then again there's stuff like this:

int Bogus(tFunc * Thing, int Number) { if (Thing) return 1 + Thing(0, Number*3); else return Number / 2; }

What's wrong with that!?

I would probably write:

. int bogus(tFunc* thing, int number) . { . return thing ? 1 + thing(0, number*3) : number/2 ; . }

:)

Bending the topic slightly - the example above demonstrates one of the problems I have with current coding - the overuse of the '*' symbol. It's as if the language innovators' keyboards had some non-working keys.

Yeah, I used to do that stuff all the time. You can't get that kind of density or performance writing with high level language. My code was filled with little relative jump tables (1 byte per entry), multiple entry points, falling out of one routine into another, special setup routines that you could fall out of into more general routines, virtual processors with multiple precision modes, internal emulation of HP-style stack math etc. etc. You do give up portability (in many cases even above the module level because parts of the strategy are optimized to the architecture). Readability is probably necessarily reduced somewhat due to the spaghetti nature of the code, but poking around with a modern text editor it's not all that difficult to deal with, assuming the comments are excellent (and they'd better be).

These days I prefer to tightly code in assembly the part of the code that needs it, and use HLL for the rest, even if it means lower performance or a slightly larger code memory. There are compensating factors-- re-using proven code, being able to use another processor if you want, time to market, productivity etc. We had a lot of tricks for dealing with those #$*($#$ crepe tape thingies and Bishop donuts too, but they are lost in time. Like tears in the rain.

Best regards, Spehro Pefhany

What a sick, cruel joke!

John

"Spehro Pefhany" schreef in bericht news: snipped-for-privacy@4ax.com...

Time to market deadline is fixed and as always to short. That means that using HHL results in a better product. That's why windows is a better product than if it were written in assembler ;)

Blade runner. You won't catch me crying over crepe tape, but I don't know anything about Bishop donuts.

That's another cool thing with C: you get to use all those ascii symbols that would otherwise go to waste. " ^ & * ( ) [ ] ' # ~ | \ !

And you don't have to remember many of those long things, "words." It's the perfect language for inarticulate geeks.

John

No, that would be perl I think you'll find. Perhaps you would prefer COBOL.

MULTIPLY price BY qty GIVING total.

Sounds like tape up to me. Bishop Graphics made the sticky pads I believe. I used Brady myself.

Graham

Bishop had the best stuff. And after you placed a big order, it might not come. So you called Bishop, and they would send out a rep, and he'd tell you that your pads would come *if* you ordered all your blueprint supplies from Bishop.

As soon as CAD got going, Bishop died.

John

"Pooh Bear" schreef in bericht news: snipped-for-privacy@hotmail.com...

better

What a shame, I thought it was some delicious donut. I've also used the Brady pads to fill out the exact height of PCB switches underneath an adhesive panel. A panel with build-in clickers was too expensive. Damn bean counters, as if fiddling with the brady pads didn't cost time and money. To give each button the same 'click' it needed 1-2-3 or 4 pads, and to figure how many, you needed to assemble/disassemble 4-5 times perhaps.

What do you mean 'last night'? The WMF exploit was recently published, but it may very well have been in use for months or even years.

Many of these are initially discovered by very skilled programmers who are employed to do industrial or political espionage. The virii created tend to work quietly for long periods of time, discretely feeding data off desktops out through firewalls to competitors or foreign governments. Later, some script kiddie stumbles across the same security hole and writes something that clogs up corporate networks, revealing itself. Or it is discovered by honest IT people who report it.

In article , Richard Henry wrote: [...]

That is one of the advantages of APL. There are 26 letters and about 200 operators.