On Sat, 22 Sep 2012, Marc Hoersken wrote:

>> Let me just remind everyone that we compile libcurl on MANY different and
>> even ancient systems so we cannot even always rely on proper POSIX
>> compliance
>
> I don't understand the relation to this specific problem. Since (s)size_t is
> used through the whole source code anyway, why shouldn't it be used to
> access arrays, too? Is there a specific problem with non-POSIX systems and
> (s)size_t? Of course there will still be "funny actions" or use of the
> "warnless" functionality.

I don't have any problems with using (s)size_t as index in arrays.

I'm talking about that the conversion from those types to int that may exist
in the code, are sometimes present because of inconsistent APIs in which older
systems don't use size_t but instead perhaps return ints.

But really, I shouldn't speak of such things that genericly. We should talk
about actual code and discuss specifics instead.

>> If you think you can fix actual warnings or errors by doing such changes
>> then I think doing them is good. Doing them only for correctness I think
>> isn't worth it but instead risks us introducing new side-effects.
>
> How can I test for those side-effects? Are there any known or documents
> restrictions on the proposed changes?

I didn't see any actual proposed change so I cannot comment. Changing variable
types and typecasts will quite possibly change the code. Like possibly get
different kinds of overflows/wraps or warnings on other systems.

I'm just generally not a fan of changing working code for only cosmetic
reasons.

> Yes. It works sometimes, but right now it shows up empty. Please see the
> attached screenshot.

Ah you mean the actal table. Yes that seems to be blank for me too right
now. :-/ I'll look into what's going on.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html