Trouble Shooting Via Error Codes in Keil 5

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".

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".

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.. 

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.