tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: warning from make(1) about unclosed variable



On 28.07.2020 11:19, Edgar Fuß wrote:
>> I would go ahead and make it an error. Anything it breaks is easily
>> fixed.
> Yes. It's even worse when you accidently do
> 	echo ${CLOSED)
> where I actually don't know how make(1) interprets this -- it neither expands CLOSED nor CLOSED) (if you write ${CLOSED)}, it does expand CLOSED) ), the result is simply nothing.

The variable name is "CLOSED)", but since the expected delimiter '}' is
missing, the returned value is varError, which is simply an empty string.

>> I think it's because make is a mess inside
> I'm under the impression someone is currently re-writing half of it anyway (in a non-portable language).

I understand the first part, but not the second.

Everything I rewrote is in C90, with the addition of
declaration-after-statements.  I added these because I prefer to have
variables with small scopes.  There was prior work that already relied
on this feature, otherwise I would have refrained from doing that, since
I am not sure whether anyone regularly builds bmake with some ancient
compiler.

I'm not going to rewrite usr.bin/make in Go or another truly
platform-specific language.

Could you tell me what you mean by "non-portable language"?

Roland


Home | Main Index | Thread Index | Old Index