All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: linux-api@vger.kernel.org, libc-alpha@sourceware.org,
	Quentin Bouget <quentin.bouget@cea.fr>,
	Jeff Layton <jlayton@kernel.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: statx struct's stx_size pointer compatibility with uint64_t/size_t
Date: Wed, 18 Dec 2019 12:51:26 +0100	[thread overview]
Message-ID: <87mubp26o1.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20191217165350.GA10729@nautica> (Dominique Martinet's message of "Tue, 17 Dec 2019 17:53:50 +0100")

* Dominique Martinet:

> This makes sense to me to avoid multiplying header files for the
> different arches, so if anything I would be tempted to ask 'why is
> stdint.h uint64_t defined with just long'?

It's not a compiler-provided header.  When it was added to glibc in the
90s, I don't think long long support was universal among 64-bit
compilers, and you could not just drop the type (which might have been
acceptable on 32-bit architectures).

Anyway, looking at this, it looks like we should define struct statx
with unsigned long long int in our copy instead of uint64_t.  I filed
bug 25292 to track this.  I guess it's just another thing to keep in
mind when adding system call support to glibc headers.

Thanks,
Florian

      parent reply	other threads:[~2019-12-18 11:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r213aykv.fsf@oldenburg2.str.redhat.com>
2019-12-17 15:21 ` statx struct's stx_size pointer compatibility with uint64_t/size_t Dominique Martinet
2019-12-17 16:53   ` Dominique Martinet
2019-12-17 18:17     ` David Howells
2019-12-18 11:51     ` Florian Weimer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mubp26o1.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=asmadeus@codewreck.org \
    --cc=dhowells@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=quentin.bouget@cea.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.