card-cac.c
* CLANG_WARNING: The left operand of '<' is a garbage value
card-coolkey.c
* CLANG_WARNING: overwriting variable
* CPPCHECK_WARNING: memory leak / overwrite variable
* CLANG_WARNING: null pointer dereference
* UNUSED_VALUE: unused return value
card-gids.c
* CLANG_WARNING: Branch condition evaluates to a garbage value
* SIZEOF_MISMATCH: suspicious_sizeof
card-myeid.c
* RESOURCE_LEAK: Variable "buf" going out of scope leaks the storage it points to.
* CLANG_WARNING: overwriting variable
* (rewrite not to confuse coverity)
pkcs15-cac.c
* RESOURCE_LEAK: Variable "cert_out" going out of scope leaks the storage it points to.
pkcs15-coolkey.c
* UNUSED_VALUE: unused return value
pkcs15-piv.c
* RESOURCE_LEAK: Variable "cert_out" going out of scope leaks the storage it points to.
pkcs15-sc-hsm.c
* DEADCODE
pkcs11/framework-pkcs15.c
* RESOURCE_LEAK: Variable "p15_cert" going out of scope leaks the storage it points to.
pkcs15init/pkcs15-lib.c
* CLANG_WARNING: Assigned value is garbage or undefined
pkcs15init/pkcs15-myeid.c
* UNREACHABLE: Probably wrong placement of code block
tests/p15dump.c
* IDENTICAL_BRANCHES
pkcs15-init.c
* CLANG_WARNING: Potential leak of memory pointed to by 'args.der_encoded.value'
pkcs15-tool.c
* RESOURCE_LEAK: Variable "cert" going out of scope leaks the storage it points to.
* MISSING_BREAK: The above case falls through to this one.
sc-hsm-tool.c
* CLANG_WARNING: Potential leak of memory pointed to by 'sp'
westcos-tool.c
* FORWARD_NULL: Passing null pointer "pin" to "unlock_pin", which dereferences it.
* (rewrite not to confuse coverity)
card-cac.c
* Avoid malloc with 0 argument
gids-tool.c
* FORWARD_NULL -- copy&paste error
scconf.c
* CLANG_WARNING: Call to 'malloc' has an allocation size of 0 bytes
closes#982
When getting string configuration parameter,
ignore non 'auto-configurated' in configuration file value
(ex. @SOME_VALUE_IN_OPENSC_CONF@) and return it's default value.
scconf.c:195:2: warning: Value stored to 'ret' is never read
ret = scconf_put_str(block, option, !value ? "false" : "true");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scconf.c:585:3: warning: Value stored to 'r' is never read
r = 0;
^ ~
scconf.c:711:3: warning: Value stored to 'r' is never read
r = 0;
^ ~
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5139 c6295689-39f2-0310-b995-f0e70906c6a9
From http://en.wikipedia.org/wiki/Malloc#Casting_and_type_safety
" Casting and type safety
malloc returns a void pointer (void *), which indicates that it is a
pointer to a region of unknown data type. One may "cast" (see type
conversion) this pointer to a specific type, as in
int *ptr = (int*)malloc(10 * sizeof (int));
When using C, this is considered bad practice; it is redundant under the
C standard. Moreover, putting in a cast may mask failure to include the
header stdlib.h, in which the prototype for malloc is found. In the
absence of a prototype for malloc, the C compiler will assume that
malloc returns an int, and will issue a warning in a context such as the
above, provided the error is not masked by a cast. On certain
architectures and data models (such as LP64 on 64 bit systems, where
long and pointers are 64 bit and int is 32 bit), this error can actually
result in undefined behavior, as the implicitly declared malloc returns
a 32 bit value whereas the actually defined function returns a 64 bit
value. Depending on calling conventions and memory layout, this may
result in stack smashing.
The returned pointer need not be explicitly cast to a more specific
pointer type, since ANSI C defines an implicit conversion between the
void pointer type and other pointers to objects. An explicit cast of
malloc's return value is sometimes performed because malloc originally
returned a char *, but this cast is unnecessary in standard C
code.[4][5] Omitting the cast, however, creates an incompatibility with
C++, which does require it.
The lack of a specific pointer type returned from malloc is type-unsafe
behaviour: malloc allocates based on byte count but not on type. This
distinguishes it from the C++ new operator that returns a pointer whose
type relies on the operand. (see C Type Safety). "
See also
http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014586.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4636 c6295689-39f2-0310-b995-f0e70906c6a9
remove unused variable ret in scconf_put_int.
from the readme: "if parm not NULL, then ... parm points to ..."
so we need to get the value of the location where it points to.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@2729 c6295689-39f2-0310-b995-f0e70906c6a9
scconf_put_{str,int,bool}
scconf_write_entries
TODO:
- Cleanups, add more sanity checks
- Rewrite parts of the API for LDAP support
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@711 c6295689-39f2-0310-b995-f0e70906c6a9
identification infrastructure by Helsinki University of Technology.
Breaks current PAM build, lot's of stuff from configure.ac
missing, some references to unknown sources and functions.
Time to get some sleep, i'll continue merging tomorrow.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@356 c6295689-39f2-0310-b995-f0e70906c6a9
Peter Marschall
Frank Morgner
Viktor Tarasov
ludovic.rousseau
aj
nils
aet
fabled