GNU bug report logs - #63556
29.0.90; Use of _Generic breaks Emacs build on GCC <4.9

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Wed, 17 May 2023 17:39:02 UTC

Severity: normal

Found in version 29.0.90

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 63556 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, eggert <at> cs.ucla.edu, 63556 <at> debbugs.gnu.org
Subject: Re: bug#63556: 29.0.90; Use of _Generic breaks Emacs build on GCC <4.9
Date: Thu, 18 May 2023 21:21:51 +0800
Eli Zaretskii <eliz <at> gnu.org> writes:

> Depends on how complex is that, and what problem does it solve.

The problem of using `long long' on systems with less than 64
significant bits in their words.  I don't think that's a particularly
good idea -- once such uses pile up, Emacs will gradually become slower
and slower on such systems.

>> Btw, couldn't the macro be defined to something along the lines of this
>> when the compiler only supports C99?
>> 
>>   #define foo(expression)			  \
>>     (sizeof (expression) == sizeof (signed char)  \
>>      ? code_for_signed_char			  \
>>      : (sizeof (expression) == sizeof (short int) \
>> 	? code_for_short_int			  \
>> 	: (sizeof (expression) == sizeof (int)	  \
>> 	   ? code_for_int			  \
>> 	   ... and so on
>
> AFAIR, sizeof is a compile-time expression, the preprocessor cannot
> evaluate it.

It doesn't have to be evaluated by the preprocessor (and nor is
_Generic.)  It just needs to expand to an expression that does the right
thing.




This bug report was last modified 2 years and 1 day ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.