Am 19.01.2019 um 18:06 schrieb Torsten Bögershausen:
> On 16.01.19 22:46, Thomas Braun wrote:
>> Am 20.11.2018 um 06:04 schrieb tbo...@web.de:
>>
>> I'm interested in helping getting this forward!
>>
>>> What we really need for this patch to fly are this branches:
>>> mk/use-size-t-in-zlib
>>
>> In
On 16.01.19 22:46, Thomas Braun wrote:
> Am 20.11.2018 um 06:04 schrieb tbo...@web.de:
>
> I'm interested in helping getting this forward!
>
>> What we really need for this patch to fly are this branches:
>> mk/use-size-t-in-zlib
>
> In pu.
Junio, is that branch ready for master ?
>
>> tb/print-s
Am 20.11.2018 um 06:04 schrieb tbo...@web.de:
I'm interested in helping getting this forward!
> What we really need for this patch to fly are this branches:
> mk/use-size-t-in-zlib
In pu.
> tb/print-size-t-with-uintmax-format
in master.
> And then it is rebased on top of all cooking stuff, to
On 11/20/2018 12:04 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bi
From: Torsten Bögershausen
Currently the length of data which is stored in memory is stored
in "unsigned long" at many places in the code base.
This is OK when both "unsigned long" and size_t are 32 bits,
(and is OK when both are 64 bits).
On a 64 bit Windows system am "unsigned long" is 32 bit,
5 matches
Mail list logo