bug-sh-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug Report


From: Bob Proulx
Subject: Re: Bug Report
Date: Mon, 22 Oct 2001 21:48:59 -0600

> I am porting an application from HP-UX to Linux
> the sleep call does not work as it should.

You have asked a question which I am putting in the FAQ list.

> In man 3 sleep is declared to accept unsigned in sec. but it does not. (
> 2^32 - 1 sec )

But if you are having a problem with sleep(3) then you should be
reporting it to the glibc folks and not to the sh-utils list.  But no
regrets.  Many people have the same confusion.

> I used a sleep forever  as follows:
> 
> if ( true )
>    {
>         do
>            {
>              sleep ( 4000000000 );
>             }
>     while ( 1 );
>    }

With the exception that 4000000000 is too big for the default value of
"int" that looks fine to me.  It should be 4000000000U, note the 'U'
on the end, to make it unsigned.

> I use the loop in case a signal hits the sleep call.
> The sleep call returns immediately and the loop eats up all my CPU time.
> 
> Of course I know how to work around but still ...
> What is wrong with the sleep call ?

The sleep(3) is a libc library routine.  A canned reply follows.  Note
that if you decide to report this as a bug you should include the
version of your glibc library.

Bob


This frequently occurs with a question such as, I have found a bug in
the sleep() function, or, I am trying to use the chown() function in my
program.  That may well be true.  But those library functions are not
the same as the command line programs.  The command line program in the
GNU utilities are also C program and just like your program are using
the same C library and operating system calls.  But we can't help you
with your problem since that code is in the system's C library and not
in any of the utility packages.

Sometimes the same name is used for both a program and a system call.
In fact most of the programs got their names because that was what the
system call was named.  One caused the other.  Which means that it is
very likely that the "sleep" program was named because it used the
"sleep" library routine.

This usually happens with "chgrp", "chmod", "chown", "mkdir", "mknod",
"nice", "rmdir", "sleep", "sync", "uname", or one of the other
programs that have a name matching a C programming routine.  It can be
confusing to realize that the program is a wrapper to the underlying
library routine or system call.  If you are compiling a program then
you are NOT using the GNU command line utility in your C/C++ program.
You could be using the GNU command line utility in your shell script,
however.

You may be confusing the C library routine used in your program with
the shell command line program.  They are not related.  Except that
the program calls the library function just like your program does.
If you have a real bug in the library routine then you need to
determine who supplied that library and report the bug to them.  If it
is the GNU Lib C, a.k.a. glibc, provided library then the glibc
mailing list at <address@hidden> might be a useful future
reference.

The online man pages can also be confusing in regard to this.  If you
are trying to use chown() in a program and get a man page you will
likely get the man page for the command line program and not the
library routine you were looking for.  You must specify the section of
the manual that you want information.

  man chown
  man 2 chown
  man sleep
  man 3 sleep

Traditionally man pages are organized by section number.  Section 1 are
command line programs.  Section 2 are operating system calls, aka kernel
calls.  Section 3 are library routines.  Library routines may or may not
use system calls.  Etc.  Other sections are used for other purposes that
are not germane here.

Many GNU programs have deprecated the man pages and have moved
entirely to info documentation.  But man pages still have a loyal
following and are quite useful for reference.  But they make poor user
guides.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]