C, inter modules dependencies

[MT]

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.

I basically do both, i write interpretable code with lots of comments what it supposed to do that ends up like a entangled
spaghetti crap! Then a week later i sit down at my desk and swear: Who is the moron who did all this this!
Worst of all, i don't have any colleagues that i can bugg!

[Mechatrommer]

...in terms of having well-defined semantics.

and what is that? afaik, if you hope a language or compiler to define the "semantics" for you, then you are in deep trouble...

[legacy]

{ ++X, --X, X++, X-- } are banned here.

[tggzzz]

...in terms of having well-defined semantics.

and what is that? afaik, if you hope a language or compiler to define the "semantics" for you, then you are in deep trouble...

I appreciate English isn't your first language, but you would appear less troll-like if, before you reply, you took a little trouble to understand words that are unfamiliar to you. See https://en.m.wikipedia.org/wiki/Semantics_(computer_science)

[legacy]

With good ADA compiler why would you need C?

because

• Green Hills offers a superb ADA compiler but it costs thousand bucks
• GNAT is an open source implementation of ADA, but it is not a comfortable compiler, especially for embedded machines and metal bare profiles
• in both cases I need to reduce its features in order to reduce the bloated code which does not fit into machines like 8bit MPU and DSP

You might save time using a C library, but by doing this you are adding in the C problems again.

currently can't see a practical way to have { drivers, BSP, kernel } written in ADA, buddy
also { VxWorks, ucOS/2, PrexOS, VelocityOS, etc } are written in C, buddy

what I can do is: writing applications in Ada, over a Kernel+its drivers+its BSP written in C

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.

sounds like an interesting idea, any example ?

edit:

I have reduced GNAT's features to compile for

• 68HC11, which is a very small stack machine
• Avr8, 8 bit risc machine

but I am still struggling to have something really usable 

[legacy]

MODCAL … Oberon

these look very interesting, thank you, I will give an eye 

[legacy]

p.s. just a personal note about the frustration in obtaining a Pascal and Ada compiler

I am a Silicon Graphics fan, and I have a few CDs set, including a Pascal compiler for Irix, but it's deprecated version, too deprecated to run on Irix v6.5, it's completely different binary format (coff instead of elf), It can run only on old version of Irix/OS, which will not run on my hw, so ... I wonder why SGI has dropped out the Pascal compiler ? I can't really understand their choice! They supported Pascal in their first business and then they completely dismissed and they made any update completely dropped. in particular, with Irix v6.5 every development CD set has been called "MIPS/Pro" and about compilers it includes { C, C++, Fortran 77 } but there is no Pascal =(

So in my Irix-Box I have installed GNU/Pascal, v2.95, which is a completely dead branch of the GNU Gcc project. There is no GNAT bootstrapper for mips32bit/BE and mips64bit/BE, and GNAT requires a working GNAT compiler to build itself: it sounds like "no party", so I have emerged GNAT only on my laptop.

[C]

The HP pascal with modcal extensions, I never got my hands on the source to compiler. The pascal compiler I used back then was missing just one thing compared to the internal HP compiler. The ability to turn on the modcal extensions.  A patch to compiler let me use a different compiler switch to turn on modcal extensions.
While it started from ucsd pascal and could still compile ucsd pascal source the internals were much different.
If you look at FreePascal compiler when it creates a new data structure for a variable it sets the memory alignment at creation of the data structure in the compiler. My best guess is that the HP compiler above delayed setting the memory alignment of the variable until actual code generation. If the pascal source needed some specific alignment then machine code generation section would work around the limits that the CPU required. When a 32 bit variable was the wrong alignment in memory for a 32 bit load instruction it would try to do two 16 bit loads and if that alignment was wrong it would use four 8 bit loads.
A alignment problem became a compiler warning about slow code in place of a fatal error. This is just one example that I remember.

If SGI was not using their pascal compiler internal to SGI then the only reason to keep updating pascal was for the customer. The change from coff to elf could take a lot of work.

If you have GNAT on your laptop, why do you not compile a cross compiler for your MIPS computer?

C

[C]

For your 8 bit cpu's
You might think of generating something like P-Code in place of native machine code. This should reduce the code size a large amount.

C

[westfw]

You might think of generating something like P-Code in place of native machine code. This should reduce the code size a large amount.

