Making the lib robust against bad (application) code

[elmom]

test/blank.c:

burn_drive_scan(&drives, &n_drives)
// index>=*n_drives !!!
blank_disc(drives[index].drive)

in blank_disc:

burn_drive_grab(drive, 1)

in burn_drive_grab:

if (!drive->released) {
    burn_print(1, "can't grab - already grabbed\n");
    return 0}

segfault!

That's quite trivial actually (and that would happen with about any function in libburn), but i'm sure there will be many not so easily recognizable points of failure in complex apps that will hopefully be made.

The real point from my part is that we should agree on the level of protection from bad code(both inside and outside libburn), i.e. the tradeof between being helpful to future debugging and having a hit on the speed and maintainability of the lib itself. I would be eager to submit patches improving the situation after the first examples about such improvements as I have no idea what would be the best way to do these things in c.

[scdbackup]

Hey ! No C++ comments in libburn please ! We are on ANSI-C.

No, there is no such thing as ERROR 17 of Rocky Mountain BASIC in C. I had to learn in 1986.

We are using ANSI-C. Luxury protection on the scale of C variants. It saves not much time but it is convenient to have parameter list errors detected by the compiler. (See carreer of burn_drive_get_adr() examples in ticket #18 and final version in SVN. Teehee.)

If programming languages were cars... my favorite definition for C is only available in german:

"Ein offener Jeep. Faehrt durch jeden Acker, aber der Fahrer sieht hinterher auch danach aus."

"An open jeep. Makes its way through any acre, but the driver looks accordingly afterwards."

There is memory managment middleware and bug finding software. I have seen commercial stuff which made my work look a bit embarrassing. I needed a week to get acceptable score by fixing several dozen more or less open doors to hell. What was the name ... ? We didn't buy it because the test version found no further fleas ... damn. It was on SunOS and Sparc IPX.

I could contribute a minimum protection malloc()-wrapper which avoids some of the starting points of nasty "fandango on core". That is the effect to have committed a sin on malloc'ed memory and to ecperience the SIGSEGV only deveral million instrutions later.

The wrapper catches malloc(0) which may or may not cause a fandango. It also catches free() of not previously issued memory addresses and it catches repeated free(). It's main purpose for me, nevertheless, is to catch memory leaks on long running services which blow up their memory consumption day by day. I got a kindof database server that runs 100+ days without restart and does 1,000,000 calls without gaining an ounce of fat.

Compare this with Mozilla which after 6 days must be rebooted. And then i learn that my wiki login has gone bad during those 6 days. :))

The non-freed memory gets reported by my malloc() wrapper on a final call directly before program exit. This feature is based on hashed address lists and therefore has its price in form of extra memory and of somewhat reduced performance on high-frequency malloc. From the reported sizes of unfreed memory objects i can conclude to the type of structure resp. object that was forgotten to free. I can see the byte-serial object value and this often gives a good hint on the location of the leak. The thing is plain K&R C. (Jeep with no flexible suspension.)

Nothing that protects you from SIGSEGV by passing or using inappropriate memory of (formally) correct type.