From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.198.210 with SMTP id je18mr90306wic.1.1366081025656; Mon, 15 Apr 2013 19:57:05 -0700 (PDT) MIME-Version: 1.0 Path: hg5ni6237wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border1.nntp.ams2.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news.teledata-fn.de!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Tue, 9 Apr 2013 17:53:41 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> <4hzv51v872q2$.1imijbwd7heqm$.dlg@40tude.net> <1htu9idmcci7x.1vr9eafeivqah$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1365548024 30493 69.95.181.76 (9 Apr 2013 22:53:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 9 Apr 2013 22:53:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-04-09T17:53:41-05:00 List-Id: wrote in message news:alpine.DEB.2.02.1304081709350.8693@debian... On Mon, 8 Apr 2013, Dmitry A. Kazakov wrote: >>> Because even if the implementation of Ada.Text_IO.Open would know the >>> encoding of the filename, it could do nothing useful with it. >> >> ??? It must know the encoding in order to handle the file properly. > >Ah! Finally you seem to understand where the problem is! > >Ada.Text_IO would have to know the encoding, but it doesn't. Of course it does, the encoding is 8-bit Latin-1 (in the absence of any implementation-defined stuff). If you want UCS-16, use Wide_Text_IO. The name of the package chooses the representation. Ada doesn't really support any other encodings than these. > So it just treats the string like a sequence of bytes (much like a > C-string) and > leaves it to the Application Programmer to apply the proper conversion > before. Which means, the conversion must be done explicitly. You can do that, but (a) it's not really true (Text_IO has to know about LF and CR and FF to deal with line endings and the like) - you get lucky with UTF-8 because the representation of those is the same as Latin-1; (b) conversions are expensive. It would be more appropriate to use a stream solution for non-Latin-1 representations, but that of course has it's own problems. Probably the best we can do today (Text_IO is going nowhere) is a combination of Root_String'Class operations (so that the *program* representation is irrelevant) and form parameters to specify file representation. I don't see any real problems with that. Randy.