[sr #107521] Lint encountered during compile
INVALID.NOREPLY at gnu.org
Wed Nov 17 08:17:59 CET 2010
Follow-up Comment #2, sr #107521 (project gnutls):
> Fixing these will be a bit of a pain, but we should do it
> since the code is not clean.
Agreed. -Wall -Wextra is a nice tattle tale. The switches vet issues before
they become problems (confer, SR #106551 and SR #106549).
> The most time consuming part is the pointer signed/unsigned
> issue. Before someone spends a lot of time on a patch,
> please tell how you think it should be solved and why.
For the signed/unsigned pointers, I would introduce a gnutls byte or octet
that was typedf'd as an unsigned char. typedef'ing would step away from
signed/unsigned chars, which is conceptually consistent with operating on the
data bytes or data octets.
With the byte_t or octet_t in place, data which is truly a char* would be
operated upon by str* functions, while data which is a byte_t*/octet_t* would
manipulated with the mem* functions.
Personally, I'm more concerned with "comparison between signed and unsigned
integer expressions". A comparison is going to be made, the question is
"How?". In this case, the [possible] negative number is most likely promoted
to unsigned, which usually results in a *really* big positive value if the
original number is negative.
Consider: the adversary controls the wire, so he/she is going to feed gnutls
bad certs and other miscreant data in an effort to get a toe hold on the
system. Adobe is a case study in this sort of vulnerability. Its not the
common case, its just something that gnutls should be mindful.
Reply to this item at:
Message sent via/by Savannah
More information about the Gnutls-devel