On Aug 26 2007 13:45, Mike Frysinger wrote:
>> can I rely on the same errno across Linuxes?
>
>nope
>
>> And should the errno values be fixed up?
>
>i guess that depends on whether you think it's even broken :)
>
>no spec requires any errno symbol have an exact numeric value ... i'm guessing
On Friday 24 August 2007, Jan Engelhardt wrote:
> So I'm just asking: can I rely on the same errno across Linuxes?
nope
> And should the errno values be fixed up?
i guess that depends on whether you think it's even broken :)
no spec requires any errno symbol have an exact numeric value ... i'm
On Friday 24 August 2007, Jan Engelhardt wrote:
So I'm just asking: can I rely on the same errno across Linuxes?
nope
And should the errno values be fixed up?
i guess that depends on whether you think it's even broken :)
no spec requires any errno symbol have an exact numeric value ... i'm
On Aug 26 2007 13:45, Mike Frysinger wrote:
can I rely on the same errno across Linuxes?
nope
And should the errno values be fixed up?
i guess that depends on whether you think it's even broken :)
no spec requires any errno symbol have an exact numeric value ... i'm guessing
your FUSE is
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 18:24:48 +0200 (CEST)
> So I'm just asking: can I rely on the same errno across Linuxes?
> And should the errno values be fixed up?
You cannot rely on error numbers being the same, every
architecture has something to a few to many
Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
> So I'm just asking: can I rely on the same errno across Linuxes?
No. The errnos were originally designed to be compatible
with the "native" Unix on that platform to make running
their binaries easier. On Sparc that would
be SunOS/Solaris.
-Andi
-
On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote:
...
> If a file does not have the requested attribute, the syscall will
> produce ENODATA. On x86_64, that is mapped to the value 61. Back on the
> sparc side, 61 is mapped to ECONNREFUSED, and that gives odd errors
> when ls tries
Hello lists,
I am currently working on a FUSE-based filesystem much like nfs/sshfs.
I pass the syscall on to the storage server, where it is executed, and
get back the result, or errno code. Let's jump into the real world
example where the storage unit is x86_64 and the mount side is
Hello lists,
I am currently working on a FUSE-based filesystem much like nfs/sshfs.
I pass the syscall on to the storage server, where it is executed, and
get back the result, or errno code. Let's jump into the real world
example where the storage unit is x86_64 and the mount side is
On Fri, Aug 24, 2007 at 06:24:48PM +0200, Jan Engelhardt wrote:
...
If a file does not have the requested attribute, the syscall will
produce ENODATA. On x86_64, that is mapped to the value 61. Back on the
sparc side, 61 is mapped to ECONNREFUSED, and that gives odd errors
when ls tries to
Jan Engelhardt [EMAIL PROTECTED] writes:
So I'm just asking: can I rely on the same errno across Linuxes?
No. The errnos were originally designed to be compatible
with the native Unix on that platform to make running
their binaries easier. On Sparc that would
be SunOS/Solaris.
-Andi
-
To
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 18:24:48 +0200 (CEST)
So I'm just asking: can I rely on the same errno across Linuxes?
And should the errno values be fixed up?
You cannot rely on error numbers being the same, every
architecture has something to a few to many
12 matches
Mail list logo
