Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#589 NetBSD Alpha build macro expansion ARGUMENT_TYPE___int64-t

v4.0
closed
Rick McGuire
5
2012-08-14
2009-03-22
Mike Protts
No

This is a problem on FreeBSD Alpha (64 bit), it does not occur on Linux Intel 32 bit.

RexxMethod2 (and others) macro expansion fails, e.g. for:
RexxMethod2(int64_t, stream_lines, CSELF, streamPtr, OPTIONAL_CSTRING, option)

the int64_t expands to ARGUMENT_TYPE___int64_t, and therefore generates an error. As a quick circumvent I changed to using the OPTIONAL value which worked - e.g.:
RexxMethod2(OPTIONAL_int64_t, stream_lines, CSELF, streamPtr, OPTIONAL_CSTRING,
option)

Typical errors:

./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'ARGUMENT_TYPEint64_t' does not name a type
./interpreter/streamLibrary/StreamNative.cpp: In function '__uint16_t
stream_lines(RexxMethodContext, ValueDescriptor*)':
./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'union ValueDescriptor::<anonymous>' has no member named 'value
int64_t'
./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'stream_lines_impl' was not declared in this scope
./interpreter/streamLibrary/StreamNative.cpp: At global scope:
./interpreter/streamLibrary/StreamNative.cpp:1729: error: 'ARGUMENT_TYPE___int64_t' does not name a type
*** Error code 1
=====

Failing freebsd alpha gcc version

$ gcc --version
gcc (GCC) 4.1.2 20061021 prerelease (NetBSD nb3 20061125)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Does work with Linux gcc:

gcc --version

gcc (GCC) 4.2.2
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Mike

Discussion

  • Mike Protts
    Mike Protts
    2009-03-28

    I've generated the preprocessor output as a file. There are a few examples where expansion has resulted in ___ instead of _, In each case I think it's where an int64_t or uint64_t type is used.

     
  • Rick McGuire
    Rick McGuire
    2009-03-28

    I might have a fix for this (already checked in). Hopefully this is confined to the int64_t and uint64_t types.

     
  • Mike Protts
    Mike Protts
    2009-03-29

    There were a couple of others, and I also had a problem with value___uintptr_t; in ./extensions/rexxutil/platform/unix/rexxutil.cpp. The attached patch gets these built.

    It's a bit strange how the expansion is not consistent, it would be nice to understand the difference.

    Cheers
    Mike

     
  • Rick McGuire
    Rick McGuire
    2009-03-29

    My suspicion is the include files for that platform #define int64_t et al to _int64_t. This gets substituted in the initial macro expansion, which messes everything else up. A serious pain, but I think we can work around the problem.

     
  • Rick McGuire
    Rick McGuire
    2009-03-29

    Mike, I'm not sure I understand your patch. Why are you using 3 underscores for the type rather than 2? Or did the the characters just run together in the original report? Also, could you generate the patch using svn diff? That will make it easier to apply the change.

     
  • Mike Protts
    Mike Protts
    2009-03-29

    Thanks for your help.

    I've uploaded the svn diff.

    There were three underscores originally.

    From /usr/include/sys/types.h:

    ifndef int64_t

    typedef __int64_t int64_t;

    define int64_t __int64_t

    endif

    ifndef uint64_t

    typedef __uint64_t uint64_t;

    define uint64_t __uint64_t

    endif

    I've set up a NetBSD intel VM so I can check there as well. I'll also try Solaris (sparc) later as I can test there quite easily.

    Thanks
    Mike

     


Anonymous


Cancel   Add attachments