[GNUnet-developers] Some small patches

[Hendrik Pagenhardt]

Hello,

when roaming through the source trying to find the reasons for some
minor annoyances I patched a few places:



Index: src/applications/afs/esed2/block.c
===================================================================
RCS file: /var/cvs/GNUnet/GNUnet/src/applications/afs/esed2/block.c,v
retrieving revision 1.10
diff -r1.10 block.c
77c77
<     if ((0 == STAT(filename, &st))) { /* if file exists, try truncate */
---
>     if ((0 == STAT(filename, &st)) && getFileSize(filename) > filesize) { /* 
> if file exists, try truncate */

This fixes a bug I encountered trying to continue a download on a
mounted windows partition, when the "truncation" of a file to a bigger
size failed. As gnunet grows downloaded files automatically the
"truncation" in this case is not really necessary...



Index: src/applications/afs/module/high_mysql.c
===================================================================
RCS file: /var/cvs/GNUnet/GNUnet/src/applications/afs/module/high_mysql.c,v
retrieving revision 1.11
diff -r1.11 high_mysql.c
574c574
<         "REPLACE INTO data%uof%u "
---
>         "REPLACE DELAYED INTO data%uof%u "

This speeds up insertion/indexation a little when using mysql as database.



cvs server: Diffing src/applications/afs/tools
Index: src/applications/afs/tools/gnunet-insert.c
===================================================================
RCS file: /var/cvs/GNUnet/GNUnet/src/applications/afs/tools/gnunet-insert.c,v
retrieving revision 1.85
diff -r1.85 gnunet-insert.c
38c38
<     printf("%8u of %8u bytes inserted\n",
---
>     printf("%8u of %8u bytes inserted\r",

This allows using the -V option with gnunet-insert without cluttering
the screen with progress messages...



As I looked through the sources I saw a few places where MALLOCs were
used for temporary variables (string buffers etc.). The only reasons I
can imagine for doing so are:
- replacing buffer overflows on the stack by corruptions in the heap,
which are harder to exploit successfully (not really a good reason)
- maximum stack size is reduced during runtime (should not be that big
a problem)

If I haven't overlooked another justification for this, I think it would
be better to replace those MALLOCs by stack allocations wherever
possible. It speeds things up a little, removes possible memory leaks,
and reduces heap fragmentation.

Ciao,
     Hendrik