Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB-Alt <bohannonindustriesllc@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: errno (was Re: C23 thoughts and opinions - why so conservative?)
Date: Thu, 30 May 2024 14:18:56 -0500
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <v3ajf0$1qlb9$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <20240523171911.00002f5a@yahoo.com>
 <v2o7re$1tlge$1@dont-email.me> <20240524003424.0000590a@yahoo.com>
 <v2qddg$2d33b$1@dont-email.me> <v2rc19$2i5ih$5@dont-email.me>
 <v2t174$2ue9j$1@dont-email.me> <875xv11mnb.fsf@nosuchdomain.example.com>
 <v2vgb9$3eaba$2@dont-email.me> <v2vi4t$3en8h$1@dont-email.me>
 <v2vn11$3ffl2$2@dont-email.me> <v33gls$e0ph$2@dont-email.me>
 <v33tob$fsul$1@dont-email.me> <v37hg8$16n0m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 30 May 2024 21:18:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="03bdfe7e03a301aab84c66d6a65cfc1d";
	logging-data="1922409"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+8AZ9spEM6YErfvV1bQX03bOryqPQyTQU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wE/uKm+tHd8l+rTMKa8hGlHZVLo=
Content-Language: en-US
In-Reply-To: <v37hg8$16n0m$1@dont-email.me>
Bytes: 2846

On 5/29/2024 10:27 AM, James Kuyper wrote:
> On 5/28/24 02:31, BGB wrote:
>> On 5/27/2024 9:48 PM, Lawrence D'Oliveiro wrote:
>>> On Sun, 26 May 2024 18:12:17 +0200, David Brown wrote:
>>>
>>>> Macros in C are not recursive. That stops them exploding, but also means
>>>> there's a lot you can't do with the preprocessor.\
> ...
>> It seems the preprocessor in BGBCC is likely not entirely conformant
>> in this case...
>>
>> If given a recursive macro, it will most likely just explode and
>> probably crash the compiler...
>>
>> Mostly as it handles macro-expansion by looping over the line and
>> performing macro-substitutions until no more substitutions are seen,
>> at which point it emits the line to the output buffer and moves on to
>> the next line.
> 
> That definitely fails to conform to the requirements in 6.10.4.4.
> 
> 

I will need to put it on my TODO list.

It has not come up yet, because if it did it will be fairly obvious 
(namely, in that it will crash the compiler if it did come up).

But, in terms of priority, this would be behind things like 
code-generation or memory corruption bugs, some of which I am also 
trying to hunt down at the moment (when I have time at least, at present 
also a lot of time is getting eaten up by my "day job", namely running a 
CNC machine, and jobs are baked up recently...).