[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] gift-write-feature-descs segfaults... (is the GIFT broke

From: Jonas Lindqvist
Subject: Re: [help-GIFT] gift-write-feature-descs segfaults... (is the GIFT broken?)
Date: Sun, 27 Aug 2006 18:34:39 +0200

This is undoubtedly my fault, for not checking the other binaries.

I wouldn't call this anyone's "fault". I expected the compiler to help, and was surprised that it didn't.

There is a general lesson here. Before committing any patches, a full build of the whole system, and test cases run (e.g. adding a collection and testing that it can be queried).

Why not instead see if we can get the compiler/linker to help out finding missing functions? Adding a collecting and then querying it, will test just the simple adding and querying in the test. Nothing more. It's difficult to test all different paths of execution possible, although testing some paths is better than nesting none. (Would an indexing-run followed by some queries assert that all the different libs work as intended?)

For example, using the latest CVS version of the GIFT, I was able to run gift-add-collection on a collection, and query it for a random set of images. No problem. However, whenever asking for any similar images, it failed.

I'm sure some other modification could break a not-so-often used functions while still appearing to work when running some basic "normal" tests. By using the compiler/linker to alert us, we would be able to find these errors in compile time instead of in runtime.
Much nicer in my opinion.

One other tool would be grep. If I decide to alter the signature of a function/method, then grep-ing for that name in the source-files, could lead me to places where that function is used. Only... this is not convenient in this case since the GIFT source code is so full of unused junk that isn't compiled anyway. (Is gabor981029.c an example of primitive source control?) I get too many matches in files that aren't needed.

Yes, normally C screams and yells at you, but the gift was written
without function prototypes, so the compiler cant tell, until link time.

Well, it didn't even complain when linking...
-Wmissing-prototypes could be used to at least get a compiler warning, but I'm not sure why the linker didn't speak up.

So, at some point a decision was made to do without the prototypes. In my original version (from Viper, before it was bundled with the GIFT), that starts:
#include "extract_features.proto"

I would guess that that changed because someone did not have access to cproto...

Too bad that one didn't decide to include all necessary header-files, the old-fashioned way...
Maybe we should fix that now? Or is there a reason not to?


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]