style question: breaking inline assembly lines

[Joel Sherrill]

On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber <
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.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230613/0f400181/attachment-0001.htm>