C, inter modules dependencies

[tggzzz]

Isn't it time for C to grow up and do away with all these stupid forward declarations and header files ?

C is indeed a terrible language which should not be used for any serious programming. Unfortunately everyone does!

so everyone are not serious except you . btw, i dont think i'm expert or know it all enough to say the necessity of forward declarations can be thrown away in newer C+++ standard (if it ever to be made) without risking compilation integrity... i think they have thought of that its a miracle if they havent. though i'm also the one person who wish forward declarations to be thrown away. but i dont say C/C++ is a terrible language.

They are only "forward declarations" in limited uninteresting circumstances - i.e. within a single file. More importantly they are used to "export" API signatures so that binary blob libraries can be invoked from your code.

Way back when C started becoming popular, I thought "this is a terrible language, it will get superseded soon" but 30+ years later, there are better languages, but people don't use them.

there must be a reason for that! the problem with plethora of new languages you name it, is... they are not C/C++, thats why they dont survive, simple dont ask why, its just that, a fact.

ask them what "a[ i ] = i++;" should do, according to the C standard.

we all know what it does. if you dont like it, you may code it another way such as..

Code: [Select]

a[i] = i;
i = i + 1;
its perfectly valid

Those two are, of course, not equivalent. The result of "a[ i ] = i++;" is undefined, and any good compiler should issue a warning (you do turn on all warnings, don't you?). The ISO standard says that you are not allowed to change a variable more than once (or change and use one) without an intervening sequence point.

I believe, from people that have served on C standardisation committees, that the definition of "sequence point" can (and is) interpreted differently by different people. That may have changed in recent standards, but I'm sceptical.

What is hilarious, is all those projects claiming to be "safety critical" but still writing in C

its hilarious that a language got blamed for the unsafetyness..

Even the book "Safety Critical Programming in C" starts off by saying, "don't use C"

thats an advice to the young players

... from people that know where the skeletons are buried in very shallow graves

[ale500]

don't use C, use something else.

exactly what? buddy. it's a rant until you do not provide practical alternatives: which language for my embedded DSP ? Have you ever tried to put Ada on 8bit MPU ? Python on Chip is a crap, and I can't use Ada or Python to write drivers or RTOSs.

We are saying the sane. I am not complaining about C, just about MISRA and the whole business. If you want something strong typed and so on... ST and Resesas and TI and so on provide the automotive chips, then why the heck they do not provide something better than C ?. "Just be careful" don't use this and this and that because it may be unsafe or difficult to read..... well renesas' compiler is being used by the industry.... how about it only accepts misra compliant code ?....

Python as a RTOS ? that would be something ! I love lists and dictionaries !. There are plenty of rants about how python is unsafe and unsuited due to its nature. There is uC python... btw, it is written in C ! .



The problem is that as "de-facto standard" is the lowest kind-of portable denominator. If they (compiler writers) provide Ada for all processors... well it may help...

(void)memcpy(dst, src, (size_t) sizeof(some_var)); // some people on our team think that this is a great solution... read below...

emm, all kind of casting is banned, buddy, and you can bypass only with the unchecked conditions method, but in this case you have to add exceptions to the code-checker and then justify by hands (it means writing documentation, and sign with your name); the code above will not pass up to 5 rules, including the comment line "//" is not allowed by MISRA,  while "/* … */" is allowed.
[/quote]

I am complaining about this specific MISRA checker and its "usefulness", the '//' comment... I added to the text to comment on it, does not belong to the original.

I don't hate C, I just find funny the "attempt" at converting it in something it is not and was not designed to be.

[legacy]

I don't hate C, I just find funny the "attempt" at converting it in something it is not and was not designed to be.

The MIT introduced a lot of year ago a project called IC, it was a C interpreter, but it had a restricted C grammar which was a super set of ANSI/C with a subset of MISRA/C: well done! Pointers, casting, goto, and a lot of bad C thing got disciplined

so I guess the idea of a new "safeC" grammar might be cute

the problem is .. GNU/C is often a dialect, and introduces bad things, e.g. you can abuse of the instruction "goto" and you can jump outside a function, that should be banned, but Gcc allows it 

Code: [Select]

void foo1()
{
    void *jump[] = { halt, soft_reset };

    /*
     * wtf is it ? assembly branch?
     *   looking at the asm level
     *   it is translated into bra foo2
     *   which is an uncodnditional branch
     *   it's not a function call
     * so what about the stack?
     * no doubt it gets compromised
     * does it make sense? so why they allow this crap?
     * oh, just to invoke the soft_reset
     * so it really makes sense
     */
    goto *jump[1];
}


void halt()
{
    /*
     * dead beaf
     */
}

void soft_reset()
{
    /*
     * hAllo, buddy,are you coming from the goto instruction ?
     * if so, sorry, the stack is now compromised =(
     * but I am the machine reset written in assembly inline
     * relax, see you later, reboot is coming ^_^
     */

    //..assembly code
}


[legacy]

and people obviously wants to use it 

[Kjelt]

The only problem with C is between the chair and the keyboard.
You can write perfectly by any human unambiguously interpretable code with lots of comments what it supposed to do.
Or you can make a spaghetti crap putting >2 operations into one loc and during coffee break keep bugging your colleagues with "hey look how smart I am" till they fire your smart ass.

[Mechatrommer]

ask them what "a[ i ] = i++;" should do, according to the C standard.

we all know what it does. if you dont like it, you may code it another way such as..

Code: [Select]

a[i] = i;
i = i + 1;
its perfectly valid

Those two are, of course, not equivalent. The result of "a[ i ] = i++;" is undefined, and any good compiler should issue a warning (you do turn on all warnings, don't you?). The ISO standard says that you are not allowed to change a variable more than once (or change and use one) without an intervening sequence point.

thank you very much my vc++1998 compiled it just fine, all warnings enabled. i'm not entire sure with your interpretation of the ISO standard but i believe the sequence point is already differentiated between i++ and ++i... anyway, as i said, if its uncomfortable to ones semantic parser then there are more other ways to do that legitimately.

[tggzzz]

The only problem with C is between the chair and the keyboard.
You can write perfectly by any human unambiguously interpretable code with lots of comments what it supposed to do.

I wish that was the case, but it isn't. And that's according to people who know far more than me since they have been on C/C++ standardisation committees for many years, and have had to fault-find many real-world programs, compilers and libraries.

For a wry introduction to the less deeply buried skeletons, read the FQA (sic) at http://yosefk.com/c++fqa/ I'm particularly fond of the "const corectness" section, but all sections are worth reading learning and inwardly digesting.

[tggzzz]

thank you very much my vc++1998 compiled it just fine, all warnings enabled.

Oh, that's alright then. (Now all you have to do is convince all the other compilers to do the same)

[C]

I keep thinking of the saying,
which comes first the chicken or the egg.

You have four things the editor, the compiler, the linker and make program.
Each has problems, but don't fix the problems, mangle things to get them to work.

In binary integer math, you know that an addition could be one bit larger then the largest of the two binary inputs.
Should the compiler tell you about this?
Should the compiler add code to check for this?
Is this being checked for earlier in the code?
Or are you counting on programmer to get it right?
Is there a way for the programmer to tell the compiler the limits that are safe?

How can the compiler know what you want?
If the compiler does not know, you can not expect it to tell you about problems.
It comes down to the programmer has to input something to get something.

Look at a C function.
Can you quickly tell what it needs to function?
What types are external to function?
What other C functions does it need?
What are the external variables?
With an editor that truly understood the programming language a lot of this could be automatic.

Go a step further
If the editor understood that you were using ___ for hardware, then when you had a question it could point you to proper documentation.
No reason for the maker of the hardware to do this until they see a benefit.
No reason for the software side to do this until the hardware side does.
Again a little input could get you a lot of benefits.


The chicken or the egg, things need to change.

C

[Kjelt]

I wish that was the case, but it isn't.

Thats C++ i was talking about C.
And yeah also in C some indiscrepancies are there. Let me say it otherwise, the programmer is responsible to check and validate his program in the end. I came from writing C for small embedded devices that have no firmware update possibility and should work for 20 years at the customer. That means after programming you really make sure everything works as you thought it ought to work.
That also means stepping through your code with a debugger verifying the compiler made no mistakes.
Nowadays I see young players writing code, doing a 5 minute verify and check in. Luckily we have now automated tests in place that run at night so next day we can at least have a pretty good estimate if something was affected. Still no excuse for sloppy fast work, check double check triple check your code incl. Running tests. And yeah some of these devices I wrote code for 18 yrs ago are still in operation today.

[tggzzz]

I wish that was the case, but it isn't.

Thats C++ i was talking about C. And yeah also in C some indiscrepancies are there.

Exactly Which was my point, of course.

I agree C++ is undoubtedly far worse than C in this respect. An occasional .sig of min is "If C++ is the  answer, you are asking the wrong question".

Let me say it otherwise, the programmer is responsible to check and validate his program in the end.

The programmer is also responsible for choosing the right tool, understanding what it can and cannot do, and avoiding the dragons.

I came from writing C for small embedded devices that have no firmware update possibility and should work for 20 years at the customer. That means after programming you really make sure everything works as you thought it ought to work.
That also means stepping through your code with a debugger verifying the compiler made no mistakes.
Nowadays I see young players writing code, doing a 5 minute verify and check in. Luckily we have now automated tests in place that run at night so next day we can at least have a pretty good estimate if something was affected. Still no excuse for sloppy fast work, check double check triple check your code incl. Running tests. And yeah some of these devices I wrote code for 18 yrs ago are still in operation today.

That's my background too, and I agree with what you say. 

I too have seen the rise of the "if it compiles and nobody complains, then it works" attitude, and I too find it very unsettling - particularly when people don't understand the limitations of their tool. (There's even an example of that in this thread) Unfortunately that is also a reason against using C/C++.

[Kjelt]

If the tool takes care of all pitfalls (if theoretically that is possible) the resulting code will be or too large (as with java where you need an entire engine to run it) or without the tool itself becomes unmaintainable (as with the simulation software that generates code which is most of the time unreadable).
As for pitfalls such as dynamic memory allocation, if you don,t exactly know what you,re doing don,t use it. Don,t blame the language for the shortcomings of the programmer.

[Mechatrommer]

I too have seen the rise of the "if it compiles and nobody complains, then it works" attitude, and I too find it very unsettling - particularly when people don't understand the limitations of their tool.

so if one know ones compiler cant do

Code: [Select]

a[i]=i++, then one have to do the other way. no need to complain about the compiler or a standard limitation.

...the resulting code will be or too large (as with java where you need an entire engine to run it

and do one thinks the bundled "java" (or insert ones flavor's name here) engine is perfect? you may an otherwise struggle to build a perfect system on top of a nonperfect construct/platform/framework/engine (insert whatever flavor system here)

here we go inter module dependency to another language bashing thread...

[tggzzz]

If the tool takes care of all pitfalls (if theoretically that is possible) the resulting code will be or too large (as with java where you need an entire engine to run it) or without the tool itself becomes unmaintainable (as with the simulation software that generates code which is most of the time unreadable).
As for pitfalls such as dynamic memory allocation, if you don,t exactly know what you,re doing don,t use it. Don,t blame the language for the shortcomings of the programmer.

Do blame the language if its specification is so poor that experts can't agree on what it is. (See various usenet groups if you doubt that's the case with C and C++)

Do blame the language if using it causes problems that are due to the language itself.

[tggzzz]

I too have seen the rise of the "if it compiles and nobody complains, then it works" attitude, and I too find it very unsettling - particularly when people don't understand the limitations of their tool.

so if one know ones compiler cant do

Code: [Select]

a[i]=i++, then one have to do the other way. no need to complain about the compiler or a standard limitation.

...the resulting code will be or too large (as with java where you need an entire engine to run it

and do one thinks the bundled "java" (or insert ones flavor's name here) engine is perfect? you may an otherwise struggle to build a perfect system on top of a nonperfect construct/platform/framework/engine (insert whatever flavor system here)

here we go inter module dependency to another language bashing thread...

Those are all strawman arguments that you have invented.

[Mechatrommer]

Those are all strawman arguments that you have invented.

https://en.wikipedia.org/wiki/Criticism_of_Java
http://www.zdnet.com/article/java-zero-day-security-flaw-exploited-in-the-wild/
dont dream for a perfection please, tell me a name if any...

[tggzzz]

Those are all strawman arguments that you have invented.

https://en.wikipedia.org/wiki/Criticism_of_Java
http://www.zdnet.com/article/java-zero-day-security-flaw-exploited-in-the-wild/
dont dream for a perfection please, tell me a name if any...

More strawman arguments. Since it is clear either you haven't read my 9 word sentence, or don't know what a strawman argument is, I suggest you read https://en.wikipedia.org/wiki/Straw_man

[Rasz]

The only problem with C is between the chair and the keyboard.
You can write perfectly by any human unambiguously interpretable code

you could if people were perfect.

[legacy]

what do you think about Ada, guys ? and in particular about GNAT ?
any user here  ?


yesterday I achieved a few steps ahead to my purpose, and the new tool is making itself reality 

[legacy]

( with the Hope this new tool will be one step ahead in C  )

[Kjelt]

Do blame the language if its specification is so poor that experts can't agree on what it is. (See various usenet groups if you doubt that's the case with C and C++)

It ain't perfect, the programmers responsibility is to see in the end what the compiler and even the linker made from it and if it works as expected.
Don't expect to copy a c program from microcontroller A with compiler B to run directly on a microcontroller C with a compiler D.
If it was not a C problem it could well be a compiler interop problem.

Do blame the language if using it causes problems that are due to the language itself.

My whole point is not to use it so it causes problems. If (for the example given above) you want two operations to occur in the right order without any problems write it in two lines of C.
And add a line of comment what it supposed to do for the programmer that is reviewing it.

But if there are problems in a language that can be fixed they should be.

[tggzzz]

Do blame the language if its specification is so poor that experts can't agree on what it is. (See various usenet groups if you doubt that's the case with C and C++)

It ain't perfect, the programmers responsibility is to see in the end what the compiler and even the linker made from it and if it works as expected.
Don't expect to copy a c program from microcontroller A with compiler B to run directly on a microcontroller C with a compiler D.
If it was not a C problem it could well be a compiler interop problem.

With C that's not practical, since a tiny change to the code (including compiler arguments) or to the compiler (e.g. the next version) or to a third party library can cause previously working code to silently fail.

Do blame the language if using it causes problems that are due to the language itself.

My whole point is not to use it so it causes problems. If (for the example given above) you want two operations to occur in the right order without any problems write it in two lines of C.
And add a line of comment what it supposed to do for the programmer that is reviewing it.

But if there are problems in a language that can be fixed they should be.

There are many such problems in C (more in C++), and they cannot be fixed.

Example: there are very good reasons why it should be possible to "cast away constness" and very good reasons why it should be impossible to "cast away constness. The debate over that one lasted years, and was never resolved - because it cannot be!

Then there are related issues such as multithreading libraries which rely on compiler operation, even though the language specifically denies such responsibility and declares it to be libraries responsibility. Resolve that! (Perhaps in the next standard, which at long long last has a memory model).

[Kjelt]

I agree but do think other languages also suffer from similar issues, or do you know a "perfect" language? ( that still is usable)

[tggzzz]

I agree but do think other languages also suffer from similar issues, or do you know a "perfect" language? ( that still is usable)

Most (not all) other common widely used modern languages are significantly better than C/C++ in terms of having well-defined semantics. There are too many instances of "nasal demons" in C ( http://www.catb.org/jargon/html/N/nasal-demons.html )

There is - and never will be - a perfect language, because there are too many application domains with wildly differing objectives and non-objectives. A language that is good for modelling and simulating hardware is unlikely to be much use for absolute beginners programming robots/drones or for implementing business rules - and vice versa.

[C]

you are talking about language, but what about what the compiler leaves out?

If you have a bit type then you should be able to have an array of bits.
Does the compiler give you an array of bits or does it give you an array of bytes or something else?
The first graphics screens I worked with was an XY array of bits.
The second graphics system was 8 separate XY arrays.
An array of bytes caused the need to write more code.

Granted when working with something the processor can not directly do it will be slower.
A lot of the 8 bit processors could not do multiply or divide directly, but this was added.
Most processors can binary math of almost any size indirectly, Not added, make programmer jump through hoops.

A lot of compilers force alignment on structures. The structure then does not match the real world. What should be easy and error free read/write of structure and then work with the fields of the structure becomes a mess.
 
legacy
Back in the 80's HP took the uscd pascal compiler and added very few extensions for system programming. They called the extensions MODCAL. They created at least two operating systems. Created pascal & basic compilers for many processors and systems and at least one interpreter. Just pascal/modcal and very little assembly language.
Professor Niklaus Wirth's Oberon (programming language) which is based on pascal created a compiler and an operating system.


With good ADA compiler why would you need C?
You might save time using a C library, but by doing this you are adding in the C problems again.
If there is not a version of a ADA compiler that creates code for your blackfin processor then look for a ADA Compiler that outputs safe C source so you can use your blackfin c compiler as final step to generate the actual code.

C