public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: linux-kernel@vger.kernel.org, bug-glibc@gnu.org
Cc: Nathan Scott <nathans@sgi.com>, Tim Shimmin <tes@sgi.com>,
	Thorsten Kukuk <kukuk@suse.de>, Andreas Schwab <schwab@suse.de>,
	Andreas Jaeger <aj@suse.de>
Subject: Kernel/Glibc:  EOPNOTSUPP vs. ENOTSUP vs. ENOTSUPP
Date: Thu, 1 Aug 2002 18:15:23 +0200	[thread overview]
Message-ID: <200208011815.23462.agruen@suse.de> (raw)

Hello,

we have a bit of a mess concerning error definitions: POSIX 1003.1-200
defines the errors EOPNOTSUPP and ENOTSUP as follows:

	[ENOTSUP] Not supported. The implementation does not support this
	feature of the Realtime Option Group.

	[EOPNOTSUPP] Operation not supported on socket. The type of socket
	(address family or protocol) does not support the requested operation.

The standard further says the numbers assigned to ENOTSUP and EOPNOTSUPP shall 
be unique.

Glibc seems to follow, but not quite:

	[ENOTSUP] "Not supported".  A function returns this error when
	certain parameter values are valid, but the functionality they request
	is not available. This can mean that the function does not implement
	a particular command or option value or flag bit at all.  For functions
	that operate on some object given in a parameter, such as a file
	descriptor or a port, it might instead mean that only that specific
	object (file descriptor, port, etc.) is unable to support the other
	parameters given; different file descriptors might support different
	ranges of parameter values.

        If the entire function is not available at all in the implementation,
	it returns ENOSYS instead.

	[EOPNOTSUPP] "Operation not supported". The operation you requested is
	not supported.  Some socket functions don't make sense for all types of
	sockets, and others may not be implemented for all communications
	protocols.  In the GNU system, this error can happen for many calls when
	the object does not support the particular operation; it is a generic
	indication that the server knows nothing to do for that call.

In Glibc's sysdeps/unix/sysv/linux/bits/errno.h it says:
	/* Linux has no ENOTSUP error code. */
	# define ENOTSUP EOPNOTSUPP

In the kernel we define EOPNOTSUPP (architecture specific) and
ENOTSUPP (in include/linux/errno.h). ENOTSUPP doesn't exist inside POSIX.

Is ENOTSUPP supposed to be the same as ENOTSUP? Some applications are
already checking for ENOTSUP; if they are compiled against Glibs they
currently will really check against EOPNOTSUPP. Renaming or aliasig
ENOTSUPP to ENOTSUP will cause trouble, but aliasing ENOTSUP to
EOPNOTSUPP leads to a conflict with POSIX.

What shall be done?

Regards,
Andreas.

------------------------------------------------------------------
 Andreas Gruenbacher                                SuSE Linux AG
 mailto:agruen@suse.de                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany


                 reply	other threads:[~2002-08-01 16:11 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200208011815.23462.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=aj@suse.de \
    --cc=bug-glibc@gnu.org \
    --cc=kukuk@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathans@sgi.com \
    --cc=schwab@suse.de \
    --cc=tes@sgi.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