View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00019701003.1(2013)/Issue7+TC1Shell and Utilitiespublic2026-01-22 07:392026-03-08 17:02
Reporterstephane Assigned Tomsbrown  
PrioritynormalSeverityEditorialTypeClarification Requested
Status Interpretation RequiredResolutionAccepted As Marked 
NameStephane Chazelas
Organization
User Reference
Sectioniconv utility
Page Number3003-3005
Line Number(Line or range of lines)
Interp StatusProposed
Final Accepted Text
Summary0001970: exit status unclear for iconv -c on invalid input
DescriptionThe iconv utility specification has:

> The presence or absence of -c shall not affect the exit status of iconv.

Which suggests that iconv should return the same exit status with -c that it should without.

But the exit status section has:

> >0
> An error occurred.

Which seems to be in contradiction.

AFAICT, both the iconv that comes with GNU libc and GNU libiconv exit with status 1 and no error message in:

printf '\303\n' | iconv -c -f UTF-8

For instance and the one from FreeBSD gives no error and exit with 0.

I've not tested other implementations.

BTW, all three implementations exit with 1 and report an error message when the decoding error is found at the end (like in printf '\303' | iconv -c -f UTF-8), which seems to be in breach of the POSIX specification. Not sure whether that's intentional or not.
Desired ActionMaybe change the exit status section to:

>0 An error occurred or would have occurred in the absence of -c.
TagsNo tags attached.

Activities

msbrown

2026-03-03 16:19

manager   bugnote:0007380

We discovered that implementations have variances on how they have implemented -c, with some clearing the exit status while others do not. IMHO, the text at page 3003 line 100489 is pretty clear that the erxit status should not be cleared and here is my suggested change:

To further make clear that the exit status should still be set when encountering an invalid sequence even if -c is present

On page 3–5 line 100558 section iconv change:

    
>0 An error occurred.


to:

>0 An error occurred, or would have occurred in the absence of -c.


However, we’ve also encountered an apparent issue with diagnostic messages: on almost all implementations the messages written to STDERR are suppressed when using -c, even though the standard calls for -s to be used if messages are to be suppressed. IMHO I think that this is erroneous, and messages should not be suppressed by -c, just as exit status is not cleared.

If we also want to say that diagnostic messages should not be suppressed by -c

On page 3003 line 100489 section iconv change:

    
The presence or absence of −c shall not affect the exit status of iconv.


to:
    
The presence or absence of −c shall not affect the exit status of, nor the issuance of messages written to standard error concerning invalid characters by, iconv.


This latter may be better expressed as a separate MANTIS issue, for a future edition?

stephane

2026-03-05 08:06

reporter   bugnote:0007381

Re: 0001970:0007380
> However, we’ve also encountered an apparent issue with diagnostic messages:
> on almost all implementations the messages written to STDERR are suppressed
> when using -c, even though the standard calls for -s to be used if messages are
> to be suppressed. IMHO I think that this is erroneous, and messages should
> not be suppressed by -c, just as exit status is not cleared.

I feel it's too late to make that change, especially if as you say that would break all existing implementations.

I don't know where -c/-s come from. They appeared in issue 6 Susv3 AFAICT (wasn't there in Susv2).

The oldest implementation I could find was GNU libiconv's where it was added in 2002 referencing (but not quoting) POSIX 2001 draft 6 (https://cgit.git.savannah.gnu.org/cgit/libiconv.git/commit/?id=dc5f739c1b29aa9f1335d025a094876d19d08eb3), suggesting they may have been a POSIX invention but already back then, -c was *documented* as *silently* discarding characters than can't be converted.

+When option \fB-c\fP is given, characters that cannot be converted are
+silently discarded, instead of leading to a conversion error.
+.PP
+When option \fB-s\fP is given, error messages about invalid or unconvertible
+characters are omitted, but the actual converted text is unaffected.
+.PP


The iconv(1) page from the linux manpage project has had

       --silent
       -s This option is ignored; it is provided only for compatibility.

since it was added there in 2014. Probably from RedHat as it had a RedHat copyright.

I'd expect users have come to rely on iconv -c not outputting errors even without -s. I certainly have.

$ echo Stéphane | iconv -t ascii
iconv: illegal input sequence at position 2
St$ echo Stéphane | iconv -ct ascii
Stphane
$ echo Stéphane | iconv -cst ascii
Stphane


The fact that it produces an error in:

$ printf %s $'St\xc3' | iconv -cst ascii
iconv: incomplete character or shift sequence at end of buffer
St


Would be a bug there.

msbrown

2026-03-05 16:27

manager   bugnote:0007383

Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
It is currently unclear in the standard that the error status should be left unchanged when -c is operative, and this should be made clear. This also applies to -s. Whether or not diagnostic messages are suppressed in the case of -c should also be clarified.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 3003 line 100489 section iconv change:

    
The presence or absence of −cshall not affect the exit status of iconv.


to:
    
The presence or absence of −c shall not affect the exit status of iconv, and any diagnostic messages that would have been issued in the absence of -c shall be omitted..

    
        
On page 3005 line 100558 section iconv change:

    
>0 An error occurred.


to:

    
>0 An error occurred, or would have occurred in the absence of -c or -s.

agadmin

2026-03-05 16:36

administrator   bugnote:0007384

Interpretation proposed: 5 March 2026

stephane

2026-03-08 17:02

reporter   bugnote:0007394

Re: 0001970:0007383

That "any diagnostic messages that would have been issued in the absence of -c shall be omitted" wording could be interpreted as "-c" causing all diagnostic messages to be suppressed, not only the ones about invalid characters.

Maybe we can just say that "-c implies -s".

Issue History

Date Modified Username Field Change
2026-01-22 07:39 stephane New Issue
2026-03-03 16:19 msbrown Note Added: 0007380
2026-03-05 08:06 stephane Note Added: 0007381
2026-03-05 16:27 msbrown Assigned To => msbrown
2026-03-05 16:27 msbrown Status New => Interpretation Required
2026-03-05 16:27 msbrown Resolution Open => Accepted As Marked
2026-03-05 16:27 msbrown Page Number (page or range of pages) => 3003-3005
2026-03-05 16:27 msbrown Interp Status => Proposed
2026-03-05 16:27 msbrown Note Added: 0007383
2026-03-05 16:36 agadmin Note Added: 0007384
2026-03-08 17:02 stephane Note Added: 0007394