Re: Introduction and 64 bit time_t

[Eric Blake <eblake at redhat dot com>]

On 08/08/2017 07:40 AM, Philipp.Trommler@preh.de wrote:
> My impression is that you're in principle interested in having a fix
> for the problem but you didn't have the resources to do it until now.
> If this impression is right, I'd gladly provide a fix but I'll need
> some advice from developers more experienced in newlib.
> 
> So here are my questions:
> 
> 1. Are you interested in a fix for the problem? If yes, what are the
>    steps that are necessary from your point of view? What are your
>    preferences for a possible implementation?

Yes, we're interested. It sounds like any solution will have to be gated
by compile-time conditionals around the typedef for time_t (so that
embedded platforms don't have to pay the size penalties when they don't
care about the larger range of time).

> 
> 2. Sadly I'm unable to check out your latest code locally, as cloning
>    the git repository via HTTP (the git protocol is no option in our
>    company's network, sorry) fails with some "Unable to get pack
>    index..." and "Unable to get pack file..." errors. Is this just me
>    or is something wrong with your git server?

If you need HTTP clones, it's easy to use a third-party tracking repo; I
find that repo.or.cz makes it very easy to set up a tracking clone
(generally lags the official repo by less than an hour), and then get
your HTTP from there rather than upstream ('git config
url.$name.insteadof' can make it even easier to automatically rewrite
your local accesses to redirect to your preferred http alternative).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature