On Fri, Jan 17, 2003 at 07:27:01PM +0200, Timo Sirainen wrote:
> I've had at least a few rewrite plans before, but they've pretty much
> sucked. Now, I think I'm finally enlightened enough and could actually
> design a good new irssi.
Does it mean that development of current vesrion will be discontinued
completely?
> get nowadays are rarely usable, I just know that "something" happened
> "somewhere" which caused this crash later (heap corruption). I'd guess it's
Did you ever tried valgrind to track the sources of the problems? :)
> So, new plan is basically: Write code that doesn't crash. Ever.
You have to use some interperted language to write such code (or spent
infinite amout of time writing this in C - large C projects are never
crash-safe).
> - still C. it's the language I know well and like :)
Why not C++? May be it worth to study C++ a bit more and use it? :)
> - anything else - especially heap corruption - means the
> design is flawed and must be fixed
Not necessary. Even if design is perfect you can never be sure that
you didn't forget that comma sign somewhere :)
> - void pointers lose type safety, avoid them
Prefix every allocated data structure with type tag and make a macro
instead of direct casting. Something like:
struct object {
int __tag;
void *self; // Assigned upon allocation
... declarations here ...
}
Then every time when you cast (void *) to this structure:
objp = CAST(T_OBJECT,voidp);
where:
#define OP(ptr) ((struct object *)ptr)
#define CAST(type,ptr) (OP(ptr)->__tag == type && OP(ptr)->self == ptr ? ptr :
__bug("Panic!", __FILE__, __LINE__))
Every object must be initialized properly upon allocation, of course,
and cleared upon deallocation. Adding linked list of all objects will
help to find leaks and to check data integrity. Well, you got the idea :)
> - char* means it's NUL terminated, unsigned char* means it's not.
Better not. Better to use something different like typedef. IMHO :)
> use string and buffer APIs.
This may also be used to access regular strings, so you will avoid any
problems including NUL.
> - minimize the code, make everything simple to use
"Everything should be made as simple as possible, but not simpler." -- A. Einstein :)
> - if it requires coder to be careful, it's usually badly
> designed
Did you forget about unexperienced coders? Nothing is safe in C for them :)
> - heap allocations aren't exactly fast and it gets fragmented
They are still quick enough. Use memory pools to avoid excessive fragmentation.
> - free() is dangerous, avoid it when possible
Alternatives?
> - garbage collectors would help, but they don't work well
> with Perl (leaks a lot)
True. So make your own :)
> - possibly create a string memory pool which allows
> defragmenting by moving the data (special pstring_t type)
This it what you call "overdesign" :) Fragmentation is not always so bad.
> - inheritance is annoying with C, probably do it like:
> struct irc_server { struct server server; ... }; to keep type
> safety. A bit annoying to access server struct though.
Another argument for C++ :)
> - reference counting is needed, especially for Perl interface
One step close to your own GC :)
> So if ^S was pressed, irssi should continue on the background
> until ^Q was pressed, when it would just redraw the screen.
Virtual terminal emulation, a-la screen? So when output is blocked, it
still gets filled, and once unblocked it will redisplay the content.
> Good internal iconv() support, to allow very simple to use UTF-8
> support.
Would be nice to have embedded charset conversions too...
> Internal scripting? The current $vars are quite near scripting
> themselves. Maybe we should have some very simple language to use in
> themes, statusbars and such.
Small, simple but powerful? There are two options - the one used in jed
and ICI (this one also has C-like syntax, powerful data structures and
core is small enough to embed; easily callable from C). But please, please,
anything but Python :)
This scripting language (whatever you choose) may be also used for regular
scripting whenever Perl is not available or is too much. C like syntax is
well-known so it shouldn't cause any problems even to beginners :)
Regards,
/Al
