[PATCH v1] Added string conversion utility functions

Imran Zaman imran.zaman at gmail.com
Mon Nov 24 23:12:31 PST 2014

On Tue, Nov 25, 2014 at 1:15 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> On 11/24/2014 11:32 AM, Imran Zaman wrote:
>> [IZ2] This is the case where endptr is used in patch. I can remove
>> endptr but it seems its used so i have to keep the existing
>> functionality in place.
>> + if (!weston_strtoi(pid, &end, 0, &other) || end != pid + 10)
> Use strlen(pid) != 10 instead.

This will not exactly replace the implemented logic e.g.
strlen(pid) = 10
end = 3 (end != pid + 10)
So cant use the solution which u propose...

>> [IZ2] Sorry still not able to grasp what you want to highlight. Can
>> you please give an example?
> If I write the following code:
>   if (strtol(string, 0, 0, 0)) ...
> I want it to crash so I notice that I passed 0 for the val output pointer.
> There is no reason to every pass null here so it must be a programmer
> mistake. As you have written it this will act like there is a syntax error
> in string, which could lead a person trying to debug their code down the
> wrong path.
Sorry, why is it a programmer mistake and how would it crash? Let me
add the exact test code and will come back to you. It should not crash
for sure IMO.

> Also if the pointer is passed as &(structure->member) it is going to crash
> anyway if structure is null and the offset to member is non-zero. I would
> think most errors causing the pointer to be invalid will be of this form so
> this is not preventing any crash.
This cant be prevented anyway. we are using pointers everywhere in the
whole weston code base.
So its the user of the function who have to pass valid pointer or NULL.

> I suppose null could be used as "I am only testing if it parses and don't
> want the number" but it is not implemented this way, and I kind of doubt
> much code is interested in that test.
At least one case above is using endptr.. if we can replace it with
exactly similarly logic, I can remove it otherwies I dont see any harm
in its usage

More information about the wayland-devel mailing list