simple question just to be sure

simple question just to be sure

[Rammeloo Stijn]

Hello,

According to me the following constructs are equivalent and are both
perfectly legal ada in ada83 and ada95:

    Bad_Frame_Name : constant String (1 .. 4) := "Bad" & Ascii.Nul;

   A_Nul : constant Character:=  Ascii.Nul;
   Bad_Frame_Name : constant String (1 .. 4) := "Bad" & A_Nul;

Why do I ask? We use a code analyses tool that stumbles over the first
construct with the error message "Bad_Frame_Name Value length 5 does not
match object length 4" but not over the second one. According to me this is
clearly a bug in the code analyses tool. According to the vendor, this 'odd'
behaviour would be caused by the fact that the first construct 'May not be
"perfect" Ada' but the second is. I totaly disagree with this statement. Can
some ada-guru out there confirm I'm right or, if not, why I'm wrong?

Thanks in foresee,
Stijn

Re: simple question just to be sure

[Ted Dennison]

In article <E472188161D5D311B08700105AF4CAAA04C99F35@kuumex03.barco.com>,
Rammeloo Stijn says...
>According to me the following constructs are equivalent and are both
>perfectly legal ada in ada83 and ada95:
>
>    Bad_Frame_Name : constant String (1 .. 4) := "Bad" & Ascii.Nul;
>
>   A_Nul : constant Character:=  Ascii.Nul;
>   Bad_Frame_Name : constant String (1 .. 4) := "Bad" & A_Nul;
>
>Why do I ask? We use a code analyses tool that stumbles over the first
>construct with the error message "Bad_Frame_Name Value length 5 does not
>match object length 4" but not over the second one. According to me this is

You may want to check package ASCII and verify that NUL isn't a 2-character
string. If it isn't, then this message is clearly wrong. If it is a 2-character
string, then the compiler is wrong. According to LRM J.5, it is supposed to be a
constant character.

>clearly a bug in the code analyses tool. According to the vendor, this 'odd'
>behaviour would be caused by the fact that the first construct 'May not be
>"perfect" Ada' but the second is. I totaly disagree with this statement. Can
>some ada-guru out there confirm I'm right or, if not, why I'm wrong?

Hopefully there's a bit of sense being lost in the translation here. It would be
fair to say that this is not exactly proper form in Ada (even Ada 83). The
declaration should not have the ranges on it, since those can be taken
automaticly from the initilizing object, and you may want that object to change
one day without having to recalculate the range. But that goes for *both*
constructions.

However, it is perfectly legal Ada. It could be that he meant to say that since
you are doing something that isn't normally done (due to it not being proper
form), you have stumbled upon a previously undiscovered bug in the compiler for
handling that situation. That's perfectly reasonable, and happens all the time
with all compilers. However, they should fix it. The fact that it seems to think
one side of the object is 5 characters long is particularly worrysome. If you
*hadn't* specified 4 characters, would it have made 5? What would be in the
extra one? Yuck.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: simple question just to be sure

[R. Tim Coslet]

Back in the early '90s I was trying to work with an Ada compiler for
Intel's i960
processor and kept having problems with arrays being longer than my code specified.
It made it impossible to do what I needed to do and get correct results (e.g.
'Range was bigger than I specified!)

It took alot of trouble to eventually get a response from the compiler
vendor about
this... their response: "...well Intel requested that arrays be 'rounded
up' to 16
byte multiiples so that their benchmarks would always use Burst
transfers to get
the fastest performance..."

We eventually switched compiler vendors...

But the problem that the original poster had appears to be an analysis tool
bug/feature...

                    RTC

Ted Dennison wrote:

> However, it is perfectly legal Ada. It could be that he meant to say that since
> you are doing something that isn't normally done (due to it not being proper
> form), you have stumbled upon a previously undiscovered bug in the compiler for
> handling that situation. That's perfectly reasonable, and happens all the time
> with all compilers. However, they should fix it. The fact that it seems to think
> one side of the object is 5 characters long is particularly worrysome. If you
> *hadn't* specified 4 characters, would it have made 5? What would be in the
> extra one? Yuck.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.

Re: simple question just to be sure

[Jeffrey Carter]

Rammeloo Stijn wrote:
> 
> Hello,
> 
> According to me the following constructs are equivalent and are both
> perfectly legal ada in ada83 and ada95:
> 
>     Bad_Frame_Name : constant String (1 .. 4) := "Bad" & Ascii.Nul;
> 
>    A_Nul : constant Character:=  Ascii.Nul;
>    Bad_Frame_Name : constant String (1 .. 4) := "Bad" & A_Nul;
> 
> Why do I ask? We use a code analyses tool that stumbles over the first
> construct with the error message "Bad_Frame_Name Value length 5 does not
> match object length 4" but not over the second one. According to me this is
> clearly a bug in the code analyses tool. According to the vendor, this 'odd'
> behaviour would be caused by the fact that the first construct 'May not be
> "perfect" Ada' but the second is. I totaly disagree with this statement. Can
> some ada-guru out there confirm I'm right or, if not, why I'm wrong?

This appears to be an error in the analysis tool. Both expressions are
legal and equivalent. However,

Name : constant String := "Whatever" & ASCII.NUL;

is better for minimizing future errors when the software changes, and
should work around the analysis tool error as well.

-- 
Jeffrey Carter