The death of Gimpel Lint. Do you read your license agreements?

I have long been a fan of Gimpel Software LLC's Lint product for doing static analysis of my projects.

I was excited about buying the new "PC-lint PLUS" version, even with the price increase. That is until I actually read their license agreement.

First we need to take a step back and discuss license agreements. Do you actually read the license agreements before or after purchasing/licensing your software/firmware? You really should as you may find something you don't agree with, for example from my own license agreement:

"...General:

This License is the complete statement of the agreement between the parties on the subject matter, and merges and supersedes all other or prior understandings (no mater how conveyed), purchase orders, agreements and arrangements. This License shall be governed by the laws of the Commonwealth of Pennsylvania. Exclusive jurisdiction and venue for all matters relating to this License shall be in courts and fora located in the Commonwealth of Pennsylvania, and you consent to such jurisdiction and venue. You agree to grant The Designer-III Company, LLC a non-transferable option to claim, for now and forever more, your immortal Soul. Should The Designer-III Company, LLC. wish to exercise this option, you agree to surrender your immortal Soul, and any claim you may have on it, within five (5) working days of receiving written notification from The Designer-III Company, LLC, or one of its duly authorized minions. There are no third party beneficiaries of any promises, obligations or representations made by The Designer-III Company, LLC, herein. Any waiver by The Designer-III Company, LLC, of any violation of this License by you shall not constitute or contribute to a waiver of any other or future violation by you of the same provision, or any other provision, of this License.

...

As no one has ever commented on the binding agreement on their Soul I surmise that no one has ever actually read the text when they clicked 'Agree' on the installer.

Returning to Gimpel, as I read their license agreement, MANY times, it seemed to state that I must buy a copy of Lint for every project that I analyze with PC-lint PLUS.

To make this more tangible lets use the analogy of a contractor building a house. You generally expect the contractor to have their own fundamental tools such as a hammer.

Now according to the Gimpel license agreement, for every house (project) the contractor builds, the contractor (you or I) must buy a new hammer. At the completion of the house, the hammer is left with the customer whom contracted for the house to be built. That the customer has no use for a hammer or does not knows its correct and safe usage is irrelevant.

So if your build three houses, or projects, you must purchase three hammers (copies of PC-Lint PLUS).

When I raised this absurdity with Gimpel, in a length email exchange, they gave me the option of buying a reusable hammer (I can use PC-lint PLUS all I want for anything as a consultant working on software for a client for a limited time) at the cost of $9980! I must give credit to the lady in sales that I was working with, whom was sympathetic to my view. Alas management above her was not.

I feel like I have been selected for personal punishment by being honest, and following the rules of actually reading the license agreement. I'm sure most people don't and simply buy one hammer (PC-lint PLUS) and go on their way.

Gimpel's position is that it was a lot of work to update their Lint product to match modern C++ proclivities and they need to be paid for that time consuming hard-work. I expect to be paid for my work as well, so I can empathize with their position, yet not at all with their current solution.

What do you feel is a better solution?

Using PC-lint PLUS with Open Source code also appears to be a problem. Saying a change was made to remove Lint error #123456 or using a Lint suppression directive around a section of code is apparently not allowed.

Now to be compliant with "5. OWNERSHIP" I must state, if we actually pony up the nearly ten grand for this new version, to be compliant with the PC-lint PLUS license agreement:

"

...Whenever You make any formal (written, printed or oral) reference to PLUS, such representation shall be accompanied by a reference to Gimpel as the developer of PLUS. However, such reference shall not be represented as an endorsement by Gimpel.

You agree that You will not represent Gimpel as endorsing or making specific claims regarding your organization, your products or your services thereof without the express written permission of Gimpel.

..."

I'm sure as the intelligent person that you are, you know Gimpel is not endorsing this particularly blog entry or The Designer-III Company, LLC. Must be true to the license agreements do we not?

I really wish we could get the world to move on to functional languages like Elixir and leave C and C++ in the dustbin of history where they belong today.

Elixir is a dynamic, functional language designed for building scalable and maintainable applications. Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain.

Bug of the Month Ends

For the last ten years Gimpel Software has posted a short stand alone program with an obscure C bug in it, with the challenge to the reader to figure out the bug.

Gimpel does this to show off their static analyzer Lint, the nitpickyest of all programs, something that I use almost daily. Lint exposes bugs by looking at a project as a whole, with multi-pass value tracking, rather than just as a file at a time as most humans would. Lint also can test for compliance with various guidelines such as MISRA or The Barr Group's Embedded C Coding Standard.

You can even input your own bugs to test short snippets of code that you might come across. For example the abysmal "if( A==B==C )" found in some of Freescale's USB stack code (I'll save the rant on poor manufacture example code for an other time).

