From: Marius Kittler <mkittler@suse.de>
To: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v7 5/5] Extend ioctl02 to test termio and termios
Date: Wed, 25 Oct 2023 11:51:19 +0200 [thread overview]
Message-ID: <4534034.LvFx2qVVIh@linux-9lzf> (raw)
In-Reply-To: <bddbae90-13a5-0947-a55a-089de6530d99@suse.cz>
Am Dienstag, 24. Oktober 2023, 17:54:27 CEST schrieb Martin Doucha:
> You don't need to duplicate the whole prepare_termio() function. You can
> either initialize both structures at once:
> termio.c_line = termios.c_line = 0;
> termio.c_cflag = termios.c_cflag = ...;
That's not possible with all the assignments because the variables have
different types (e.g. unsigned short vs. unsigned int). These different types
are the reason why there are different structs in the first place. (Of course it
would technically be possible but introducing implicit conversions and relying
on these conversions not being too lossy is a bad idea in my opinion.)
> of #define an init macro:
> #define TERM_INIT_VALUES { .c_line = 0, .c_cflag = ... }
> termio = (struct termio)TERM_INIT_VALUES;
> termios = (struct termios)TERM_INIT_VALUES;
>
That is rather ugly but likely the way to go then. And I assume I'd call this
"combined" prepare function during the setup then.
> Some code duplication is unavoidable here but the value validation can
> be simplified:
>
> 1) Add another pair of termio+termios variables which will be
> initialized in setup() and passed only to SAFE_IOCTL(TCSETA/TCSETS).
>
> 2) memset() the existing termio+termios variables before passing them to
> SAFE_IOCTL(TCGETA/TCGETS). As is, the test can pass even if
> TCGETA/TCGETS does nothing because they store data into a structure that
> already contains the exact same values.
>
> 3) Define a macro to compare the "set" and "get" variables:
> #define CMP_ATTR(tcexp, tcval, attr) \
> if ((tcval).attr != (tcexp).attr) { \
> tst_res(TINFO, #attr " has incorrect value %o", \
> (tcval).attr); \
> flag++; \
> }
>
> Then all attribtute checks except the loop can be reduced to one line.
>
I guess that is the least ugly way to use macros, indeed. (Supposedly better
than just wrapping the whole function body into a macro.)
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2023-10-25 9:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-23 16:02 [LTP] [PATCH v7 0/5] Improve ioctl02.c Marius Kittler
2023-10-23 16:02 ` [LTP] [PATCH v7 1/5] Refactor ioctl02.c to use the new test API Marius Kittler
2023-10-25 9:00 ` Cyril Hrubis
2023-10-23 16:02 ` [LTP] [PATCH v7 2/5] Make checks for termio flags more strict Marius Kittler
2023-10-23 16:02 ` [LTP] [PATCH v7 3/5] Remove disabled code in ioctl02.c Marius Kittler
2023-10-24 15:02 ` Martin Doucha
2023-10-23 16:02 ` [LTP] [PATCH v7 4/5] Use termios instead of legacy struct " Marius Kittler
2023-10-23 16:02 ` [LTP] [PATCH v7 5/5] Extend ioctl02 to test termio and termios Marius Kittler
2023-10-24 15:54 ` Martin Doucha
2023-10-25 9:51 ` Marius Kittler [this message]
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=4534034.LvFx2qVVIh@linux-9lzf \
--to=mkittler@suse.de \
--cc=ltp@lists.linux.it \
/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