"Grant Edwards" <grante@visi.com> wrote in message
news:41a3e059$0$85085$a1866201@visi.com...
> On 2004-11-24, Dave Hansen <iddw@hotmail.com> wrote:
>
> I'm also alergic to node-locked stuff.  I've been burned too
> many times when a motherboard, disk drive, or whatnot died and
> I had to cough up a pile of cash for the privledge of running a
> program I already paid for once.
>

If the company even exists by the time that happens!

It's too bad there's not a law requiring companies discontinuing software
known to be in current use to place it in the public domain...

Rufus

jpetrang@harris.com (JeanneP) wrote:

[PC-Lint vs. splint]

>Has anyone been so dissatisfied with splint that they switched to 
>PC Lint, and did PC Lint solve the problem(s) that caused the 
>dissatisfaction?

Yes, me. Splint has (had?) problems with some non-ANSI (legacy)
"extensions" of embedded compilers. Look at the Splint mailing list
archive or search for my posting here dated 2003-05-17, Message-ID
<3ec5f992.373447@z1.oliverbetz.de>.

And the already mentioned problems when assigning literals to U8 are
really annoying in embedded environments where this happens often.

Oliver
-- 
Oliver Betz, Muenchen (oliverbetz.de)

On Wed, 24 Nov 2004 18:06:52 +0000, "Paul E. Bennett"
<peb@amleth.demon.co.uk> wrote:
>Sounds like you may also benefit from installing a decent version control 

Check out subversion: http://subversion.tigris.org/

(And it's free.)


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list

JeanneP wrote:

> I'm asking because we have code that's shared across multiple projects.
> When you check in a file that is used by another project, that project
> gets updated too. The advanages are that everyone gets to benefit from
> the updates right away, but the downsides are that what works in one
> project may break another. Maybe someone used a #defined value from a
> non-shared file in a shared file, or something similar. Folks usually
> don't bother building all of the other projects that share their file
> before checking in code, due to looming deadlines on their own projects.
> They usually get away with it, but it sure can be a headache when you
> have to make sure updating your sandbox won't cause a break before you
> actually update it.  It's impractical to ask people to always check
> every affected build before checking in updates, because it would take
> several hours to build every flavor of every project, during which time
> there may have been more updates. Of course we have an automated builder
> so it doesn't get out of control. But, if lint is fast enough, people
> could lint the other projects before checking in their code.
 
Sounds like you may also benefit from installing a decent version control 
system with sand-boxing capabilities. That way you would not affect the 
other projects in a haphazard way. They could get to benefit from updates 
of the common source tree when they were good and ready for it.


-- 
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

On Wed, 24 Nov 2004 16:41:31 +0000, Rich Walker <rw@shadow.org.uk>
wrote:

>iddw@hotmail.com (Dave Hansen) writes:
[...]
>> The only restriction of that type I see in the "workstation" license
>> is that it forbids you to access the program through a network.  If
>> your mobo, hard drive, or whatever failed, I expect you could replace
>> any part or all of the system and legally continue to use the program
>> under the terms of the license.  But, of course, IANAL.  You could ask
>> Gimpel if you have any questions.  IME, they're very reasonable to
>> deal with.
>
>So I actually have to be physically logged-in to that very machine with
>my keyboard, mouse and monitor connected to it?

It doesn't say that.

>     I can't use an
>X-Terminal with it? 

It doesn't say that either.


>     If /usr is mounted from a remote machine, I can't
>use it? 

If FlexeLint is installed under /usr, I believe it does say that.

>     What kind of maroon thinks up these things...

Just an average Joe (or above-average Jim) trying to make a living, I
guess.  I expect the FlexeLint licensing policies are costing Gimpel
customers.  I'm beginning to think it's not costing him any profits,
however...

[...]

>>>Cranking up the warnings on gcc does a fair job.
>>
>> Compilers are much better at this than they were when I began using
>> PC-lint.  But they still don't come close.
>
>CFLAGS :=  -D__USE_GNU=1 -D__USE_MISC=1 -D__USE_BSD=1 -D_GNU_SOURCE=1 -O -Wall -W -DNDEBUG
>CFLAGS +=  -Wcast-align -Wpointer-arith -Wbad-function-cast -Wsign-compare
>CFLAGS +=  -Wno-unused -Wundef  -Wmissing-noreturn -Wmissing-format-attribute 
>
>does pretty well for me.

Probably fair, as Grant said.

>
>Mind you, I have a .splintrc in every directory as well - typical
>contents:

[...]

I don't know much about splint, so this didn't mean much to me.  The
project.lnt file for the project I'm current working on looks like
this:

--- begin included file ---
// Compiler definitions
//
c:\lint\lnt\co-gnu3.lnt         // 2.95.3 and later
-si2                            // Change int and ptr sizes for AVR
-sp2

//c:\lint\lnt\au-misra.lnt        // MISRA checking

// Header file locations
//
-i"C:\WinAVR\avr\include"
-i"C:\WinAVR\lib\gcc\avr\3.4.1\include"

// Project definitions
//
-d__AVR_ATmega16__          // Compiler does this from MCU definition
-dOSC_FREQ=12000000         // Make file derives this from HZ
-dDBUG=0
-dHIGH_CAP=0
-dDISABLE_VBATT_TEST=0

// Error reporting suspension
//
// Some GNU macros return a value from bracketed expressions.
//
-emacro(155,__LPM*)

// Interrupt vectors must be extern but aren't referenced
//
-esym(714,__vector_*)
-esym(765,__vector_*)

// Global macros in header files might not all be used
// Global typedefs might not all be used
//
-esym(755,EE_*,IO_*,ADC_*,ADCSR_*)
-esym(756,S8,U8,S16,U16,S32,U32)

--- end included file ---

The options probably do what you expect.  The -esym options disable a
message for particular symbols, and -emacro disables the message
during the invocation of the specified macros.  

For example, I have a header file that defines typedefs for S8, U8,
etc.  Nowhere in this project do I have a signed 32-bit integer.
Without the last line in the file shown above, I'd get a message 756
(global typedef not referenced) message for S32.  

I don't have the MISRA checking options enabled (yet -- they're
commented out).  We're at the prototype stage at this point.

