Linux-Development-Sys Digest #64, Volume #8 Thu, 3 Aug 00 23:13:15 EDT
Contents:
Re: linux device drivers info (Robert Lynch)
Re: glibc bug strtol (Dave Platt)
Re: glibc bug strtol (Erik Max Francis)
Re: ntfs support in kernel 2.2.14? (Tim Moore)
Re: glibc bug strtol (tye4)
Re: glibc bug strtol (Jonathan Kamens)
Re: read() and directories (Grant Edwards)
Re: glibc bug strtol (Dave Platt)
Re: glibc bug strtol (tye4)
Re: glibc bug strtol (Dave Platt)
Re: glibc bug strtol (Jonathan Kamens)
Re: glibc bug strtol (Kaz Kylheku)
----------------------------------------------------------------------------
From: Robert Lynch <[EMAIL PROTECTED]>
Subject: Re: linux device drivers info
Date: Thu, 03 Aug 2000 17:17:51 -0700
Reply-To: [EMAIL PROTECTED]
Kai Xu wrote:
>
> Where did you find the "Linux Kernel Module Programming Guide" ?
> I searched the www.linuxdoc.org and couldn't find it.
>
> Thanks
I'm not Matt; but it's at:
http://www.linuxdoc.org/LDP/lkmpg/mpg.html
Reason I butted in, is I wanted to note a couple of very good links:
Richard Gooch's pages:
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.3.html
And some stuff by Alan Cox listed at:
http://www.linux-mag.com/auth.html
FWIW. Bob L.
> MJ Dainty wrote:
>
> > On Wed, 2 Aug 2000, Rafael [iso-8859-1] Garc�a wrote:
> >
> > | There are anything as good as the book 'Linux Device Drivers' by
> > | Alessandro Rubini in a non printed format?
> >
> > Depending on how much depth you want to go into, I've dug up the "Linux
> > Kernel Module Programming Guide", which should be available from most
> > LDP mirrors. In the concluding section, it has a link to a page that
> > lists loads of kernel-related HOWTOs, including a set of 5 tutorials
> > co-written by the aforementioned Alessandro Rubini.
> >
> > If anyone else can suggest some other on-line docs, I'd also appreciate
> > a pointer...
> >
> > Matt
--
Robert Lynch-Berkeley CA [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Fri, 04 Aug 2000 00:31:31 GMT
In article <[EMAIL PROTECTED]>, tye4 <[EMAIL PROTECTED]> wrote:
>num = strtol("5", &endptr, 10);
>perror("should be success");
>
>
>This is a bug. If a function uses errno to indicate failure, it should
>set it to 0 on success.
My understanding is that the ANSI C standard says otherwise, and for
good reason.
If every library function sets errno to 0 when returning correct
results, then it becomes difficult for library functions to call one
another safely - there's a serious risk that they will wipe out an
error code generated by a higher-level, or lower-level library
function.
Consider a hypothetical library function F1(a,b), and an additional
function F2(c). Let's say that the F1 does something like
F1(a,b) = F2(F2(a)+F2(b))
Let's also say that F2() has a limited range (and can set errno to
ERANGE to indicate this), and that F1(a,b) also has certain
combinations of (a,b) which are out of range and result in an errno of
ERANGE.
Now... who should set F2 to 0 to indicate success?
Should F2 set errno to 0 upon successful return? If so, the easy and
obvious implementation of F1() above can't be done... F2 is being
called three times, and the later calls to F2 would wipe out any
ERANGE error returned by the earlier calls. F1 would have to
initialize a private shadow-of-errno to 0, make _individual_ calls to
F2, check errno after each one, and set its shadow to ERANGE if any
single call to F2 set errno to ERANGE. It would then set errno to its
shadow prior to returning.
Should F1 set errno to 0? If so, every function which calls F1
is going to have the same problem - it's going to have to construct a
local shadow of errno as it goes through its steps and calls
lower-level functions (including F1).
This would play merry hell with the runtime efficiency of routines
which set errno - it would add a great deal of additional work, and
bloat the code.
Instead, the standard (and the glibc implementation) take a different
approach to the problem. They declare that it's the responsibility of
the high-level code which _cares_ about the error/no-error situation
to preinitialize errno to 0 at appropriate points. It can then
perform any desired sequence of operations (including linear, nested,
and recursive calls to the library routines), and then test errno to
see if _any_ library routine in that sequence indicated that an error
occurred. The high-level code need not check errno after _every_ call
to the library - only after the last one.
The libraries are thus smaller and more efficient, and there's far
less chance that an error generated by one library call will be "lost"
due to a no-error return by a later call.
That's how it works. I realize that you may disagree with it in
principle, but you're going to have to live with it.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Thu, 03 Aug 2000 18:09:13 -0700
Dave Platt wrote:
> tye4 wrote:
>
> > This is a bug. If a function uses errno to indicate failure, it
> > should set it to 0 on success.
>
> My understanding is that the ANSI C standard says otherwise, and for
> good reason.
You're absolutely correct. C99, Section 7.5/3 reads, "The value of
errnois zero at program startup, but is never set to zero by any library
function [170]." The corresponding footnote reads, "Thus, a program
that uses errno for error checking should set it to zero before a
library function call, then inspect it before a subsequent library
function call. Of course, a library function can save the value of
errno on entry and then set it to zero, as long as the original value is
restored if errno's value is still zero just before the return."
Indeed, that is not only not a bug, but is a feature.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Conversation is the enemy of good wine and food.
\__/ Alfred Hitchcock
Kepler's laws / http://www.alcyone.com/max/physics/kepler/
A proof of Kepler's laws.
------------------------------
From: Tim Moore <[EMAIL PROTECTED]>
Subject: Re: ntfs support in kernel 2.2.14?
Date: Fri, 04 Aug 2000 01:41:33 GMT
[2.2.14 + ide patch]
Windows NT NTFS support (read only)
CONFIG_NTFS_FS
NTFS is the file system of Microsoft Windows NT. Say Y if you want
to get read access to files on NTFS partitions of your hard drive.
The Linux NTFS driver supports most of the mount options of the VFAT
driver, see Documentation/filesystems/ntfs.txt. Saying Y here will
give you read-only access to NTFS partitions.
This code is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you want).
The module will be called ntfs.o. If you want to compile it as a
module, say M here and read Documentation/modules.txt.
NTFS read-write support (experimental)
CONFIG_NTFS_RW
If you say Y here, you will (hopefully) be able to write to NTFS
file systems as well as read from them. The read-write support
in NTFS is far from being complete and is not well tested. If you
enable this, back up your NTFS volume first since it may get
damaged.
If unsure, say N.
Kent Bergelin wrote:
>
> Is there yet no ntfs support for Linux kernel 2.2? I was convinced there
> was.....
>
> There is an alpha patch at www.penguin.cz which claims itself to be "very
> buggy". Are there other resources to Your knowledge?
>
> My only need is to mount two local ntfs partitions.
--
timothymoore
bigfoot
com
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Thu, 03 Aug 2000 18:46:52 -0700
Following your logic, no function should set errno to 0. Hence, all system
calls should return -1 on failure and checking errno will the application
the exact error. Nobody should be required to set errno before calling a
function (this is the first time I'm doing such a thing.)
The prototype of strtol should be rewritten from:
long int strtol(const char* s, char **endptr, int base);
to:
int strtol(const char* s, long int* result, char**endptr, int base);
// error if return == -1 and endptr does not point to application specific
value
tye4
Dave Platt wrote:
> If every library function sets errno to 0 when returning correct
> results, then it becomes difficult for library functions to call one
> another safely - there's a serious risk that they will wipe out an
> error code generated by a higher-level, or lower-level library
> function.
>
> Consider a hypothetical library function F1(a,b), and an additional
> function F2(c). Let's say that the F1 does something like
>
> F1(a,b) = F2(F2(a)+F2(b))
>
> Let's also say that F2() has a limited range (and can set errno to
> ERANGE to indicate this), and that F1(a,b) also has certain
> combinations of (a,b) which are out of range and result in an errno of
> ERANGE.
>
> Now... who should set F2 to 0 to indicate success?
>
> Should F2 set errno to 0 upon successful return? If so, the easy and
> obvious implementation of F1() above can't be done... F2 is being
> called three times, and the later calls to F2 would wipe out any
> ERANGE error returned by the earlier calls. F1 would have to
> initialize a private shadow-of-errno to 0, make _individual_ calls to
> F2, check errno after each one, and set its shadow to ERANGE if any
> single call to F2 set errno to ERANGE. It would then set errno to its
> shadow prior to returning.
>
> Should F1 set errno to 0? If so, every function which calls F1
> is going to have the same problem - it's going to have to construct a
> local shadow of errno as it goes through its steps and calls
> lower-level functions (including F1).
>
> This would play merry hell with the runtime efficiency of routines
> which set errno - it would add a great deal of additional work, and
> bloat the code.
>
> Instead, the standard (and the glibc implementation) take a different
> approach to the problem. They declare that it's the responsibility of
> the high-level code which _cares_ about the error/no-error situation
> to preinitialize errno to 0 at appropriate points. It can then
> perform any desired sequence of operations (including linear, nested,
> and recursive calls to the library routines), and then test errno to
> see if _any_ library routine in that sequence indicated that an error
> occurred. The high-level code need not check errno after _every_ call
> to the library - only after the last one.
>
> The libraries are thus smaller and more efficient, and there's far
> less chance that an error generated by one library call will be "lost"
> due to a no-error return by a later call.
>
> That's how it works. I realize that you may disagree with it in
> principle, but you're going to have to live with it.
>
> --
> Dave Platt [EMAIL PROTECTED]
> Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
> I do _not_ wish to receive unsolicited commercial email, and I will
> boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Jonathan Kamens)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: 4 Aug 2000 01:14:02 GMT
In article <[EMAIL PROTECTED]>,
tye4 <[EMAIL PROTECTED]> writes:
>This is a bug. If a function uses errno to indicate failure, it should set it to 0
>on success.
No. It is not that way and it has never been that way.
Functions do not use errno to indicate failure. They use their return
values to indicate failure. When the return value of a function
indicates failure, *then* errno can be used to find out the cause of
the failure.
As specified in the man page for strtol, it returns LONG_MIN to
indicate an underflow or LONG_MAX to indicate an overflow. If either
of these errors occur, then errno can be consulted to determine the
cause of the error (which, in the case of strtol, shouldn't be anything
but ERANGE, but you never know).
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: read() and directories
Date: Fri, 04 Aug 2000 02:17:26 GMT
In article <[EMAIL PROTECTED]>, Daniel P. Katz wrote:
>I don't quite follow this. I mean, I understand the problem of people
>doing silly low level coding when they ought to be using a higher
>level abstraction, but actively forbidding people to *see* how
>something is physically implemented seems an extreme response.
If you're going to impliment read(), then you're required to convert
whatever a directory "is" into a byte stream. Prehaps some filesystems
impliment a directory as a stream of bytes -- for those systems implimenting
read() is easy. For other systems, implimenting read() might take a lot
more effort than it's worth.
--
Grant Edwards grante Yow! It's OKAY --- I'm an
at INTELLECTUAL, too.
visi.com
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Fri, 04 Aug 2000 02:27:49 GMT
In article <[EMAIL PROTECTED]>, tye4 <[EMAIL PROTECTED]> wrote:
>Following your logic, no function should set errno to 0.)
No conforming ANSI C library function should ever set errno to 0.
That's _specifically_ what the spec says - somebody was kind enough to
quote the exact working of the spec.
> Hence, all system
>calls should return -1 on failure and checking errno will the application
>the exact error.
It seems to me that you've being unnecessarily contentious, tye.
That's not at all what the specification requires, nor is it a good
idea.
> Nobody should be required to set errno before calling a
>function (this is the first time I'm doing such a thing.
You keep using this word "should". That's an opinion, and of course
you're perfectly welcome to hold such an opinion.
The fact of the matter is: if you are writing in C, and using the
standard C library, and you wish to use the errno feature, you _do_
have to set errno to 0 at points in your code which are appropriate
for your application.
That's what the standard says. That's how everybody implements it.
"Should" has nothing to do with it, except intellectually.
You're free to feel that this is inelegant, bletcherous, morally
wrong, and likely to cause the decline and fall of Western
civilization, if you wish.
You are utterly unlikely to be able to persuade _anyone_ to change
either the standard, or the existing library implementations, to
conform to your point of view. This sort of change would break far,
far too many programs.
>The prototype of strtol should be rewritten from:
>
>long int strtol(const char* s, char **endptr, int base);
>
>to:
>
>int strtol(const char* s, long int* result, char**endptr, int base);
>
>// error if return == -1 and endptr does not point to application specific
>value
*SIGH*
You're welcome to design your own library which does things that way.
Just don't expect anyone to call it "stdlib.h" or "stdio.h".
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Thu, 03 Aug 2000 19:40:28 -0700
Jonathan Kamens wrote:
> As specified in the man page for strtol, it returns LONG_MIN to
> indicate an underflow or LONG_MAX to indicate an overflow. If either
> of these errors occur, then errno can be consulted to determine the
> cause of the error (which, in the case of strtol, shouldn't be anything
> but ERANGE, but you never know).
There is at least one case where strtol returns error by the above definition,
_even when the input is right_. There is no way around it if the prog is multithreaded.
program has two threads:
////////////////////////////////////////////////
func_thread1()
{
int num;
num = strtol( "999999999999999" );
// number too big; errno is now set to ERANGE
num == LONG_MAX && errno == ERANGE --> therefore error
}
/////////////////////////////////////////////////////
func_thread2()
{
errno = 0; // clear error
// meanwhile, this thread is preempted, and func_thread1() runs and
// sets errno = ERANGE
// read LONG_MAX
num = strtol("2147483647");
// num == LONG_MAX && errno == ERANGE --> hence error
// error condition detected even when input is valid
}
In any case, setting errno to 0 is not a good idea in a multithreaded program because
you might erase errno's value set by some other system function.
tye4
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: Fri, 04 Aug 2000 02:55:06 GMT
In article <[EMAIL PROTECTED]>, tye4 <[EMAIL PROTECTED]> wrote:
>
>
>Jonathan Kamens wrote:
>
>> As specified in the man page for strtol, it returns LONG_MIN to
>> indicate an underflow or LONG_MAX to indicate an overflow. If either
>> of these errors occur, then errno can be consulted to determine the
>> cause of the error (which, in the case of strtol, shouldn't be anything
>> but ERANGE, but you never know).
>
>There is at least one case where strtol returns error by the above definition,
>_even when the input is right_. There is no way around it if the prog is
>multithreaded.
My recollection, such as it is, is that the original ANSI C library is
not thread-safe. Therefore, using it in a multithreaded application
produces results which are quite undefined.
>program has two threads:
>
>////////////////////////////////////////////////
>func_thread1()
>{
> int num;
>
> num = strtol( "999999999999999" );
> // number too big; errno is now set to ERANGE
>
> num == LONG_MAX && errno == ERANGE --> therefore error
>}
>
>/////////////////////////////////////////////////////
>func_thread2()
>{
> errno = 0; // clear error
>
> // meanwhile, this thread is preempted, and func_thread1() runs and
> // sets errno = ERANGE
>
> // read LONG_MAX
> num = strtol("2147483647");
>
> // num == LONG_MAX && errno == ERANGE --> hence error
>
> // error condition detected even when input is valid
>}
>
>In any case, setting errno to 0 is not a good idea in a multithreaded
>program because you might erase errno's value set by some other
>system function.
Using a non-thread-save ANSI C library in a multithreaded application
is not a good idea. You'll end up with FAR WORSE problems, most
likely, than an incorrect errno setting.
I believe that more recent definitions of the ANSI C library spec have
been reworked so that they are thread-safe. In these versions (when
properly implemented) errno does not have the problem you describe.
As I recall, in order to be thread-safe, you must not use the usual
extern int errno;
reference in your code. Instead, you simply
#include <errno.h>
and the include file brings in a thread-safe version of errno. In the
versions I've seen, errno is not defined as an ordinary extern -
instead, it's #define'd as a field in the current thread's private
data structure.
This way, you can test, and assign values (0, and error codes) to
"errno" in either user code or library code, and this has no effect on
the value of "errno" in any other thread.
Another way of doing it is to have "errno" be defined via the usual
extern, and to have the operating system or thread-switching library
(e.g. pthreads) maintain a thread-local copy in the thread private
data structure. Whenever you switch from thread1 to thread2, the
system copies the extern variable "errno" into the thread1 private
data area, and then moves the thread2 private copy of "errno" into the
extern variable. This has the same effect as the first
implementation... each thread has an independent errno value... but
doesn't disallow the old-style "extern int errno;" declaration.
And, in both of these implementations (and any other thread-safe ANSI
C versions), it is _still_ the responsibility of the application
writer to set errno to 0 at appropriate points!
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Jonathan Kamens)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Date: 4 Aug 2000 02:40:19 GMT
Oh, my God! The strtol() function can't be used to parse a number
equal to LONG_MIN or LONG_MAX! Whatever will we do? The world is
coming to an end! Run for the hills!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: glibc bug strtol
Reply-To: [EMAIL PROTECTED]
Date: Fri, 04 Aug 2000 03:03:48 GMT
On Thu, 03 Aug 2000 16:53:33 -0700, tye4 <[EMAIL PROTECTED]> wrote:
>// uncomment next line for correct behaviour
>// errno = 0;
>
>num = strtol("5", &endptr, 10);
>perror("should be success");
>
>
>This is a bug. If a function uses errno to indicate failure, it should set it to 0
>on success.
Sheer nonsense, read the applicable standards.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
