Is this an IFS bug in getopts?

[Steven W. Orr]

GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu)

I ran a program that was supposed to die with an error message that said:

Invalid format: example: 2.103.269.28-1-3

Instead, it died with:

i -- Invalid format: example: 2.103.269.28-1-3

I traced the problem back to a call to getopts. It turns out that when I 
called getopts, I had set IFS='-'. It never occurred to me that I could impact 
the function of getopts by setting IFS.

The old code was this:
DRVREV="$1"
IFS=-
set -- $DRVREV
(( $# == 3 )) || die -i -- 'Invalid format: example: 2.103.269.28-1-3'

I can fix the problem easily by saying

oldIFS="$IFS"
DRVREV="$1"
IFS=-
set -- $DRVREV
IFS="$oldIFS"
(( $# == 3 )) || die -i -- 'Invalid format: example: 2.103.269.28-1-3'

So here we are.
1. Should getopts be documented to say that it uses IFS?
2. Should getopts be hardcoded to use the dash as the option delimiter?
3. Is the current functionality correct the way it is and I'm just looking at 
it wrong?

TIA :-)

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net