Greetings, On Thursday, July 12, 2012 11:54:01 AM UTC-7, RobH wrote: > > > Glad to hear there is still hope for a new compiler version ;) >
The delay's is your fault :) I decided to fix record initialization to allow for constant records, and make things work better in general. > The compiler - at least the version you are working on - seems to be > stricter than previous versions: I don't get this warning with 2.4o, not > even with the latest published 2.4p-beta. It seems to insist on getting > a bit-value. > The new initialization code works more consistently. Long ago (prior to June 2007) the controlling expression in a conditional could be anything and follows the C rules -- 0 meant FALSE, anything else was TRUE. Folks requested that I return to the original JAL behavior which required the controlling expression to be a BIT. > > Only if 'lexpr' must evaluate to a bit-value you can say the sample is > in error, and the proper declaration would then be: > > const bit usart_hw_serial = TRUE > > BTW: - this is the default in usart_common.jal when > usart_hw_serial is not specified by the program > - 'TRUE' is defined as bit in constants_jallib.jal > Right, that's why I think the bug is in the examples as they do not follow the library. Would anyone be offended if the new compiler causes warnings in the existing samples? There are ~50 cases of this. --kyle -- You received this message because you are subscribed to the Google Groups "jallib" group. To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/syMOawlczt8J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
