I apologize for the prior post. Try and focus on this one and either correct my (current) misconceptions or yours.
I find I badly mangle my first reply based on trying to interpret your patch by visual comparison. I don't have anything that can seem to apply it, and finally broke down and did it by hand other than some white space changes of no matter in the source. The diff 2.8.1 on my Mac was having none of it. B.255 white space character: A space, a nonbreaking space, or a horizontal tabulation character (SP, NBSP, or HT). (§ 14.3 ) The leading and trailing whitespace allowed in T'VALUE(X) (§ 14.1 ) (the string) doesn't include NUL and SOH. Without trying to understand your patch fully the restriction that a string representation (X) must be a valid string representation of a literal of type T and that the result must belong to the subtype implied by T is still in effect. I take it this is what your are trying to enforce. Assuming this reading of your code is more accurate than the last, your patch is still not standard compliant and likely won't be include in the VHDL code base. VHDL portability would suffer. Without testing the present code for based literals it should function for base 2. In the original file at line 39 the loop eats leading white space. There's a check at line 50 to see if the string (X) is empty, A check to see if there's a leading sign at line 56. At line 61 there's a loop that either traverses a decimal literal or the base of a based literal, determined by the length check at line 92. If the next character is a '#' or alternately an ':' (and both must be consistent) the base is the current value and must be between 2 and 16. Note that Tristan has code that insures the trailing '#' after the mantissa or based literal integer part matches the base separator (§ 13.10). The '#' or ':' is stored in Sep. There's a loop at line 108 that reads in characters that are between 0-9 and A-F (either case). Each character is tested against the base. In any event we might tend to think Tristan's code works. Your's however seems to have a defect. If I implemented your patch by hand correctly your code duplicates the functionality of the section of code, the loop starting at 108 in the original file, through the original file 145 at line 145 without any conditional invocation. You've placed limits on the input character restricting it to '0' and '1' for the integer part. It appears you're missing anything that makes this code base 2 specific, and it is executed after the previous loop that is base 2 to base 16 specific. This means it will re-parse the integer part and complain about characters above base 2. It means for non-base 2 numbers in the integer part of a based literal it is sure to cause an error. I wouldn't have done all this but I had obviously propagated some incorrect information in the previous post of mine. So I'll but out now. As I had mentioned earlier in a private email there's no indication what you are trying to do here. If you expect anyone to be able to help, approve or deal with what you're trying to do, you could be a little more forthcoming. I've noted you have asked for help far and wide, but you haven't been too clear on what exactly is wrong. I personally don't mind puzzles, it's what being a VHDL lawyer is all about. But this is a guessing game. My guess at this point is that if your code does something for you that Tristan's doesn't for base 2 based integers that's its because you are eating leading and/or trailing NUL or SOH characters that don't belong in the string you are using to invoke the VALUE attribute. One could wonder if you are extracting it from a packet or parsing something based on graphical characters or something. Let us know if I or anyone else can help. And I apologize again for the previous post being in error.
grt-values_modificado.adb
Description: Binary data
_______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
