COIN-OR::LEMON - Graph Library

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#230 closed defect (fixed)

Faulty check whether 'long long' is available in tolerance.h

Reported by: Alpar Juttner Owned by: Akos Ladanyi
Priority: major Milestone: LEMON 1.1 release
Component: build system Version: release branch 1.0
Keywords: Cc: Balazs Dezso
Revision id: r1.0.2

Description

The current check

#if defined __GNUC__ && !defined __STRICT_ANSI__

evaluates to false somehow (using autotools' default settings)

It would be nice if we had a reliable HAVE_LONG_LONG define which could be used throughout the library.

Attachments (3)

bac03d6fae99.patch (1.1 KB) - added by Alpar Juttner 10 years ago.
dbfb21a939d6.patch (2.9 KB) - added by Balazs Dezso 10 years ago.
Long long checking in build environment
39aaeea2d471.patch (833 bytes) - added by Alpar Juttner 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by Alpar Juttner

Attachment: bac03d6fae99.patch added

comment:1 Changed 10 years ago by Alpar Juttner

The situation is very strange. As it turned out, the -ansi compiler option defines __STRICT_ANSI__, but it does not even warning if long long is used.

My proposal (see the changeset [bac03d6fae99] attached) is to simply assume that if a compiler survives our template-abuse attack, then it will also have long long type. Thus we don't have to check if it is available or not.

IMHO, it is enough to think about a more sophisticated solution only when we first come across a decent C++ compiler that somehow does not support long long.

What's your opinion?

comment:2 Changed 10 years ago by Akos Ladanyi

Status: newassigned

I agree.

Changed 10 years ago by Balazs Dezso

Attachment: dbfb21a939d6.patch added

Long long checking in build environment

comment:3 Changed 10 years ago by Balazs Dezso

I have uploaded a patch, which checks the long long in cmake and automake.

comment:4 in reply to:  3 Changed 10 years ago by Alpar Juttner

Resolution: fixed
Status: assignedclosed

Replying to deba:

I have uploaded a patch, which checks the long long in cmake and automake.

I rebased this changeset so that I could merge it into both the 1.0 and the main branches, see [7992dcb0d0e6].

comment:5 Changed 10 years ago by Peter Kovacs

Resolution: fixed
Status: closedreopened

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

And the changeset [7992dcb0d0e6] also seems faulty. In bits/default_map.h

#if defined HAVE_LONG_LONG

is used, but in tolerance.h

#if HAVE_LONG_LONG

is used.

I'm not sure, but I think the later one should be used everywhere, so in the dimacs solver as well. (It also contains #ifdef HAVE_LONG_LONG.)

comment:6 in reply to:  5 Changed 10 years ago by Alpar Juttner

Cc: Balazs Dezso added

Replying to kpeter:

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

This is my mistake - I should have been more aggressively against the stupid idea of this HAVE_LONG_LONG. We should have just assume that long long is there instead for taking the extra hassle for nothing.

But: what's the real reason for this? Isn't

#include<lemon/config.h>

missing from somewhere?

And the changeset [7992dcb0d0e6] also seems faulty. In bits/default_map.h

#if defined HAVE_LONG_LONG

is used, but in tolerance.h

#if HAVE_LONG_LONG

is used.

Hmmm. Strange. I can't see HAVE_LONG_LONG in the current version of lemon/tolerance.h.

I'm not sure, but I think the later one should be used everywhere, so in the dimacs solver as well. (It also contains #ifdef HAVE_LONG_LONG.)

Anyhow, Most people will use #ifdef in cases like that, so I strongly want this form to work.

Changed 10 years ago by Alpar Juttner

Attachment: 39aaeea2d471.patch added

comment:7 in reply to:  5 ; Changed 10 years ago by Alpar Juttner

Replying to kpeter:

I found that the dimacs solver doesn't use 'long long' in [1c5d6e47921f] (on lime.cs.elte.hu), although it is available.

I hope [39aaeea2d471] solves this issue.

comment:8 in reply to:  7 Changed 10 years ago by Peter Kovacs

Replying to alpar:

I hope [39aaeea2d471] solves this issue.

The dimacs solver works properly with this changeset. I think it solves this issue. Btw. whether we have this HAVE_LONG_LONG macro or not, it seems a good idea to include the config file globally.

comment:9 Changed 10 years ago by Alpar Juttner

Resolution: fixed
Status: reopenedclosed

comment:10 Changed 10 years ago by Alpar Juttner

Component: corebuild system
Note: See TracTickets for help on using tickets.