Stefan Krah wrote:
> 
> New submission from Stefan Krah <stefan-usenet@bytereef.org>:
> 
> Not sure if this is valid or if there is some internal trickery that Valgrind isn't aware of. If it's the latter, perhaps an entry to
> Misc/valgrind.supp could be added.
> 
> 
> test_bug1175396 (__main__.UTF32Test) ... ==26861== Conditional jump or move depends on uninitialised value(s)
> ==26861==    at 0x48A2DD: PyUnicodeUCS2_DecodeUTF32Stateful (unicodeobject.c:2282)
> ==26861==    by 0x50E25C: utf_32_le_decode (_codecsmodule.c:420)
> ==26861==    by 0x52E727: PyCFunction_Call (methodobject.c:81)
> ==26861==    by 0x4B4EB7: call_function (ceval.c:4012)
> ==26861==    by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665)
> ==26861==    by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252)
> ==26861==    by 0x4B52C0: fast_function (ceval.c:4108)
> ==26861==    by 0x4B4FE1: call_function (ceval.c:4033)
> ==26861==    by 0x4B1402: PyEval_EvalFrameEx (ceval.c:2665)
> ==26861==    by 0x4B31DA: PyEval_EvalCodeEx (ceval.c:3252)
> ==26861==    by 0x4B52C0: fast_function (ceval.c:4108)
> ==26861==    by 0x4B4FE1: call_function (ceval.c:4033)
> ==26861== 
> ==26861== 
> ==26861== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
> ==26861== starting debugger with cmd: /usr/bin/gdb -nw /proc/26862/fd/1014 26862
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu"...
> Attaching to program: /proc/26862/fd/1014, process 26862
> 0x000000000048a2dd in PyUnicodeUCS2_DecodeUTF32Stateful (s=0x5bd6a54 "\n", size=1, errors=0x5add144 "strict", byteorder=0x7feffb18c, 
>     consumed=0x7feffb170) at Objects/unicodeobject.c:2282
> 2282            if (qq[iorder[2]] != 0 || qq[iorder[3]] != 0)
> (gdb) p s
> $1 = 0x5bd6a54 "\n"
> (gdb) p qq
> $2 = (const unsigned char *) 0x5bd6a54 "\n"
> (gdb) p iorder[2]
> $3 = 2
> (gdb) p iorder[3]
> $4 = 3
> (gdb) p bo
> $5 = -1
> (gdb) p *byteorder
> $6 = -1

Could you check whether the report goes away when using the following
definition of iorder in that function:

#ifdef BYTEORDER_IS_LITTLE_ENDIAN
    const int iorder[4] = {0, 1, 2, 3};
#else
    const int iorder[4] = {3, 2, 1, 0};
#endif

I guess that the missing dimension is causing the valgrind report.

From a code perspective, everything is in order, in fact I'd expect
the compiler to optimize the array away. It may even be a good idea
to replace the array with symbols:

#ifdef BYTEORDER_IS_LITTLE_ENDIAN
# define BYTEORDER_0 0
# define BYTEORDER_1 1
# define BYTEORDER_2 2
# define BYTEORDER_3 3
#else
# define BYTEORDER_0 3
# define BYTEORDER_1 2
# define BYTEORDER_2 1
# define BYTEORDER_3 0
#endif