[Toybox] [PATCH] Use NULL rather than 0 in vargs. (Rob Landley)

[James McMechan]

On Sun, Dec 10, 2017 at 5:29 PM, scsijon <scsijon at lamiaworks.com.au> wrote:
>
>
> On 12/11/2017 08:20 AM, toybox-request at lists.landley.net wrote:
>
>>    2. Re: [PATCH] Use NULL rather than 0 in vargs. (Rob Landley)
>>
>> Message: 2
>
> Date: Sun, 10 Dec 2017 14:28:50 -0600
> From: Rob Landley <rob at landley.net>
> To: enh <enh at google.com>
> Cc: toybox at lists.landley.net
> Subject: Re: [Toybox] [PATCH] Use NULL rather than 0 in vargs.
> Message-ID: <295e1992-8a2f-0070-3c2f-6e5fde0be33c at landley.net>
> Content-Type: text/plain; charset=utf-8
>
> 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.
>
> 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...)
>
> 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.
>
> No, it's still used in a lot of thermal, flood and security sensors and
> 'gear' like lift switching mechanisms in old pre 2000 buildings and a lot of
> it is still 7 x 2. They often work on the principle of 'if it ain't broken
> don't touch it', it's often a simple analog>digital>analog system. Changing
> a building over is VERY expensive!

Yes, history still has a lot of sharp teeth waiting to bite.
Alas, it is not just old buildings, people are still producing stuff
with oddball settings.
e.g. my controller software is hardcoded to 7-o-1.5 make the
replacement work like the old stuff did.
then a few years later, make the new controller software work with the old gear.
So both ends have been replaced, only the format between them has not changed :(
And it seems no one wants to replace both ends at the same time, even
if they did
it would likely be only one of the 17 pieces of gear that would be
replaced with the controller,
and I usually it would break something...

There were even some good reasons for some of it, a open wire would
produce a stream
 with bad checksums for odd parity.

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

I don't think it ever has, there was likely a reason 30 years ago,
that I have forgotten.

> 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. 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? (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?)

I too have been working with the USB serial ports, mostly it is nice.
The custom of having the reference voltage on board next to the TX/RX
does make life much easier, just pulling the jumper on the USB board
and hooking it up to the reference makes it simpler.

Except of course when the manufacture puts something like a 5V supply
next to a 3.3V serial port, I unfortunately have some of these.

The other problem of the hardware comes up in something old fashioned
like 9600-8-n-1 if you are lucky, means that until you are fully booted
you get to watch the screen slowly scroll.

At least until it is up enough to reprogram the serial speed, but that can
require reprogramming the shared clock generator, oh for the days when
it was only a divider value... Now we get to reprogram the other devices
sharing that clock generator, what could be easier that fiddling with the
video and SD card interfaces just to set the baud rate...

> 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 should check some of this in...

This just struck my fancy,

Jim McMechan