> I can tell that rev can be VERY large... Wait, am I remembering these
> (Open)CVS internals all of a sudden again? :P
Some of us have memories wired for guilt.
I wouldn't call this definition readable:
void
cvs_ent_line_str(const char *name, char *rev, char *tstamp, char *opts,
char *sticky, int isdir, int isremoved, char *buf, size_t len)
So what about changing it to return allocated memory by itself,
which would mean changing the internals from xs
Hi
Sure, so what are you saying... we shouldn't change this?
Or we should change it? If so, why not also change, for example,
cvs_add_entry, cvs_remove_local and update_clear_conflict, which have
very similar bits of code?
On Mon, Nov 02, 2015 at 03:38:24PM -0500, Michael McConville wrote:
>
Nicholas Marriott wrote:
> Sure, but this idiom is all over the place in opencvs, are you going to
> change the rest?
As Theo mentioned recently, there's an inherent tradeoff here. Stack
allocation is faster at runtime and easier to write. However, we miss
out on malloc's memory sanitization. So,
Sure, but this idiom is all over the place in opencvs, are you going to
change the rest?
On Mon, Nov 02, 2015 at 12:31:14PM -0500, Michael McConville wrote:
> Don't bother mallocing a statically-sized 1,024-byte chunk of mem, for
> simplicity and speed.
>
> ok?
>
>
> Index: usr.bin/cvs/server.
Don't bother mallocing a statically-sized 1,024-byte chunk of mem, for
simplicity and speed.
ok?
Index: usr.bin/cvs/server.c
===
RCS file: /cvs/src/usr.bin/cvs/server.c,v
retrieving revision 1.102
diff -u -p -r1.102 server.c
--- usr
