NSAssert and noescape?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NSAssert and noescape?

Aaron Hillegass
Hi,

I’m porting the FMDB library to run on GNUstep on Linux:

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]);
                                   ^
/usr/local/include/Foundation/NSException.h:475:9: note: macro 'NSAssert' defined here
#define NSAssert(condition, desc)                      

I’m also getting some warnings on noescape:
./FMDatabasePool.h:199:36: warning: unknown attribute 'noescape' ignored [-Wunknown-attributes]
- (void)inDatabase:(__attribute__((noescape)) void (^)(FMDatabase *db))block;

I’d appreciate any help I can get.

- Aaron

P.S.

Trivia for other who will come after me: I had to install libbsd and libdispatch. As a dumb work-around, I also defined some empty macros:

#ifdef __linux__
    #define SInt32 int32_t
    #define NS_SWIFT_NAME(the_name)
    #define __deprecated_msg(the_message)
#endif

Here’s how I’m building it:
clang -x objective-c -fconstant-string-class=NSConstantString -fPIC -fobjc-nonfragile-abi -fblocks  -I/usr/local/include/ -c FMDatabase.m -o FMDatabase.o

Clang details:
$ clang --version
clang version 4.0.1-6 (tags/RELEASE_401/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin





_______________________________________________
Help-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: NSAssert and noescape?

Fred Kiefer
Hi Aaron,

thank you for this bug report. I really would like to hear more from your porting experiance

> Am 05.02.2018 um 19:47 schrieb Aaron Hillegass <[hidden email]>:
>
> 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.

> /usr/local/include/Foundation/NSException.h:475:9: note: macro 'NSAssert' defined here
> #define NSAssert(condition, desc)                      
>
> I’m also getting some warnings on noescape:
> ./FMDatabasePool.h:199:36: warning: unknown attribute 'noescape' ignored [-Wunknown-attributes]
> - (void)inDatabase:(__attribute__((noescape)) void (^)(FMDatabase *db))block;

This is a clang issue. Your clang version seems to be too old to support this attribute.


> Trivia for other who will come after me: I had to install libbsd and libdispatch. As a dumb work-around, I also defined some empty macros:
>
> #ifdef __linux__
>     #define SInt32 int32_t
>     #define NS_SWIFT_NAME(the_name)
>     #define __deprecated_msg(the_message)
> #endif
>
> Here’s how I’m building it:
> clang -x objective-c -fconstant-string-class=NSConstantString -fPIC -fobjc-nonfragile-abi -fblocks  -I/usr/local/include/ -c FMDatabase.m -o FMDatabase.o


I would always suggest to write a GNUmakefile even when a project is very small. That way you don’t have to fiddle with the compiler parameters yourself.

Cheers
Fred
_______________________________________________
Help-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: NSAssert and noescape?

Richard Frith-Macdonald-7


> On 5 Feb 2018, at 21:23, Fred Kiefer <[hidden email]> 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 <[hidden email]>:
>>
>> 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.


_______________________________________________
Help-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gnustep