# types conversion mistakes in cli's server

- Thread: https://externals.io/message/54650
- Original archive: https://news-web.php.net/php.internals/54650
- Started by Pierre Joye on 2011-08-17T15:19:44+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #54650 — Pierre Joye — 2011-08-17T15:19:44+00:00

URL: https://externals.io/message/54650#54650

Hi

There are many loosely conversions in the CLI web server. Mostly from
(u)int64 to size_t (on 32bit platforms) or in64t to char, or the other
way 'round.

What was the goal to support 64bit data range for content length (or
read data) in 32 bit environments? If LFS support was the goal, it
could be possible to make it server large files but the way it is now
won't work.

Any objection if I change it to use exclusively size_t to avoid any
possible issues?

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #54674 — Pierre Joye — 2011-08-18T09:16:24+00:00

URL: https://externals.io/message/54650#54674 · In reply to: #54650

done in r315128


> Hi
>
> There are many loosely conversions in the CLI web server. Mostly from
> (u)int64 to size_t (on 32bit platforms) or in64t to char, or the other
> way 'round.
>
> What was the goal to support 64bit data range for content length (or
> read data) in 32 bit environments? If LFS support was the goal, it
> could be possible to make it server large files but the way it is now
> won't work.
>
> Any objection if I change it to use exclusively size_t to avoid any
> possible issues?
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org