Hi Shawn,
thank you for attacking this, and sorry for the long delay in answering.
I think that the approach of copying working code from elsewhere for this
is right, but I think it should go into its own file, so that two coding
styles are not mixed.

Also, can those new functions replace normal ellipsize and ellipsize_mem,
so that we have support everywhere?

e = new0(char, new_length*4 < old_length ? new_length*4 : old_length);

→ we have a min macro

There are some compilation warnings:

../src/shared/utf8.c: In function 'unichar_iswide':
../src/shared/utf8.c:435:9: warning: passing argument 1 of 'bsearch' makes 
pointer from integer without a cast [enabled by default]
         interval_compare))
         ^
In file included from ../src/shared/utf8.c:51:0:
/usr/include/stdlib.h:754:14: note: expected 'const void *' but argument is of 
type 'long int'
 extern void *bsearch (const void *__key, const void *__base,

../src/shared/util.c: In function 'wellipsize_mem':
../src/shared/util.c:3353:9: warning: array subscript has type 'char' 
[-Wchar-subscripts]
         for (i = (char *)s;k < x;i = utf8_next_char(i)) {
         ^
../src/shared/util.c:3380:17: warning: array subscript has type 'char' 
[-Wchar-subscripts]
                 i = utf8_next_char(i);
                 ^

and valgrind finds some leaks:

% valgrind --leak-check=full build/.libs/test-wellipsize 
==19953== 
==19953== HEAP SUMMARY:
==19953==     in use at exit: 1,379 bytes in 6 blocks
==19953==   total heap usage: 6 allocs, 0 frees, 1,379 bytes allocated
==19953== 
==19953== 81 bytes in 1 blocks are definitely lost in loss record 1 of 6
==19953==    at 0x4A08121: calloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19953==    by 0x400F57: ellipsize_mem (util.c:3300)
==19953==    by 0x401082: wellipsize_mem (util.c:3336)
==19953==    by 0x40122A: wellipsize (util.c:3388)
==19953==    by 0x400CFF: test_one (test-wellipsize.c:28)
==19953==    by 0x400D4C: main (test-wellipsize.c:37)
...

On Wed, Aug 28, 2013 at 03:58:29PM -0700, Shawn wrote:
> here is the test runner I am using, doesn't really make sense to add this
> to the tree as it has to be visually inspected
I think it is still useful, since we don't have anything better for now. Anyway,
we have a bunch of tests which can only be run manually. Your test is certainly
good enough for valgrind testing and visual inspection, so it should go in.

Zbyszek
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to