All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive
Date: Fri, 18 Oct 2019 07:28:40 +0200	[thread overview]
Message-ID: <20191018052839.efpqhxkqsjoqtdks@ltop.local> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1910172127220.3026@viisi.sifive.com>

On Thu, Oct 17, 2019 at 09:38:18PM -0700, Paul Walmsley wrote:
> On Fri, 18 Oct 2019, Luc Van Oostenryck wrote:
> 
> > On Thu, Oct 17, 2019 at 05:49:24PM -0700, Paul Walmsley wrote:
> > > sparse complains loudly when string literals associated with
> > > preprocessor directives are split into multiple, separately quoted
> > > strings across different lines:
> > 
> > ...
> >  
> > >  #ifndef __riscv_cmodel_medany
> > > -#error "setup_vm() is called from head.S before relocate so it should "
> > > -	"not use absolute addressing."
> > > +#error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
> > >  #endif
> > 
> > Using a blacslash should do the trick :
> > 	#error "blablablablablablablablablablablabla" \
> > 			"and blablabla again"
> > Or if need I cn fix Sparse if needed and desiable.
> 
> Thanks for the kind offer!
> 
> The backslashless syntax is pretty horrible to my eyes.  As far as I can 
> tell from a brief glance, the instance fixed by this patch was the only 
> instance of its kind in the kernel.  The existing kernel precedents appear 
> to be to simply use a single long line.  Example:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler-gcc.h#n3
> 
> So, from a kernel point of view, we should just fix this specific 
> instance.  It doesn't seem worth changing sparse for such a rare case.
> 
> On the other hand, gcc seems to support the non-backslashed syntax.  So if 
> the intention is for sparse to follow the gcc practice, and to be used 
> beyond the kernel, maybe it's worth aligning sparse to gcc?  Only if 
> you're bored, I suppose...

I'll first see what is acceptable for the point of view of the standard
(and maybe some justifications from GCC).

-- Luc 

WARNING: multiple messages have this Message-ID (diff)
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive
Date: Fri, 18 Oct 2019 07:28:40 +0200	[thread overview]
Message-ID: <20191018052839.efpqhxkqsjoqtdks@ltop.local> (raw)
In-Reply-To: <alpine.DEB.2.21.9999.1910172127220.3026@viisi.sifive.com>

On Thu, Oct 17, 2019 at 09:38:18PM -0700, Paul Walmsley wrote:
> On Fri, 18 Oct 2019, Luc Van Oostenryck wrote:
> 
> > On Thu, Oct 17, 2019 at 05:49:24PM -0700, Paul Walmsley wrote:
> > > sparse complains loudly when string literals associated with
> > > preprocessor directives are split into multiple, separately quoted
> > > strings across different lines:
> > 
> > ...
> >  
> > >  #ifndef __riscv_cmodel_medany
> > > -#error "setup_vm() is called from head.S before relocate so it should "
> > > -	"not use absolute addressing."
> > > +#error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
> > >  #endif
> > 
> > Using a blacslash should do the trick :
> > 	#error "blablablablablablablablablablablabla" \
> > 			"and blablabla again"
> > Or if need I cn fix Sparse if needed and desiable.
> 
> Thanks for the kind offer!
> 
> The backslashless syntax is pretty horrible to my eyes.  As far as I can 
> tell from a brief glance, the instance fixed by this patch was the only 
> instance of its kind in the kernel.  The existing kernel precedents appear 
> to be to simply use a single long line.  Example:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler-gcc.h#n3
> 
> So, from a kernel point of view, we should just fix this specific 
> instance.  It doesn't seem worth changing sparse for such a rare case.
> 
> On the other hand, gcc seems to support the non-backslashed syntax.  So if 
> the intention is for sparse to follow the gcc practice, and to be used 
> beyond the kernel, maybe it's worth aligning sparse to gcc?  Only if 
> you're bored, I suppose...

I'll first see what is acceptable for the point of view of the standard
(and maybe some justifications from GCC).

-- Luc 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-10-18  5:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18  0:49 [PATCH 0/8] riscv: resolve most warnings from sparse Paul Walmsley
2019-10-18  0:49 ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 1/8] riscv: add prototypes for assembly language functions from entry.S Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 2/8] riscv: add prototypes for assembly language functions from head.S Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  1:15   ` Paul Walmsley
2019-10-18  1:15     ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 3/8] riscv: init: merge split string literals in preprocessor directive Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  4:02   ` Luc Van Oostenryck
2019-10-18  4:02     ` Luc Van Oostenryck
2019-10-18  4:38     ` Paul Walmsley
2019-10-18  4:38       ` Paul Walmsley
2019-10-18  5:28       ` Luc Van Oostenryck [this message]
2019-10-18  5:28         ` Luc Van Oostenryck
2019-10-18  5:47       ` Luc Van Oostenryck
2019-10-18  5:47         ` Luc Van Oostenryck
2019-10-18  6:08         ` Paul Walmsley
2019-10-18  6:08           ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 4/8] riscv: ensure RISC-V C model definitions are passed to static analyzers Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  4:06   ` Luc Van Oostenryck
2019-10-18  4:06     ` Luc Van Oostenryck
2019-10-18  4:39     ` Paul Walmsley
2019-10-18  4:39       ` Paul Walmsley
2019-10-18  5:25       ` Luc Van Oostenryck
2019-10-18  5:25         ` Luc Van Oostenryck
2019-10-22 15:09       ` Palmer Dabbelt
2019-10-22 15:09         ` Palmer Dabbelt
2019-10-28 22:11         ` Luc Van Oostenryck
2019-10-28 22:11           ` Luc Van Oostenryck
2019-10-18  0:49 ` [PATCH 5/8] riscv: add missing prototypes Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  4:15   ` Luc Van Oostenryck
2019-10-18  4:15     ` Luc Van Oostenryck
2019-10-18  6:06     ` Paul Walmsley
2019-10-18  6:06       ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 6/8] riscv: mark some code and data as file-static Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 7/8] riscv: add missing header file includes Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  0:49 ` [PATCH 8/8] riscv: fp: add missing __user pointer annotations Paul Walmsley
2019-10-18  0:49   ` Paul Walmsley
2019-10-18  3:12 ` [PATCH 0/8] riscv: resolve most warnings from sparse Anup Patel
2019-10-18  3:12   ` Anup Patel

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=20191018052839.efpqhxkqsjoqtdks@ltop.local \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=paul.walmsley@sifive.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.