Problems using cgogen with func types and functions that return char**

[xlab]

Problems using cgogen with func types and functions that return char**

[deepakjois]

I have managed to compile the Go bindings for Harfbuzz after ignoring the buggy typedefs, and the functions that use them:

https://github.com/deepakjois/harfbuzz-go/blob/615f54f0f88780387b56a5ddd6dcc7699fb129b1/harfbuzz.yml

I now have a few more questions regarding adjusting the PtrTips for some functions. I will open a new issue specifically for questions, instead of cluttering up this issue. Hope that is not a problem.

[cznic]

@xlab Max, if it's CC fault, please fill an issue there. Thanks.

[deepakjois]

I created to repo to isolate the issues (need to add to it) in a minimal test case: https://github.com/deepakjois/cgogentest

You will need harfbuzz installed though to do a build.

[deepakjois]

Here is the minimal header file which covers all the problems reported above: https://github.com/deepakjois/cgogentest/blob/master/cgogentest/cgogentest.h

[xlab]

@deepakjois
Hi, I'm glad you're having fun.

1. You should never edit the original headers you're parsing, that conflicts with the concept of cgogen. Any problem should be avoidable with manifest tweaks, if not, then I'll adjust the engine itself. Anyways, instead of including everything and then cut slices from the original header, try to include just parts you'll need. With - { action: "accept" from: "hb_abc$" } for instance.

2. With overflowing constant issue — you can avoid that by setting defs: eval in const rules. Not that beautiful, but works.

3. const char ** hb_buffer_serialize_list_formats — returns clearly []string, however by default for function return values the default tip is a reference, *string expression has no sense in this context. So you must give a pointer tip here (note self: arr):

  PtrTips:
    function:
      - {target: "_buffer_serialize_list_formats$", self: arr, tips: [ref]}

4. Not sure what kind of problem you're getting with function types, it is supported well. Let me know how this is handled and what's wrong with it.

Anyway, you know how to ignore it:

  Rules: 
    type:
      - {action: ignore, from: _font_get_glyph_func_t$}

These things are hard to get is a short glimpse of docs, but will be easier with experience.

[deepakjois]

2. With overflowing constant issue — you can avoid that by setting defs: eval in const rules. Not that beautiful, but works.

Is it possible to use eval only for the overflowing constant, and keep the rest of the constants as expand?

4. Not sure what kind of problem you're getting with function types, it is supported well. Let me know how this is handled and what's wrong with it.

If you look at the cgogentest repo, where I isolated the problem, I see these lines:

typedef hb_bool_t (*hb_font_get_font_extents_func_t) (hb_font_t *font, void *font_data,
                               hb_font_extents_t *metrics,
                               void *user_data);

typedef hb_font_get_font_extents_func_t hb_font_get_font_h_extents_func_t;
typedef hb_font_get_font_extents_func_t hb_font_get_font_v_extents_func_t;

get translated to:

// FontGetFontExtentsFunc type as declared in cgogentest/cgogentest.h:38
type FontGetFontExtentsFunc func(font *Font, fontData unsafe.Pointer, metrics *FontExtents, userData unsafe.Pointer) Bool

// FontGetFontHExtentsFunc type as declared in cgogentest/cgogentest.h:42
type FontGetFontHExtentsFunc func(font *Font, fontData unsafe.Pointer, metrics *FontExtents, userData unsafe.Pointer) FontGetFontExtentsFunc

// FontGetFontVExtentsFunc type as declared in cgogentest/cgogentest.h:43
type FontGetFontVExtentsFunc func(font *Font, fontData unsafe.Pointer, metrics *FontExtents, userData unsafe.Pointer) FontGetFontExtentsFunc

Isn’t that wrong?

Moreover here is the compiler output:

01:19 $ go build
# _/Users/deepak/code/personal/cgogentest/cgogentest
./cgo_helpers.c:14:9: warning: incompatible pointer to integer conversion returning 'hb_font_get_font_extents_func_t' (aka 'int (*)(struct hb_font_t *, void *, struct hb_font_extents_t *, void *)') from a function with result type 'int' [-Wint-conversion]
./cgo_helpers.c:18:9: warning: incompatible pointer to integer conversion returning 'hb_font_get_font_extents_func_t' (aka 'int (*)(struct hb_font_t *, void *, struct hb_font_extents_t *, void *)') from a function with result type 'int' [-Wint-conversion]
# _/Users/deepak/code/personal/cgogentest/cgogentest
./cgo_helpers.go:393: cannot convert retbfdb6d00 (type FontGetFontExtentsFunc) to type C.hb_font_get_font_extents_func_t
./cgo_helpers.go:429: cannot convert ret797ea535 (type FontGetFontExtentsFunc) to type C.hb_font_get_font_extents_func_t

[xlab]

@cznic I'm struggling with this case and CC, see cznic/cc#57

[xlab]

@deepakjois thank you very much for the report, I got the repro code and this an old bug that bothered me a while, you just triggered it. Try to avoid these two typedefs by ignoring them. We'll fix that soon I hope.

As for const rules — no, these are global, however you can simply ignore that constant value so it won't be included in the output (rule scope: const). And write your definition of that value in a separate file, so it won't be overwritten on the next generation.

[deepakjois]

@xlab, I ignored the overflowing constant and the _func_t$ types. I also set the self:arr on the type that returns a string array, as you suggested. See deepakjois/cgogentest@b96b64332a1dd1221c36af2a4ab3339fca28579a

But now I get a compilation error:

09:02 $ go build
# _/Users/deepak/code/personal/cgogentest/cgogentest
./cgo_helpers.go:333: undefined: sizeOfPtr
./cgo_helpers.go:333: invalid array bound m / sizeOfPtr

[deepakjois]

Ok, I built with the latest cgogen and the build errors are gone.

[xlab]

Gj, anyways, you could ignore them with a single line

- {action: ignore, from: "hb_font_funcs_set_"}

That's a regular expression and it matches substrings.

[deepakjois]

Gj, anyways, you could ignore them with a single line

Yes I could. I just wanted to be explicit so that I can keep track of functions that have been ignored.

Speaking of regular expressions, will something like hb_font_get_.*_func_t work as well?

[xlab]

Yes, for sure, but I prefer using prefixes or postfix for better readability.

[xlab]

@deepakjois please check the functions referenced there #4 (comment)
should be OK with the latest version.

[deepakjois]

After updating to latest version, and removing the ignores, I am getting build errors:

19:14 $ go build
# github.com/deepakjois/harfbuzz-go/harfbuzz
./harfbuzz.go:23: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:65: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:261: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:624: _func.PassRef undefined (type *func(*BufferT, *FontT, string, unsafe.Pointer) BufferMessageFuncT has no field or method PassRef)
./harfbuzz.go:626: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:671: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:712: _func.PassRef undefined (type *func(*UnicodeFuncsT, CodepointT, unsafe.Pointer) UnicodeCombiningClassFuncT has no field or method PassRef)
./harfbuzz.go:714: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:721: _func.PassRef undefined (type *func(*UnicodeFuncsT, CodepointT, unsafe.Pointer) UnicodeEastasianWidthFuncT has no field or method PassRef)
./harfbuzz.go:723: destroy.PassRef undefined (type *func(unsafe.Pointer) has no field or method PassRef)
./harfbuzz.go:723: too many errors

[deepakjois]

Actually it is happening regardless of whether I turn the ignores on or off. Seems like it might be a problem with the latest build

[xlab]

@deepakjois whoops, I used github web editor to commit those fixes on the go, accidentally removed a line. Try now, I've checked on my machine, it builds fine.