public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/18799] New: iconv_prog exit status with -c is inconsistent
@ 2015-08-10 16:20 ben at 0x539 dot de
  2015-08-27 22:29 ` [Bug locale/18799] " jsm28 at gcc dot gnu.org
  0 siblings, 1 reply; 2+ messages in thread
From: ben at 0x539 dot de @ 2015-08-10 16:20 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=18799

            Bug ID: 18799
           Summary: iconv_prog exit status with -c is inconsistent
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: ben at 0x539 dot de
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/iconv.html , which
looks reasonably authoritative, says

> -c
>    Omit any characters that are invalid in the codeset of the input file
>    from the output.
>    [...]
>    The presence or absence of -c shall not affect the exit status of iconv.

I believe this means that invalid input sequences should be silently ignored,
but the exit status should still report failure if any were encountered.

iconv_prog.c currently fails to implement that, though the attempt is made: It
records when an invalid input sequence has been encountered and ignored, but it
clobbers the variable if there was any input in the current buffer that has
been successfully converted and needs to be written out (in the process_block
function):

      if (n == (size_t) -1 && omit_invalid && errno == EILSEQ)
        {
          ret = 1;
      [...]
      if (outptr != outbuf)
        {
          ret = write_output (outbuf, outptr, output, output_file);

As a result, we can observe the following when telling iconv_prog to interpret
0xff as an ASCII character:

    $ echo -n $'OK \xff' | iconv -c -f ascii > /dev/null; echo $?
    0

    $ echo -n $'\xff OK' | iconv -c -f ascii > /dev/null; echo $?
    0

    $ echo -n $'\xff' | iconv -c -f ascii > /dev/null; echo $?
    1

    $ (head -c 32769 /dev/zero; echo -n $'\xff') | iconv -c -f ascii >
/dev/null; echo $?
    1

I believe it should exit with non-zero exit status in all of these situations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug locale/18799] iconv_prog exit status with -c is inconsistent
  2015-08-10 16:20 [Bug libc/18799] New: iconv_prog exit status with -c is inconsistent ben at 0x539 dot de
@ 2015-08-27 22:29 ` jsm28 at gcc dot gnu.org
  0 siblings, 0 replies; 2+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2015-08-27 22:29 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=18799

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |locale

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-27 22:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-10 16:20 [Bug libc/18799] New: iconv_prog exit status with -c is inconsistent ben at 0x539 dot de
2015-08-27 22:29 ` [Bug locale/18799] " jsm28 at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).