Not particularly; you have to include the interpreter, so the "minimum" code side goes up a great deal.  Keep in mind than an 8bit microcontroller with 8k of program memory is "large" by many standards; you can put pretty substantial C programs into one of those. (the smallest micro I've ever programmed in C had 1k code words (a PIC with 12bit words), and the program I'm thinking of was 131 words long.  It used 13 bytes of RAM.)

Java ME (Micro Edition) Embedded claims a "very small memory footprint: as little as 1M of ROM and 128k of RAM."  (I laugh.)
UCSD Pascal (P-code) ran on some reasonably small micros (CP/M, Apple ][), although I'm not sure anyone would be happy trying to code a real embedded application in PCode.  Or Pascal from that era, either.)  And of course "time critical" or "processor dependent" features would probably have to be coded in assembly (or maybe C :-))

C is a better assembler, not a worse PL/1 or Smalltalk.  It succeeded (IMO) because it has very small requirements for run-time environment, and is much easier to port to a new environment.  When PCs revolutionized the computing industry, no other language managed to keep up with the pace of machine evolution.  (gcc includes support for a bunch of other languages, including ada, fortran, and pascal.  But there are very few of the run-time libraries needed, and most of them work on top of a "real operating system."   There are precious few languages designed to support bare metal environments (beyond the ability to call external functions.  And some don't have that.)  (and to a large extent, the things you DO need to support bare metal are exactly the sort of things that make a language "dangerous.")

[legacy]

If you have GNAT on your laptop, why do you not compile a cross compiler for your MIPS computer?

possible, but a bit complex

[Mechatrommer]

...in terms of having well-defined semantics.

and what is that? afaik, if you hope a language or compiler to define the "semantics" for you, then you are in deep trouble...

I appreciate English isn't your first language, but you would appear less troll-like if, before you reply, you took a little trouble to understand words that are unfamiliar to you. See https://en.m.wikipedia.org/wiki/Semantics_(computer_science)

i will appreciate if you make an effort to make less assumption. thank you for the link, i've read it before i made the post, and i've understood "advanced semantics" very long time ago. here again more reading for you...

https://en.wikipedia.org/wiki/Programming_language
http://web.eecs.umich.edu/~rthomaso/documents/general/what-is-semantics.html
http://homepage.cs.uiowa.edu/~slonnegr/plf/Book/

if you were talking about static semantics, and some "basic level of semantics", c/c++ "COMPILERs" addressed most of them decades ago. so what are you talking about newer languages have better "well defined semantics"? i hope you know what you are talking about. without giving specific examples, i see your argument as strawman argument.

[legacy]

An interesting reading I have found: Why should I have written ZeroMQ in C, not C++

[tggzzz]

...in terms of having well-defined semantics.

and what is that? afaik, if you hope a language or compiler to define the "semantics" for you, then you are in deep trouble...

I appreciate English isn't your first language, but you would appear less troll-like if, before you reply, you took a little trouble to understand words that are unfamiliar to you. See https://en.m.wikipedia.org/wiki/Semantics_(computer_science)

i will appreciate if you make an effort to make less assumption. thank you for the link, i've read it before i made the post, and i've understood "advanced semantics" very long time ago. here again more reading for you...

https://en.wikipedia.org/wiki/Programming_language
http://web.eecs.umich.edu/~rthomaso/documents/general/what-is-semantics.html
http://homepage.cs.uiowa.edu/~slonnegr/plf/Book/

if you were talking about static semantics, and some "basic level of semantics", c/c++ "COMPILERs" addressed most of them decades ago. so what are you talking about newer languages have better "well defined semantics"? i hope you know what you are talking about. without giving specific examples, i see your argument as strawman argument.

I was using it in the sense used in the definition on page 1 of your third reference:

For programming languages, semantics describes the behavior that a computer follows when executing a program in the language. We might disclose this behavior by describing the relationship between the input and output of a program or by a step-by-step explanation of how a program will execute on a real or an abstract machine.

The High Performance Computing (HPC) community traditionally stress languages and machines. What they have found is that, while multithreaded C programs running on multicore machines usually work, there are infrequent intermittent failures. These are, of course, very difficult to diagnose and isolate. When they are isolated, they are often traced back to

• subtle differences between compilers/libraries on different machines where different (valid) interpretations were made by different compiler writers
• experienced users accidentally straying into nasal demon territory
• libraries that relied on behaviour that is explicitly not guaranteed in the language (think Posix)

Such problems cannot be simply and easily defined - nor reliably invoked; they are complex and subtle. Nonetheless, they are very real.

For a taster of some easily stated problems, have a look at http://www.cpptalk.net/inconsistencies-in-the-standard-vt48713.html

[Mechatrommer]

For a taster of some easily stated problems, have a look at http://www.cpptalk.net/inconsistencies-in-the-standard-vt48713.html

from his code style clearly show non-safe type cast, and i can consider it not the best practice (see bolded line).. his way of pointers manipulation is also heavy he tried to manipulate directly struct's members several branches down the tree... something that i wont advice without close administration from the programmer's cerebral cortex... he also probably tried to use the C++ features and hackability beyond what is consider safe in computer programming...

typedef struct {int c; int d;} A;
typedef union {int a[2]; A b;} B;
B e;
int *p = (int *)&e, *q = &e.a[0], *r = &e.b.c;

it shows that i will not give high esteem to his comment. but granted, he tried to make some points and i hope C/C++ committee may listen and improve in the next C/C++ generation (its been 9 years is it worth listening? i dont know). pointers operation as shown in his example clearly shows how powerful C/C++ operation can be, but if you use it unwisely you can get nasty results. hence i wont give much high esteem either to another newer languages with their pitfalls, limitations and flaws as well, no language is perfect. if i want to give a high esteem on another "semantically correct" language, i'll give Basic a vote, but it with its own wisdom has its own unflawlessness, so... in the end...
http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages
and i believe java wins not because its language flawlessness, but just its cross platform cross machine doo doo... and thats where the money goes...

and one more thing... from your post... we should differentiate very very clearly between the standard/objective of a language and the implementation of it. the lackness in the standard maybe resulting in various way of implementation of each compiler/library vendor. but i dont think solving the flaws by dismissing a feature in "the standard" level is a good way to go, like dismissing pointers operations in java none of the example used to complaint C/C++ above you linked can be done in java... for some reason of course, your pick

[Kjelt]

http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages
and i believe java wins not because its language flawlessness, but just its cross platform cross machine doo doo...

Nice post 
If you look in the table at types it is interesting to see there are only two embedded languages, C and C++.

[free_electron]

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?

it should flag a warning if there is a risk for a mathematical operation to cause an overflow. the language should have a construct to tell the compiler : i know of this problem : it is safe.

for example the following construction could solve that

uint16 a,b,c
uint32 d
c = b+a   <- generates warning/compile error
c = uint16(b+a) <- does not generate warning as the programmer has explicitly instructed the compiler to allow the overflow to happen
d = b+a  <- does not generate warning as d is large enough to hold the result.

Should the compiler add code to check for this?

if it can be resolved at compile time ? no. variables are cast so the maximum storage space can be deduced at compile time.

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?

i gave an example above of how it can be done.

What other C functions does it need?

irellevant. the 'outward' functions either exist or they don't. the linker will tell you

What are the external variables?

Bad programming style . Functions should pass data only through their definition. They should not access anything else.
The language could easily be adapted to prohibit this. Any variable accessed that is not in the function header is automatically a local variable. Done. no more ambiguity. For those cases where you do want such functionality : implement a specific keyword although i can't imagine a cse where you could not do without it

function blah(a,b) as boolean
   extern c   <- keyword to declare there is an external variable being called in. the compiler can then check that such a beast exists and is of the correct type.
   c = a+b
  return a-b
end function

There is nothing wrong with the syntax of C. Syntax is syntax. Just take a way the ambiguity and strip it off it's parser induced limitations. semicolons , the darned == / = problem ( come on , it's 2015 you can't tell me a compiler cannot figure out of it is an assignment or a comparison... Basic could do that in 1964 ... And that is a child's language... Surely 'superior' C should be able to do that too ?

There are other things a compiler should do , especially when it comes to memory management. for example : if i free a block of memory : wipe it clean.
We've had oodles of problems lately with voided memory containing 'sensitive data' and scraping programs ( viruses) going on the hunt for this. What was the flaw again ? something in SSL ?
If the memory manager would actually destroy the memory content , as opposed to simply marking it as 'free'. This kind of crap could not happen.

The flaw was cause by a single failed check in the code. shit like that should not be left to the coder. it should be handled by the compiler. if i ask for a chunk of memory it hsoudl be handed to me 'clean'. if you ask to create a new file to the file system : it is empty. it does not contain garbage left over from its previous user. Why can't memory be treated the same way ?

the same shit happens with array definitions. There is nothing in the C language preventing me reading past the end of an array. in basic an array has a marker in it telling how large it is . try to go past the end and you get a slap on the wrist. Strings are the same thing. depending on the terminating character is crap. if i accidentally do not terminate properly all kinds of mayhem happens. simply store the length of the string in the string. a string could be defined as an array of a 32 bit number defining the length, following by the actual data. go over the limit and the compiler, or the runtime delivers you a swift kick in the pants. no more buffer overruns, underruns or leaky memory.

there are many simple things that could be implemented to make C a very good language.
MISRA is one attempt. there are others. but they do this using preprocessors. some of this stuff has to be done by the compiler.

[tggzzz]

For a taster of some easily stated problems, have a look at http://www.cpptalk.net/inconsistencies-in-the-standard-vt48713.html

from his code style clearly show non-safe type cast, and i can consider it not the best practice (see bolded line).. his way of pointers manipulation is also heavy he tried to manipulate directly struct's members several branches down the tree... something that i wont advice without close administration from the programmer's cerebral cortex... he also probably tried to use the C++ features and hackability beyond what is consider safe in computer programming...

You have completely missed the point. The author is deliberately using a very short programme in order to highlight inconsistencies and problems.

Maclaren is very well aware of how to write solid code; see any of his presentations at http://people.ds.cam.ac.uk/nmm1/ and note the institution. He has been on the bleeding edge of this kind of problem since the 60s, and is extremely well aware of where  the skeletons are buried. He also knows how to write debuggable and maintainable code, and gives lectures on the subject.

In short, on this subject he knows far more than you or I.

typedef struct {int c; int d;} A;
typedef union {int a[2]; A b;} B;
B e;
int *p = (int *)&e, *q = &e.a[0], *r = &e.b.c;

it shows that i will not give high esteem to his comment. but granted, he tried to make some points and i hope C/C++ committee may listen and improve in the next C/C++ generation (its been 9 years is it worth listening? i dont know). pointers operation as shown in his example clearly shows how powerful C/C++ operation can be, but if you use it unwisely you can get nasty results.

See above comment.

Auto-generated code, i.e. using C as a back-end high-level assembler for another language, often contains strange but legal code.

Maclaren has been on various international standardisation committees, and he has a range of stories about C/C++ where there were two language lawyers that both stated they understood an aspect of the language. He got each to explain it to the other, and they discovered and had to admit they both had valid reasonable but incompatibly different understandings of the aspect!

hence i wont give much high esteem either to another newer languages with their pitfalls, limitations and flaws as well, no language is perfect. if i want to give a high esteem on another "semantically correct" language, i'll give Basic a vote, but it with its own wisdom has its own unflawlessness, so... in the end...
http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages
and i believe java wins not because its language flawlessness, but just its cross platform cross machine doo doo... and thats where the money goes...

Meaningless, in this context.

and one more thing... from your post... we should differentiate very very clearly between the standard/objective of a language and the implementation of it. the lackness in the standard maybe resulting in various way of implementation of each compiler/library vendor. but i dont think solving the flaws by dismissing a feature in "the standard" level is a good way to go, like dismissing pointers operations in java none of the example used to complaint C/C++ above you linked can be done in java... for some reason of course, your pick

Flaws in the standard lead to differing implementations and hence differing compiler/program output.

Having to guess what your compiler will do is a complete waste of time - your time is best spent solving the problem, not fighting the unnecessarily inconsistent tools.

[Mechatrommer]

Having to guess what your compiler will do is a complete waste of time - your time is best spent solving the problem, not fighting the unnecessarily inconsistent tools.

so dont waste your time on so many compilers. pick few that you really use and make sure they have good feedback or ranking. get really to understand them, master them and... happy coding. another fight this language vs that language is better is a complete waste of time back to module dependency people...

There are only two kinds of programming languages: those people always bitch about and those nobody uses.   -- Bjarne Stroustrup

[Kjelt]

I agree with you except for:

There are other things a compiler should do , especially when it comes to memory management. for example : if i free a block of memory : wipe it clean.
We've had oodles of problems lately with voided memory containing 'sensitive data' and scraping programs ( viruses) going on the hunt for this. What was the flaw again ? something in SSL ?
If the memory manager would actually destroy the memory content , as opposed to simply marking it as 'free'. This kind of crap could not happen.

Any security software engineer knows to destroy sensitive data such as keying material etc. as soon as it is no longer needed. Never ever assume the system/OS will take care of it.
It will not pass the review if it is not erased explicitly. Lazy security programmers have caused a lot of problems in the past.
Nice example: An 16 byte MAC (message authentication code) over a message was checked using memcmp function and a bad mac was returned if it was not ok.
So why should you as a security engineer never ever use memcmp in this case? Answer: the memcmp function returns at the first byte that is not equal. So you can create a timing attack, the time it takes to get the answer is an indication of the position of the wrong byte, instead of a 128 bit security it is degraded to 16 time 8 bit security 

[Marco]

The only problem with C is between the chair and the keyboard.

When the problem is the fact that there is a human EBCAK and that problem is solvable with tools more suited to human beings then the problem is not PEBCAK. C, SQL, suid bits, etc etc etc etc ... from a communal point of view we shouldn't be using any of this as much as we do, they all require inhuman levels of discipline not to screw up.

Of course from a personal point of view the market is highly accepting of failure so you might as well just follow the herd and make money in this broken system rather than create better tools.

[Kjelt]

If there were alternatives.
But face it for small embedded devices C is and will be king, till the small embedded devices are dead.
Till then you need real embedded C programmers that have the knowledge what can go wrong and know how compilers and linkers work.
Yes we have seen numerous examples in this thread that C is far from perfect, but if you want to play in the field you have to know and avoid the pitfalls.

There are too many "programmers" that do not have real embedded C knowledge and screw up:
1) A lot of them have C#/java experience and are used to program on PCs (real story: new sw test engineer came to me asking for help since his embedded test program did not work, one of the first locs he did were a few mallocs of 1 MB on a 128kB device  )
2) Have no real interest in the matter or have a study that has no relevance like Biology even had a temp hired colleague with History as a major OMG!!!!!!!.
Programmers that became programmers because they wanted a job and there were none in their line of business.
Some become real good programmers, but most lack the interest or understanding to become good and they then start to blame the language if they fuck up.

