* Re: execute external shell program and process the output line by line
2019-10-17 15:34 5% ` Dennis Lee Bieber
@ 2019-10-18 7:43 0% ` Simon Wright
0 siblings, 0 replies; 11+ results
From: Simon Wright @ 2019-10-18 7:43 UTC (permalink / raw)
Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
> Ada.Directories.Hierarchical_File_Names (A.16.1)
> This package provides additional directory operations handling
> hiearchical file names.
Not implemented in current CE or FSF releases (but ISTR seeing reference
to it on an AdaCore site)
^ permalink raw reply [relevance 0%]
* Re: execute external shell program and process the output line by line
@ 2019-10-17 15:34 5% ` Dennis Lee Bieber
2019-10-18 7:43 0% ` Simon Wright
0 siblings, 1 reply; 11+ results
From: Dennis Lee Bieber @ 2019-10-17 15:34 UTC (permalink / raw)
On Thu, 17 Oct 2019 05:25:26 -0700 (PDT), devosalain71@gmail.com declaimed
the following:
>I need the call a process like "ls",
>And process the output line by line.
>So it is not sufficient if i have the return code success or error.
So... first question: which compiler suite? I'm going to presume Linux
compatible given the specification of "ls". GNAT extension libraries cover
some of this need.
I would also mention that "ls" may not be the best example. If your
really mean that the command you need the output from IS "ls" you might
find that you don't need it at all if using GNAT:
"""
12.68. GNAT.Directory_Operations (g-dirope.ads)
Provides a set of routines for manipulating directories, including changing
the current directory, making new directories, and scanning the files in a
directory.
12.69. GNAT.Directory_Operations.Iteration (g-diopit.ads)
A child unit of GNAT.Directory_Operations providing additional operations
for iterating through directories.
"""
However, even that library has likely been superceded in Ada 2005 and
later by ada.directories
"""
Ada.Directories (A.16)
This package provides operations on directories.
Ada.Directories.Hierarchical_File_Names (A.16.1)
This package provides additional directory operations handling
hiearchical file names.
Ada.Directories.Information (A.16)
This is an implementation defined package for additional directory
operations, which is not implemented in GNAT.
"""
example:
"""
procedure Start_Search
(Search : in out Search_Type;
Directory : String;
Pattern : String;
Filter : Filter_Type := (others => True));
-- Starts a search in the directory entry in the directory named by
-- Directory for entries matching Pattern. Pattern represents a file
name
-- matching pattern. If Pattern is null, all items in the directory are
-- matched; otherwise, the interpretation of Pattern is implementation-
-- defined. Only items which match Filter will be returned. After a
-- successful call on Start_Search, the object Search may have entries
-- available, but it may have no entries available if no files or
-- directories match Pattern and Filter. The exception Name_Error is
-- propagated if the string given by Directory does not identify an
-- existing directory, or if Pattern does not allow the identification
of
-- any possible external file or directory. The exception Use_Error is
-- propagated if the external environment does not support the
searching
-- of the directory with the given name (in the absence of Name_Error).
"""
And for those where you must run an external command, there are things
in GNAT extensions like:
"""
12.77. GNAT.Expect (g-expect.ads)
Provides a set of subprograms similar to what is available with the
standard Tcl Expect tool. It allows you to easily spawn and communicate
with an external process. You can send commands or inputs to the process,
and compare the output with some expected regular expression. Currently
GNAT.Expect is implemented on all native GNAT ports. It is not implemented
for cross ports, and in particular is not implemented for VxWorks or
LynxOS.
"""
The more general mode would be to have the output of the command
written to a file, and then open/read the file... From system.os_lib
(probably another GNAT extension)
"""
procedure Spawn
(Program_Name : String;
Args : Argument_List;
Output_File : String;
Success : out Boolean;
Return_Code : out Integer;
Err_To_Out : Boolean := True);
-- Similar to the procedure above, but saves the output of the command
to
-- a file with the name Output_File.
--
-- Success is set to True if the command is executed and its output
-- successfully written to the file. If Success is True, then
Return_Code
-- will be set to the status code returned by the operating system.
-- Otherwise, Return_Code is undefined.
--
-- Spawning processes from tasking programs is not recommended. See
-- "NOTE: Spawn in tasking programs" below.
"""
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
^ permalink raw reply [relevance 5%]
* Re: Strings with discriminated records
@ 2018-05-31 22:18 5% ` Randy Brukardt
0 siblings, 0 replies; 11+ results
From: Randy Brukardt @ 2018-05-31 22:18 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]
"J-P. Rosen" <rosen@adalog.fr> wrote in message
news:pent4f$nrj$1@gioia.aioe.org...
> Le 30/05/2018 à 22:09, Randy Brukardt a écrit :
>> (B) But package use clauses make things visible that are not overloadable
>> (like objects), so they tend to be a substantial maintenance hazard --
>> adding something to a package can make client code using use clauses
>> illegal
>> because of conflicts. Adding unrelated stuff should *never* make any
>> client
>> illegal (changes, obviously are different).
> Here I don't agree. OF COURSE, changing a specification can make client
> code illegal, with or without use clauses. And I would not call making
> code illegal a "maintenance hazard"; on the contrary, a maintenance
> hazard is when a change does not make code illegal, but acts
> differently. We know how hard Tuck fought in Ada 95 to eliminate the
> Beaujolais effect...
Whenever large amounts of code depend on some package, causing unusual
illegalities in working code just because of the addition of a new
object/exception is a major problem. Consider something like Claw: we have
to avoid making changes to the specs -- even ones that are clearly good
ideas -- in order to avoid breaking user code. Similarly, I have to document
*every single* change in a language-defined package as an incompatibility --
even though only people overusing use clauses have a possibility of such an
incompatibility. And this is a real problem; it bites me often in Janus/Ada
(which itself overuses use clauses) -- the main reason that I hardly ever
use them in new code.
Ada's "solution" of making things illegal is better than silent changes
(although those can happen, too, especially in child units), but the best
situation is one where adding new subprograms/objects/exceptions don't have
any effect at all on existing code (in the absence of dubious design - that
is multiple different things with the same name and profile). Anything else
makes it hard to enhance libraries cleanly (you end up with unnecessary
child packages - like "Ada.Directories.Hierarchical_File_Names" - to avoid
the incompatibilities - and that itself is just another kind of pain.
Randy.
^ permalink raw reply [relevance 5%]
* Re: When to use Bounded_String?
@ 2017-12-29 9:11 6% ` Simon Wright
0 siblings, 0 replies; 11+ results
From: Simon Wright @ 2017-12-29 9:11 UTC (permalink / raw)
Mehdi Saada <00120260a@gmail.com> writes:
> GNAT is now the de-facto only fully-ceritified Ada 2012 compiler
GNAT implements a lot of Ada 2012, but definitely not all of the
optional parts; for instance, in both GNAT GPL 2017 and FSF GCC <= 8
Ada.Directories.Hierarchical_File_Names is
unimplemented. (Ada.Directories.Name_Case_Equivalence is also missing,
which I think is a mistake[1]).
Even the fully-supported versions available only to AdaCore customers
will have bugs/features, which may be OS-dependent; out of the box,
Linux & macOS systems have problems around ceiling locking (don't know
about Windows).
I don't know what form of certification is available/provided to AdaCore
customers, but it's likely to say something like "conforms to the ARM
with the following exceptions: <list of issues>".
None of this is intended as a criticism of AdaCore, who do an amazing
job!
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869
^ permalink raw reply [relevance 6%]
* Re: Operating System differences and Ada OS independent programming
2016-03-21 22:04 5% ` Randy Brukardt
@ 2016-03-22 8:43 0% ` Dmitry A. Kazakov
0 siblings, 0 replies; 11+ results
From: Dmitry A. Kazakov @ 2016-03-22 8:43 UTC (permalink / raw)
On 21/03/2016 23:04, Randy Brukardt wrote:
> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
> news:dta0fbll6sipc98r88nacm4k9adthj3amn@4ax.com...
> ....
>> Standard library Directories
>> http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-16.html
>> may provide some help, though it appears to lack a "normalize path"
>> operation... The compose() operation may allow for building up OS
>> compatible paths but is nothing like Python's os.path.join()
>
> There's also Ada.Directories.Hierarchical_File_Names, which adds some of the
> missing parts. (Unfortunately, GNAT missed its addition to Ada 2012, so it
> might not be much help in practice.)
>
> "normalize path" is an attractive idea, but it's pretty much unimplementable
> on Windows. Certain Windows operations will normalize paths, but they don't
> do it consistently. And with the long and short file names on Windows, paths
> *really* need to be normalized. But various Windows documentation says that
> comparing file names should never, ever be done on a Windows system. (It
> turns out that whether two file names are equal depends on the locale
> setting, on the file system of the partition that contains the file, and
> other variables. So it's impossible to compare paths accurately unless you
> know the file system involved -- which makes a general path comparison
> routine impossible [a general routine has to be able to compare paths of
> files that don't necessarily exist, as that might be a preliminary to
> creating a file].
>
> If one follows the advice to avoid comparisons, then there is not much need
> to normalize paths in the first place.
The need is to have portable programs working with directories.
Comparisons are necessary to have ordered sets of paths. BTW, path
comparison has nothing to do with the question if both paths denote the
same file or the same set of files. Under most OS it would be impossible
to tell normalized path or not. The very notion of "same file" might be
meaningless under certain circumstances.
Of course, it is not normalization what is needed, but proper typing
instead. Path is not a string. It must be a defined in the Ada standard
type with basic operations including OS-dependent string to path
conversion and backwards. Of course standard packages must take
instances of the type as parameters when opening a file. This will
eliminate most if not all real problems (as opposed to imaginary ones)
with it.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 0%]
* Re: Operating System differences and Ada OS independent programming
@ 2016-03-21 22:04 5% ` Randy Brukardt
2016-03-22 8:43 0% ` Dmitry A. Kazakov
0 siblings, 1 reply; 11+ results
From: Randy Brukardt @ 2016-03-21 22:04 UTC (permalink / raw)
"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
news:dta0fbll6sipc98r88nacm4k9adthj3amn@4ax.com...
...
> Standard library Directories
> http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-16.html
> may provide some help, though it appears to lack a "normalize path"
> operation... The compose() operation may allow for building up OS
> compatible paths but is nothing like Python's os.path.join()
There's also Ada.Directories.Hierarchical_File_Names, which adds some of the
missing parts. (Unfortunately, GNAT missed its addition to Ada 2012, so it
might not be much help in practice.)
"normalize path" is an attractive idea, but it's pretty much unimplementable
on Windows. Certain Windows operations will normalize paths, but they don't
do it consistently. And with the long and short file names on Windows, paths
*really* need to be normalized. But various Windows documentation says that
comparing file names should never, ever be done on a Windows system. (It
turns out that whether two file names are equal depends on the locale
setting, on the file system of the partition that contains the file, and
other variables. So it's impossible to compare paths accurately unless you
know the file system involved -- which makes a general path comparison
routine impossible [a general routine has to be able to compare paths of
files that don't necessarily exist, as that might be a preliminary to
creating a file].
If one follows the advice to avoid comparisons, then there is not much need
to normalize paths in the first place.
Randy.
^ permalink raw reply [relevance 5%]
* Re: Is there some way of calling a system command?
2013-11-26 16:10 7% ` adambeneschan
@ 2013-11-26 18:54 0% ` tolkamp
0 siblings, 0 replies; 11+ results
From: tolkamp @ 2013-11-26 18:54 UTC (permalink / raw)
Op dinsdag 26 november 2013 17:10:32 UTC+1 schreef adambe...@gmail.com:
> On Tuesday, November 26, 2013 7:35:26 AM UTC-8, tolkamp wrote:
>
> > Op zondag 11 juni 2006 15:19:12 UTC+2 schreef jimmaure...@worldnet.att.net:
>
>
>
> > > The easiest way is to simply call the C system command.
>
> > > The example below was run on my Windows XP system.
>
> >
>
> > > with Interfaces.C.Strings;
>
> > > use Interfaces.C.Strings;
>
> >
>
> > > procedure System_Example is
>
> > > function System_Call(Command : Chars_Ptr) return Interfaces.C.Int;
>
> > > pragma Import(Convention => C, Entity => System_Call,
>
> > > External_Name => "system");
>
> > > Rc : Interfaces.C.Int;
>
> >
>
> > > begin
>
> > > Rc := System_Call(New_String("dir"));
>
> > > end System_Example;
>
>
>
> > > The important part of the example is the creation of a function
>
> > > specification I have named System_Call. That function specification
>
> > > take a parameter of Chars_Ptr, which corresponds to a C char *.
>
> > > The function specification is used as the Ada interface to the C
>
> > > system call. The compiler is notified of that association through
>
> > > the pragma Import. That pragma causes the compiler to link the C
>
> > > system command and call it whenever System_Call is called in the
>
> > > Ada code.
>
>
>
> > Thank you for your reaction.
>
> > For me this is not very understandable.
>
> > Where must I put the directory path to the executable?
>
> > Is this "dir" in Rc := System_Call(New_String("dir"));?
>
>
>
> No, "dir" is the command. The effect of this statement is that it will execute the "dir" command just as if a user had typed it into the Command Prompt window. On Windows, "dir" causes a directory listing to appear on the screen.
>
>
>
> System_Call (that is, the C system() routine) more or less requires a string that is something the user would type in a shell or a Command Prompt window. So if you want to include the directory path, just include it as part of the command, same as you would if you typed it in yourself:
>
>
>
> Rc := System_Call(New_String("c:\users\abc\subdirectory\mytool"));
>
>
>
> or use the Ada.Directories and possibly Ada.Directories.Hierarchical_File_Names to create the file name:
>
>
>
> Dir : constant String := "c:\users\abc\subdirectory";
>
>
>
> Rc := System.Call(New_String(Ada.Directories.Compose(Dir, "mytool")));
>
>
>
> -- Adam
Thank you for your explanation. Now it works, the extra program is started.
The only disadvantage is that the Ada code below the procedure System_Example is suspended untill the extra started program is terminated. Is there a possibility that the Ada program continues while the extra program runs?
^ permalink raw reply [relevance 0%]
* Re: Is there some way of calling a system command?
@ 2013-11-26 16:10 7% ` adambeneschan
2013-11-26 18:54 0% ` tolkamp
0 siblings, 1 reply; 11+ results
From: adambeneschan @ 2013-11-26 16:10 UTC (permalink / raw)
On Tuesday, November 26, 2013 7:35:26 AM UTC-8, tolkamp wrote:
> Op zondag 11 juni 2006 15:19:12 UTC+2 schreef jimmaure...@worldnet.att.net:
> > The easiest way is to simply call the C system command.
> > The example below was run on my Windows XP system.
>
> > with Interfaces.C.Strings;
> > use Interfaces.C.Strings;
>
> > procedure System_Example is
> > function System_Call(Command : Chars_Ptr) return Interfaces.C.Int;
> > pragma Import(Convention => C, Entity => System_Call,
> > External_Name => "system");
> > Rc : Interfaces.C.Int;
>
> > begin
> > Rc := System_Call(New_String("dir"));
> > end System_Example;
> > The important part of the example is the creation of a function
> > specification I have named System_Call. That function specification
> > take a parameter of Chars_Ptr, which corresponds to a C char *.
> > The function specification is used as the Ada interface to the C
> > system call. The compiler is notified of that association through
> > the pragma Import. That pragma causes the compiler to link the C
> > system command and call it whenever System_Call is called in the
> > Ada code.
> Thank you for your reaction.
> For me this is not very understandable.
> Where must I put the directory path to the executable?
> Is this "dir" in Rc := System_Call(New_String("dir"));?
No, "dir" is the command. The effect of this statement is that it will execute the "dir" command just as if a user had typed it into the Command Prompt window. On Windows, "dir" causes a directory listing to appear on the screen.
System_Call (that is, the C system() routine) more or less requires a string that is something the user would type in a shell or a Command Prompt window. So if you want to include the directory path, just include it as part of the command, same as you would if you typed it in yourself:
Rc := System_Call(New_String("c:\users\abc\subdirectory\mytool"));
or use the Ada.Directories and possibly Ada.Directories.Hierarchical_File_Names to create the file name:
Dir : constant String := "c:\users\abc\subdirectory";
Rc := System.Call(New_String(Ada.Directories.Compose(Dir, "mytool")));
-- Adam
^ permalink raw reply [relevance 7%]
* Re: Why no Ada.Wide_Directories?
2011-10-18 1:10 0% ` Adam Beneschan
@ 2011-10-18 2:32 0% ` ytomino
0 siblings, 0 replies; 11+ results
From: ytomino @ 2011-10-18 2:32 UTC (permalink / raw)
On Oct 18, 10:10 am, Adam Beneschan <a...@irvine.com> wrote:
> On Oct 17, 4:47 pm, ytomino <aghi...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Oct 18, 6:33 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > > Say what?
>
> > > Ada.Strings.Encoding (new in Ada 2012) uses a subtype of String to store
> > > UTF-8 encoded strings. As such, I'd find it pretty surprising if doing so
> > > was "a violation of the standard".
>
> > > The intent has always been that Open, Ada.Directories, etc. take UTF-8
> > > strings as an option. Presumably the implementation would use a Form to
> > > specify that the file names in UTF-8 form rather than Latin-1. (I wasn't
> > > able to find a reference for this in a quick search, but I know it has been
> > > talked about on several occasions.)
>
> > > One of the primary reasons that Ada.Strings.Encoding uses a subtype of
> > > String rather than a separate type is so that it can be passed to Open and
> > > the like.
>
> > > It's probably true that we should standardize on the Form needed to use
> > > UTF-8 strings in these contexts, or at least come up with Implementation
> > > Advice on that point.
>
> > > Randy.
>
> > Good news. Thanks for letting know.
> > My worry is decreased a little.
>
> > However, even if that is right, Form parameters are missing for many
> > subprograms.
> > Probably, All subprograms in Ada.Directories,
> > Ada.Directories.Hierarchical_File_Names, Ada.Command_Line,
> > Ada.Environment_Variables and other subprograms having Name parameter
> > or returning a file name should have Form parameter.
> > (For example, I do Open (X, Form => "UTF-8"). Which does Name (X)
> > returns UTF-8 or Latin-1?)
>
> > Moreover, in the future, we will always use I/O subprograms as UTF-8
> > mode if what you say is realized.
> > But other libraries in the standard are explicitly defined as Latin-1.
> > It's certain that Ada.Character.Handling.To_Upper breaks UTF-8.
>
> I have a feeling you're fundamentally confused about what UTF-8 is, as
> compared to "Latin-1". Latin-1 is a character mapping. It defines,
> for all integers in the range 0..255, what character that integer
> represents (e.g. 77 represents 'M', etc.). Unicode is a character
> mapping that defines characters for a much larger integer range. For
> integers in the range 0..255, the character represented in Unicode is
> the same as that in Latin-1; higher integers represent characters in
> other alphabets, other symbols, etc. Those mappings just tell you
> what symbols go with what numbers, and they don't say anything about
> how the numbers are supposed to be stored.
>
> UTF-8 is an encoding (representation). It defines, for each non-
> negative integer up to a certain point, what bits are used to
> represent that integer. The number of bits is not fixed. So even if
> you're working with characters all in the 0..255 range, some of those
> characters will be represented in 8 bits (one byte) and some will take
> 16 bits (two bytes).
>
> Because of this, it is not feasible to work with strings or characters
> in UTF-8 encoding. Suppose you declare a string
>
> S : String (1 .. 100);
>
> but you want it to be a UTF-8 string. How would that work? If you
> want to look at S(50), the computer would have to start at the
> beginning of the string and figure out whether each character is
> represented as 1 or 2 bytes. Nobody wants that.
>
> The only sane way to work with strings in memory is to use a format
> where every character is the same size (String if all your characters
> are in the 0..255 range, Wide_String for 0..65535, Wide_Wide_String
> for 0..2**32-1). Then, if you have a string of bytes in UTF-8 format,
> you convert it to a regular (Wide_)(Wide_)String with routines in
> Ada.Strings.UTF_Encoding; and it also has routines for converting
> regular strings to UTF-8 format. But you don't want to *keep* strings
> in memory and work with them in UTF-8 format. That's why it doesn't
> make sense to have string routines (like
> Ada.Strings.Equal_Case_Insensitive or Ada.Character_Handling.To_Upper)
> that work with UTF-8.
>
> Hope this solves your problem.
>
> -- Adam
I'm not confused. Your misreading.
Of course, if applications always hold file names as Wide_Wide_String,
and encode to UTF-8 only/every calling I/O subprograms as what you
say, so it's very simple and it is perhaps intended method. I
understand it.
But, where do these file names come from?
These are usually told by command-line or configuration file (written
by user).
It is probably encoded UTF-8 if the locale setting of OS is UTF-8.
So Form parameters of subprograms in Ada.Command_Line are necessary
and it's natural keeping UTF-8.
(Some file systems like Linux accept broken code as correct file name.
Applications must not (can not?) decode/encode file names in this
case.
Broken file name may be right file name if user sets LANG variable.
Same thing is in NTFS/NFS+. These file systems can accept broken
UTF-16. Strictly speaking, always, an application should not encode/
decode file names. But, Ada decides file names are stored into String
(as long as Randy says). So we have to give up about UTF-16 file
systems.)
And, it's popular that text processing functions keep encoded strings
in many other libraries or languages. I do not necessarily want to
deny the way of Ada, but I feel your opinion is prejudiced. It is not
so difficult as you say in fact.
^ permalink raw reply [relevance 0%]
* Re: Why no Ada.Wide_Directories?
2011-10-17 23:47 6% ` ytomino
@ 2011-10-18 1:10 0% ` Adam Beneschan
2011-10-18 2:32 0% ` ytomino
0 siblings, 1 reply; 11+ results
From: Adam Beneschan @ 2011-10-18 1:10 UTC (permalink / raw)
On Oct 17, 4:47 pm, ytomino <aghi...@gmail.com> wrote:
> On Oct 18, 6:33 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
>
>
>
>
>
>
> > Say what?
>
> > Ada.Strings.Encoding (new in Ada 2012) uses a subtype of String to store
> > UTF-8 encoded strings. As such, I'd find it pretty surprising if doing so
> > was "a violation of the standard".
>
> > The intent has always been that Open, Ada.Directories, etc. take UTF-8
> > strings as an option. Presumably the implementation would use a Form to
> > specify that the file names in UTF-8 form rather than Latin-1. (I wasn't
> > able to find a reference for this in a quick search, but I know it has been
> > talked about on several occasions.)
>
> > One of the primary reasons that Ada.Strings.Encoding uses a subtype of
> > String rather than a separate type is so that it can be passed to Open and
> > the like.
>
> > It's probably true that we should standardize on the Form needed to use
> > UTF-8 strings in these contexts, or at least come up with Implementation
> > Advice on that point.
>
> > Randy.
>
> Good news. Thanks for letting know.
> My worry is decreased a little.
>
> However, even if that is right, Form parameters are missing for many
> subprograms.
> Probably, All subprograms in Ada.Directories,
> Ada.Directories.Hierarchical_File_Names, Ada.Command_Line,
> Ada.Environment_Variables and other subprograms having Name parameter
> or returning a file name should have Form parameter.
> (For example, I do Open (X, Form => "UTF-8"). Which does Name (X)
> returns UTF-8 or Latin-1?)
>
> Moreover, in the future, we will always use I/O subprograms as UTF-8
> mode if what you say is realized.
> But other libraries in the standard are explicitly defined as Latin-1.
> It's certain that Ada.Character.Handling.To_Upper breaks UTF-8.
I have a feeling you're fundamentally confused about what UTF-8 is, as
compared to "Latin-1". Latin-1 is a character mapping. It defines,
for all integers in the range 0..255, what character that integer
represents (e.g. 77 represents 'M', etc.). Unicode is a character
mapping that defines characters for a much larger integer range. For
integers in the range 0..255, the character represented in Unicode is
the same as that in Latin-1; higher integers represent characters in
other alphabets, other symbols, etc. Those mappings just tell you
what symbols go with what numbers, and they don't say anything about
how the numbers are supposed to be stored.
UTF-8 is an encoding (representation). It defines, for each non-
negative integer up to a certain point, what bits are used to
represent that integer. The number of bits is not fixed. So even if
you're working with characters all in the 0..255 range, some of those
characters will be represented in 8 bits (one byte) and some will take
16 bits (two bytes).
Because of this, it is not feasible to work with strings or characters
in UTF-8 encoding. Suppose you declare a string
S : String (1 .. 100);
but you want it to be a UTF-8 string. How would that work? If you
want to look at S(50), the computer would have to start at the
beginning of the string and figure out whether each character is
represented as 1 or 2 bytes. Nobody wants that.
The only sane way to work with strings in memory is to use a format
where every character is the same size (String if all your characters
are in the 0..255 range, Wide_String for 0..65535, Wide_Wide_String
for 0..2**32-1). Then, if you have a string of bytes in UTF-8 format,
you convert it to a regular (Wide_)(Wide_)String with routines in
Ada.Strings.UTF_Encoding; and it also has routines for converting
regular strings to UTF-8 format. But you don't want to *keep* strings
in memory and work with them in UTF-8 format. That's why it doesn't
make sense to have string routines (like
Ada.Strings.Equal_Case_Insensitive or Ada.Character_Handling.To_Upper)
that work with UTF-8.
Hope this solves your problem.
-- Adam
^ permalink raw reply [relevance 0%]
* Re: Why no Ada.Wide_Directories?
@ 2011-10-17 23:47 6% ` ytomino
2011-10-18 1:10 0% ` Adam Beneschan
0 siblings, 1 reply; 11+ results
From: ytomino @ 2011-10-17 23:47 UTC (permalink / raw)
On Oct 18, 6:33 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> Say what?
>
> Ada.Strings.Encoding (new in Ada 2012) uses a subtype of String to store
> UTF-8 encoded strings. As such, I'd find it pretty surprising if doing so
> was "a violation of the standard".
>
> The intent has always been that Open, Ada.Directories, etc. take UTF-8
> strings as an option. Presumably the implementation would use a Form to
> specify that the file names in UTF-8 form rather than Latin-1. (I wasn't
> able to find a reference for this in a quick search, but I know it has been
> talked about on several occasions.)
>
> One of the primary reasons that Ada.Strings.Encoding uses a subtype of
> String rather than a separate type is so that it can be passed to Open and
> the like.
>
> It's probably true that we should standardize on the Form needed to use
> UTF-8 strings in these contexts, or at least come up with Implementation
> Advice on that point.
>
> Randy.
Good news. Thanks for letting know.
My worry is decreased a little.
However, even if that is right, Form parameters are missing for many
subprograms.
Probably, All subprograms in Ada.Directories,
Ada.Directories.Hierarchical_File_Names, Ada.Command_Line,
Ada.Environment_Variables and other subprograms having Name parameter
or returning a file name should have Form parameter.
(For example, I do Open (X, Form => "UTF-8"). Which does Name (X)
returns UTF-8 or Latin-1?)
Moreover, in the future, we will always use I/O subprograms as UTF-8
mode if what you say is realized.
But other libraries in the standard are explicitly defined as Latin-1.
It's certain that Ada.Character.Handling.To_Upper breaks UTF-8.
So we can not use almost subprograms in Ada.Characters and Ada.Strings
for handling file names.
(For example, Ada.Directories.Name_Case_Equivalence returns
Case_Insensitive. We can not use Ada.Strings.Equal_Case_Insensitive to
compare two file names.)
It means standard libraries are separated UTF-8 from Latin-1.
It's not reasonable.
I wish it be solved.
^ permalink raw reply [relevance 6%]
Results 1-11 of 11 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2006-06-11 8:46 Is there some way of calling a system command? Aldebaran
2006-06-11 13:19 ` jimmaureenrogers
2013-11-26 15:35 ` tolkamp
2013-11-26 16:10 7% ` adambeneschan
2013-11-26 18:54 0% ` tolkamp
2011-10-14 6:58 Why no Ada.Wide_Directories? Michael Rohan
2011-10-15 1:06 ` ytomino
2011-10-17 21:33 ` Randy Brukardt
2011-10-17 23:47 6% ` ytomino
2011-10-18 1:10 0% ` Adam Beneschan
2011-10-18 2:32 0% ` ytomino
2016-03-21 13:18 Operating System differences and Ada OS independent programming ldries46
2016-03-21 17:24 ` Dennis Lee Bieber
2016-03-21 22:04 5% ` Randy Brukardt
2016-03-22 8:43 0% ` Dmitry A. Kazakov
2017-11-19 2:19 When to use Bounded_String? Victor Porton
2017-11-23 10:04 ` briot.emmanuel
2017-12-28 11:46 ` Vincent DIEMUNSCH
2017-12-28 12:00 ` Dmitry A. Kazakov
2017-12-28 12:29 ` Mehdi Saada
2017-12-29 9:11 6% ` Simon Wright
2018-05-26 21:43 Strings with discriminated records NiGHTS
2018-05-27 17:11 ` NiGHTS
2018-05-27 18:25 ` Dmitry A. Kazakov
2018-05-27 22:44 ` NiGHTS
2018-05-28 7:42 ` Simon Wright
2018-05-28 18:38 ` Shark8
2018-05-28 21:15 ` Mehdi Saada
2018-05-28 21:48 ` Shark8
2018-05-28 22:27 ` Mehdi Saada
2018-05-29 7:49 ` Dmitry A. Kazakov
2018-05-29 13:40 ` Dan'l Miller
2018-05-29 14:04 ` Dmitry A. Kazakov
2018-05-29 22:41 ` Randy Brukardt
2018-05-30 5:00 ` J-P. Rosen
2018-05-30 20:09 ` Randy Brukardt
2018-05-31 4:19 ` J-P. Rosen
2018-05-31 22:18 5% ` Randy Brukardt
2019-10-17 12:25 execute external shell program and process the output line by line devosalain71
2019-10-17 15:34 5% ` Dennis Lee Bieber
2019-10-18 7:43 0% ` Simon Wright
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox