[Toybox] [PATCH] new Android toy: log

[Rob Landley]

On 06/21/2016 05:29 PM, enh wrote:
> On Tue, Jun 21, 2016 at 2:13 PM, Rob Landley <rob at landley.net> wrote:
>> On 06/20/2016 07:41 PM, enh wrote:
>>> the logging library will actually silently truncate long strings, so
>>> it might make sense to have something like "if (strlen(toybuf) > 1024)
>>> break;" in the main loop. but i doubt anyone will ever notice the
>>> difference...
>>
>> It seems to me like the break should emit a warning to stderr that it
>> was truncated. (Silent loss of data makes me uncomfortable. That said,
>> failure to log because string too long also seems wrong, which is what
>> xstrncat() will do at 4k when it calls error_exit().)
> 
> i just checked, and liblog (i.e. the choke point for all logging) will
> silently truncate. i did consider writing this with xmprintf and just
> leaving the guilt at liblog's door...

Writing truncated log data seems less of an error than failing to log
anything. Warning that it was truncated but still logging what we can
seems like the best compromise, but I could be talked out of it. :)

>> Is 1024 the specific value the logging library will truncate at, or an
>> approximation?
> 
> there's no public constant for that, and it's an implementation
> detail, but, yeah, it's been 1024 for a long time.
> 
>> Let's see, cleanup comments:
>>
>> Don't #ifdef ANDROID on something that already depends on
>> TOYBOX_ON_ANDROID, we only compile it when it's buildable (compile-time
>> probes set the symbol). Typing "make log" at the command line assumes
>> you know what you're doing, and building an empty command isn't an
>> improvement.
> 
> like i say each time this comes up :-) --- i need to be able to "make"
> on the host to be able to run all your stuff to generate the generated
> files. we could add bogus implementations to portability, but then you
> end up with quite a lot of fake android crap in there...

It regenerates all the headers before it tries to compile any of the *.o
files, so a failing build should still update the headers. I realize
that's untidy though. Maybe what I need to do is add a "make
check_headers" target?

> (right now, half the toys/android directory has #if __ANDROID__, and
> the other half is SELinux stuff that is likely to be useful to some
> non-Android folks.)

Yeah, I'm not sure how best to organize this stuff.

Moving toys/*.c into subdirectories was mainly because I wanted to label
"posix" and "lsb" commands in an obvious way. The "example" directory
was also logical to split out, since you generally don't deploy that stuff.

The android dir was split out more or less because you maintain that and
I can't always even build it. (Although I keep meaning to fix that last
part.)

I've pondered splitting "net" out of "other", but haven't because there
isn't really a huge _benefit_, just... one big heap got kind of untidy.

>> Re-wordwrapped help text and added *. (If we recognize it, we should
>> document it, although don't you have to quote * to avoid shell
>> wildcarding it?)
> 
> yeah, i sincerely doubt anyone's ever used that. i was brave enough to
> not document it, but not brave enough to remove it. maybe we should
> just remove it and wait until someone notices instead?

I leave that decision to you. I don't know enough here to even have a
strong opinion...

Rob