Re: unsigned type

[anon@anon.org (anon)]

        As for confusing when the index type is defined as Positive, but the 
compiler and runtime system allows zero.  That's either a compiler Bug or a 
total lack of reading the RM definition of the terms Natural and Positive types 
for Adacore and the GNU GCC Ada maintainers.


        About types and standards. GNU GCC does not work for 16 bit machines 
unless you can find a code developed back in the 1980s. But 8 and 16 bit 
machine are still being use today in special purpose designs. So, code that can 
be develope for those machine are still needed. 

        But using Unsigned_8, Unsigned_16, Unsigned_32 and Unsigned_64 
which are define in the INTERFACE package are true standard because 
Unsigned_8, Unsigned_16, Unsigned_32 and Unsigned_64 do not change rather 
you are using a 8 bit machine or a 64 bit machine or anything in between.

	And Unsigned type is what the person ask about in the first place.

	Always use standards, its is a common ground that allow 
programmers a starting place to understand your code.


In <4a48968a$0$31863$9b4e6d93@newsspool3.arcor-online.net>, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>anon schrieb:
>> For Strings:
>>                           --  'A' is a zero length string, A'Last = 0, and
>>                           --  put_line  ( A ( A'First .. A'Last ) ) ;
>>                           --  does not raise an Constraint_Error even though in  
>>                           --  this case it translate to:
>>                           --  put_line  ( A ( 0 .. 0 ) ) ; 
>>   A : String := ""        ; 
>> 
>> Since you can have zero length string , the index is Natual instead of Positive, 
>> because zero is in Natural but is not define in Positive. Even though the 
>> Standard package define String index as a Positive type. (GNAT)
>
>(It is slightly confusing, I think, to say that in a
>definition like
>
>   type String is array (Positive range <>) of Character;
>
>the index type is Natural. It's not Natural in the Ada sense;
>that fact that many String related subprograms use the Natural
>subtype emphasizes the presence of Natural in String handling,
>but does not turn subtype Positive into index type Natural,
>does it?)
>
>> Always use standards, those who do not are the one making the mistakes 
>> that others must correct to make the program portable during updating. 
>
>How is it possible for _any_ implementation defined type
>to be portable just because the standard says it is
>implementation defined? (Like Standard.Integer?)
>
>For example, the GNU Ada Database Environment uses a 64 bit
>type available with GNAT.  This type may well be impossible when
>using other compilers.
>
>   type SQLBIGINT    is range -(2 ** 63) .. +(2 ** 63) - 1;
>   for SQLBIGINT'Size use 64;
>
>How will a subtype of Long_Long_Integer be different?
>Long_Long_Integer may not be provided at all. Or it
>does not have 64 bits.  I don't see how to gain anything
>with subtyping or deriving from the predefined integer
>types in cases such as this one.
>
>Using a subtype, there is more opportunity for
>shooting yourself in the foot when you use them
>where you should have been using database integers.
>A more striking example has been outlined by Tom Moran.
>
>Any Ada compiler can immediately decide whether or not this
>library unit can be translated (ported) when it sees SQLBIGINT.
>Seems perfectly clear, uses standard conforming type definitions,
>and explicitly stating what is needed.  Wouldn't this be much
>more implicit and more diffuse if the developers had tried to
>force database integers to be standard integers?