style question: breaking inline assembly lines

[Gedare Bloom]

On Tue, Jun 13, 2023 at 7:41 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 14/6/2023 10:20 am, Joel Sherrill wrote:
> >
> >
> > On Tue, Jun 13, 2023, 4:43 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 14/6/2023 5:47 am, Joel Sherrill wrote:
> >     >
> >     >
> >     > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
> >     > <sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>
> >     <mailto:sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>>>
> >     > wrote:
> >     >
> >     >     On 13.06.23 00:04, Gedare Bloom wrote:
> >     >     >       "b _ARM_Exception_default\n"
> >     >     >       :
> >     >     > -    : [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> >     >     > -      [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
> >     >     > -      [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
> >     >     > -      [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> >     >     > -      [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> >     >     > -      [cpacr] "i" (ARMV7M_CPACR),
> >     >     > -      [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> >     >     > +    : [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> >     >
> >     >     If we place operators (e.g. &&, ||, ...) at the end of a broken line,
> >     >     then we should do this for the : as well.
> >     >
> >     >
> >     > OK.
> >     >
> >     >
> >     >
> >     >     My current preference would be to format all non-third-party sources
> >     >     with a standard clang-format selection. I guess in the long run, this
> >     >     will be the easiest approach to maintain. If we use exotic options, then
> >     >     we may up ending as clang-format maintainers.
> >     >
> >     >
> >     > I think this is the thing we have to keep in mind and I even said I would
> >     > go along with compromises when we started. Get as close as you can
> >     > and we will have to accept that -- for now. We should definitely file tickets
> >     > with clang-format and ourselves to track things we don't like. If we get an
> >     > option in the future whether we or someone else implements it, we can
> >     > use it and reformat again. Those hopefully are not that invasive.
> >
> >     Sounds like a plan.
> >
> >     I am a little concerned about the version of clang-format I need as some
> >     machines I work on are no at current OS versions.
> >
> >
> > I am finding myself experimenting with it for a customer's C++ project. So far,
> > I have not matched the style. But I am now on Rocky 9 since I built it from
> > source and needed cmake 3 at least. So you can't be on an old distribution and
> > build from source.
>
> I use clang-format on a couple projects with something close the standard
> format. It works well.
>
> > And Doxygen has and three different major versions between RHEL 7, 8, and 9.
> > Using a configuration file from one on another seems to give you warnings about
> > unknown options or obsolete options.
> >
> > Mixing new and old systems is a pain.
>
> It is but we have to for reasons specific to local sites.
>
As a developer tool that can be used also by CI tools to automate
style fixes, I view the availability of clang-format as less of a
concern (than say a specific version of gcc). People can still create
and send commits without having the tool.

If someone ends up proposing a requirement for clang-format clean
patch submissions, then it becomes a problem.

> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel