NetBSD Problem Report #13

From jtc  Fri Oct  8 17:26:55 1993
Received: from localhost (jtc@localhost) by sun-lamp.cs.berkeley.edu (8.3/8.3) id RAA16819; Fri, 8 Oct 1993 17:26:55 -0700
Message-Id: <199310090026.RAA16819@sun-lamp.cs.berkeley.edu>
Date: Fri, 8 Oct 1993 17:26:55 -0700
From: "J.T. Conklin" <jtc>
To: gnats-bugs@sun-lamp.cs.berkeley.edu
Subject: getopt(3) should handle wide characters intelligently

>Number:         13
>Category:       lib
>Synopsis:       getopt(3) should handle wide characters intelligently
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 08 17:35:08 +0000 1993
>Closed-Date:    Sun Oct 28 15:59:09 +0000 2001
>Last-Modified:  Sun Oct 28 15:59:09 +0000 2001
>Originator:     
>Release:        0.9
>Organization:
Winning Strategies, Inc.
>Environment:

System: NetBSD sun-lamp.cs.berkeley.edu 0.9a SUN_LAMP#6 i386

>Description:
	Locales with wide characters are coming real soon now and 
	routines like getopt(3) should be updated to deal with them
	intelligently.

>How-To-Repeat:

>Fix:
>Release-Note:
>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->jtc
Responsible-Changed-By: jtc
Responsible-Changed-When: Fri Jan 14 14:56:58 1994
Responsible-Changed-Why:
I'm the person responsible for localization support in the C library.

State-Changed-From-To: open->analyzed
State-Changed-By: jtc
State-Changed-When: Fri Jan 14 14:57:50 1994
State-Changed-Why:
Trivial once localization code is integrated.


Responsible-Changed-From-To: jtc->lib-bug-people 
Responsible-Changed-By: hwr 
Responsible-Changed-When: Thu May 6 04:52:16 PDT 1999 
Responsible-Changed-Why:  
JTC has vanished 

From: Jaromír Dolecek <jdolecek@netbsd.org>
To: tech-toolchain@netbsd.org
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: Fri, 12 Oct 2001 20:32:18 +0200 (CEST)

 Hi,
 this seems to linger in PR database quite a long time. I wonder
 if this is really worth the efford or not, especially considering
 that if getopt(3) would be changed to use the wide character support
 in libc, it would pull in quite a lot code over to all static binaries
 using getopt(3).

 SUSv2 has this to say:
 """
 APPLICATION USAGE
 The getopt() function is only required to support option characters
 included in Guideline 3.  Many historical implementations of getopt()
 support other characters as options. This is an allowed extension,
 but applications that use extensions are not maximally portable.
 Note that support for multi-byte option characters is only possible
 when such characters can be represented as type int.
 """

 I have not found that the referred to 'Guideline 3' contains,
 but I expect it to contain US-ASCII characters only.

 So, it's perfectly reasonable for getopt(3) to not support wide
 characters and an application using them would not be portable anyway.
 Given this (and bloat factor mentioned above), I don't really
 see compelling reason to add that support to getopt(3).

 Thoughts?

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
 NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: jdolecek@netbsd.org
Cc: tech-userlevel@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: Sun, 14 Oct 2001 09:16:41 +0900 (JST)

 hi.
 [move to tech-userlevel from tech-toolchain]

 From: "Jarom=EDr" Dolecek <jdolecek@netbsd.org>
 > I have not found that the referred to 'Guideline 3' contains,
 > but I expect it to contain US-ASCII characters only.

 guideline 3 is:
 >    Guideline  3:
 >        Each option name should be a single alphanumeric character (th=
 e alnum character
 >        classification) from the portable character set.
 >        Multi-digit options are not allowed. Instances of historical u=
 tilities that used them
 >        have been marked LEGACY in the XCU specification, with the num=
 bers being changed from
 >        option names to option-arguments.



 > So, it's perfectly reasonable for getopt(3) to not support wide
 > characters and an application using them would not be portable anyway=
 .=

 > Given this (and bloat factor mentioned above), I don't really
 > see compelling reason to add that support to getopt(3).
 > =

 > Thoughts?

 are you talking about 'n' of "echo -n abc" ?
 if so, supporting only portable character set seems
 reasonable.

 "abc" of "echo -n abc" should be multibyte-capable, IMO.

 ---
 YAMAMOTO Takashi<yamt@mwd.biglobe.ne.jp>

From: Jaromír Dolecek <jdolecek@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: tech-userlevel@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: Sun, 14 Oct 2001 15:37:10 +0200 (CEST)

 YAMAMOTO Takashi wrote:
 > are you talking about 'n' of "echo -n abc" ?
 > if so, supporting only portable character set seems
 > reasonable.

 Yes, we are talking about 'n' in the above example. I'm not aware
 of _any_ application using wide characters for program options.

 Jaromir 
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
 NetBSD - just plain best OS! -=*=- Got spare MCA cards or docs? Hand me them!

