This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Obsolete and Removed POSIX Functions

On 2016-02-15 13:37, Joel Sherrill wrote:
On 2/15/2016 1:21 PM, Yaakov Selkowitz wrote:
On 2016-02-15 13:09, Joel Sherrill wrote:
I am unsure how methods noted by POSIX as obsolete should
be guarded.

For example, asctime() and asctime_r() were marked as obsolescent
in Issue 7.

obsolete != removed:

Agreed. But an aggressive approach would be to warn users
and recommend changes. Obsolete is the first step on the
path to removal.

If I had working code that used an obsolete methods, I
wouldn't read a man page to see that I used a methods which
was on the way out. I wouldn't notice this unless I was lucky
or writing new code.

Just wondering if there is a possibility of an action that
is helpful to users.

Technically it would be possible to mark these __attribute__((__deprecated__)) if __POSIX2008_VISIBLE. I'm not sure if that *should* be done or not.

Similarly, that page lists some methods that should be removed.
I am assuming it is OK to still support them but what should the
guards be?

Did you see my RFC:

There are several examples therein, which can easily be found by
searching for "&& !__"

I looked through there and using bcmp() as an example...

  int     _EXFUN(bcmp,(const void *, const void *, size_t));
  void     _EXFUN(bcopy,(const void *, void *, size_t));
  void     _EXFUN(bzero,(void *, size_t));

Where is __POSIX2008_VISIBLE defined?

If POSIX 2013 is requested, then is bcmp() prototyped or not?

There is no "POSIX 2013"; just as there is no "POSIX 2004" (2001 + technical corrigendum), the 2013 edition is the 2008 standard with technical corrigendum applied.

It is removed in 2013 and (I assume) obsolete in 2008.

It was marked legacy in 2001 and removed in 2008.

And I see some CYGWIN conditions replaced with checks for
POSIX 2008. Is that an equivalent check?  fexecve() is a
very simple example and AT_FDCWD has a more complicated

There are some cases where __CYGWIN__ and/or __rtems__ are used because that feature is only implemented on those system(s) and other cases where they are clearly in place of a proper feature test. The question is if the headers really need to reflect the former.

ucontext.h methods are removed in Issue 7 so I wonder if
the check around <sys/ucontext.h> is right.

The mcontext_t and ucontext_t *types* are still required in signal.h, which is all <sys/ucontext.h> provides. But that should probably be __XOPEN6_VISIBLE || __POSIX2008_VISIBLE instead.

The 2013 question may not be fair because I doubt newlib
has been reviewed at all for that. But that's the change
boundary I am looking at.

I'm all for catching up our headers to the latest standards.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]