Reply by Phil Hobbs February 10, 20182018-02-10
On 02/10/18 04:55, Clifford Heath wrote:
> On 09/02/18 19:17, David Brown wrote: >> On 08/02/18 18:58, Stefan Reuther wrote: >>> Am 07.02.2018 um 20:54 schrieb David Brown: >>>>> But having a C API (i.e. no inline functions), >>>> C has had inline functions for two decades. >>> Windows has existed for two-and-a-half... >> >> Yes, but the world has moved on since then, and the only reason MS did >> not gradually supersede the messiest parts of WinAPI with better >> versions from C99 (uint32_t instead of DWORD, inline instead of macros, >> etc.) is that they did not make a C99 compiler. > > Or any compiler, in fact. There were three C compilers for > 8086 at the time they bought one. The only two that were > any good told Microsoft to bugger off, so MS bought the > worst one available and proceeded to abuse it mercilessly, > thereby holding back the industry for decades and producing > mountains of unreliable rubbish that they foisted on their > unwilling victims. > > Clifford Heath
MSC 5.x was fairly horrible, but 6.00ax was pretty good, I thought. I used both the DOS and OS/2 versions pretty extensively BITD. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by Phil Hobbs February 10, 20182018-02-10
On 02/10/18 04:55, Clifford Heath wrote:
> On 09/02/18 19:17, David Brown wrote: >> On 08/02/18 18:58, Stefan Reuther wrote: >>> Am 07.02.2018 um 20:54 schrieb David Brown: >>>>> But having a C API (i.e. no inline functions), >>>> C has had inline functions for two decades. >>> Windows has existed for two-and-a-half... >> >> Yes, but the world has moved on since then, and the only reason MS did >> not gradually supersede the messiest parts of WinAPI with better >> versions from C99 (uint32_t instead of DWORD, inline instead of macros, >> etc.) is that they did not make a C99 compiler. > > Or any compiler, in fact. There were three C compilers for > 8086 at the time they bought one. The only two that were > any good told Microsoft to bugger off, so MS bought the > worst one available and proceeded to abuse it mercilessly, > thereby holding back the industry for decades and producing > mountains of unreliable rubbish that they foisted on their > unwilling victims. > > Clifford Heath
MSC 5.x was fairly horrible, but 6.00ax was pretty good, I thought. I used both the DOS and OS/2 versions pretty extensively BITD. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by Clifford Heath February 10, 20182018-02-10
On 09/02/18 19:17, David Brown wrote:
> On 08/02/18 18:58, Stefan Reuther wrote: >> Am 07.02.2018 um 20:54 schrieb David Brown: >>>> But having a C API (i.e. no inline functions), >>> C has had inline functions for two decades. >> Windows has existed for two-and-a-half... > > Yes, but the world has moved on since then, and the only reason MS did > not gradually supersede the messiest parts of WinAPI with better > versions from C99 (uint32_t instead of DWORD, inline instead of macros, > etc.) is that they did not make a C99 compiler.
Or any compiler, in fact. There were three C compilers for 8086 at the time they bought one. The only two that were any good told Microsoft to bugger off, so MS bought the worst one available and proceeded to abuse it mercilessly, thereby holding back the industry for decades and producing mountains of unreliable rubbish that they foisted on their unwilling victims. Clifford Heath
Reply by Clifford Heath February 10, 20182018-02-10
On 08/02/18 06:04, Stefan Reuther wrote:
> Am 06.02.2018 um 23:02 schrieb David Brown: >> On 06/02/18 19:05, Stefan Reuther wrote: >>> Problem is, we're actually doing C++, where MISRA imposes the same rules >>> for numbers, but would actually require us to write >>> >>> uint32_t MASK = static_cast<uint32_t>(1) << 17; >>> >>> which is pretty much noise for my taste. >> >> That's MISRA for you - rules for rules sake, no matter how ugly and >> incomprehensible your code ends up. In situations like this, it totally >> misses the point. > > Exactly. Now tell that the people who want cool downward pointing charts > on their PowerPoints to justify the money spent on the checker... > >>> I like to use this actual definition from Windows APIs as a "how not" >>> example for cast-addicts: >>> >>> #define MAKELONG(a, b) ((LONG) (((WORD) (((DWORD_PTR) (a)) & \ >>> 0xffff)) | ((DWORD) ((WORD) (((DWORD_PTR) (b)) & 0xffff))) << 16)) >> >> I doubt if anyone will hold up the Windows API as a shining example of >> good design and clear programming! > > Actually, the Windows API isn't too bad. The combination of rules that > built 16-bit Windows are borderline genius (e.g. how do you do virtual > memory on an 8086 that has not any hardware support for that?).
That part is a direct copy of the early Apple APIs.
Reply by David Brown February 9, 20182018-02-09
On 08/02/18 18:58, Stefan Reuther wrote:
> Am 07.02.2018 um 20:54 schrieb David Brown:
<snip, as it's getting way off topic>
> Everyone got their dark corners.
That is a fair summary!
> >>> But having a C API (i.e. no inline functions), >> >> C has had inline functions for two decades. > > Windows has existed for two-and-a-half...
Yes, but the world has moved on since then, and the only reason MS did not gradually supersede the messiest parts of WinAPI with better versions from C99 (uint32_t instead of DWORD, inline instead of macros, etc.) is that they did not make a C99 compiler. Some design choices you have to live with because a clean break is not possible, some you get stuck with because a clean break is too expensive, but some we live with because no one bothered to make the change.
> >>>> I have nothing against thinking! But I /do/ have something against >>>> having to write a deviation report in order to avoid a cast monstrosity >>>> just because the rules say that "1" is not an int. >>> >>> Exactly. >>> >>> (Just today had another discussion because Klocwork spit out new >>> warnings. One "remove this error handling because I think this error >>> does not occur", one "remove this variable initialisation because I >>> think this is a dead store", two "this variable isn't used [but I see it >>> being used the next line]". This surely justifies leaving everything >>> behind and pet the tool.) >> >> I have had more luck using gcc, and its increasingly more sophisticated >> static warnings. At least then I know the static error checking and the >> compiler agree with each other! > > In general, I agree, but unfortunately sometimes even gcc disappoints.
Yes, indeed - gcc and its static error checking is excellent, but very far from perfect.
> > Last two weeks' disappointments: '1 << 31' is not a warning although it > has unspecified behaviour.
Left shift 1 << 31 (with 32-bit ints) is undefined behaviour, not unspecified behaviour (there is a big difference) in the C standards. However, gcc treats some additional aspects of signed << as defined behaviour. Unfortunately, the documentation does not give the details, but it is reasonable to suppose that it treats this as two's complement shifting. Being undefined in the C standards does not preclude a compiler from having well-defined behaviour for the expression. (I'd have preferred a warning, personally. And the weak documentation here is definitely a flaw.)
> It accepts VLAs in C++ by default even with > '-std=c++11 -ansi', and requires '-pedantic' to notice it.
That is in accordance with the gcc documentation. "-ansi" merely selects the standard, and should arguably give an error when used with "-std=c++11" as "-ansi" is equivalent to "-std=c90" or "-std=c++98" depending on the language. It does not enable other diagnostics or disable gcc extensions - it picks the basic standards and disables any gcc extensions that conflict with them. Thus it tells the compiler that it needs to be able to compile all C90 or C++98 programs, even if you happen to have functions called "asm" or "typeof". It does /not/ tell the compiler to reject programs that are not standard-conforming C90 or C++98 programs. "-pedantic" tells the compiler to enable all diagnostics required by the standards. Note that this /still/ does not mean rejecting programs which use gcc extensions, or other code that does not have fully defined behaviour in the standards. It means providing diagnostics when the standards explicitly say so, even if gcc would normally give meaning to the code as an extension (such as using VLA's outside of C99/C11). So no bugs there - just some misunderstandings about the gcc flags. You are not the first person to make such mixups, so arguably the choice of flag names or the documentation could be better.
> > This makes it harder to convince QA people that just using gcc is enough. >
That can be true. But I think using any tool for QA requires a careful understanding of the tool and its options. I would not say that gcc is a good static analysis tool - I would say that gcc used appropriately with a careful choice of flags and warnings is a good static analysis tool. And I would say that about other tools too - /no/ static analysis tool I have looked at works as I would like it without careful choices of flags.
Reply by Stefan Reuther February 8, 20182018-02-08
Am 07.02.2018 um 20:54 schrieb David Brown:
> On 07/02/18 20:04, Stefan Reuther wrote: >>>> I like to use this actual definition from Windows APIs as a "how not" >>>> example for cast-addicts: >>>> >>>> #define MAKELONG(a, b) ((LONG) (((WORD) (((DWORD_PTR) (a)) & \ >>>> 0xffff)) | ((DWORD) ((WORD) (((DWORD_PTR) (b)) & 0xffff))) >>>> << 16)) >>> >>> I doubt if anyone will hold up the Windows API as a shining example of >>> good design and clear programming! >> >> Actually, the Windows API isn't too bad. The combination of rules that >> built 16-bit Windows are borderline genius (e.g. how do you do virtual >> memory on an 8086 that has not any hardware support for that?). The >> Win32 API has async I/O, wait for multiple semaphores, etc., all of >> which was bolted-on in Linux years later. > > That is not what I am talking about. There have been plenty of useful > (and some imaginative) features in Windows API, no doubts there. (The > async I/O functions needed to be in Windows because it was originally > pretty much single-tasking and single-threaded. Linux didn't have > nearly as much need of it because you could quickly and cheaply create > new processes, and because of the "select" call. Async I/O was > essential to Windows, and merely "nice to have" on other systems.)
Being able to create processes does not help if you actually need threads to be able to efficiently communicate, e.g. between a GUI thread and a background thread. 'select' does not allow you to wait on semaphores, meaning you have to emulate this with a self-pipe. Now that we have 'eventfd' and native threads - bolted-on years later - it starts to make sense somehow.
> The mess of Windows API is the 16 different calling conventions, the > 23.5 different non-standard types duplicating existing functionality > (while still impressively managing to mix up "long" and pointers, > leading to it being the only 64-bit system with 32-bit "long"), function > calls with the same name doing significantly different things in > different versions of the OS (compare Win32s, Win9x and WinNT APIs), and > beauties such as the "CreateFile" call that could handle every kind of > resource except files.
This sounds vastly exaggerated. I haven't tried Win32s, but so far the only difference between Win9x and WinNT APIs was an occasional error return in wrong format, INVALID_HANDLE instead of NULL or something like that. POSIX APIs give you beauties such as 'int' vs 'socklen_t', I/O functions that take a 'size_t' size but return a 'ssize_t' result, error codes such as EINTR, the whole mess of 'lseek'/'lseek64' and 'off_t'/'off64_t'. Everyone got their dark corners.
>> But having a C API (i.e. no inline functions), > > C has had inline functions for two decades.
Windows has existed for two-and-a-half...
>>> I have nothing against thinking! But I /do/ have something against >>> having to write a deviation report in order to avoid a cast monstrosity >>> just because the rules say that "1" is not an int. >> >> Exactly. >> >> (Just today had another discussion because Klocwork spit out new >> warnings. One "remove this error handling because I think this error >> does not occur", one "remove this variable initialisation because I >> think this is a dead store", two "this variable isn't used [but I see it >> being used the next line]". This surely justifies leaving everything >> behind and pet the tool.) > > I have had more luck using gcc, and its increasingly more sophisticated > static warnings. At least then I know the static error checking and the > compiler agree with each other!
In general, I agree, but unfortunately sometimes even gcc disappoints. Last two weeks' disappointments: '1 << 31' is not a warning although it has unspecified behaviour. It accepts VLAs in C++ by default even with '-std=c++11 -ansi', and requires '-pedantic' to notice it. This makes it harder to convince QA people that just using gcc is enough. Stefan
Reply by David Brown February 8, 20182018-02-08
On 08/02/18 00:57, Hans-Bernhard Br&#4294967295;ker wrote:
> Am 07.02.2018 um 09:21 schrieb David Brown: > >> I have seen bugs in a certain massively popular, expensive but nameless >> (to protect the guilty) 8051 compiler in the way it handled integer >> promotions. > > I'm quite sure I'm talking about that very same compiler when I say: no, > those weren't bugs. They were the amply documented effect of that > compiler being run in an explicitly _not_ standard compliant setting. >
That is entirely possible. As I say, it was a colleague that asked for help, wondering if his C code was wrong. The C was correct, the compiler was generating object code that did not match the C. But it could well have been as you say, and the compiler was running in a significantly non-standard mode.
>> I don't remember the details (it was a colleague that used >> the tool), but it is conceivable that the compiler was running in some >> sort of "MISRA mode" with different semantics for types than standard C. > > No. It was running in a "let's not even pretend this micro is actually > big enough to efficiently implement C without seriously breaking a large > fraction of the rules" mode. > > Many, maybe all the C compilers for small 8-bitters have such a mode, > and often that's their default mode because, frankly, the > standard-conforming mode would be nearly useless for most serious work. > OTOH, those micros, and the projects they're used in, are generally > small enough that you don't really have to go all MISRA on them.
Certainly there are some things that standard C requires that would be very painful for handling in these brain-dead devices. A prime example is re-entrant or recursive functions. Without a decent data stack (and, in particular, SP+x addressing modes), it is very inefficient to have local variables in a stack on things like an 8051. So most compilers for these kinds of chips will put the local variables at fixed addresses in ram. Functions cannot then be used recursively. However, dealing with this efficiently does not need a change to the language supported - the compiler can analyse the source code and call paths, see that all or most functions are /not/ used recursively, and generate code taking advantage of that fact. The lazy way to handle it is to say that any recursive functions need to be specially marked (with a pragma, attribute, or whatever). This will be used so rarely in such code that it is not a problem. In the case I had seen here, I think (IIRC) the problem was that the compiler was doing arithmetic on 8-bit types as 8-bit arithmetic - it was not promoting it to 16-bit ints. IMHO there is no justification for this non-standard behaviour. It is simple enough for the compiler to give the correct C logical behaviour while optimising to 8-bit generated code in cases where the high byte is not needed. I have no problem with compilers requiring the use of extensions or extra features to get good code from these devices. Having a "flash" keyword, or distinguishing between short and long pointers - that's fine. Making "double" the same as "float" - less fine, but understandable. But changing the rules for integer promotions and the usual arithmetic conversions? No, that is not appropriate. Other "helpful" ideas I have seen on compilers that I consider broken are to skip the zeroing of uninitialised file-scope data (and hide a tiny note about it deep within the manual), and to make "const" work as a kind of "flash" keyword on a Harvard architecture cpu so that "const char *" and "char *" become completely incompatible.
Reply by Hans-Bernhard Bröker February 7, 20182018-02-07
Am 07.02.2018 um 09:21 schrieb David Brown:

> I have seen bugs in a certain massively popular, expensive but nameless > (to protect the guilty) 8051 compiler in the way it handled integer > promotions.
I'm quite sure I'm talking about that very same compiler when I say: no, those weren't bugs. They were the amply documented effect of that compiler being run in an explicitly _not_ standard compliant setting.
> I don't remember the details (it was a colleague that used > the tool), but it is conceivable that the compiler was running in some > sort of "MISRA mode" with different semantics for types than standard C.
No. It was running in a "let's not even pretend this micro is actually big enough to efficiently implement C without seriously breaking a large fraction of the rules" mode. Many, maybe all the C compilers for small 8-bitters have such a mode, and often that's their default mode because, frankly, the standard-conforming mode would be nearly useless for most serious work. OTOH, those micros, and the projects they're used in, are generally small enough that you don't really have to go all MISRA on them.
Reply by David Brown February 7, 20182018-02-07
On 07/02/18 20:04, Stefan Reuther wrote:
> Am 06.02.2018 um 23:02 schrieb David Brown: >> On 06/02/18 19:05, Stefan Reuther wrote: >>> Problem is, we're actually doing C++, where MISRA imposes the same rules >>> for numbers, but would actually require us to write >>> >>> uint32_t MASK = static_cast<uint32_t>(1) << 17; >>> >>> which is pretty much noise for my taste. >> >> That's MISRA for you - rules for rules sake, no matter how ugly and >> incomprehensible your code ends up. In situations like this, it totally >> misses the point. > > Exactly. Now tell that the people who want cool downward pointing charts > on their PowerPoints to justify the money spent on the checker... > >>> I like to use this actual definition from Windows APIs as a "how not" >>> example for cast-addicts: >>> >>> #define MAKELONG(a, b) ((LONG) (((WORD) (((DWORD_PTR) (a)) & \ >>> 0xffff)) | ((DWORD) ((WORD) (((DWORD_PTR) (b)) & 0xffff))) << 16)) >> >> I doubt if anyone will hold up the Windows API as a shining example of >> good design and clear programming! > > Actually, the Windows API isn't too bad. The combination of rules that > built 16-bit Windows are borderline genius (e.g. how do you do virtual > memory on an 8086 that has not any hardware support for that?). The > Win32 API has async I/O, wait for multiple semaphores, etc., all of > which was bolted-on in Linux years later.
That is not what I am talking about. There have been plenty of useful (and some imaginative) features in Windows API, no doubts there. (The async I/O functions needed to be in Windows because it was originally pretty much single-tasking and single-threaded. Linux didn't have nearly as much need of it because you could quickly and cheaply create new processes, and because of the "select" call. Async I/O was essential to Windows, and merely "nice to have" on other systems.) The mess of Windows API is the 16 different calling conventions, the 23.5 different non-standard types duplicating existing functionality (while still impressively managing to mix up "long" and pointers, leading to it being the only 64-bit system with 32-bit "long"), function calls with the same name doing significantly different things in different versions of the OS (compare Win32s, Win9x and WinNT APIs), and beauties such as the "CreateFile" call that could handle every kind of resource except files.
> > But having a C API (i.e. no inline functions),
C has had inline functions for two decades. The lack of inline functions in the Windows C world is purely a matter of laziness on MS's part in not providing C99 support in their tools. It is an absurd and unjustifiable gap.
> and evolving that through > years, will lead to monstrosities like the above. I would have written > > inline LONG makeLong(WORD a, WORD b) { return ((LONG)a << 16) | b; } > > and leave the truncating to the compiler.
However it is written, there should be no pointer types in there! But yes, there are entirely understandable "historical reasons" for at least some of the baggage in the WinAPI. The design started out as a complete mess from an overgrown toy system rushed to the market without thought other than to cause trouble for competitors. The Windows and API design has been a lot better, and lot more professional, since the days of NT - but it takes a long time to deal with the leftovers. There has never been a possibility of clearing out the bad parts and starting again.
> >>>>>> In MISRA C, the literal 1 is a char not an int? >>>>> >>>>> Yes. >>>> >>>> No. You are mixing MISRA rules with language rules. >>>> >>>> MISRA provides rules on how to write C - it most certainly does not >>>> /change/ C. In C, the literal 1 is an decimal integer constant of type >>>> "int" (section 6.4.1.1). >>>> >>>> As a coding standard, MISRA /can/ have rules to say that you are not >>>> allowed to /use/ a literal here - but it cannot change its meaning in >>>> the language. >>> >>> MISRA defines a subset of C, and a program must follow the rules of that >>> subset. Of course that can be an own type system. >> >> No, it cannot - it /has/ to use the C type system when you are >> programming in C. > > Not as long as its own type system defines a subset. A coding standard > cannot define a '+' operator that adds two strings. But it can surely > say "although the C standard allows you to add an 8-bit unsigned and a > 16-bit signed to get 32-bit signed, I won't allow that".
Yes, that's true. But what it /cannot/ do is say that if you add an 8-bit signed and a 16-bit signed you will get a 16-bit signed (on a 32-bit system). It can't change the rules of C, or the way the types work - all it can do is add extra restrictions.
> >>> The most important takeaways I have from MISRA is: think about what you >>> do and why you do it, and: you need a deviation procedure that allows >>> you to break every rule. That deviation procedure is what makes MISRA >>> work because it rules out laziness as a reason for not doing something. >>> I won't write a deviation request to be allowed to leave out the {}'s, >>> but if my design requires me to have malloc and recursion, I want to >>> have that! >> >> I have nothing against thinking! But I /do/ have something against >> having to write a deviation report in order to avoid a cast monstrosity >> just because the rules say that "1" is not an int. > > Exactly. > > (Just today had another discussion because Klocwork spit out new > warnings. One "remove this error handling because I think this error > does not occur", one "remove this variable initialisation because I > think this is a dead store", two "this variable isn't used [but I see it > being used the next line]". This surely justifies leaving everything > behind and pet the tool.) >
I have had more luck using gcc, and its increasingly more sophisticated static warnings. At least then I know the static error checking and the compiler agree with each other!
Reply by Stefan Reuther February 7, 20182018-02-07
Am 06.02.2018 um 23:02 schrieb David Brown:
> On 06/02/18 19:05, Stefan Reuther wrote: >> Problem is, we're actually doing C++, where MISRA imposes the same rules >> for numbers, but would actually require us to write >> >> uint32_t MASK = static_cast<uint32_t>(1) << 17; >> >> which is pretty much noise for my taste. > > That's MISRA for you - rules for rules sake, no matter how ugly and > incomprehensible your code ends up. In situations like this, it totally > misses the point.
Exactly. Now tell that the people who want cool downward pointing charts on their PowerPoints to justify the money spent on the checker...
>> I like to use this actual definition from Windows APIs as a "how not" >> example for cast-addicts: >> >> #define MAKELONG(a, b) ((LONG) (((WORD) (((DWORD_PTR) (a)) & \ >> 0xffff)) | ((DWORD) ((WORD) (((DWORD_PTR) (b)) & 0xffff))) << 16)) > > I doubt if anyone will hold up the Windows API as a shining example of > good design and clear programming!
Actually, the Windows API isn't too bad. The combination of rules that built 16-bit Windows are borderline genius (e.g. how do you do virtual memory on an 8086 that has not any hardware support for that?). The Win32 API has async I/O, wait for multiple semaphores, etc., all of which was bolted-on in Linux years later. But having a C API (i.e. no inline functions), and evolving that through years, will lead to monstrosities like the above. I would have written inline LONG makeLong(WORD a, WORD b) { return ((LONG)a << 16) | b; } and leave the truncating to the compiler.
>>>>> In MISRA C, the literal 1 is a char not an int? >>>> >>>> Yes. >>> >>> No. You are mixing MISRA rules with language rules. >>> >>> MISRA provides rules on how to write C - it most certainly does not >>> /change/ C. In C, the literal 1 is an decimal integer constant of type >>> "int" (section 6.4.1.1). >>> >>> As a coding standard, MISRA /can/ have rules to say that you are not >>> allowed to /use/ a literal here - but it cannot change its meaning in >>> the language. >> >> MISRA defines a subset of C, and a program must follow the rules of that >> subset. Of course that can be an own type system. > > No, it cannot - it /has/ to use the C type system when you are > programming in C.
Not as long as its own type system defines a subset. A coding standard cannot define a '+' operator that adds two strings. But it can surely say "although the C standard allows you to add an 8-bit unsigned and a 16-bit signed to get 32-bit signed, I won't allow that".
>> The most important takeaways I have from MISRA is: think about what you >> do and why you do it, and: you need a deviation procedure that allows >> you to break every rule. That deviation procedure is what makes MISRA >> work because it rules out laziness as a reason for not doing something. >> I won't write a deviation request to be allowed to leave out the {}'s, >> but if my design requires me to have malloc and recursion, I want to >> have that! > > I have nothing against thinking! But I /do/ have something against > having to write a deviation report in order to avoid a cast monstrosity > just because the rules say that "1" is not an int.
Exactly. (Just today had another discussion because Klocwork spit out new warnings. One "remove this error handling because I think this error does not occur", one "remove this variable initialisation because I think this is a dead store", two "this variable isn't used [but I see it being used the next line]". This surely justifies leaving everything behind and pet the tool.) Stefan