From: Klaus Klein <kleink@reziprozitaet.de>
To: "=?iso-8859-1?q?Jarom=EDr?=" Dolecek <jdolecek@netbsd.org>
Cc: tech-userlevel@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: 18 Oct 2001 12:11:35 +0200

 "Jarom=EDr" Dolecek <jdolecek@netbsd.org> writes:

 > SUSv2 has this to say:
 > """
 > APPLICATION USAGE
 > The getopt() function is only required to support option characters
 > included in Guideline 3.  Many historical implementations of getopt()
 > support other characters as options. This is an allowed extension,
 > but applications that use extensions are not maximally portable.
 > Note that support for multi-byte option characters is only possible
 > when such characters can be represented as type int.
 > """
 >=20
 > I have not found that the referred to 'Guideline 3' contains,
 > but I expect it to contain US-ASCII characters only.

 "Guideline 3" refers to "Utility Syntax Guideline 3", which can be
 found in the "Utility Conventions" page in XBD.

 It's not clear to me what the objective of the PR is, i.e. option
 letters or option arguments.  For the former, there seems to be no
 compelling reason for extension (though I hear nothing screaming
 against doing so either, per se); the latter is an
 application-specific issue.


 - Klaus

From: Jaromir Dolecek <jdolecek@netbsd.org>
To: Klaus Klein <kleink@reziprozitaet.de>
Cc: tech-userlevel@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: Thu, 18 Oct 2001 22:04:45 +0200 (CEST)

 Klaus Klein wrote:
 > It's not clear to me what the objective of the PR is, i.e. option
 > letters or option arguments.  For the former, there seems to be no
 > compelling reason for extension (though I hear nothing screaming
 > against doing so either, per se); the latter is an
 > application-specific issue.

 I think the objective of the PR is indeed the former (i.e. option letters).
 The option arguments are not handled by getopt at all, so it's
 entirely application's thing how it would treat them.

 I don't see any compelling reason for such extension too.

 Jaromir
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
 -=  Those who would give up liberty for a little temporary safety deserve  =-
 -=  neither liberty nor safety, and will lose both.  -- Benjamin Franklin  =-

From: Klaus Klein <kleink@reziprozitaet.de>
To: Jaromir Dolecek <jdolecek@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: 18 Oct 2001 22:48:28 +0200

 Jaromir Dolecek <jdolecek@netbsd.org> writes:

 > Klaus Klein wrote:
 > > It's not clear to me what the objective of the PR is, i.e. option
 > > letters or option arguments.  For the former, there seems to be no
 > > compelling reason for extension (though I hear nothing screaming
 > > against doing so either, per se); the latter is an
 > > application-specific issue.
 > 
 > I think the objective of the PR is indeed the former (i.e. option letters).
 > The option arguments are not handled by getopt at all, so it's
 > entirely application's thing how it would treat them.
 > 
 > I don't see any compelling reason for such extension too.

 Actually, I can imagine _some_ justification for supporting "something
 like it", but not in the plain getopt(3): there might be use for this
 functionality in getopt_long(), but unless the glibc developers decide
 to step ahead on this, it's still not compelling.  (I've dropped
 tech-userlevel intentionally from the distribution, lest people start
 blaming me for spreading such ideas...)

 That said, I believe you should suspend the PR. :-)


 - Klaus

From: Jaromir Dolecek <jdolecek@netbsd.org>
To: Klaus Klein <kleink@reziprozitaet.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
Date: Sun, 21 Oct 2001 20:23:54 +0200 (CEST)

 Klaus Klein wrote:
 > That said, I believe you should suspend the PR. :-)

 Actually, I want to _close_ it. Nobody is going to work on this in future.

 Jaromir 
 -- 
 Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
 -=  Those who would give up liberty for a little temporary safety deserve  =-
 -=  neither liberty nor safety, and will lose both.  -- Benjamin Franklin  =-
State-Changed-From-To: analyzed->closed 
State-Changed-By: jdolecek 
State-Changed-When: Sun Oct 28 07:55:36 PST 2001 
State-Changed-Why:  
Nobody really wants this feature. Though it would be quite easy 
to implement now that we have support for wide characters 
in libc, doing that would pull in lots of commonly unused stuff 
into programs using getopt(3) (think 'static binaries'). Standards 
list this as an optional non-portable feature. 
So, since no-one seems to actually need this feature, this PR is closed. 
If there would be any need to implement this in future, feel free 
to re-open this. 
>Unformatted:
 To: gnats-bugs@sun-lamp.cs.berkeley.edu
 Subject: getopt(3) should handle wide characters intelligently
 From: jtc@sun-lamp.cs.berkeley.edu
 Reply-To: jtc@sun-lamp.cs.berkeley.edu
 X-send-pr-version: 3.01

Home	PR Database Search