This is the mail archive of the newlib@sourceware.org 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]

syscall stubs (Was: Re: RFA: Add Epiphany newlib & libgloss port)

From: Joern Rennecke <amylaar at spamcop dot net>
To: Jim Meyering <jim at meyering dot net>
Cc: newlib at sources dot redhat dot com
Date: Wed, 09 Nov 2011 06:07:41 -0500
Subject: syscall stubs (Was: Re: RFA: Add Epiphany newlib & libgloss port)
References: <20111105172305.j4oc3oy1sk4kog44-nzlynne@webmail.spamcop.net> <87pqh5sglv.fsf@rho.meyering.net>

Quoting Jim Meyering <jim@meyering.net>:

stat always succeeds.  Even with a very rudimentary file system, shouldn't
  stat be able to fail with ENOENT, EFAULT, ENAMETOOLONG, ENOTDIR, etc?

fstat always succeeds. What about EBADF, EFAULT, etc.?

link.c always fails with EMLINK;  wouldn't ENOSYS be better?
wait.c: likewise always with ECHILD;  wouldn't ENOSYS be better?
  Tools that detect lack of support recognize ENOSYS as indicating that.


These minimal stubs agree with what the newlib documentation
says at http://sourceware.org/newlib/ under 14.1 .

Is that documentation wrong?

Follow-Ups:
- Re: syscall stubs
  - From: Jim Meyering

References:
- RFA: Add Epiphany newlib & libgloss port
  - From: Joern Rennecke
- Re: RFA: Add Epiphany newlib & libgloss port
  - From: Jim Meyering

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