>(Running splint against kernel sources is ... interesting)

The subtitle of Chapter 14 (Living with Lint) of the PC-lint/FlexeLint
manual is "Don't Kill the Messenger."

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On 24 Nov 2004 16:14:42 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2004-11-24, Dave Hansen <iddw@hotmail.com> wrote:
>
[...]
>> The only restriction of that type I see in the "workstation"
>> license is that it forbids you to access the program through a
>> network.
>
>That's ridiculous.  I can't ssh in from home and work?  I can't
>work with an X window displayed on a different machine?

Again, IANAL, but I believe you can.  You are still the only user, and
you are running the program on that one workstation, and that
workstation isn't accessing the program over a network.  The license
doesn't say you are limited to a single keyboard or display.  As long
as you don't try to run the software on your local machine...  

>
>Bah.  Somebody should drag Gimpel into the 1990's.

Well, they do have floating licenses, with the cost delta for
additional simultaneous users at or below the cost for a single
workstation license.  Of course, those have an even higher entry
point, and are limited to a LAN...

None of which explains why the cost of licensing FlexeLint is so much
greater than PC-lint.  My best guess is that support costs might be
higher because of the distribution method.

But even at 4x the cost, that just means it takes a month to pay for
itself rather than a week.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

iddw@hotmail.com (Dave Hansen) writes:

[snip]
> I think you're reading too much into the phrase "non-floating," or
> maybe "A single user on a computer workstation."  AFAIK, there is no
> software licensing management for FlexeLint (there certainly is none
> for PC-lint).
>
> The only restriction of that type I see in the "workstation" license
> is that it forbids you to access the program through a network.  If
> your mobo, hard drive, or whatever failed, I expect you could replace
> any part or all of the system and legally continue to use the program
> under the terms of the license.  But, of course, IANAL.  You could ask
> Gimpel if you have any questions.  IME, they're very reasonable to
> deal with.

So I actually have to be physically logged-in to that very machine with
my keyboard, mouse and monitor connected to it? I can't use an
X-Terminal with it? If /usr is mounted from a remote machine, I can't
use it? What kind of maroon thinks up these things...

>
>>
>>> Note, however, the Windoze version includes DOS and OS/2
>>> binaries, and the Win32 version is a console app.  I have seen
>>> speculation it could run in DOSEMU or wine or something
>>> similar.
>>
>>Probably so.  I'm sure it would run under Win4Lin, but it's a
>>lot of hassle either way and exceeds my pain threshold.
>
> In at least one sense you're right.  If you can't be bothered to run
> lint, it won't do you any good.  But IMHO, the greater pain is trying
> to work _without_ lint.
>
>>Cranking up the warnings on gcc does a fair job.
>
> Compilers are much better at this than they were when I began using
> PC-lint.  But they still don't come close.

CFLAGS :=  -D__USE_GNU=1 -D__USE_MISC=1 -D__USE_BSD=1 -D_GNU_SOURCE=1 -O -Wall -W -DNDEBUG
CFLAGS +=  -Wcast-align -Wpointer-arith -Wbad-function-cast -Wsign-compare
CFLAGS +=  -Wno-unused -Wundef  -Wmissing-noreturn -Wmissing-format-attribute 

does pretty well for me.

Mind you, I have a .splintrc in every directory as well - typical
contents:

-I/usr/src/linux/include/ -I/usr/src/rtai/include/ -I/usr/lib/gcc-lib/i386-linux/3.2.3/include/ -I/usr/include 

