19 Oct
2017
19 Oct
'17
4:52 p.m.
My favorite reduction to absurdity was /bin/true. Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
19 Oct
19 Oct
5:01 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On 10/19/2017 07:52, Ron Natalie wrote:
My favorite reduction to absurdity was /bin/true.
Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
heh yea it certainly seems pretty funny, but i will say it did present a
neat opportunity for the NYC BSD user-group back in 2015:
http://www.nycbug.org/index.cgi?action=view&id=10635
it was pretty funny to see how many different implementations one could
dream up for such a simple program, and it seemed to speak to how each
project approaches complexity.
-pete
--
Pete Wright
pete(a)nomadlogic.org
@nomadlogicLA
5:17 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On 10/19/17 11:01 AM, Pete Wright wrote:
heh yea it certainly seems pretty funny, but i will
say it did present a
neat opportunity for the NYC BSD user-group back in 2015:
http://www.nycbug.org/index.cgi?action=view&id=10635
it was pretty funny to see how many different implementations one could
dream up for such a simple program, and it seemed to speak to how each
project approaches complexity.
It's a nitpick, but I notice they didn't use the actual bash code that
implements this, but rather an example template for a loadable shell
builtin.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
11:23 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
Mr. Ron Natalie,
"Ron Natalie" <ron(a)ronnatalie.com> wrote:
|My favorite reduction to absurdity was /bin/true. Someone decided we
|needed shell commands for true and false. Easy enough to add a script that
|said "exit 0" or exit 1" as its only line.
|Then someone realized that the "exit 0" in /bin true was superfluous, the
|default return was 0. /bin/true turned into an empty, yet executable, file.
i am actively chewing on this.
These things can be found by the exec family of C functions,
as Chet Ramey points out from time to time (but i think on other
lists). That even makes things which make no sense but as
a shell builtin a little bit understandable... maybe..
I for one am ever so fascinated of Unix!
I cannot remember what i thought once entering the Unix world,
i remember i first did not understand why and that [ etc. do exist.
|Then the lawyers got involved. We got a version of a packaged UNIX (I
|think it was Interactive Systems). Every shell script got twelve lines of
|copyright/license boilerplate. Including /bin true.
|The file had nothing but useless comment in it.
Yes. But then nonetheless quite the opposite, it was very strange
looking at Plan9 source code which does not have such a file
header, after living in the world of BSD and GNU source code for
one and a half decade. Different to your experience, for me the
lawyers were there first.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
11:43 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On 10/19/17 5:23 PM, Steffen Nurpmeso wrote:
These things can be found by the exec family of C
functions,
as Chet Ramey points out from time to time (but i think on other
lists).
Yes, Posix requires that all builtins be execable. It doesn't require
true and false to be implemented as builtins, though.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
20 Oct
20 Oct
1 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Thu, 19 Oct 2017, Chet Ramey wrote:
Yes, Posix requires that all builtins be execable. It
doesn't require
true and false to be implemented as builtins, though.
Good luck with "cd"...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
1:23 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
: lyndon@orthanc:/home/lyndon; cat ./cd
#!/bin/sh
builtin cd $1 && /bin/sh -i
1:27 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Thu, Oct 19, 2017 at 05:14:49PM -0600, Grant Taylor via TUHS wrote:
On 10/19/2017 05:00 PM, Dave Horsfall wrote:
It's still useful. Minimal example:
[khm@pc ~]$ (exec cd /); echo $?
0
[khm@pc ~]$ (exec cd /nosuchpath); echo $?
/usr/bin/cd: line 2: cd: /nosuchpath: No such file or directory
1
You can use this to dodge some of the crappier shells' problems,
sometimes, or to test for directory accessibility in a clean
environment. I've run across it in the wild on occasion, even if I
don't really play this sort of game myself.
khm
Good luck with "cd"...
There's nothing that states that the executable effectively do anything.
22 Oct
22 Oct
6:18 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Thu, 19 Oct 2017, Kurt H Maier wrote:
It's still useful. Minimal example:
[khm@pc ~]$ (exec cd /); echo $?
0
[khm@pc ~]$ (exec cd /nosuchpath); echo $?
/usr/bin/cd: line 2: cd: /nosuchpath: No such file or directory
1
And others pointed out the same thing; OK, it's obscure (because "test -x
{}" doesn't quite fit the bill) but I'm convinced.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
20 Oct
20 Oct
2:10 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On 10/19/17 7:00 PM, Dave Horsfall wrote:
On Thu, 19 Oct 2017, Chet Ramey wrote:
It doesn't have to do what you think it should. Using `cd' with something
like `find' or `env' is a fine way to test directory accessibility. The
Posix standard contains several examples of such use.
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag…
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
Yes, Posix requires that all builtins be
execable. It doesn't require
true and false to be implemented as builtins, though.
Good luck with "cd"...
19 Oct
19 Oct
11:43 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Thu, 19 Oct 2017, Ron Natalie wrote:
My favorite reduction to absurdity was /bin/true.
Someone decided we
needed shell commands for true and false. Easy enough to add a script
that said "exit 0" or exit 1" as its only line. Then someone realized
that the "exit 0" in /bin true was superfluous, the default return was
0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines
of copyright/license boilerplate. Including /bin true. The file had
nothing but useless comment in it.
I've also seen /bin/true and /bin/false (I've often been tempted to write
"/bin/maybe" to introduce a little non-determinism) as *separate binaries*
i.e. not even linked.
These days they appear to be built-ins (as I would expect).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
20 Oct
20 Oct
12:04 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
I've also seen /bin/true and /bin/false (I've often been tempted to write
"/bin/maybe" to introduce a little non-determinism) as *separate binaries* i.e.
not even linked.
/bin/maybe goes well with the motd that says “You might have mail.” I told one of my
student programmers that he could put that in the motd and I guaranteed that within an
hour someone would come in and tell me that he checked and he didn’t have mail. Sure
enough one of my senior programmers came in and said “It said I might have mail and I
didn’t have any.” I pointed out it only said “might.”
1:25 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Thu, 19 Oct 2017, Ronald Natalie wrote:
/bin/maybe goes well with the motd that says “You
might have mail.” I
told one of my student programmers that he could put that in the motd
and I guaranteed that within an hour someone would come in and tell me
that he checked and he didn’t have mail. Sure enough one of my senior
programmers came in and said “It said I might have mail and I didn’t
have any.” I pointed out it only said “might.”
Seriously, it could be used in test scripts, to see whether a test depends
implicitly upon a previous one, so if something fails it would be worthy
of investigation.
Usage: maybe [p]
Returns "true" (0) with a probability of "p" [0.0:1.0] (default:
0.5),
else "false" (1).
C: exit(**argv != 't'); // Assumes "t*" or not.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
28 Nov
28 Nov
5:21 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On 19 October 2017 at 10:52, Ron Natalie <ron(a)ronnatalie.com> wrote:
My favorite reduction to absurdity was /bin/true.
Someone decided we
needed shell commands for true and false. Easy enough to add a script that
said "exit 0" or exit 1" as its only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable, file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve lines of
copyright/license boilerplate. Including /bin true.
The file had nothing but useless comment in it.
A late comment: I seem to recall this boilerplate in earlier Solaris
but Solaris 10 has an executable. So I looked at the OpenSolaris
source out of curiosity and found this.
[CDDL stuff here]
/*
* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
#pragma ident "%Z%%M% %I% %E% SMI"
#include <unistd.h>
/*
* Exit with a zero value as quickly as possible.
*/
int
main(void)
{
_exit(0);
/*NOTREACHED*/
return (0);
}
N.
6:56 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224(a)gmail.com> wrote:
On 19 October 2017 at 10:52, Ron Natalie
<ron(a)ronnatalie.com> wrote:
Ah, the tyranny of static analysis tools... _exit(0) should be marked such
that the tools know it does not return. This means the /*NOTREACHED*/ isn't
needed. And since there's no real exit path out of main, the return (0) is
equally bogus (because main can't return). Yet lint and other tools have
ushered in this insanity.
I'm glad to see these days that these sorts of lame false positives have
been eliminated...
Then again _exit(0) is a useless optimization. It saves three closes for
files that are bound to be closed at image tear down. If it really is that
important (absent data, my gut tells me it isn't), then this should be
written in assembler. FreeBSD/amd64 would be something like:
#include <sys/syscall.h>
#include <machine/asm.h>
ENTRY(_start)
xor %r10, %r10
mov $SYS_exit, %eax
syscall
END(_start)
This some small hacks to each arch's SYS.h in libc, this could even be
smaller and MI :). this is tiny:
-rwxrwxr-x 1 imp imp 672 Nov 28 10:18 true
text data bss dec hex filename
10 0 0 10 0xa true
Contrast that with FreeBSD's /usr/bin/true:
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56 /usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
Warner
My favorite reduction to absurdity was /bin/true.
Someone decided we
needed shell commands for true and false. Easy enough to add a script
that
said "exit 0" or exit 1" as its
only line.
Then someone realized that the "exit 0" in /bin true was superfluous, the
default return was 0. /bin/true turned into an empty, yet executable,
file.
Then the lawyers got involved. We got a version of a packaged UNIX (I
think it was Interactive Systems). Every shell script got twelve
lines of
copyright/license boilerplate. Including /bin
true.
The file had nothing but useless comment in it.
A late comment: I seem to recall this boilerplate in earlier Solaris
but Solaris 10 has an executable. So I looked at the OpenSolaris
source out of curiosity and found this.
[CDDL stuff here]
/*
* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
#pragma ident "%Z%%M% %I% %E% SMI"
#include <unistd.h>
/*
* Exit with a zero value as quickly as possible.
*/
int
main(void)
{
_exit(0);
/*NOTREACHED*/
return (0);
}
7:26 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp(a)bsdimp.com> wrote:
Ah, the tyranny of static analysis tools... _exit(0) should be marked
such that the tools know it does not return. This means the /*NOTREACHED*/
isn't needed. And since there's no real exit path out of main, the return
(0) is equally bogus (because main can't return). Yet lint and other tools
have ushered in this insanity.
Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.
: tempest; cat r.c
#include <stdio.h>
int
main(int argc, char *argv[])
{
if (argc > 1) {
argc--; argv++;
printf("%s", argv[0]);
if (argc > 1) printf(" ");
return main(argc, argv);
}
printf("\n");
return 0;
}
: tempest; make r
cc r.c -o r
: tempest; ./r hi from Dan
hi from Dan
: tempest;
This is sort of an admittedly weird way to write `echo`, but it seems to
work ok.
I'm glad to see these days that these sorts of lame false positives have
been eliminated...
+1.
Then again _exit(0) is a useless optimization. It saves three closes for
files that are bound to be closed at image tear down.
If it really is that
important (absent data, my gut tells me it isn't), then this should be
written in assembler. FreeBSD/amd64 would be something like:
#include <sys/syscall.h>
#include <machine/asm.h>
ENTRY(_start)
xor %r10, %r10
mov $SYS_exit, %eax
syscall
END(_start)
This some small hacks to each arch's SYS.h in libc, this could even be
smaller and MI :). this is tiny:
-rwxrwxr-x 1 imp imp 672 Nov 28 10:18 true
text data bss dec hex filename
10 0 0 10 0xa true
This is much smaller than the binary for the assembler program I posted for
macOS earlier in this thread: the result there was much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).
Contrast that with FreeBSD's /usr/bin/true:
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56
/usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.
- Dan C.
7:41 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd(a)gmail.com> wrote:
On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh
<imp(a)bsdimp.com> wrote:
Ture but completely irrelevant. If exit happens, the process is done. main
isn't going to return because control never returns back to main. That's
what makes the messages completely bogus. Execution simply stops. _exit()
doesn't cause main() to return to _start(), the process stops executing at
that point.
This is much smaller than the binary for the assembler program I posted for
Ah, the tyranny of static analysis tools... _exit(0) should be marked
such that the tools know it does not return. This means the /*NOTREACHED*/
isn't needed. And since there's no real exit path out of main, the return
(0) is equally bogus (because main can't return). Yet lint and other tools
have ushered in this insanity.
Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.
macOS earlier in this thread: the result there was
much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).
Contrast that with FreeBSD's /usr/bin/true:
Ah yes, I read the source, but hadn't checked the final binary... Most of
the data seems to be other things... It used to get the copyright data
with gcc a long time ago...
Warner
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56
/usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.
8:09 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Tue, Nov 28, 2017 at 1:41 PM, Warner Losh <imp(a)bsdimp.com> wrote:
There is, perhaps, some debugging value in embedding ident strings in
object code: one can see which versions of which sources were used to
construct a given binary. I suspect the incremental value of such things is
diminishing with faster computers and fast (relatively) compilation; it's
easier to simply construct a binary from known versions of source files
than to extrapolate versions of files from a known binary. I can't think of
a great use case for embedding copyright data into an object file, however.
- Dan C.
On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd(a)gmail.com> wrote:
I think perhaps we are talking past one another.
You had written '(because main can't return)' and it seems (if you'll
forgive me putting words in your mouth, so to speak) that you either
intended to say that _exit() can't return, or that main can't return *in
this context* (because it invoked exit). Exit obviously cannot return, as
you and I both explicitly mentioned, but I was addressing the comment that
*main* cannot return. main() absolutely can return, just not _here_.
This is much smaller than the binary for the assembler program I posted for
On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh
<imp(a)bsdimp.com> wrote:
Ture but completely irrelevant. If exit happens, the process is done. main
isn't going to return because control never returns back to main. That's
what makes the messages completely bogus. Execution simply stops. _exit()
doesn't cause main() to return to _start(), the process stops executing at
that point.
Ah, the tyranny of static analysis tools... _exit(0) should be marked
such that the tools know it does not return. This means the /*NOTREACHED*/
isn't needed. And since there's no real exit path out of main, the return
(0) is equally bogus (because main can't return). Yet lint and other tools
have ushered in this insanity.
Hmm; in what way can main() not return? Surely this is true if `_exit(0)`
is called as this calls the exit system call, which cannot -- by definition
-- return. But main() itself can return to whatever calls it (usually
`start`, I'd imagine). For that matter, I'm not aware of any prohibition
against calling `main()` recursively.
macOS earlier
in this thread: the result there was much larger (but due to
the requirement to have a non-empty data segment in the executable; this
ends up being page-aligned and filled with zeros).
Contrast that with FreeBSD's /usr/bin/true:
Ah yes, I read the source, but hadn't checked the final binary... Most of
the data seems to be other things... It used to get the copyright data
with gcc a long time ago...
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56
/usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
Is the copyright data actually present in the object file? I see some RCS
$Id$ strings (in the guise of $FreeBSD:$ stuff) but no copyright strings in
/usr/bin/true on my system.
9:34 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
I'm not a lawyer nor play one on TV. That said, I talk to a lot of them
and have worked for firms that have to deal with this sort of issue. Your
milage may vary ....
On Tue, Nov 28, 2017 at 2:09 PM, Dan Cross <crossd(a)gmail.com> wrote:
I can't think of a great use case for embedding
copyright data into an
object file, however.
This is from some one who used to work for TPC who took out a copyright on
every page in the phone directory.
As I understand it from my legal folks, it is all post the Franklin/Apple
case. Making sure all object files also have legally recognized set of
stamps in them.
I suspect one can argue with the judge that a single copyright notice are
coving all of the SCCS stamps on from all the files shipped in the release
(source or binary). But just like putting a copyright on every page in the
phone book, I think the argument is that a page can ripped from the phone
book and a binary and can copied from a system. Because of the 'motion'
of the object, making sure every object has a mark is best.
11:42 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
Hi Dan,
There is, perhaps, some debugging value in embedding
ident strings in
object code: one can see which versions of which sources were used to
construct a given binary.
That's died away, but there is a `build ID' that's gained favour with
the pursuit of `reproducable builds', e.g. don't have the compiler add a
timestamp.
$ readelf -n /bin/true
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.32
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 32c992f2f7265996a76ca416c229b92f4c9edcf4
$
https://en.wikipedia.org/wiki/Deterministic_compilation
https://reproducible-builds.org/
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
7:34 p.m.
New subject: /bin/true (was basic tools / Universal Unix)
On Tue, 28 Nov 2017 10:56:52 -0700 Warner Losh <imp(a)bsdimp.com> wrote:
Warner Losh writes:
On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224(a)gmail.com> wrote:
int main(void) { return 0; }
is sufficient for true. BTW this is pretty much what
/usr/src/usr.bin/true/true.c does.
And true can also be a file of length 0 chmoded to +x. No
need to optimize such things.
It should really be linked staticallly but crt1.o seems to
bring in the entire libc. I guess linking with just the things
a program needs is a hard problem!
A late comment: I seem to recall this
boilerplate in earlier Solaris
but Solaris 10 has an executable. So I looked at the OpenSolaris
source out of curiosity and found this.
[CDDL stuff here]
/*
* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
#pragma ident "%Z%%M% %I% %E% SMI"
#include <unistd.h>
/*
* Exit with a zero value as quickly as possible.
*/
int
main(void)
{
_exit(0);
/*NOTREACHED*/
return (0);
}
Ah, the tyranny of static analysis tools... _exit(0) should be marked such
that the tools know it does not return. This means the /*NOTREACHED*/ isn't
needed. And since there's no real exit path out of main, the return (0) is
equally bogus (because main can't return). Yet lint and other tools have
ushered in this insanity.
I'm glad to see these days that these sorts of lame false positives have
been eliminated...
Then again _exit(0) is a useless optimization. It saves three closes for
files that are bound to be closed at image tear down. If it really is that
important (absent data, my gut tells me it isn't), then this should be
written in assembler. FreeBSD/amd64 would be something like:
#include <sys/syscall.h>
#include <machine/asm.h>
ENTRY(_start)
xor %r10, %r10
mov $SYS_exit, %eax
syscall
END(_start)
This some small hacks to each arch's SYS.h in libc, this could even be
smaller and MI :). this is tiny:
-rwxrwxr-x 1 imp imp 672 Nov 28 10:18 true
text data bss dec hex filename
10 0 0 10 0xa true
Contrast that with FreeBSD's /usr/bin/true:
-r-xr-xr-x 1 root wheel 4624 Nov 20 11:56 /usr/bin/true
text data bss dec hex filename
1540 481 8 2029 0x7ed /usr/bin/true
which is little more than return(0), but also has a fair amount of
copyright and SCCS data.
29 Nov
29 Nov
12:25 a.m.
New subject: /bin/true (was basic tools / Universal Unix)
Hi Werner,
...
* Exit with a
zero value as quickly as possible.
...
> _exit(0); Then again _exit(0) is a useless optimization. It
saves three closes
for files that are bound to be closed at image tear down.
It also avoids checking the atexit(3) list, yet here on Linux x86_64
with glibc 2.26-6, `_exit(0)' is more instructions to execute than
`return 0', as measured with `perf stat -e instructions ./exit'.
`return 0' can just do
xor %eax, %eax
retq
whereas _exit makes room on the stack before the JSR, and that's through
the dynamic-linking table, `PLT'.
sub $0x8, %rsp
xor %edi, %edi
callq 530 <_exit@plt>
Even with `-static' linking, `return 0' wins on instruction count.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
2546
days inactive
2586
days old
22 comments
15 participants
participants (15)
-
Bakul Shah -
Chet Ramey -
Clem Cole -
Dan Cross -
Dave Horsfall -
Grant Taylor -
Kurt H Maier -
Lyndon Nerenberg -
Nemo -
Pete Wright -
Ralph Corderoy -
Ron Natalie -
Ronald Natalie
-
Steffen Nurpmeso -
Warner Losh