public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "Dionna Amalie Glaze via newlib" <newlib@sourceware.org>
To: newlib@sourceware.org,
	Dionna Amalie Glaze <dionnaglaze@google.com>,
		Yaakov Selkowitz <yselkowi@redhat.com>
Subject: Re: [PATCH] Make st_*tim visible in stat for POSIX.1-2008
Date: Thu, 15 Aug 2019 15:59:00 -0000	[thread overview]
Message-ID: <CAAH4kHZ9uH3exQsQtR0o26prBjGTcB1z89xgHgFwPVcURaFqLw@mail.gmail.com> (raw)
In-Reply-To: <20190815100353.GK11632@calimero.vinschen.de>

You would also need the st_*time defines to be defined if
!(defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)) instead of
the current defined(__rtems__). Otherwise that seems fine by me.

On Thu, Aug 15, 2019 at 3:03 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 14 12:49, Dionna Amalie Glaze via newlib wrote:
> > Fixed the __MISC_VISIBLE part.
> > I'm not sure I understand your question. I'm just restructuring how that
> > code gets exposed. Where previously the timespec and blocks were defined
> if
> > rtems, and otherwise just the timespec if srv4 etc, I've changed the
> > timespec declarations to all be grouped together. The block declarations
> > are separate because only the #else after defined(__rtems__) is evaluated
> > false and `defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)`
> is
> > evaluated false.
> >
> > ---
> >  newlib/libc/include/sys/stat.h | 64 ++++++++++++++++++----------------
> >  1 file changed, 34 insertions(+), 30 deletions(-)
> >
> > diff --git a/newlib/libc/include/sys/stat.h
> b/newlib/libc/include/sys/stat.h
> > index eee98db64..d7d08e830 100644
> > --- a/newlib/libc/include/sys/stat.h
> > +++ b/newlib/libc/include/sys/stat.h
> > @@ -24,7 +24,7 @@ extern "C" {
> >  #define stat64 stat
> >  #endif
> >  #else
> > -struct stat
> > +struct stat
> >  {
> >    dev_t                st_dev;
> >    ino_t                st_ino;
> > @@ -34,15 +34,11 @@ struct      stat
> >    gid_t                st_gid;
> >    dev_t                st_rdev;
> >    off_t                st_size;
> > -#if defined(__rtems__)
> > +#if __MISC_VISIBLE || __POSIX_VISIBLE >= 200809 || defined(__rtems__)
>
> Do we really need that?  I'm cringing at the idea to redefine a struct
> based on macros set depending on user settings.  Can't we simplify this?
> AFAICS, the timestamps definition of rtems is equivalent to the timestamps
> definition of all other targets, except svr4 etc.  The only difference
> is the additional st_spare4.
>
> I'd like to make the following suggestion, so all targets except svr4 etc.
> default to the POSIX compatible definition:
>
> diff --git a/newlib/libc/include/sys/stat.h
> b/newlib/libc/include/sys/stat.h
> index eee98db64a9a..e460c69c963f 100644
> --- a/newlib/libc/include/sys/stat.h
> +++ b/newlib/libc/include/sys/stat.h
> @@ -34,27 +34,17 @@ struct      stat
>    gid_t                st_gid;
>    dev_t                st_rdev;
>    off_t                st_size;
> -#if defined(__rtems__)
> -  struct timespec st_atim;
> -  struct timespec st_mtim;
> -  struct timespec st_ctim;
> -  blksize_t     st_blksize;
> -  blkcnt_t     st_blocks;
> -#else
> -  /* SysV/sco doesn't have the rest... But Solaris, eabi does.  */
>  #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)
>    time_t       st_atime;
>    time_t       st_mtime;
>    time_t       st_ctime;
>  #else
> -  time_t       st_atime;
> -  long         st_spare1;
> -  time_t       st_mtime;
> -  long         st_spare2;
> -  time_t       st_ctime;
> -  long         st_spare3;
> -  blksize_t    st_blksize;
> +  struct timespec st_atim;
> +  struct timespec st_mtim;
> +  struct timespec st_ctim;
> +  blksize_t     st_blksize;
>    blkcnt_t     st_blocks;
> +#if !defined(__rtems__)
>    long st_spare4[2];
>  #endif
>  #endif
>
>
> Thoughts?
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>


-- 
-Dionna Glaze, PhD (she/her)

  reply	other threads:[~2019-08-15 15:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13 18:30 Dionna Amalie Glaze via newlib
2019-08-13 18:46 ` Joel Sherrill
2019-08-14  8:41   ` Corinna Vinschen
2019-08-14 18:45     ` Dionna Amalie Glaze via newlib
2019-08-14 18:52 ` Yaakov Selkowitz
2019-08-14 19:06   ` Dionna Amalie Glaze via newlib
2019-08-14 19:25     ` Yaakov Selkowitz
2019-08-14 19:50       ` Dionna Amalie Glaze via newlib
2019-08-15 10:03         ` Corinna Vinschen
2019-08-15 15:59           ` Dionna Amalie Glaze via newlib [this message]
2019-08-15 18:29             ` Joel Sherrill
2019-08-16  8:59               ` Corinna Vinschen

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=CAAH4kHZ9uH3exQsQtR0o26prBjGTcB1z89xgHgFwPVcURaFqLw@mail.gmail.com \
    --to=newlib@sourceware.org \
    --cc=dionnaglaze@google.com \
    --cc=yselkowi@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).