>Description:
  The problem was spotted and confirmed on glibc-2.3.2 (i386, Slackware,
  Debian), and in glibc-2.6 by source inspection, and also in CVS via
  cvsweb.

  In glibc-2.6/wcsmbs/wcsnlen.c one can easily see that __wcsnlen() first
  accesses data, then checks if it's allowed to.  This invokes undefined
  behaviour when the character array is not zero-terminated.

  This bug is inherited by other library functions which call __wcsnlen(),
  eg. *printf() family.

  The bug makes it at least impossible to properly test programs
  with Electric Fence, but might be fatal in normal operation, too
  (end of process memory hit).

>How-To-Repeat:
    wchar_t *wcp = malloc(4 * sizeof *wcp);
    wcp[0] = 'a';  wcp[1] = 'b';
    wcp[2] = 'c';  wcp[3] = 'd';
    wcsnlen(wcp, 4);               /* CRASH */
    wprintf(L"wcp=%.4ls\n", wcp);  /* CRASH */

  Running:  LD_PRELOAD=./libefence.so ./a.out

>Fix:
  I don't dare to give a solution, maybe it should be enough to reverse
  the order of logical sub-expressions in `while' and `if' conditions, 
  like:
    if (++len, --maxlen == 0 || s[len] == L'\0' )