https://bugzilla.redhat.com/show_bug.cgi?id=454030
Resolves: bug 454030
Bug Description: Need to address 64-bit compiler warnings - part 1
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The intptr_t and uintptr_t are types which are defined
as integer types that are the same size as the pointer (void *) type.
On the platforms we currently support, this is the same as long and
unsigned long, respectively (ILP32 and LP64). However, intptr_t and
uintptr_t are more portable. These can be used to assign a value passed
as a void * to get an integer value, then "cast down" to an int or
PRBool, and vice versa. This seems to be a common idiom in other
applications where values must be passed as void *.
For the printf/scanf formats, there is a standard header called
inttypes.h which defines formats to use for various 64 bit quantities,
so that you don't need to figure out if you have to use %lld or %ld for
a 64-bit value - you just use PRId64 which is set to the correct value.
I also assumed that size_t is defined as the same size as a pointer so I
used the PRIuPTR format macro for size_t.
I removed many unused variables and some unused functions.
I put parentheses around assignments in conditional expressions to tell
the compiler not to complain about them.
I cleaned up some #defines that were defined more than once.
I commented out some unused goto labels.
Some of our header files shared among several source files define static
variables. I made it so that those variables are not defined unless a
macro is set in the source file. This avoids a lot of unused variable
warnings.
I added some return values to functions that were declared as returning
a value but did not return a value. In all of these cases no one was
checking the return value anyway.
I put explicit parentheses around cases like this: expr || expr && expr
- the && has greater precedence than the ||. The compiler complains
because it wants you to make sure you mean expr || (expr && expr), not
(expr || expr) && expr.
I cleaned up several places where the compiler was complaining about
possible use of uninitialized variables. There are still a lot of these
cases remaining.
There are a lot of warnings like this:
lib/ldaputil/certmap.c:1279: warning: dereferencing type-punned pointer
will break strict-aliasing rules
These are due to our use of void ** to pass in addresses of addresses of
structures. Many of these are calls to slapi_ch_free, but many are not
- they are cases where we do not know what the type is going to be and
may have to cast and modify the structure or pointer. I started
replacing the calls to slapi_ch_free with slapi_ch_free_string, but
there are many many more that need to be fixed.
The dblayer code also contains a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=463991 - instead of checking
for dbenv->foo_handle to see if a db "feature" is enabled, instead check
the flags passed to open the dbenv. This works for bdb 4.2 through bdb
4.7 and probably other releases as well.
Platforms tested: RHEL5 x86_64, Fedora 8 i386
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=318201&action=diff
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
