Hi,
The issue was raised at opengroup, see
http://www.opengroup.org/austin/aardvark/latest/xbdbug2.txt
ENOTSUP and EOPNOTSUPP may then be equal.
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, Feb 24, 2006 at 08:46:23AM +, Brian M. Carlson wrote:
> Neither side is willing to "lose" and give in all the way. I tried a
> compromise. Apparently, that didn't work, so let me try another one:
> glibc could no longer claim compliance with SUSv3/POSIX 1003.1-2001 or
> SUSv2. Then
On Thu, 2006-02-23 at 13:24 +0100, Gabor Gombas wrote:
> On Thu, Feb 23, 2006 at 04:30:55AM +, Brian M. Carlson wrote:
>
> > > By introducing a new define, you are breaking standard compliance.
> >
> > Well, there is no better way. You want to preserve binary compatibility
> > at the expense
On Thu, Feb 23, 2006 at 04:30:55AM +, Brian M. Carlson wrote:
> > By introducing a new define, you are breaking standard compliance.
>
> Well, there is no better way. You want to preserve binary compatibility
> at the expense of all else. I want to preserve standards compliance at
> the exp
On Tue, 2006-02-21 at 16:22 +0100, Aurelien Jarno wrote:
> Brian M. Carlson a écrit :
> > It's been done at least once before. However, if there were a libc7,
>
> Could please give me the number of packages affected and compare to now?
I don't know how many packages were in hamm, because the ear
On Thu, Feb 23, 2006 at 04:14:40AM +, Brian M. Carlson wrote:
> Second, glibc claims (as I have just shown in another message) that it
> conforms to POSIX 1003.1-2001. Therefore, currently I can expect that
> the errors are different. Anyway, I don't want to have to work around
> every Unix's
On Tue, 2006-02-21 at 16:44 -0800, Russ Allbery wrote:
> The sad part is that if it's just an issue with duplicate case statements,
> it's a two-line fix.
>
> case ENOTSUP:
> case EOPNOTSUPP:
>
> becomes:
>
> case ENOTSUP:
> #if ENOTSUP != EOPNOTSUPP
> case EOPNOTSUPP:
> #endif
On Tue, 2006-02-21 at 16:25 +0100, Aurelien Jarno wrote:
> severity 227386 wishlist
> thanks
>
> I have found no place where either the Linux kernel, the GNU libc or
> Debian claim full POSIX compliance. Therefore this a wishlist.
>
> If you found such a place, I will upgrade the bug back to min
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Why you don't fix your code instead of creating more problems than you
> try to solve? You say us you already have a technical solution in your
> code for EWOULDBLOCK and EAGAIN. Please apply the same for ENOTSUP and
> EOPNOTSUPP.
The sad part is that
Processing commands for [EMAIL PROTECTED]:
> severity 227386 wishlist
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Severity set to `wishlist'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system ad
Brian M. Carlson a écrit :
On Mon, 2006-02-20 at 07:51 +0100, Aurelien Jarno wrote:
The problem is not that there is currently not possibility to fix the
bug without broking everything, at least nobody found one. Please
provide us a patch instead of complaning.
Attached.
We can't change
severity 227386 wishlist
thanks
I have found no place where either the Linux kernel, the GNU libc or
Debian claim full POSIX compliance. Therefore this a wishlist.
If you found such a place, I will upgrade the bug back to minor.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
:
On Tue, Feb 21, 2006 at 06:23:21AM +, Brian M. Carlson wrote:
> > (void *)strerror(error_code);
>
> Not thread safe.
Then use strerror_r().
> Also, this code does not check that it is a *POSIX*
> error code. If you check the Linux sources, you can see that there are
> many error
On Mon, 2006-02-20 at 07:51 +0100, Aurelien Jarno wrote:
> Brian M. Carlson a écrit :
> > # bcc'd to control
> > forwarded 227386 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
> > thanks, control, and have a nice day
> >
> > On Sun, 2006-02-19 at 17:36 +0100, Aurelien Jarno wrote:
>
> T
On Mon, 2006-02-20 at 17:37 +0100, Gabor Gombas wrote:
> That seems overly complex. You should most certainly know the range of
> your own error codes, so something like the below looks much simpler (no
> script needed, no dependance on the value of standard error codes):
The problem with that is
On Sun, Feb 19, 2006 at 08:25:34AM +, Brian M. Carlson wrote:
> Anyway, my problem is that the fact that these two errors are
> the same is causing my code to break very badly. I have a
> library that contains its own error codes that will be negative
> if casted to an int. Additionally, I w
Brian M. Carlson a écrit :
# bcc'd to control
forwarded 227386 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
thanks, control, and have a nice day
On Sun, 2006-02-19 at 17:36 +0100, Aurelien Jarno wrote:
severity 227386 minor
thanks
I'm not going to play bug tennis with you. I thi
Processing commands for [EMAIL PROTECTED]:
> # bcc'd to control
> forwarded 227386 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Noted your statement that Bug has been forwarded to
http://sources.redhat.c
# bcc'd to control
forwarded 227386 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
thanks, control, and have a nice day
On Sun, 2006-02-19 at 17:36 +0100, Aurelien Jarno wrote:
> severity 227386 minor
> thanks
I'm not going to play bug tennis with you. I think the bug should be
rated im
Processing commands for [EMAIL PROTECTED]:
> severity 227386 minor
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Severity set to `minor'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(ad
severity 227386 minor
thanks
Brian M. Carlson a écrit :
severity 227386 important
clone 227386 -1
reassign -1 linux-2.6
retitle -1 linux-2.6: ENOTSUP and EOPNOTSUPP should be different
thanks, control, and have a nice day
[Copied and pasted from the bug log, because I don't have the original.]
Processing commands for [EMAIL PROTECTED]:
> severity 227386 important
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Severity set to `important'.
> clone 227386 -1
Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Bug 227386 cloned as bug 353516.
&g
severity 227386 important
clone 227386 -1
reassign -1 linux-2.6
retitle -1 linux-2.6: ENOTSUP and EOPNOTSUPP should be different
thanks, control, and have a nice day
[Copied and pasted from the bug log, because I don't have the original.]
> At Mon, 12 Jan 2004 22:21:39 +,
> Brian M. Carlson <
At Mon, 12 Jan 2004 22:21:39 +,
Brian M. Carlson <[EMAIL PROTECTED]> wrote:
> ENOTSUP is the same as EOPNOTSUPP.
Because linux kernel does not distinct both, moreover they don't
return ENOTSUP.
> SUSv3 requires these two values to be
> distinct, even though no function uses both of them. The
At Mon, 12 Jan 2004 22:21:39 +,
Brian M. Carlson <[EMAIL PROTECTED]> wrote:
> ENOTSUP is the same as EOPNOTSUPP.
Because linux kernel does not distinct both, moreover they don't
return ENOTSUP.
> SUSv3 requires these two values to be
> distinct, even though no function uses both of them. The
Package: libc6-dev
Version: 2.3.2.ds1-10
Severity: normal
ENOTSUP is the same as EOPNOTSUPP. SUSv3 requires these two values to be
distinct, even though no function uses both of them. The obvious
solution is for glibc to remap EOPNOTSUPP to the new ENOTSUP code when
the error code should be ENOTSU
Package: libc6-dev
Version: 2.3.2.ds1-10
Severity: normal
ENOTSUP is the same as EOPNOTSUPP. SUSv3 requires these two values to be
distinct, even though no function uses both of them. The obvious
solution is for glibc to remap EOPNOTSUPP to the new ENOTSUP code when
the error code should be ENOTSU
27 matches
Mail list logo
