X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
NNTP-Posting-Date:	Thu, 25 Feb 2010 23:52:26 -0600
From:	"Robbie Hatley" <see DOT my DOT signature AT for DOT my DOT contact DOT info>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Bug in findfirst/findnext: mangles certain characters.
Date:	Thu, 25 Feb 2010 21:54:26 -0800
Organization:	Tustin Free Zone
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 6.00.2800.1983
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1983
Message-ID:	<2PydnQe72P4H_BrWnZ2dnUVZ_vmdnZ2d@giganews.com>
Lines:	58
X-Usenet-Provider:	http://www.giganews.com
X-Trace:	sv3-Tgft29Oa7fOGKzphxk2o67NYgI8oGHR+vplHYMQRDKAEolCdSuOXhjd4kYCzFbTweznFzzYdF0MEL6X!LB88yx4TzAPzq82pkN3z8aLPcX3xnuQUdixwvRI6mnfH+KGVoTDwyeBWzglAMDFn+SNASLu9fA==
X-Complaints-To:	abuse AT giganews DOT com
X-DMCA-Notifications:	http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info:	Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info:	Otherwise we will be unable to process your complaint properly
X-Postfilter:	1.3.40
Bytes:	3515
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

I've noticed that whenever I write programs using djgpp which
rename files, if they encounter files with certain characters
in their names, rename attempts fail, because findfirst()
and findnext() change the numeric value of those characters,
apparently in an attempt to re-map them to some other
character encoding.

Some extended-ASCII characters DO get through unmolested.
Examples:
'Z' = char(158)  findfirst/findnext RETURNS IT UNALTERED
'Å' = char(197)  findfirst/findnext RETURNS IT UNALTERED

But most non-ASCII character get re-mapped.
Examples:
'À' = char(192)  findfirst/findnext convert to 'A' = char(65)
'Á' = char(193)  findfirst/findnext convert to 'A' = char(65)
'Å' = char(194)  findfirst/findnext convert to 'A' = char(65)
'Ã' = char(195)  findfirst/findnext convert to 'A' = char(65)
'Ì' = char(204)  findfirst/findnext convert to 'I' = char(73)
'Í' = char(205)  findfirst/findnext convert to 'I' = char(73)
'à' = char(224)  findfirst/findnext convert to '.' = char(133)
'å' = char(229)  findfirst/findnext convert to '?' = char(134)
'í' = char(237)  findfirst/findnext convert to '¡' = char(161)
'ï' = char(239)  findfirst/findnext convert to '<' = char(139)
'õ' = char(245)  findfirst/findnext convert to 'o' = char(111)

Those are all legal characters in both iso-8859-1 and
in Windows long file names.  BUT, for some reason,
findfirst() and findnext() convert them to other characters.
It looks to me like these functions are trying to convert
characters they don't like into characters with similar-looking
glyphs in some other encoding.

This is broken, because it causes rename attempts to fail,
because no files actually exist with the altered versions
of their names given by findfirst/findnext.

I'm curious if anyone has run across this bug before?

And has this been fixed in recent versions?  (I'm using djgpp's
gcc version "4.2.3", so i'm about 3 versions behind the latest.)

If it's not been fixed, I suggest it should be put on the list of
"bugs to fix in next release".

In the mean time, anyone know of any workarounds for this?
Some way to turn off the "character re-mapping" which
findfirst and findnext are doing, and force them to retain
the original numeric value of each character?

-- 
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

- Raw text -