question on const

[Mantorok Redgormor]

How wrong you are. Many cases of undefined behaviour are not detectable.
On the other hand, getting a program "lint free" could be a considerable
effort; even for programs that were completely portable.

Ensuring a program is lint free is impossible.
The following is an example:

[ -------- a.c ---------- ]
#include <stdio.h>

int main(void)
{
printf("Hello world\n");
return 0;
}
[ -------- a.c ---------- ]


splint -strict a.c
Splint 3.0.1.6 --- 26 Feb 2002

a.c: (in function main)
a.c:4:5: Called procedure printf may access file system state, but globals list
does not include globals fileSystem
A called function uses internal state, but the globals list for the function
being checked does not include internalState (Use -internalglobs to inhibit
warning)
a.c:4:5: Undocumented modification of file system state possible from call to
printf: printf("Hello world\n")
report undocumented file system modifications (applies to unspecified
functions if modnomods is set) (Use -modfilesys to inhibit warning)

Finished checking --- 2 code warnings


I am not even sure what is wrong with accessing the file system
or what in the world a "file system state" is.
The warning seems to be rather bizarre and I don't even
know if it is important.

 

[glen herrmannsfeldt]

Dik T. Winter wrote:

(snip)

How wrong you are. Many cases of undefined behaviour are not detectable.
On the other hand, getting a program "lint free" could be a considerable
effort; even for programs that were completely portable.

I suppose that was a little bit overdoing it. I meant it in the
context of possible compiler messages. I would not want a compiler
that generated the messages that lint does. It would be too hard
to find the real error messages.

That many lint messages are for constructs that may be valid, but
can be confusing, or that it is not possible to tell.

It might have been lint that gave the warning for the =- operator.
Maybe it still does.

-- glen

 

[Peter Shaggy Haywood]

Groovy hepcat user was jivin' on Thu, 8 Jan 2004 14:50:42 +0530 in
comp.lang.c.
question on const's a cool scene! Dig it!

#include stdio

Wrong. Should be this:

int main(void)
{
const int num = 100;
int *ip;

ip = (int *)&num;

Playing with fire!

*ip = 200;

I smell something burning. You just invoked undefined behaviour.
When you play with fire, you get burnt. What do you expect?

printf("value of num is %d(%d) \n", num, *ip);
}
Output:
value of num is 100(200)

I said it before and I'll say it again. What do you expect? You
caused undefined behaviour. Anything can happen. Stand back and watch
the nasal demons eat your hard drive.

The output says that *ip is changed and 'num' is unchanged. How is this
possible when both of them point to the same memory location? My wild guess

No, "both of them" do not "point to the same memory location. One
points to an object stored at a memory location, while the other is
that object and does not point.
And as for how it's possible, it's simple. The compiler determines
two things. First, it sees the const qualified definition of num, and
decides to do a simple optimisation by keeping its value in a
register. Realising that the value of this object can never change
(because it is const qualified), the resulting object code only has to
fetch its value once and keep this value in a register. And second,
the compiler determines that num must be an actual object stored in
memory someplace, because its address is taken. Now, combining these
two simple facts, the program updates the stored value of num when it
is accessed via the pointer, but the compiler still thinks num's value
cannot change, so it doesn't re-fetch this value. Thus, the old value
of num remains in the register that is being used to represent it.
When the values are used in the printf() call, the compiler fetches
the value of num from the register, as usual. But since the pointer
points at an actual location in memory, the value fetched via that
pointer is the new value that was previously stored via that pointer.

says that this trick is handled at the compiler level. Am I correct?

"Handled at the compiler level"? I have no idea what you mean by
this expression.

Even when the memory location is accessable and the contents changed the
'const integer' is unaffected.

Right.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[August Derleth]

You can get a much improved version of lint for you favorite unix flavor
here:

http://www.splint.org

It works damn well

It's available for Cygwin as well [e.g. windows users].

You don't even need Cygwin. There are native Windows builds. But it is
one of the packages you can choose to install with Cygwin, so this is an
easy way to get it (complete with documentation, I assume).

Getting it from the main site does indeed include a bundle of
documentation, if that's the correct way to parse that sentence.

I'd suggest using some caution with splint. It does catch many
legitimate
bugs, possible bugs and general "bad coding styles" but it also does
report
many things that are not invalid code. E.g.

void func(int *data)
{
if (data == NULL) { trap(); return; }
data[0] = 1;
}

Will report possible dereferencing of a NULL value [etc..]

Overall I agree with the suggestion.

It can definitely be overly paranoid (and sometimes blatantly stupid),
to the point where you get so much output that it's very difficult to
determine what is and is not cause for concern.

You don't need to be so diplomatic about things: It seems that plenty of
lint-like programs are downright /broken/ in some respects, and will
produce messages that indicate a less-than-complete knowledge of the
relevant Standards.

But I think you can also
enable and disable specific warnings, so with some effort you should be
able to come up with a reasonable set. This could be particularly nice
if your compiler's warnings leave something to be desired (as they often
do).

splint makes this particularly easy, in fact. Each error message comes
with three things: The short form (printed each time on messages that
are generated more than once), the long form (only printed once), and
the argument you can pass on the command line to splint to make it not
generate that warning at all (also only printed once). It's the only
reason I use splint instead of another lint, especially after a
discussion I had once here about the general intelligence of lint-like
programs.