Closed Bug 404272 Opened 15 years ago Closed 15 years ago
_LONG _LONG nicely
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20071025 Firefox/22.214.171.124 Build Identifier: If NSPR is used with other projects, especially GNU projects, HAVE_LONG_LONG is already defined by the configure script, through AC_CHECK_TYPES([long long]) Since this is fairly reasonable to do, I think NSPR should not try to redefine the value so the strict preprocessors/compilers won't complain about HAVE_LONG_LONG being redefined. Reproducible: Always Steps to Reproduce: #define HAVE_LONG_LONG #include <nspr/prio.h> /* or another nspr header */ Actual Results: In file included from /usr/include/nspr/prtypes.h:58, from /usr/include/nspr/prlong.h:49, from /usr/include/nspr/prio.h:48, from jsfile.c:91: /usr/include/nspr/prcpucf.h:633:1: warning: "HAVE_LONG_LONG" redefined <command line>:1:1: warning: this is the location of the previous definition Expected Results: The compiler should not complain for the headers shouldn't define HAVE_LONG_LONG if it is already defined.
This is a patch for the latest version fromthe HEAD branch in CVS.
Do you think we should define HAVE_LONG_LONG as 1? Thanks for the patch.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
It should not be necessary, the only reason that HAVE_LONG_LONG is defined, is for checking it with #ifdef, #ifndef, etc. The actual value should never be used. But it can't hurt to define it to 1. Autoconf/configure scripts define HAVE_* as 1
Edwin, there are several more files that need to be patched. (They have a tab character between #define and HAVE_LONG_LONG, which must be why you missed them.) Since it is tedious to change so many files, I just want to make sure you're running into this problem in practice.
I've extended Edwin's patch to all the files that need to be patched. I will check it in next week.
This patch extends Edwin's patch to all the *.cfg files that need this change. I've checked in this patch on the NSPR trunk for NSPR 4.7.
Attachment #289244 - Attachment is obsolete: true
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.7
You need to log in before you can comment on or make changes to this bug.