summaryrefslogtreecommitdiffstats
path: root/ldap/servers/slapd/uuid.c
Commit message (Collapse)AuthorAgeFilesLines
* Bug Description: Need to address 64-bit compiler warnings - part 1Rich Megginson2008-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | Reviewed by: nhosoi (Thanks!) 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
* Resolves: #188320Noriko Hosoi2007-10-181-2/+2
| | | | Summary: HP-UX: warnings reported by the HP-UX compiler
* Resolves: bug 330121Rich Megginson2007-10-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Bug Description: uuid generator truncates clock_seq_hi_and_reserved field Reviewed by: nkinder (Thanks!) Fix Description: The uuid code has this code (where clock_seq is unsigned16 - 2 bytes and uuid->clock_seq_hi_and_reserved is unsigned8 - 1 byte): uuid->clock_seq_hi_and_reserved = (unsigned8)(clock_seq & 0x3F00) >> 8; In this code, the cast to unsigned8 takes precedence over over the shift. So what happens is that (clock_seq & 0x3F00) is first cast to an 8 bit quantity, then shifted by 8 bits. The result is that the value is _always 0_. The code also does this: uuid->clock_seq_hi_and_reserved |= 0x80; You can see this because every nsUniqueID looks like this: XXXXXXXX-XXXXXXXX-80XXXXXXXX-XXXXXXXX The first byte of the 3rd octet is always 80. This may also be related to https://bugzilla.redhat.com/show_bug.cgi?id=197886 and may explain why the sequence numbers were exhausted so quickly. Without this fix, we only have 256 sequence numbers available. This fix adds another 6 bits. The fix is to mask and shift as an unsigned16 quantity, then cast to unsigned8. Platforms tested: RHEL5 x86_64 Flag Day: no - I think this will only impact new unique IDs that are generated. It will not affect existing unique IDs. Doc impact: no
* Resolves: bug 262021Rich Megginson2007-09-241-1/+14
| | | | | | | | | | | Bug Description: Migration script does not migrate nsDS5ReplicaCredentials correctly. Reviewed by: nkinder (Thanks!) Fix Description: 7.1 and earlier chaining and replication credentials were stored incorrectly on little endian machines (x86 and itanium). They were "accidentally" stored correctly on big endian machines (sparc, pa-risc) because val == ntohl(val) on those platforms. When migrating from a little endian machine, we need to decode the password using the broken algorithm and re-encode it using the good method. We determine if the password is encode incorrectly by the following method: we use migratecred to decode and encode using the old path. If the values are equal, this means the password was already encoded correctly and we don't need to fix it. Otherwise, we set the flag that tells migratecred to fix it. In order to decode the broken password correctly on big endian machines, we have to swap the byte order to convert the values to little endian. Platforms tested: RHEL5 x86_64, RHEL5 i386, Solaris 9 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none
* Resolves: bug 262021Rich Megginson2007-09-201-4/+8
| | | | | | | | | | | Bug Description: Migration script does not migrate nsDS5ReplicaCredentials correctly. Reviewed by: nhosoi (Thanks!) Fix Description: We still need to be able to decrypt passwords using the broken method. I guess it works on Solaris and HP because the values are already in network byte order. But when the values were encrypted on x86, they were encrypted the wrong way. It is safe to use MIGRATE_BROKEN_PWD on Solaris and HP because it is essentially a no-op. But this allows us to decrypt x86 passwords and store them correctly. Platforms tested: RHEL4 i386, RHEL5 x86_64 Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none
* Resolves: bug 262021Rich Megginson2007-08-301-3/+3
| | | | | | | | | | | Bug Description: Migration script does not migrate nsDS5ReplicaCredentials correctly. Reviewed by: nhosoi (Thanks!) Fix Description: This was a big endian vs. little endian issue. We only use name based UUID generation with the reversible password code. This code was not doing the ntoh with the numeric values generated. I'm sure there is probably a compiler warning about this on some platform. Platforms tested: RHEL5 x86_64, Solaris 9 64-bit Flag Day: no Doc impact: no QA impact: should be covered by regular nightly and manual testing New Tests integrated into TET: none
* Resolves: #214533Noriko Hosoi2006-11-101-0/+5
| | | | | | | | | | Summary: configure needs to support --with-fhs (Comment #6) Changes: Added the following include next to the end of the copyright block. + +#ifdef HAVE_CONFIG_H +# include <config.h> +#endif +
* Fixed licensing typoNathan Kinder2005-04-191-1/+3
|
* 155068 - Added license to source filesNathan Kinder2005-04-151-0/+30
|
* clean up sprintf usage and many other flawfinder issues; clean up compiler ↵Rich Megginson2005-03-051-2/+1
| | | | warnings on Linux; remove pam_passthru from DS 7.1
* 149951 - Updated source code copyrightsNathan Kinder2005-02-281-2/+2
|
* Moving NSCP Directory Server from DirectoryBranch to TRUNK, initial drop. ↵ldapserver7xcvsadm2005-01-211-0/+893
(foxworth)