[tggzzz]

If there were alternatives.
But face it for small embedded devices C is and will be king, till the small embedded devices are dead.
Till then you need real embedded C programmers that have the knowledge what can go wrong and know how compilers and linkers work.
Yes we have seen numerous examples in this thread that C is far from perfect, but if you want to play in the field you have to know and avoid the pitfalls.

Those are fair comments about C on small embedded devices. Many of the problems arise when C/C++ is used for larger and larger problems, with larger and larger programs, on processors with more and more cores. And in those application domains C/C++ does not scale as well as other languages.

But the small end is rapidly becoming bigger and that may slowly squeeze C. For example, I'm looking forward to putting Lua on an ESP8266 and seeing where some of the pain points are or aren't in an IoT device (a very low power temperature and humidity sensor, with a minimal reliance on any infrastructure or on external companies)

There are too many "programmers" that do not have real embedded C knowledge and screw up:
1) A lot of them have C#/java experience and are used to program on PCs (real story: new sw test engineer came to me asking for help since his embedded test program did not work, one of the first locs he did were a few mallocs of 1 MB on a 128kB device  )
2) Have no real interest in the matter or have a study that has no relevance like Biology even had a temp hired colleague with History as a major OMG!!!!!!!.
Programmers that became programmers because they wanted a job and there were none in their line of business.
Some become real good programmers, but most lack the interest or understanding to become good and they then start to blame the language if they fuck up.

