From: crossd@gmail.com (Dan Cross)
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
Date: Tue, 28 Nov 2017 13:26:54 -0500 [thread overview]
Message-ID: <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com> (raw)
In-Reply-To: <CANCZdfqwK1WT8FLJsJs6Eu9TqxABJzx4Nm7niHo3yxFtUk7+0A@mail.gmail.com>
On Tue, Nov 28, 2017 at 12:56 PM, Warner Losh <imp at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/bdce1e28/attachment.html>
next prev parent reply other threads:[~2017-11-28 18:26 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 [this message]
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
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='CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com' \
--to=crossd@gmail.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).