The POSIX standard says printf %c is supposed to take a string argument, not an integer.  The current behaviour is required by POSIX

http://pubs.opengroup.org/onlinepubs/009695399/utilities/printf.html

quoting the standard:
 The argument operands shall be treated as strings if the corresponding conversion specifier is b, c, or s ; otherwise, it shall be evaluated as a C constant, as described by the ISO C standard, with the following extensions: ...


 printf lets you do the opposite of what the original submitter wanted, get the ASCII (or Unicode!) value of a character as a string of decimal numbers.  Use
char=A
charvalue=$(printf '%d' "'$char")

 You can do the reverse with
charvalue=65  # ascii value of "A"
oct=$(printf '%03o' "$c")
printf '%b\n' "\\$oct"

After searching a bit after typing most of this, I see I wasn't the first person to try this.  (and I was using bc to convert decimal to octal for feeding to printf, instead of using another printf with %o.)  So anyway, there are shell snippets floating around using that printf trick,

chr() {
  printf \\$(printf '%03o' "$1")
}

ord() {
  printf '%d' "'$1"
}

 but see
http://mywiki.wooledge.org/BashFAQ/071 for more complete safer versions.  (e.g. setting LC_CTYPE=C)

 Those simple versions don't work with wide characters in a UTF-8 environment.  The byte sequence representing a Unicode character in UTF-8 isn't always the same as the character's value (codepoint).  The only overlap is in the ASCII range.

 It looks like the wooledge BashFAQ even has versions of chr and ord that handle UTF8 properly, though, so check that out.

 The naive approach breaks as follows:
e.g. Unicode smiley face is codepoint 0x263a
char=$(perl -e 'print chr(0x263a)')
echo "$char"  # prints a smiley face (assuming support Unicode etc.)

 Now taking the codepoint for that character
printf '%d' "'$char"
9786

 This is simply the decimal representation of 0x263A, and converting that to octal with bc will not produce a sequence of bytes that represent that codepoint in UTF-8.

printf "%s" "$char" | hexdump -b
0000000 342 230 272

 (also, oddly, printf "%c" "$char" only outputs the first byte of the UTF-8 representation, 0342.  I'm using LANG=en_CA.utf8 on Ubuntu GNU/Linux)

printf '\342\230\272\n'
☺

but
printf '%03o\n' 9786
23072
printf '\\23072\n'  isn't going to work.

printf '\u0x263a\n' works, though.

 Again, look at the Wooledge BashFAQ.

 So in summary, this bug report is in error, the current behaviour is required by POSIX, and there are ways to do what you want in pure bash, if not pure POSIX.  It appears POSIX does not specify the \u or \U escape sequences.