C, inter modules dependencies

[legacy]

hi guys
I am in the need to have a tool able to show me all the dependencies(*) inter modules

a C-module is usually composed by two files

• header, defines types, global variables, constants and interfaces (C prototypes of public functions, methods than can be called by other modules), and dependencies (other include files)
• body, it's the implementation part, it also includes private variables, constants, and private functions (other modules can't see and call them, they are hidden to the world)

having a collection of these modules implies dependencies between them

two types of (*)dependencies at least

• type dependencies, a module in the need to use a typedef to define something (e.g. a struct field, or a function's parameter type) and the itypedef is defined in the header of an other module
• interface dependencies, a module which has a function call in its body, but the called function is defined in an other module

having a C module called lib_xxxx_vz, i'd like to see it composed by

• lib_xxxx_vz.h, including "lib_xxxx_vz.interface" and "lib_xxxx_vz.dep"
• lib_xxxx_vz.c, body, calling #include "lib_xxxx_vz.private"
• lib_xxxx_vz.interface public interfaces
• lib_xxxx_vz.private private interfaces
• lib_xxxx_vz.dep dependencies with other modules

is there anything able to do so ? able to built the lib_xxxx_vz.dep or something similar ? .


it makes sense for my hobby, but it makes more sense for my job
especially when it happens that I have to collaborate with the testing-squad
I mean I am often asked to fill "tables" of dependencies and manually filling them is a very boring activity,
nobody wants to do this job, so it's always my turn
and those damn tables are are absolutely required
by Microsoft Word and by a program called "Stood"   
so I also have to fill them twice
because it happens that Microsoft Word tables are not compatible with Stood tables
oh, well 


all the tricks&tips are the welcome, thank you in advance 

[nctnico]

Smells like some Doxygen could be useful for. But promise not to use Doxygen as a replacement for actual documentation. Source code never explains clearly why it is written that way so Doxygen output doesn't help understanding a program.

[legacy]

Understand by Scitools can help you to understand a project, I mean it creates different graphs and reports, e.g. tree-call graphs, and it can perform coverage (a plug in is required). It's useful for me, I have a few licenses for MacOSX/intel and Windows/XP, but it does not help me with the tables I have to create in order to do my job.

I will read the Doxygen documentation (never used before) in order to understand if it is able to create a dependencies-table. In case It will not, I can plan and allocate up to 2 weeks (and no more) of development in order to created the tool I need, but no more than 4 hours a day.

[Mechatrommer]

i also looking forward if any such app to make reverse engineering or understanding ossw code easier. i made my own very simple "inter-files dependency only" library manager (capture attached) to make things easier by searching #include keyword, to make inter-functions things can get too difficult to code, there will be too much to parse and generate. if i'm not mistaken, doxygen only generates comments (explanation) for each subroutines which is something i usually do myself and more effective for my need, no?

[westfw]

• lib_xxxx_vz.h, including "lib_xxxx_vz.interface" and "lib_xxxx_vz.dep"
• lib_xxxx_vz.c, body, calling #include "lib_xxxx_vz.private"
• lib_xxxx_vz.interface public interfaces
• lib_xxxx_vz.private private interfaces

You will probably make your life much easier, wrt "standard tools" if you name the files with a .h extension, even if that means
"lib_xxxx_vz_interface.h", "lib_xxxx_vz_private.h", etc.  (hopefully your compiler supports long filenames.)

lib_xxxx_vz.dep dependencies with other modules

Do you actually need something different than the dependency files that the compiler (most compilers) will generate for you automatically?  http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html
(make needs that list, anyway.)

There are a bunch of tools that build additional information about a project, that are very useful for understanding other peoples code (or your own, for that matter.)   The two that I use "a lot" are the "ID Database tools" (http://www.gnu.org/software/idutils/manual/idutils.html ), and EMACS "tags"  (there are equivalents for other editors.)   These are essentially old-fashioned CLI tools; a modern IDE like Eclipse or Visual Studio will build similar databases for you automatically and invisibly, letting you "browse" source pretty effectively.   I think.   Once you figure out how to use them.   (I guess one advantage of the old CLI tools is that they'll tend to work on a source tree regardless of whether it's set up to be built using some other IDE.)

[legacy]

You will probably make your life much easier, wrt "standard tools" if you name the files with a .h extension, even if that means
"lib_xxxx_vz_interface.h", "lib_xxxx_vz_private.h", etc.  (hopefully your compiler supports long filenames.)

It's not my choice, my boss wants project's files called that way, and I would be surprised if a modern OS could not manage long file names.

Do you actually need something different than the dependency files that the compiler (most compilers) will generate for you automatically?

I have to fill tables in Microsoft Word and Stood, with thousand and thousand of entry -> extremely boring! so if a tool is able to generate dependency files then it's the welcome because I will only have to parse its output in order to automatically build the tables I need for my purpose.

My ideal purpose: just to create 2 sub tools (one for Microsoft Word, one for Stood) making them able to produce what I need, so then I will just copy and paste their outputs

yo man, easy life, I am lazy 



ID Database tools looks very interesting to me

[tggzzz]

You will not, in general, be able to do this with C without (in one form or another) running the compiler. There are many reasons for that, of which the simplest and most obvious are conditional preprocessor directives, and macros.

If you have a very well disciplined codebase then you might be able to make simplifying assumptions.

To assess what will and won't be possible, consider importing your codebase into a decent IDE, and seeing what that can and cannot discover.

[legacy]

i also looking forward if any such app to make reverse engineering or understanding ossw code easier

try Understand by SciTools, shoot a PM to me for a few tricks

i made my own very simple "inter-files dependency only" library manager (capture attached)

it looks very good, do you have a tokeners ? a parser ? I have coded a C interpreter covering just a part of the C grammar, so I am only able to do a few checks, but I am able to check the McCabe Cyclomatic Complexity without the need to access the customer "code-validator" that  …. has a floating license manager, so just n=2 connects  are allowed (and I found it always refusing mine  ).

An other tool that I HATE is VectorCast, this tool needs to be used for the coverage analysis, but it's really a crap and it crashes too often 
It's too complex to be rewritten, or hacked (and I can't, in the principle, hack a customer tool), so I just have added it to my you-hate-but-you-must tolerance list.

to make things easier by searching #include keyword, to make inter-functions things can get too difficult to code, there will be too much to parse and generate. if i'm not mistaken, doxygen only generates comments (explanation) for each subroutines which is something i usually do myself and more effective for my need, no?

I guess yes.

[legacy]

obvious are conditional preprocessor directives, and macros.

why ?

• interfaces dependencies do not require the preprocessor
• typedef dependencies might require the preprocessor, but we (in the team) are not allowed by the boss to use any #define with typedef, and it makes him pissed off if he sees a an abuse of #define, and our code must also pass a lot of "code-validators" in order to make the commit accepted in the repository (our final customers want that way)

but in case of need, I have no trouble to "add" a "preprocessor" that expands macros and #defines, I have already coded a working one and I can integrate into my tools.

to tell you the truth, we have a special include file in our projects, it's called "types.h", it's located at the top of our libraries path and it's a mixture of #define and typedef, but mainly typedef is used to (re)define things like uint32_t, fp_IEEE_754 _t , fxp32_t (fixed point, used by our soft core, VHDL), etc, while #define is used to (re)define the language, e.g. we are NOT allowed to use "==" in the if-then-else statement, so we have to use "isEqualTo", and we can't use "&" to get the address of an entity, we must use "get_address()", which are both #defines

- "it's boring and pedantic, but it makes sense" - I was told by my boss, even if I am still too young to understand why? 

What I Know is that our sources need to pass a super-set of MISRA checks, I mean our customers give us their "code validators" and we have to apply them to our sources. These "code validators" are extremely pedantic and also apply special rules from DO178/A-B, plus other constraints, e.g. for each module the maximal McCabe Cyclomatic Complexity  must be < 7, which is not "C", and it's not MISRA, it's an additional rule imposed by our customers.

I am not in the development squad, I am the testing-boy, unfortunately, because of my junior-profile, against their senior-profile, so often I am asked to care about the full documentation, which I have to provide written in Microsoft Word (puuaahhh, I hate it, but I MUST use), plus an other document produced by Stood. A part of this documentation is related to the dependencies, so I have to fill a big matrix {1..n,1..n} in where I have to enumerate all the modules from 1---to--n and then, for each 1={1..n} I have to indicate which module is in dependency by which module, with both direct and inverse matrix.

Stood should be able to provide all of these informations, but ... it's an other story, like having the full version released only for SunOS, with the licence expired since a while, problems to get a new license (never understood the Why-on-the-Why(1)?), and a demo version for Windows installed on our desks, which is cool and free but with a lot of features disabled (including the dependency matrix  ) ....

(1) about the Why-on-the-Why
I guess, because a job in avionics must not be fun 

[free_electron]

Isn't it time for C to grow up and do away with all these stupid forward declarations and header files ?
Why is that needed anyway ? all the compiler has ot do is go over all your source files once , collect all globals and functions and build a map. and then start compiling.

All the misery with headers that don't match the actual routines , all the extra keyboard pounding .. it all goes away. Huge time and misery saver.

C is an archaic language full of restrictions and idiosyncrasies because the original code parser was severely limited in what it could handle.

I have seen IDE's for C where you can simply define a function and the IDE will create the forward declaration for you. i think it is called Cide ( short for C-IDE).
It maintains all dependencies for you. so no more problems with circular inclusions either. 

[tggzzz]

obvious are conditional preprocessor directives, and macros.

why ?

• interfaces dependencies do not require the preprocessor
• typedef dependencies might require the preprocessor, but we (in the team) are not allowed by the boss to use any #define with typedef, and it makes him pissed off if he sees a an abuse of #define, and our code must also pass a lot of "code-validators" in order to make the commit accepted in the repository (our final customers want that way)

but in case of need, I have no trouble to "add" a "preprocessor" that expands macros and #defines, I have already coded a working one and I can integrate into my tools.

to tell you the truth, we have a special include file in our projects, it's called "types.h", it's located at the top of our libraries path and it's a mixture of #define and typedef, but mainly typedef is used to (re)define things like uint32_t, fp_IEEE_754 _t , fxp32_t (fixed point, used by our soft core, VHDL), etc, while #define is used to (re)define the language, e.g. we are NOT allowed to use "==" in the if-then-else statement, so we have to use "isEqualTo", and we can't use "&" to get the address of an entity, we must use "get_address()", which are both #defines

- "it's boring and pedantic, but it makes sense" - I was told by my boss, even if I am still too young to understand why? 

What I Know is that our sources need to pass a super-set of MISRA checks, I mean our customers give us their "code validators" and we have to apply them to our sources. These "code validators" are extremely pedantic and also apply special rules from DO178/A-B, plus other constraints, e.g. for each module the maximal McCabe Cyclomatic Complexity  must be < 7, which is not "C", and it's not MISRA, it's an additional rule imposed by our customers.

I am not in the development squad, I am the testing-boy, unfortunately, because of my junior-profile, against their senior-profile, so often I am asked to care about the full documentation, which I have to provide written in Microsoft Word (puuaahhh, I hate it, but I MUST use), plus an other document produced by Stood. A part of this documentation is related to the dependencies, so I have to fill a big matrix {1..n,1..n} in where I have to enumerate all the modules from 1---to--n and then, for each 1={1..n} I have to indicate which module is in dependency by which module, with both direct and inverse matrix.

Stood should be able to provide all of these informations, but ... it's an other story, like having the full version released only for SunOS, with the licence expired since a while, problems to get a new license (never understood the Why-on-the-Why(1)?), and a demo version for Windows installed on our desks, which is cool and free but with a lot of features disabled (including the dependency matrix  ) ....

(1) about the Why-on-the-Why
I guess, because a job in avionics must not be fun 

Why? Because C allows and encourages poor practices, and claims it to be an advantage - not restricting the programmer etc. And there is a lot of strange code out there.

Another spanner in the works is pointers-to-functions, where the pointed to functions cannot be determined statically, but can only be determined dynamically i.e. at runtime. Such facilities are extremely useful in some cases.

However, since you have now told us that the code is MISRA compliant, most difficulties will be trapped out by the MISRA rules. Shame you didn't mention that earlier.

[Mechatrommer]

i also looking forward if any such app to make reverse engineering or understanding ossw code easier

try Understand by SciTools, shoot a PM to me for a few tricks

$1K tag? cough cough...

i made my own very simple "inter-files dependency only" library manager (capture attached)

it looks very good, do you have a tokeners ? a parser ?

no, nothing. just check for "#include" keyword and figure out what another file that the file tried to include, once collected, draw it in "tree-like" diagram as pictured (took me sometime to code all that), sort of like what Understand by SciTools does, but it surely got alot more features than mine. i wish i have "inter-subroutines or inter-functions" dependency as well, but that is too complex for me to code. i'm not a professional programmer, just for personal use, i dont even need any complexity analysis i prefer to do that or anything else by hand. so any tool with price tag greater than $50 is cough cough for me.

[legacy]

$1K tag?

quite shocking but $1K is a reasonable price for a tool like that, in the avionics budget. Apps&Tools by Green Hills and Windriver are mmmmmmmoooooorrrrrrreeeeeee expensive.

i wish i have "inter-subroutines or inter-functions" dependency as well, but that is too complex for me to code

yep, I can code these features, and I think they are extremely useful
I can modify and recycle the C interpreter, perhaps its AST tree will be useful to reduce the development time of the new tool.

so any tool with price tag greater than $50 is cough cough for me.

I know what you mean, the Scitools app is cute for my job tasks, my boss has paid it for me, but it's completely out of my hobby budget
(and … in the theory, I couldn't install anything on my personal laptop)

[donotdespisethesnake]

Isn't it time for C to grow up and do away with all these stupid forward declarations and header files ?
Why is that needed anyway ? all the compiler has got to do is go over all your source files once , collect all globals and functions and build a map. and then start compiling.

All the misery with headers that don't match the actual routines , all the extra keyboard pounding .. it all goes away. Huge time and misery saver.

C is an archaic language full of restrictions and idiosyncrasies because the original code parser was severely limited in what it could handle.

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

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.

C++ really doubled down on the whole mess, and unfortunately just prolonged the life of something that should have died.

We were having a quality exercise at work, and was asked what would really improve our software. I said "we should stop writing in C, for a start". I may as well have said "we should all go and live on Mars"!

And if anyone still thinks C is a good idea, ask them what "a[ i ] = i++;" should do, according to the C standard.

What is hilarious, is all those projects claiming to be "safety critical" but still writing in C. Even the book "Safety Critical Programming in C" starts off by saying, "don't use C"

[legacy]

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

don't use C, it's too hippy! and don't smoke too grass, buddy!
oh well, good theory, what about practical alternatives ?

lord Pascal and lady Modula2 seem died since a while
so here, in avionics, we have to deal with schoolmarm Ada (In Strong Typing We Trust)
but at home I can use python on my laptop, it's powerful and elegant
thousand light years away from all the crap about C, there is no need to invoke a "code validator", but ...
... I can't use it to compile for my DSP, oh shit 

in short, I guess there is a reason, a practical reason, if C has survived until now
I am too young to argue, I was born when C was already fixed in ANSI/C
and then into safeC (MISRA compliant), and all my embedded devices have a C toolchain

[legacy]

p.s.
here we have a professional tool called "AdaMULTI" made by Green Hills Software. It supports C/C++ and Ada, no pascal/modula2/... and my boss has showed me that Ada is used to code the high level, all the low level, including drivers and the operating system (VxWorks, Integrity, whatever_RTOS), is written in C, all my testing-activity is to care about drivers, and BSPs

In the open-source-world I found that gcc has no internal support for Ada, it requires an external core.

Code: [Select]

dev-lang/gnat-gcc

GNAT is a good choice, but it needs a bootstrap in order to be compiled, and it's hard to get Ada bootstrappers for MIPS, or for HPPA, while it's easy to get one for X86, AMD64, PPC, SPARC, and … may be ARM (I have seen bootstrap ARM/LE around)

Code: [Select]

SRC_URI="ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-core-${PV}.tar.bz2
        ftp://gcc.gnu.org/pub/gcc/releases/gcc-${PV}/gcc-ada-${PV}.tar.bz2
        amd64? ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-amd64.tar.bz2 )
        sparc? ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-sparc.tar.bz2 )
        x86?   ( https://dev.gentoo.org/~george/src/gnatboot-${BOOT_SLOT}-i686.tar.bz2 )"
        ppc?   ( mirror://gentoo/gnatboot-${BOOT_SLOT}-ppc.tar.bz2 )

so, i have emerged GNAT on my PPC laptop, but I am still struggling with practical things on my embedded toys: too effort is required, and often … it the toy is 8bit with a few resources … Ada needs to be reduced in its features (disabling exceptions, and other run-time stuff, like range-check)

in short, I guess it is a tradeoff

[amyk]

The way to make intermodule dependencies easier to understand is simply to create fewer of them, which means making the modules reasonably large and simplifying the whole project structure/design as much as possible. The worst are multi-file projects where each file contains a dozen or so lines of actual code at most.

[tggzzz]

The way to make intermodule dependencies easier to understand is simply to create fewer of them, which means making the modules reasonably large and simplifying the whole project structure/design as much as possible. The worst are multi-file projects where each file contains a dozen or so lines of actual code at most.

That is perilously close to saying make everything global

Minimising dependencies (i.e. coupling) is only half of it: you also need to maximise cohesion.

The number of source code files is a secondary concern. The objective is to have a module/library containing a suitable number of source code files whose overall operation can be specified by a small number of functions and data structures. Those (few) functions and data structures are declared in the single header file that is "exported" from the module/library an #included in other modules.

What's the best size for a module? Open to debate, but the neatest description I've seen is that "unit of modularity" = "unit of publication/distribution".

[ale500]

And those >1k $ tools are soo crappy inflexible and full of wtf didn't they think of this, that, why the hecks does it crash !, crappy reports and so on.

What I ask myself is if they want MISRA compatible code, why the heck the compiler does not enforce it !, it make no sense whatsoever to write the code twice, so to say. C has no strong types ? great, don't use C, use something else. Write a bloody compiler ! it is not rocket science after all...

One very nice example:

I don't remember which rule but one of them says that you have to cast the result of sizeof to something else because its size is implementation dependent and the code will not be portable.

This has two problems (at least)

1. What if the code is not gonna be ported to other compiler/architecture ? (I know about the exceptions...)
2. At least one of those "MISRA" checkers (costs like 3k per seat or so) allows:

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

if you remove the cast to size_t is complains with the comment above, if you cast !! it doesn't. Yeah, poor implementation. It doesn't help that such "solutions" to a poor implementation of the checker pollute the way around such "problems" so to say

void *memcpy(void *, void * size_t)

[legacy]

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.

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

[legacy]

in short I hate C, but I think we have no practical alternatives, so we'd better improve the language (e.g. adding strong checks) instead of trashing it away.

about me, I have no alternatives with my Blackfin DSP, I can only use C, while if I am trying to integrate Ada/GNAT with my mips32-r2/32bit board. The low level is still written in C (because the RTOS is written in C), but … the high level (aka Applications) is going to be rewritten in Ada.

[Mechatrommer]

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.

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

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

[C]

Header files

In a great language if the header stays the same then the program using that header to link to code, data or other things does not need to change.

This allows many people to be working on different parts of the code.

A text hack preprocessor like C uses can cause all kinds of problems.
Is the code good when the C preprocessor changes a data type from 16 bits to 128 bits? What about the other direction 128 bits to 16 bits.

After all the text hacking of the preprocessor is all the different versions of code good?

C

[mikerj]

Do all these people that hate C routinely use higher level languages on PCs etc?  C is without doubt my favourite language though I would agree that it's not ideal of inexperienced programmers and that the learning curve is steeper than some higher level languages.

[retrolefty]

I have seen IDE's for C where you can simply define a function and the IDE will create the forward declaration for you. i think it is called Cide ( short for C-IDE).

 The Arduino IDE also performs creating any needed function prototypes in the user's 'sketch'.

[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

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

[Kjelt]

There are ofcourse a lot of third party bounds checkers and static code analyzers.
The problem becomes personal taste. Some prefer extreme strict checks others not.
 For instance Lint can find very good things but more often is nitpicking and whining about proper C.
 

[C]

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.

This is real common

Each option or change creates new problems and cures for problems.
By having a length you remove the need to read the string to find it length and as you are not using a CHR(0) to mark the end you can have that character in the string.
A lot of the first pascals reserved space for each string to be 255 char long.
So you had two varables
Max_string_length
Current_string_length
Some let you define a shorter string length.
Some would use a pool of memory and  recreate the string with a new max_length when needed.
FreePascal adds a string type with a 16bit length, and adds a wide string type so you can have 16 bit wide unicode characters. Adds a C type of string where chr(0) marks the end.
All needed at times and all can be a source for errors.

C

[legacy]

code used to check my dev_tool:

-------------------------------------------------
app.c

Code: [Select]

#include "types.h"
void_t main()
{
    reset();
}

lib_A.c

Code: [Select]

#include "lib_A.h"

private char_t module[] = "lib_A";

#include "lib_A.private"

void_t foo_A0()
{
}

void_t foo_A1()
{
    foo_B1();
}

void_t foo_A2()
{
    foo_C1();
}

void_t foo_A3()
{
}

lib_B.c

Code: [Select]

#include "lib_B.h"

private char_t module[] = "lib_B";

#include "lib_B.private"

void_t foo_B0()
{
}

void_t foo_B1()
{
}

void_t foo_B2()
{
}

void_t foo_B3()
{
}

void_t foo_B4()
{
}



lib_C.c

Code: [Select]

#include "lib_C.h"

private char_t module[] = "lib_C";

#include "lib_C.private"

void_t foo_C0()
{
}

void_t foo_C1()
{
}

void_t foo_C2()
{
}

void_t foo_C3()
{
}

void_t foo_C4()
{
}

reset.c

Code: [Select]

void halt()
{
    /*
     * ...
     */
}

void soft_reset()
{
    /*
     * hAllo, buddy
     * the stack is now compromised
     * but I am the machine reset written in assembly inline
     * see you later, reboot is coming ^_^
     */

    //..assembly code
    printf("soft_reset\n");
}

void reset()
{
    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];
}
-------------------------------------------------

output:

Code: [Select]

registering ...
module0: [app]
module1: [reset]
module2: [lib_A]
module3: [lib_C]
module4: [lib_B]

methods
   0: [main] .k=1 i=0
   1: [halt] .k=1 i=1
   2: [soft_reset] .k=1 i=1
   3: [reset] .k=1 i=1
   4: [foo_A0] .k=1 i=2
   5: [foo_A1] .k=1 i=2
   6: [foo_A2] .k=1 i=2
   7: [foo_A3] .k=1 i=2
   8: [foo_C0] .k=1 i=3
   9: [foo_C1] .k=1 i=3
  10: [foo_C2] .k=1 i=3
  11: [foo_C3] .k=1 i=3
  12: [foo_C4] .k=1 i=3
  13: [foo_B0] .k=1 i=4
  14: [foo_B1] .k=1 i=4
  15: [foo_B2] .k=1 i=4
  16: [foo_B3] .k=1 i=4
  17: [foo_B4] .k=1 i=4

dependencies:
module0, needs module1
module2, needs module3
module2, needs module4

first results achieved by my dev_tool, perhaps the first mile stone, because it seems working, but it's a draft version and of course it needs a lot of improvement and more tests.

steps

• create a list of all the C modules (*.c), and add them to a list (module_list)
• extract all the public functions, and add them to a list (method_list)
• for each item in the module_list, parse it, and see if there is a function which is owned by a module in the module_list, if so, mark a dependency

it seems decent enough, and to parse each module I am using a list_library and a tokenizer library which I have developed time ago, happy to see that it's useful code.

Code: [Select]

    ...
    p_file = file_open(filename, file_is_text_ro);

    if (p_file isNotEqualTo NULL)
    {
        is_done = False;
        while (is_done isEqualTo False)
        {
            ans = linea_get_from_file(p_file, p_linea);
            if (ans isEqualTo True)
            {
                if (p_linea->len > 0)
                {
                    tokener_init_linea(p_tokener, linea_body);

                    i = 0;
                    while (ans isEqualTo True)
                    {
                        p_token = get_address(token[i]);
                        tokener_init_item(p_tokener, p_token);
                        ans = token_get(p_tokener);

                        switch (p_token->type)
                        {
                        case token_StrictAlphaNum:
                        case token_AlphaNum:
                            /*
                             * functions and variables are token_StrictAlphaNum
                             * keywords_training still needs to learn them: feature disabled!
                             */

    ...

I think the next feature, that I will try to add is: look for a dead code (are there functions never called?). it's an other task often assigned to me in my job, and it's extremely boring to have to check for the dead code 

[helius]

computed goto to a function pointer is not legal even in non-portable GCC extensions.

[Mechatrommer]

Why isn't optional automated bounds checking part of C for instance?

because a good programmer can easily make that in code, library, or a more advanced memory management class. do you remember that? the once famous technique, company own brew memory manager in Win311 era? 100 companies and you have 100 memory manager classes in a system? today, most noobs code monkeys expect the system should manage their app memory, with high level of security.... and dont hesitate to care whats going on in the middle, in the runtime environment engine.

[legacy]

computed goto to a function pointer is not legal even in non-portable GCC extensions.

sure, strong emotions if you dare to compile and execute the code above, including a pretty "segmentation fault" served as dessert

[Marco]

because a good programmer can easily make that in code

But considering you are too competent to actually need it it's still too much work right?

That's why we had/have the original string functions, it's all those other coders who just can't seem to get it right.

[C]

Would some report from GCC help you get the information you need?
or
something like this
 GCC-XML, the XML output extension to GCC!
http://gccxml.github.io/HTML/Index.html

C

[legacy]

@C
yes, gccxml can help a lot!
Thank you for your link 

[C]

Found GCC-XML with a quick idea, no idea how good it is.
Note that site now says

Note: GCC-XML has been succeeded by CastXML.

If you find it missing something you need you might think of trying to find a complete praiser to get what you need.
 
C

[legacy]

Or to code what I need by myself, but I find other tools interesting because I usually learn from them 

[tggzzz]

Would some report from GCC help you get the information you need?
or
something like this
 GCC-XML, the XML output extension to GCC!
http://gccxml.github.io/HTML/Index.html

Apparently, it is not uncommon for different compiler and library writers to interpret the C/C++ standards is subtly different ways. So this might not reflect the implementation of other compilers.

Source: those that have been bitten repeatedly.

[westfw]

it is not uncommon for different compiler and library writers to interpret the C/C++ standards is subtly different ways

I was going to say that that would be unlikely to affect dependencies (this used to be about dependencies, right?), but then I remember that we ran into EXACTLY that sort of thing.
We had this idea of "components", which were independently compiled things not-quite-like libraries.  And there would be code off in #includes like
#define COMPONENT_SOURCE ../../../components/
#define COMPONENT_VERSION 1

so that you could write your include like:

#include COMPONENT(ip, tcp)

And the compiler would go off and use a combination of concatenation and stringification to produce
#include "../../../components/ip/v1/tcp.h"
and it would include the file and everything would be swell.   In gcc 2.95 or so.

Pre-processor behavior is one of those things that is not really completely defined in the C standards (AFAIK.)  (Or perhaps it wasn't, and became so.)   In any case, sometime before gcc 4.5, the processing order of stringification/concatenation vs #include CHANGED in ways incompatible with the "component" macros, and it all stopped working :-(

[C]

Remember the C Pre-processor  is text-in to text-out.

Some output is new text
Some output is a text replace

A text replace can easily cause problems. If the c compiler does not catch an error from the text replace, you could have just created a unchecked logic error.
How many people read the output of the C Pre-processor to see if it's really valid?
How many people assume it's all valid changes?

C

[helius]

Remember the C Pre-processor  is text-in to text-out.

Technically, it's tokens-in to tokens-out. Fragments of tokens like unterminated strings are not valid data to the preprocessor.

[richardman]

... but then I remember that we ran into EXACTLY that sort of thing.
We had this idea of "components", which were independently compiled things not-quite-like libraries.  And there would be code off in #includes like
#define COMPONENT_SOURCE ../../../components/
#define COMPONENT_VERSION 1

so that you could write your include like:

#include COMPONENT(ip, tcp)

And the compiler would go off and use a combination of concatenation and stringification to produce
#include "../../../components/ip/v1/tcp.h"
and it would include the file and everything would be swell.   In gcc 2.95 or so.

Pre-processor behavior is one of those things that is not really completely defined in the C standards (AFAIK.)  (Or perhaps it wasn't, and became so.)   In any case, sometime before gcc 4.5, the processing order of stringification/concatenation vs #include CHANGED in ways incompatible with the "component" macros, and it all stopped working :-(

Actually, the C preprocessor behaviors are fairly well defined in the C Standards. I don't know exactly how the COMPONENTS macro is defined and what the expectations were, but C clearly states that if the #include filename part isn't a double quote string or <> quoted, then it is macro-expanded, and the process of macro expansion will handle the stringizing and token pasting operators.

[legacy]

Code: [Select]

=======> opening file=[cavia/reset.h], module=[reset]
:: >0,[#ifndef]
:: >0,[_reset_]
:: >0,[#define]
:: >0,[_reset_]
:: >0,[#include]
:: >0,[types.h]
:: >0,[typedef]
:: >1,[union]
:: >2,[{]
brace_balance=1
:: >3,[struct]
:: >3,[{]
brace_balance=2
:: >1,[uint32_t]
:: >4,[xxeta]
:: >5,[;]
:: >3,[struct]
:: >3,[{]
brace_balance=3
:: >1,[sint32_t]
:: >4,[oota]
:: >5,[;]
:: >3,[}]
brace_balance=2
:: >4,[zzeta]
:: >5,[;]
:: >3,[}]
brace_balance=1
:: >4,[f_a1]
:: >5,[;]
:: >3,[struct]
:: >3,[{]
brace_balance=2
:: >1,[uint32_t]
:: >4,[yyellow]
:: >5,[;]
:: >3,[}]
brace_balance=1
:: >4,[f_b1]
:: >5,[;]
:: >3,[}]
brace_balance=0
:: >4,[my_reset_t]
########## new type ###########[my_reset_t]
:: >5,[;]
:: >0,[typedef]
:: >1,[my_reset_t]
needs my_reset_t
:: >4,[*]
:: >4,[p_my_reset_t]
########## new type ###########[p_my_reset_t]
:: >5,[;]
:: >0,[typedef]
:: >1,[device_handler_ans_t]
needs device_handler_ans_t
:: >4,[(]
:: >4,[*]
:: >4,[device_handler_DO_init_t]
########## new type ###########[device_handler_DO_init_t]
:: >5,[)]
:: >5,[(]
:: >5,[p_this_t]
:: >5,[p_this_A]
:: >5,[)]
:: >5,[;]
:: >0,[typedef]
:: >1,[device_handler_ans_t]
needs device_handler_ans_t
:: >4,[(]
:: >4,[*]
:: >4,[device_handler_DO_done_t]
########## new type ###########[device_handler_DO_done_t]
:: >5,[)]
:: >5,[(]
:: >5,[p_this_t]
:: >5,[p_this]
:: >5,[)]
:: >5,[;]
:: >0,[typedef]
:: >1,[device_handler_ans_t]
needs device_handler_ans_t
:: >4,[(]
:: >4,[*]
:: >4,[device_handler_DO_open_t]
########## new type ###########[device_handler_DO_open_t]
:: >5,[)]
:: >5,[(]
:: >5,[p_this_t]
:: >5,[p_this]
:: >5,[)]
:: >5,[;]
:: >0,[typedef]
:: >1,[device_handler_ans_t]
needs device_handler_ans_t
:: >4,[(]
:: >4,[*]
:: >4,[device_handler_DO_close_t]
########## new type ###########[device_handler_DO_close_t]
:: >5,[)]
:: >5,[(]
:: >5,[p_this_t]
:: >5,[p_this]
:: >5,[)]
:: >5,[;]
:: >0,[typedef]
:: >1,[device_handler_ans_t]
needs device_handler_ans_t
:: >4,[(]
:: >4,[*]
:: >4,[device_handler_DO_reset_t]
########## new type ###########[device_handler_DO_reset_t]
:: >5,[)]
:: >5,[(]
:: >5,[p_this_t]
:: >5,[p_this]
:: >5,[)]
:: >5,[;]
:: >0,[#include]
:: >0,[reset.interface]
:: >0,[#endif]
debug console, verbose mode

Code: [Select]

cat guineapig/reset.h
#ifndef _reset_
#define _reset_

#include "types.h"

typedef union
{
struct
    {
    uint32_t xxeta;
    struct
    {
sint32_t oota;
} zzeta;
} f_a1;
struct
    {
    uint32_t yyellow;
} f_b1;
} my_reset_t;

typedef my_reset_t* p_my_reset_t;

typedef device_handler_ans_t (*device_handler_DO_init_t)(p_this_t p_this_A);
typedef device_handler_ans_t (*device_handler_DO_done_t)(p_this_t p_this);
typedef device_handler_ans_t (*device_handler_DO_open_t)(p_this_t p_this);
typedef device_handler_ans_t (*device_handler_DO_close_t)(p_this_t p_this);
typedef device_handler_ans_t (*device_handler_DO_reset_t)(p_this_t p_this);


#include "reset.interface"

#endif
guinea-pig code, used as source to test the algorithm 

Code: [Select]

########## new type ###########[my_reset_t]
########## new type ###########[p_my_reset_t]
########## new type ###########[device_handler_DO_init_t]
########## new type ###########[device_handler_DO_done_t]
########## new type ###########[device_handler_DO_open_t]
########## new type ###########[device_handler_DO_close_t]
########## new type ###########[device_handler_DO_reset_t]
debug console, verbose mode, focusing on results (types identified)

little free time, but more progress: it's now able to correctly identify "types" (what comes defined by "typedef") in order to fill a giant sparse matrix of dependencies, so the tool has the complete vision of the inter-module dependencies, both interface dependencies (C prototypes) and types (typedef).

I just need to care about global public variables (extern), and constants (#define ...), but that at the current state of art, that tool is almost already working