There are too many people that should be kept away from a keyboard whatever language they are (mis)using And it is not, I can assure you, confined to software: it is just as prevalent in hardware.

The most "entertaining" example I saw was a programmer that had to get soft realtime messages from one C process to another in a Unix environment. Now there are many simple obvious techniques he could have used (e.g. sockets, shared memory), but he chose to have the sender write a line into a database and the receiver poll the database to see if any new messages had arrived.

[legacy]

the same shit happens with array definitions. There is nothing in the C language preventing me reading past the end of an array. in basic an array has a marker in it telling how large it is .

I have seen a few Pascal implementation trying to "embed" the string length within the string, and the trick is very easy: it uses the first cell to store the length! Oh well, this implies a maximal length limited to 255 chars. It seems a good idea.

there are many simple things that could be implemented to make C a very good language.
MISRA is one attempt. there are others. but they do this using preprocessors. some of this stuff has to be done by the compiler.

I agree!

[Marco]

If there were alternatives.

That's my point. Why isn't optional automated bounds checking part of C for instance? (Also annotations to be able to tell the compiler how to do it when we pull pointer shenanigans.) Just because we generally don't want it at runtime is no excuse, it's still valuable during debug and unit testing. We just muddle on, little rhyme or reason ... just overconfidence and collective stupidity.