All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: n.merinov@inango-systems.com, bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH] parse: Forbid ambiguous assignments to ${.}, ${+}, and ${:} variables
Date: Sat, 01 Feb 2025 13:29:47 +0000	[thread overview]
Message-ID: <fc1891e201b3baaefb86c7c5f27202bc86ac171d.camel@linuxfoundation.org> (raw)
In-Reply-To: <20250129185531.3752682-1-n.merinov@inango-systems.com>

On Wed, 2025-01-29 at 20:55 +0200, Nikolay Merinov via lists.openembedded.org wrote:
> Old code that parse variable names in assignment commands behave differntly for
> variables that ends with special symbol for single-character variable names and
> multi-character variable names. For example:
> 
>   A+="1"   # Change variable ${A}, '+' glued to '='
>   A+ = "1" # Change variable ${A+}
> 
>   +="1"    # Change variable ${+}, the '+' symbol not part of assignment operator
>   + = "1"  # Change variable ${+}
> 
> New code would always assume that '.=', '+=', and ':=' is assignment operator.
> As result code like the following would raise parsing error
> 
>   +="value"
> 
> While code with extra spaces would work as before
> 
>   + = "value" # Change variable ${+}
> 
> This change allow to catch issues in code that generate bitbake configuration
> files in a manner like "echo ${VARNAME}+=${VALUE} >> conf/local.conf"
> 
> Signed-off-by: Nikolai Merinov <n.merinov@inango-systems.com>
> ---
>  lib/bb/parse/parse_py/ConfHandler.py                       | 2 +-
>  lib/toaster/toastermain/management/commands/buildimport.py | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

This is an interesting bug, thanks for reporting it and sending a patch.

I'm a little torn on what the right thing to do here is. I'm wondering
if it is time to say that whitespace around the assignment operator is
required. That will break metadata and I've found a few hundred places
it would break. Equally, those can be fixed and we'd end up with a
better end result as the whitespace does make recipe files more
readable. I have a patch to fix most of the references in OE-Core.

I'm worried that if we do what you patch does, we're complicating the
code and potentially setting ourselves up for other new interesting
future problems.

I'd also love to see some test cases adding to lib/bb/tests/parse.py so
that "bitbake-selftest bb.tests.parse" would detect these problems if
we ever introduced them in future.

Cheers,

Richard






  parent reply	other threads:[~2025-02-01 13:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29 18:55 [PATCH] parse: Forbid ambiguous assignments to ${.}, ${+}, and ${:} variables Nikolai Merinov
2025-01-31 20:40 ` [bitbake-devel] " Peter Kjellerstedt
2025-02-03 17:42   ` Richard Purdie
2025-02-04 11:11   ` Nikolai Merinov
2025-02-01 13:29 ` Richard Purdie [this message]
2025-02-03 16:42   ` Nikolai Merinov
2025-02-03 17:40     ` Richard Purdie
2025-02-04  7:13       ` Nikolai Merinov
2025-02-04  7:13         ` [PATCH v3 1/1] " Nikolai Merinov
2025-02-03 16:42   ` [PATCH v2] " Nikolai Merinov
2025-02-03 17:39     ` Richard Purdie

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=fc1891e201b3baaefb86c7c5f27202bc86ac171d.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=n.merinov@inango-systems.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.