TIFFPrintDirectory does this to print a custom tag that it doesn't otherwise
know:

                uint32 value_count;
                void *raw_data;

            if(TIFFGetField(tif, tag, &value_count, &raw_data) != 1)
                continue;

(this is tif_print.c, around line 521 in the 3.9.4 sources).  The trouble with
this is that the code inside TIFFGetField is very likely to believe that the
first argument is uint16* not uint32*; see for example this bit in
_TIFFVSetField, around line 863 of tif_dir.c:

            if (fip->field_readcount == TIFF_VARIABLE2) 
                *va_arg(ap, uint32*) = (uint32)tv->count;
            else    /* Assume TIFF_VARIABLE */
                *va_arg(ap, uint16*) = (uint16)tv->count;
            *va_arg(ap, void **) = tv->value;

This leads to various platform-dependent, but uniformly bad, behavior.  The
test file shown in this Red Hat bug report
https://bugzilla.redhat.com/show_bug.cgi?id=623664
illustrates the problem.  It fails to crash on little-endian machines only
because the high order bits of value_count happen to start out zero, a thing
obviously not to be relied on.  You could get around that by initializing
value_count to zero, but it's still not gonna work on big-endian machines.

I'm unclear about what the least messy fix would be, and in particular which
end of this incompatibility is violating expectations.