By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,617 Members | 1,605 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,617 IT Pros & Developers. It's quick & easy.

Lint doesn't catch signed => unsigned arg passing

P: n/a
Hi,

I have a little program as follows :

=================== STARTS HERE ================
#include <stdio.h>

void f (unsigned long);
int main()
{
short s=0x7FFF; /* == 32767 */

/* == 0x8000 == 32768 (in unsigned) == -32768 (in
signed) */
s++;
/* passing signed short to f(), which expects unsigned long */
f(s);

return (0);
}

void f(unsigned long l)
{
/* note the huge value passed here */
printf ("value is unsigned long = (%lu), hexadecimal =
(0x%lX)\n",
l, l);
}

=================== ENDS HERE ================

(FYI : I am using Solaris Workshop 6.2 on Solaris 8).

Running the above program (compiled with -xarch=v9 option -- for
64-bit), gives me following result (which I guess, expected) :
--------
value is unsigned long = (18446744073709518848), hexadecimal =
(0xFFFFFFFFFFFF8000)
--------

If I run lint to catch such mismatch datatype, I cann't see any
complains from lint :-( ...

lint -errchk=%all a.c (note, %all includes sizematch see
http://docs.sun.com/db/doc/805-4952/6j4mdcehi?a=view), gives me
following output :
-------
function returns value which is always ignored
printf

declared global, could be static
f a.c(19)
-------

My question is : Is there any way that I can catch such wrong
mismatchs in datatypes (-errchk=sizematch does catch if I pass
unsigned to signed, but not the other way)?

Thanks a lot!
RMD.
Nov 14 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On 23 Feb 2004 12:42:40 -0800, mr****@hotmail.com (Rahul) wrote in
comp.lang.c:
Hi,

I have a little program as follows :

=================== STARTS HERE ================
#include <stdio.h>

void f (unsigned long);
int main()
{
short s=0x7FFF; /* == 32767 */

/* == 0x8000 == 32768 (in unsigned) == -32768 (in
signed) */
s++;
Assuming that short is 16 bits, your program generates undefined
behavior at the line above. I am surprised your lint doesn't catch
that.
/* passing signed short to f(), which expects unsigned long */
f(s);
There is no problem with passing a signed short to a function that
takes an unsigned long parameter. There is an automatic promotion,
and the conversion cannot overflow even if the value is negative.
return (0);
}

void f(unsigned long l)
{
/* note the huge value passed here */
printf ("value is unsigned long = (%lu), hexadecimal =
(0x%lX)\n",
l, l);
}

=================== ENDS HERE ================

(FYI : I am using Solaris Workshop 6.2 on Solaris 8).

Running the above program (compiled with -xarch=v9 option -- for
64-bit), gives me following result (which I guess, expected) :
--------
value is unsigned long = (18446744073709518848), hexadecimal =
(0xFFFFFFFFFFFF8000)
--------

If I run lint to catch such mismatch datatype, I cann't see any
complains from lint :-( ...

lint -errchk=%all a.c (note, %all includes sizematch see
http://docs.sun.com/db/doc/805-4952/6j4mdcehi?a=view), gives me
following output :
-------
function returns value which is always ignored
printf

declared global, could be static
f a.c(19)
-------

My question is : Is there any way that I can catch such wrong
mismatchs in datatypes (-errchk=sizematch does catch if I pass
unsigned to signed, but not the other way)?

Thanks a lot!
RMD.


As to why your version of lint does not do what you want, you had
better check with your lint vendor or try a Solaris group.

Lint is not defined or specified by the C language standard, making it
off-topic here. Furthermore, there is not one lint, but many, and
only the vendors decide how each one operates.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #2

P: n/a
Groovy hepcat Rahul was jivin' on 23 Feb 2004 12:42:40 -0800 in
comp.lang.c.
Lint doesn't catch signed => unsigned arg passing's a cool scene! Dig
it!
#include <stdio.h>

void f (unsigned long);
int main()
{
short s=0x7FFF; /* == 32767 */

/* == 0x8000 == 32768 (in unsigned) == -32768 (in
signed) */
s++;
You may have just invoked undefined behaviour by overflowing a
signed integral type. If SHRT_MAX is 32767, then that is the case. Of
course, if it is higher, then incrementing s is perfectly fine, and
has a positive result.
In the real world, compilers will typically just wrap the value
around to a negative one if it overflows.
/* passing signed short to f(), which expects unsigned long */
f(s);
Converting a signed number to an unsigned one is well defined. If
the value is positive and fits in the type being converted to, it is
unchanged. Otherwise the value is modified by adding or subtracting
the maximum value of the type being converted to plus one.
So, assuming that on some hypothetical implementation s wraps in the
above lines of code to -32768, and ULONG_MAX is 4294967295, then
function f() recieves the value -32768 + 4294967295 + 1 or
4294934528.
return (0);
}

void f(unsigned long l)
{
/* note the huge value passed here */
printf ("value is unsigned long = (%lu), hexadecimal =
(0x%lX)\n",
l, l);
}

=================== ENDS HERE ================

(FYI : I am using Solaris Workshop 6.2 on Solaris 8).

Running the above program (compiled with -xarch=v9 option -- for
64-bit), gives me following result (which I guess, expected) :
--------
value is unsigned long = (18446744073709518848), hexadecimal =
(0xFFFFFFFFFFFF8000)
This is to be expected if a) s is being wrapped to a negative
number, and b) unsigned long is a 64 bit type (with no padding bits).
If I run lint to catch such mismatch datatype, I cann't see any
complains from lint :-( ...
Nor should you. This is perfectly legal.
lint -errchk=%all a.c (note, %all includes sizematch see
http://docs.sun.com/db/doc/805-4952/6j4mdcehi?a=view), gives me
following output :
-------
function returns value which is always ignored
printf

declared global, could be static
f a.c(19)
-------

My question is : Is there any way that I can catch such wrong
mismatchs in datatypes (-errchk=sizematch does catch if I pass
unsigned to signed, but not the other way)?


Yes. Open up your eyes and fire up a few synapses, and get your
brain working on it.

--

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"?
Nov 14 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.