[1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

The following issue has a resolution that has been APPLIED. == http://austingroupbugs.net/view.php?id=1008 == Reported By:steffen Assigned

[1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1008 == Reported By:steffen Assigned To:ajosey

Re: [1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

I reorder a bit for clarity, this why this lady is a tramp… Shware Systems wrote: ||It is the responsibility of the application to ensure that, if the output ||codeset has a locking-shift encoding, the output buffer is returned to its ||initial shift state when conversion

Re: [1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

Hi Steffen, You should still be able to add notes to http://austingroupbugs.net/view.php?id=1008 . But, the point is that an application using iconv() to convert text doesn't need to know whether or not the target codeset has locking shift states. It should always make a final call similar

Re: [1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

Knowing which statefulness applies to the code set labels an implementation supports is an implementation quality matter, as part of all those labels being implementation-defined, as I read it. On Thursday, August 4, 2016 Steffen Nurpmeso wrote: Good evening.