I am a newbie for about ten years now, off and on, so I've forgotten so much. I do my Build in Keil for the TI Launchpad Board and I get, on a horizontal pane, at the bottom , a list of warnings and error codes that I cannot make any sense of. First of all, Warnings aren't, that I know of , going to stop a Build. In my case however, I'm getting a tsunami of warnings that bury my one or two errors like a needle in a haystack. I have no idea why keil does that, mingling errors with warnings. Can I suppress the warnings for now, so I have a chance at trouble shooting the errors ? I did find a listing of error codes that attempts, in chart form, to demystify the error codes which, to me at least are so cryptic I haven't a clue what they mean. Here is an example of what I mean, with a warning. I cannot even find the errors. To me this is just meaningless ...
C:/Users/Binky/AppData/Local/Arm/Packs/ARM/CMSIS-DSP/1.14.4/Source/TransformFunctions/arm_cfft_radix2_init_q31.c(138): warning: cast from 'const unsigned short *' to 'unsigned short *' drops const qualifier [-Wcast-qual] S->pBitRevTable = (uint16_t *) & armBitRevTable[7];
Abraxas said:Can I suppress the warnings for now, so I have a chance at trouble shooting the errors ?
https://community.arm.com/support-forums/f/keil-forum/56058/how-does-one-disable-warnings-during-the-build-process-in-keil-5
Abraxas said: I'm getting a tsunami of warnings that bury my one or two errors like a needle in a haystack. I have no idea why keil does that, mingling errors with warnings.
I think most (all?) compilers do that - they give the messages in the order they find the issues.
GCC is the same.
Abraxas said:Warnings aren't, that I know of , going to stop a Build
Sometimes a warning can lead to an error later in file - so it's generally best to address messages in order, starting from the first one reported.
An example here: https://community.st.com/t5/stm32-mcus-products/conflicting-types-error/m-p/686823/highlight/true#M252539
Abraxas said: To me this is just meaningless ... C:/Users/Binky/AppData/Local/Arm/Packs/ARM/CMSIS-DSP/1.14.4/Source/TransformFunctions/arm_cfft_radix2_init_q31.c(138): warning: cast from 'const unsigned short *' to 'unsigned short *' drops const qualifier [-Wcast-qual] S->pBitRevTable = (uint16_t *) & armBitRevTable[7];
To me this is just meaningless ...
So in this line:
S->pBitRevTable = (uint16_t *) & armBitRevTable[7];
You are performing a cast - you are telling the compiler to ignore the actual type of armBitRevTable[7], and take it as if its type were uint16_t
The compiler is warning you that, in doing so, your are ignoring the fact that armBitRevTable[7] was declared as const.
Presumably, it was declared as const for a reason - so the compiler is just alerting you to the fact that you are ignoring that.
Declaring something as const indicates that the thing should never be written to, and allows the compiler to detect potential errors if you do try to write to it. By throwing away that const, you are opening yourself up for such errors to go undetected - hence the compiler warns you.
Thanks. I found the setting to turn off warnings.
I wish the folks who write these IDE's would stop using such cryptic codes.
The most popular online course on the internet is "The Science of Every Day Thinking". It's short and enjoyable. I wish anyone writing software would take it. The first lesson is on how everyone thinks if they know what is running around in their head, most other people will also, That assumption doesn't end well, in the first lab. As they tap out a ubiquitous song, of their choosing, no one in the class has a clue what it is despite the assumption that 'most will get it".
Abraxas said:I wish the folks who write these IDE's would stop using such cryptic codes.
The message comes from the Compiler rather than the IDE.
The compiler does assume that the user is familiar with the C language and its terminology.
I guess the IDE could, indeed, expand on the compiler's terse/technical message.
Did my explanation make sense? Do you now understand that warning? Anything else need clarification?
I've been at C for about 40 years, so it's nothing new to me. I don't see what ""C:/Users/Binky/AppData/Local/Arm/Packs/ARM/CMSIS-DSP/1.14.4/Source/TransformFunctions/arm_cfft_radix2_init_q31.c(138):S->pBitRevTable = (uint16_t *) & armBitRevTable[7]; "" has to do with the C language ? It's just unreasonably cryptic technical gibberish to me. It's like insider jargon that only members of the club with the secret decoder ring can participate. The most popular and successful software on the market are the intuitive packages.
It would also be nice to have it presented in an organized way, segregated Errors from Warnings. I think that most will want to take care of errors first to get their program working and then warnings later to safeguard against later problems.
Yes I understand your explanation but I can't go running to others every time I do a build and with 50 warnings. The compiler is part of the IDE. Perhaps the most important part of it. It's an Integrated Development Environment. I'm starting to go back to PIC as I don't recall these sorts of indecipherable compiler messages in their MPLab IDE and I need to troubleshoot my code with meaningful feedback from the compiler or IDE..
Abraxas said: I don't see what ""C:/Users/Binky/AppData/Local/Arm/Packs/ARM/CMSIS-DSP/1.14.4/Source/TransformFunctions/arm_cfft_radix2_init_q31.c(138):S->pBitRevTable = (uint16_t *) & armBitRevTable[7]; "" has to do with the C language ?
C:/Users/Binky/AppData/Local/Arm/Packs/ARM/CMSIS-DSP/1.14.4/Source/TransformFunctions/arm_cfft_radix2_init_q31.c(138)
is just the full path name of the file, and the number in brackets is the line number.
Is the line of code to which the message refers.
Abraxas said:It would also be nice to have it presented in an organized way, segregated Errors from Warnings
Some IDEs do this; eg, Eclipse and MSVC.
But it's not a panacea: as previously noted, it's often the case that a warning can lead to a later error - so separating them often causes more confusion!
Abraxas said:Yes I understand your explanation but I can't go running to others every time I do a build
So which parts did you find unclear - wasn't all the rest of it just C terminology?
As mentioned, and alluded to in the MOOC The Science of Every Day Thinking, when we know something, it's all perfectly clear. As the saying goes "Hindsight is always 20/20", To yourself it's all perfectly clear and just the C language. "is just the full path name of the file, and the number in brackets is the line number." is NOT part of the C language and unless the end user is told this, I don't know how they would ever know or be expected to know. Ditto for much of the rest of the warnings. Why not " Warning: Type cast conflict in file arm_cfft_radix2_init_q31.c on line 138". Short and sweet and understandable. A user of the C language can be expected to know that once some data is declared as a certain type, not to undertake other operations on it that conflict with that data type. I'm not saying a file path isn't useful info, I could have just looked it up easily enough, but since I did not create the file, nor do I recall even including it as a linked entity, I did not know what it was or it's contents. "What's this about some table ?" were my thoughts...... and I still don't know what the table is, or why it's needed. I don't want an explanation now. I'm just saying how the uninitiated outsiders think. They can't put the word "File:" or "File path:" or "Line:" before the info ? We are expected to know this ? How ? It comes to us in a dream ? This has nothing to do with Kerns and Ritchie.
Abraxas said:Why not " Warning: Type cast conflict in file arm_cfft_radix2_init_q31.c on line 138".
Because that omits important information:
But agree that explicitly saying "File:", "Line:" (and some compilers include "Column:") would be better - it's not like the messages don't have the space for them!
Hmmm - this page claims to describe "the format of compiler diagnostic messages" for the ARM compiler:
https://developer.arm.com/documentation/dui0472/m/Compiler-Diagnostic-Messages
But it actually doesn't - there is no description of the format of the messages.
:(