The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
Date: Tue, 28 Nov 2017 10:34:13 -0800	[thread overview]
Message-ID: <20171128183428.A825F156E523@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Tue, 28 Nov 2017 10:56:52 -0700." <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>

On Tue, 28 Nov 2017 10:56:52 -0700 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Tue, Nov 28, 2017 at 9:21 AM, Nemo <cym224 at gmail.com> wrote:
> 
> > 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.

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!



  parent reply	other threads:[~2017-11-28 18:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 14:52 /bin/true (was [TUHS] " Ron Natalie
2017-10-19 15:01 ` Pete Wright
2017-10-19 15:17   ` Chet Ramey
2017-10-19 21:23 ` Steffen Nurpmeso
2017-10-19 21:43   ` Chet Ramey
2017-10-19 23:00     ` [TUHS] /bin/true (was " Dave Horsfall
2017-10-19 23:14       ` Grant Taylor
2017-10-19 23:23         ` Lyndon Nerenberg
2017-10-19 23:27         ` Kurt H Maier
2017-10-22  4:18           ` Dave Horsfall
2017-10-20 12:10       ` Chet Ramey
2017-10-19 21:43 ` /bin/true (was [TUHS] " Dave Horsfall
2017-10-19 22:04   ` Ronald Natalie
2017-10-19 23:25     ` [TUHS] /bin/true (was " Dave Horsfall
     [not found] ` <CAEoi9W7YZ7YXUip0JTMGip3Nd0czgdjqRCMRcK2GYmDJsckuDg@mail.gmail.com>
     [not found]   ` <CAEoi9W4zdJ3+RXjK5-5rAJ6rwx_0kx6N-bn1U61=txJGyLT_mw@mail.gmail.com>
2017-10-20  1:27     ` Dan Cross
2017-10-20  1:31       ` Lyndon Nerenberg
2017-10-20  2:05         ` Ronald Natalie
2017-11-28 16:21 ` Nemo
2017-11-28 17:56   ` Warner Losh
2017-11-28 18:26     ` Dan Cross
2017-11-28 18:41       ` Warner Losh
2017-11-28 19:09         ` Dan Cross
2017-11-28 20:34           ` Clem Cole
2017-11-28 22:42           ` Ralph Corderoy
2017-11-28 18:34     ` Bakul Shah [this message]
2017-11-28 23:25     ` Ralph Corderoy
2017-10-22 23:00 Doug McIlroy
2017-10-23  1:11 ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171128183428.A825F156E523@mail.bitblocks.com \
    --to=bakul@bitblocks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).