The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: imp@bsdimp.com (Warner Losh)
Subject: [TUHS] /bin/true (was basic tools / Universal Unix)
Date: Tue, 28 Nov 2017 11:41:23 -0700	[thread overview]
Message-ID: <CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com> (raw)
In-Reply-To: <CAEoi9W4Xkk7pfP=q+WV_v=vfFy9PRq9bmjxH4n-mmt=PMOoRbw@mail.gmail.com>

On Tue, Nov 28, 2017 at 11:26 AM, Dan Cross <crossd at gmail.com> wrote:

> 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.
>

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
> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/e92b7118/attachment-0001.html>


  reply	other threads:[~2017-11-28 18:41 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 [this message]
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='CANCZdfrT7PH61=uoy_9p=ORudi+qFwCuipW6Q=N=+w_WQCgBig@mail.gmail.com' \
    --to=imp@bsdimp.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).