I always looked forward to the challenge of the Bug of the Month, sadly it has be discontinued in favor of a new blog (May not be operational until late summer). I really don't like how everyone thinks replacing something useful with something akin to 'Social Media' is a good thing, how about you?

Colleagues over the years have complained that Lint puts out to many warnings. That is usually the case of Linting legacy code. Error messages may be turned off in layers. Get rid of the ones that will crash the system first, followed by the ones that might, until you get down to none or the ones you are willing to live with. Also with people trying to turn serious development in to some kind of game, see Development has become the game. Whats your Potty Mouth Score today?, make Lint a game. Can you write code that will give no Lint errors today?

Frama-C to prove formal properties for critical software.

I just came across a project, which has been around for a couple of years, that looks like it could be very useful: Frama-C. Frama-C stands for Framework for Modular Analysis of C programs.

Frama-C is intended to be an extensible static analyzer, that can prove formal properties for critical software. Frama-C does static analysis, dead code removal, security checks, and other functions depending on which plug-ins are used.

Armand, one of the project participants, is working on implementing the MISRA-C 2004 rules for the static analyzer.

Trying out Frama-C: analyzing a simple C program.

Does Time Keeping become a safety issue during Leap Seconds in a Leap Year?

At the end of 2008 we had a unusual event of a double compound time leap. 2008 was both a Leap Year, and ended with a Leap Second.

Wikipedia covers how to calculate Leap Years quite well, so I will not duplicate what should be very well known rules of how to calculate leap years here. Sadly it seem programmers don't know these rules. After all as far back as 1886 Christian Zeller came up with Zeller's Congruence to calculate the day of the week, and he got it right without even knowing what a computer was.

The event that most are talking about today, are the locking up of Microsoft's Zune 30 gigabyte devices.

While most people are bashing Microsoft for the problem, the problem really lies in the i.MX31 Board Support Package from Freescale. After registering you can download the i.MX31: Multimedia Applications Processor Board Support Package (FSL-WCE500-14-BSP), with full source code.

The now infamous file rtc.c, as reported on may other Zune related web sites, may be found in WINCE500\PLATFORM\COMMON\SRC\ARM\FREESCALE\PMIC\MC13783\RTC. The lockup bug comes down to the error that there will never be 367 days in *any* year in the function ConvertDays:

 while (days > 365)

  {

    if (IsLeapYear(year))

   {

    if (days > 366)

     {

      days -= 366;

      year += 1;

     }

    }

   else

   {

     days -= 365;

     year += 1;

    }

  }

The line should have read "366 == days" or my preference "days >= 366". A simple Code Inspection should have caught a simple minded bug like this during a design review. We can only assume based on this code, and other questionable constructions in the same file (I did not look at other files), that no such inspections or reviews were done. It is also clear that they didn't even running something as inexpensive as Lint on their code. Doing so would have weeded out several of the non-executable paths that are present.

There have been Leap Second related crashes of various devices, beyond Zune related to Leap Seconds, such as some Linux Kernel Versions. So what I want to concentrate on is the Leap Second. A Leap Second may be inserted or removed to get the common UTC time standard in sync with the Earth's Rotation.

What is more insidious than rtc code above is that any product based on the MC13783 Power Management and Audio Circuit chip, as used in the crashing Zune's, is doomed from the start, because at the hardware level it is impossible to support Leap Seconds correctly. To be fair to Freescale most second counting clock chips have the same problem.

"4.1.2.2.1 Time and Day Counters

The real time clock runs from the 32 kHz clock. This clock is divided down to a 1 Hz time tick which drives a 17 bit time of day (TOD) counter. The TOD counter counts the seconds during a 24 hour period from 0 to 86,399 and will then roll over to 0. When the roll over occurs, it increments the 15-bit DAY counter. The DAY counter can count up to 32767 days..."

According to the National Institute of Standard and Technology on Radio Controled Clocks (page 27) a properly functioning clock would tick from 23:59:59 to 23:59:60, then to 00:00:00 during a Leap Second event. So a single day could have 86,400 seconds, counting zero.

A clock that that is not capable of display 23:59:60 would have two consecutive displays of 23:59:59.

Leap Seconds do not always add a second, they can also subtract a second, so a 'day' could correctly only have 86,398 seconds.

From a software perspective something like libtai that supports two time scales: (1) TAI64, covering a few hundred billion years with 1-second precision; (2) TAI64NA, covering the same period with 1-attosecond precision. Both scales are defined in terms of TAI, the current international real time standard, is worth considering. As long as the Leap Second tables are properly kept up to date, which presents problems of its own.

If you really want to dig into issues of Leap Seconds then check out the LEAPSECS -- Leap Second Discussion List. Also if you are in any way interested in the preciseness of time keeping then check out the Time Nuts Discussion List at the LeapSeconds site.

I am not aware of any loss of life, or loss of major income, due to any of the Leap Second problems that occurred this time. Will we be able to say the same for the next Leap Second that occurs?