[Toybox] [PATCH] Use NULL rather than 0 in vargs.

[enh]

On Sun, Dec 10, 2017 at 12:28 PM, Rob Landley <rob at landley.net> wrote:
> My first weekend back home in Austin, and GOING to pick something to
> spend some time on, and I guess it's this. :)
>
> On 12/05/2017 11:32 AM, enh wrote:
>> want me to switch to arrays? (and if so, presumably using ARRAY_LEN
>> rather than an explicit end element?)
>
> I can do it as part of my cleanup pass. Let's see...
>
> You sent in commit eb7e847adcec removing periods from help text and then
> submit a command with periods in help text. :)

always a problem trying to match someone else's style. (a check in the
generator script might be a good idea.)

> There is no tests/stty.test. I'm not entirely sure how to make one
> either. Um... (Even with a qemu instance to test under, I'd need a pty
> wrapper to automate testing of this. I've considered _writing_ a pty
> wrapper for a while, it's in the "implement screen" bucket. And other
> stuff like set baud and print baud... if it's the same implementation
> setting and checking you're not showing that it's _right_, just that it
> matches...)

that was my problem too. i just did manual testing on throwaway terminals.

> One of the reasons I hadn't done stty yet is I'm not sure how much of
> the serial settings are relevant in 2017. Every serial port in the world
> was 8-n-1 already in the 80's, so the even/odd/parity stuff is a
> historical relic.

me neither. that's why i'd got by with a much smaller subset. i wasn't
going to add any of the "weird shit" from the end of the POSIX spec
until i noticed that all the examples i could find (including on the
toybox mailing list) tended to use those rather than the "canonical"
forms.

> Um, shouldn't stty operate on _stdout_ instead of stdin when modifying?
> Hmmm... no, I guess not, the other one isn't doing so and "cooked/raw"
> are stdin questions anyway. So yes, open stdin for _writing_. Which
> presumably means the shell that launched us has to have opened stdin for
> writing if it's a tty? I should write that down somewhere...
>
> Lots of things can be inlined, starting with do_stty().
>
> Trivial code style tweaks: I generally don't put curly brackets around
> single lines, and when an if () is multiline I put the curly bracket at
> the start of the next line. Space after commas in function arguments
> (unless removing some brings it under 80 columns to avoid a line split).
>
> Factor out xtcgetattr() doing the error handling (just into a static
> function so it can still use the globals, only two calls but still a win).
>
> You have the baud list in microcom.c already, it should move to lib.

i think i put in a TODO for that. i assumed it would be easier to get
this in if the initial patch was self-contained.

> And
> I already did the bit pattern skipping compression, but I didn't make
> the array unsigned short and multiply by 100 safter 57600. (It's the
> same logic as the skip.) Query: why do you allow 0 as a baud value? Does
> that have some meaning?

it has _some_ meaning, though i admit i've no idea what. there's a
constant for it, GNU stty lets you set it, the kernel doesn't complain
and duly reports it back...

> (The serial ports I've dealt with recently were
> all USB so it was a packet protocol, and then the j-core uartlite device
> is simple hardware running at a fixed speed, so I'm trying to think when
> the last time is I set a serial port speed. Probably the cortex-m board,
> but the kernel set the speed of that for me. Makes it kind of hard to
> TEST any changes I make here, doesn't it?)
>
> N_TTY is 0 so all the low bounds of get_arg() are zero. I can cheat by
> having all the non-option arguments come first, and then when we fall
> down to the right point parse the next numerical argument...
>
> We don't actually care about the return value of tcsetattr() as long as
> the returned data is right when we tcgetattr() on the next line.

i did actually wonder about being clever because we basically have all
the code to say "here's the difference between what i tried to set and
what actually got set" in human-readable form, but i assumed no-one
will ever need it.

> I should check some of this in...
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.