azbycxdw909 / garglk

Automatically exported from code.google.com/p/garglk
Other
0 stars 0 forks source link

Typo's in glk.h #91

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When trying to build the latest release from source, I noticed to problems
in glk.h, specifically in the following part:

#include <limits.h>
#if (USHORT_MAX == 4294967295)
typedef unsigned short glui32;
typedef signed   short glsi32;
#elif (UINT_MAX   == 4294967295)
typedef unsigned int glui32;
typedef signed   int glsi32;
#elif (ULONG_MAX) == 4294967295)
typedef unsigned long glui32;
typedef signed long glsi32;
#else
#error No 32-bit integer type found.
#endif

The first problem is that the code checks USHORT_MAX which is not defined
in limits.h; the intent was probably to use USHRT_MAX instead (although on
most platforms USHRT_MAX will be too small anyway). The second problem is
the extra parenthesis after ULONG_MAX, which prevents the code from
compiling at all.

The second problem has already been fixed in the repository, but this makes
me wonder if anyone has ever been able to compile the August release from
source at all. Surely the extra parenthesis is a fatal error for any C
compiler. If so, maybe it's a good idea to create another release that
actually builds without patching the source?

Original issue reported on code.google.com by znxfire...@gmail.com on 12 Jan 2010 at 1:49

GoogleCodeExporter commented 8 years ago
I didn't have any trouble building under Ubuntu, else I wouldn't have released 
it. I
agree that the misplaced paren was trouble but it didn't block the build 
process on
any machine I used.

I'll look into the USHORT_MAX issue, though I believe it's there for a 
non-existent
architecture with a 32-bit short.

We're closing in on a new release; should happen in the next few weeks.

Original comment by bcressey@gmail.com on 14 Jan 2010 at 1:20

GoogleCodeExporter commented 8 years ago
Hmm, I'm guessing the behaviour of GCC's preprocessor changed somewhere between
version 4.3.3 (which works) and 4.4.2 (which doesn't). No idea which behaviour 
is
correct, and it probably doesn't matter much, since it's fixed in Svn. If you 
have
another release in the pipeline, that should take care of it. I'll just wait 
for that
one or build from Svn if I get impatient. Thanks for the work!

Original comment by znxfire...@gmail.com on 14 Jan 2010 at 3:05

GoogleCodeExporter commented 8 years ago
Fixed in r380. Still no new release but soon!

Original comment by bcressey@gmail.com on 5 Aug 2010 at 10:23

GoogleCodeExporter commented 8 years ago

Original comment by bcressey@gmail.com on 5 Aug 2010 at 10:23