On 14/6/2023 5:47 am, Joel Sherrill wrote: > > > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
