getopt finds no ambiguous optional argument - getopt

Question

I wrote down a shell script which uses the getopt command. The list of long options supplied to the getopt command include the following three different options:
localaddress
localport
listen
When I run my script with
myscript.sh --local xxxx
which clearly contains an ambiguous option (--local), getopt returns it as '--local-address' and a zero code.
++ getopt -o a:p: --long localaddress:,localport: -- --local 172.30.2.4
+ AUX='-- --localaddress '\''172.30.2.4'\'
But if I try
myscript.sh --l xxxx
here getopt does find it ambiguous:
getopt: option `--l' is ambiguous
I think this behaviour is weird given that the manual pages of getopt(1) show:
Long options may be abbreviated, as long as the abbreviation is not ambiguous.
What have I missed?
Thanx in advance
P.D: tested in RHEL5
Addendum
After I read the answer of Jonathan Leffler, I tried some tests -- pay attention on the colon pattern:
# getopt -V
getopt (enhanced) 1.1.4
# getopt -o a:p: --long localaddress,localport,listen -- --l xxx
--localaddress -- 'xxx'
# getopt -o a:p: --long localaddress,localport,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress,localport:,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress,localport:,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress:,localport,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress:,localport,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress:,localport:,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
# getopt -o a:p: --long localaddress:,localport:,listen: -- --l xxx
--localaddress 'xxx' --
UPDATE on 2014-05-26 -- testing getopt_long(3)
I created a simple C program to test the getopt_long(3) function.
In my source code, the array of the structure "option" passed to getopt_long(3) contains the definition of the three long options "xxaaa", "xxxyy" and "xxxzz" -- They all start with the same string "xx" to test the ability of getopt_long(3) to detect the ambiguous options.
/*
FIELD NAMES OF option STRUCTURE
name has_arg flag val
*/
{ "xxaaa", no_argument, NULL, 9},
{ "xxxyy", no_argument, NULL, 7},
{ "xxxyz", no_argument, NULL, 7},
{ "mmmAA", no_argument, NULL, 3},
{ "mmmBB", required_argument, NULL, 3},
(see the manual page of getopt_long(3) for details about the purposes of those fields).
Pay attention on that an ambiguous option as "--xx" has three possible candidates, but "---xxx" has only two ones.
The behaviour of getopt_long changes according to the values of two struct fields named "has_arg" and "val":
WHEN
the value of "val" field is the same in every possible candidate
AND
the value of the "has_arg" field is the same in every possible candidate,
THEN
the function getopt_long wrongly complains NOTHING about ambiguity
and the first candidate is returned
OTHERWISE
an error message about ambiguity is reported.
From the above example:
test 1. "--xxx" is WRONGLY admitted as "--xxxyy".
test 2. "--xx" is properly refused as ambiguous.
test 3. "--mmm" is properly refused as ambiguous.
The getopt(1) command assigns a 2 (labeled as LONG_OPT in the source code) in the "val" field of every "user-defined long option". In the case starting this thread, the array of "option" structures would look like:
{ "localaddress", required_argument, NULL, 2},
{ "localport", required_argument, NULL, 2},
Therefore the only way to getopt(1) detect an ambiguous long option is that that candidates have different values in their "has_arg" field.
QUESTIONS
Q1. Why does getopt_long(3) behave that way?
Q2. Why does getopt_long_only(3) not?
Q3. How can the creators of getopt_long(3) be notified? -- I'm not into the linux kernel
development nor I do not use to visit linux kernel websites.
WORKAROUND SUGGESTION
As I cannot answer Q1 yet, I think the source code of getopt(1) command might be modified to assign different values in the "val" field for each user-defined long option, instead of the same 2 (LONG_OPT) value. As getopt_long(3) can return single ASCII character in the case of short options, those values should fall out of ASCII map -- val >= 256

Answer 1

Very curious! I am at least nominally running the same version of getopt (admittedly not on RHEL5, which is fairly old, now, IIRC — not that age has much to do with it), but I can't reproduce the results you get. For every one of the operational examples in the addendum, I get the warning message getopt: option `--l' is ambiguous (and the exit status of getopt is 1, indicating failure).
Test script
for la in '' :
do
for lp in '' :
do
for li in '' :
do
(
set -x
getopt -o a:p: --long localaddress${la},localport${lp},listen${li} -- --l xxx
)
echo $?
done
done
done
Example output
+ getopt -o a:p: --long localaddress,localport,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress,localport,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress,localport:,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress,localport:,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress:,localport,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress:,localport,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress:,localport:,listen -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
+ getopt -o a:p: --long localaddress:,localport:,listen: -- --l xxx
getopt: option `--l' is ambiguous
-- 'xxx'
1
This is self-consistent and consistent with the documentation. Can you run the script shown and verify the output?