Re: NSAssert and noescape?

[Richard Frith-Macdonald]

> On 5 Feb 2018, at 21:23, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 
> Hi Aaron,
> 
> thank you for this bug report. I really would like to hear more from your 
> porting experience
> 
>> Am 05.02.2018 um 19:47 schrieb Aaron Hillegass <aaron@bignerdranch.com>:
>> 
>> Hi,
>> 
>> I’m porting the FMDB library to run on GNUstep on Linux:
>>      https://github.com/ccgus/fmdb
>> 
>> I’m getting errors with the vargs on NSAssert:
>> FMDatabase.m:1495:36: error: too many arguments provided to function-like 
>> macro invocation
>>            NSAssert(false, @"%@", [self lastErrorMessage]);
> 
> This first issue here is a bug in GNUstep base. It looks to me like it is 
> easy to fix. But as I am no expert on the usage of variadic arguments in C 
> macros, I would prefer for Richard to look into this.
> The problem is that the solution will have to work with different compilers 
> and should still work when no extra arguments are given.
> The simplest and safest solutions I see is to rename the macro  _NSAssertArgs 
> to NSAssert in NSException and remove the old definition (and similar for 
> NSCAssert). That way we keep the same tested code.
> 
> Interestingly nobody ever noticed this issue before in the over 20 years of 
> GNUstep.

I think this is because the behaviour is correct (for OpenStep).  The 
specification defines NSAssert as having two arguments (condition and message 
to log).  In order to support format strings rather than just simple messages, 
The specification defines NSAssert1 to NSAssert5 supporting up to 5 additional 
arguments to be used by the format string.
I assume that the reason for the original spec is that, at the time the 
OpenStep specification was written, the compiler preprocessor did not support 
variadic macros.

The simple change for porting would therefore be to use NSAssert1:  
NSAssert1(false, @"%@", [self lastErrorMessage]);

At some point, Apple seem to have changed the specification of NSAssert() to 
support a variable number of arguments, while retaining all the other macros 
(which are no longer needed) for backward compatibility.

I see no reason why we shouldn't do the same for the next release of base.