-realcompare
-predboolint 
-boolops
-exportlocal
-fcnuse
-exitarg
-booltype bool
-fullinitblock
+charindex 
+charint
-formattype
-castfcnptr
-shiftimplementation

-Dsizeof(x)=(size_t)(sizeof(x))
-D_GNU_SOURCE=1
-D__GNUC__=3
-D__GNUC_MINOR__=2
-D__STDC__
-D__signed__=
-D__const__=const
-D__inline__=inline
-D__attribute__(x)=
-D__const=const
-D__restrict=
-DKERNEL
-D__builtin_va_list=int

(Running splint against kernel sources is ... interesting)

cheers, Rich.

-- 
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

On 2004-11-24, Dave Hansen <iddw@hotmail.com> wrote:

>>I'm also alergic to node-locked stuff.  I've been burned too
>>many times when a motherboard, disk drive, or whatnot died and
>>I had to cough up a pile of cash for the privledge of running a
>>program I already paid for once.
>
> I think you're reading too much into the phrase
> "non-floating," or maybe "A single user on a computer
> workstation." AFAIK, there is no software licensing management
> for FlexeLint (there certainly is none for PC-lint).
>
> The only restriction of that type I see in the "workstation"
> license is that it forbids you to access the program through a
> network.

That's ridiculous.  I can't ssh in from home and work?  I can't
work with an X window displayed on a different machine?

Bah.  Somebody should drag Gimpel into the 1990's.

> If your mobo, hard drive, or whatever failed, I expect you
> could replace any part or all of the system and legally
> continue to use the program under the terms of the license.
> But, of course, IANAL.  You could ask Gimpel if you have any
> questions.  IME, they're very reasonable to deal with.

Except for the pricing and license terms, apparently.

-- 
Grant Edwards                   grante             Yow!  I was in a HOT
                                  at               TUB! I was NORMAL! I was
                               visi.com            ITALIAN!! I enjoyed th'
                                                   EARTHQUAKE!

On 24 Nov 2004 01:14:01 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2004-11-24, Dave Hansen <iddw@hotmail.com> wrote:
>
[...]
>> though I have never understood their FlexeLint pricing, even
>> if it is distributed in source form.
>
>The fact that it's in obfuscated source files doesn't increase
>the value to the customer, so why should the price be higher?

Exactly my point.  Which is why I don't understand it.

[...]

>I'm also alergic to node-locked stuff.  I've been burned too
>many times when a motherboard, disk drive, or whatnot died and
>I had to cough up a pile of cash for the privledge of running a
>program I already paid for once.

I think you're reading too much into the phrase "non-floating," or
maybe "A single user on a computer workstation."  AFAIK, there is no
software licensing management for FlexeLint (there certainly is none
for PC-lint).

The only restriction of that type I see in the "workstation" license
is that it forbids you to access the program through a network.  If
your mobo, hard drive, or whatever failed, I expect you could replace
any part or all of the system and legally continue to use the program
under the terms of the license.  But, of course, IANAL.  You could ask
Gimpel if you have any questions.  IME, they're very reasonable to
deal with.

>
>> Note, however, the Windoze version includes DOS and OS/2
>> binaries, and the Win32 version is a console app.  I have seen
>> speculation it could run in DOSEMU or wine or something
>> similar.
>
>Probably so.  I'm sure it would run under Win4Lin, but it's a
>lot of hassle either way and exceeds my pain threshold.

In at least one sense you're right.  If you can't be bothered to run
lint, it won't do you any good.  But IMHO, the greater pain is trying
to work _without_ lint.

>Cranking up the warnings on gcc does a fair job.

Compilers are much better at this than they were when I began using
PC-lint.  But they still don't come close.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On 24 Nov 2004 07:08:44 -0800, jpetrang@harris.com (JeanneP) wrote:

[...]
>
>I have another question for those who use either tool; how the speed of
>a lint run compare to building your code? Is it faster? Slower? How
>much?

Lint is _much_ faster.  It's often so quick that my knee-jerk reaction
is "Oops, what went wrong?... Oh, it's just done."

The current project I'm working on is fairly small.  About 6k of code
using avr-gcc.  Consisting of 7 .c and 7 .h files totaling about 112k
of code on the disk.  Building and linking the object files using make
takes about 3 seconds (2.77 according to the system clock) on my
system.  Linting everything with "make lint" takes less than a second
(0.36 seconds, identical to performing a make with an up-to-date
build).  Removing make from the equation and linting everything from
the command line takes even less time (0.16 seconds).  These are crude
timings, performed by running batch files that look something like:

   time < nul
   make
   time < nul

PC-lint has the ability to create "lint object" files so you only have
to lint what actually has changed.  But IME linting an entire project
takes so little time that it's not been worthwhile to use them.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.