bugnyacc parser generator - Bugs: bug #59374, Difference to gcc in handling...


bug #59374: Difference to gcc in handling structs with "ArgBlob arguments[]" as last argument of struct

Submitted by:  Danny Milosavljevic <dannym>
Submitted on:  Wed 28 Oct 2020 08:24:47 AM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Ready For Test
Privacy:  Public Assigned to:  mwette
Open/Closed:  Open
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


( Jump to the original submission )

Sat 22 May 2021 12:56:10 AM UTC, comment #7: 

I think this may be fixed.  If you have the repo cloned please try commit cb5b08f950aa1848310c7bd0faa3d42dd82059e5

Matt Wette <mwette>
Project Administrator
Sat 31 Oct 2020 03:30:17 PM UTC, comment #6: 

Idea: For objects generated by pointer->bytevector, provide a procedure to resize the bytevector.  Initially a pointer returned by a c function would get wrapped as SignatureBlob type, then later user would resize based on sizeof(SignatureBlob)+n_arguments*sizeof(ArgBlob)

Matt Wette <mwette>
Project Administrator
Thu 29 Oct 2020 05:59:38 PM UTC, comment #5: 

OK.  That makes sense.   It does raise another issue with "flexible arrays".   If we get a C pointer value to the structure then we need to have the correct size to pass to pointer->bytevector.   In your examples, we have to know the sizeof the struct and the value of n_arguments.  For that reason, it makes sense to explore this issue.

Thanks for the report.

Matt Wette <mwette>
Project Administrator
Thu 29 Oct 2020 03:49:01 PM UTC, comment #4: 

I just wanted to bring it up because it's a difference between gcc and this project.

If you do not aim for sizeof compatibility, it's fine like it is.

If you do, then it could cause difficult-to-diagnose problems for users (it's not really customary for users to distrust structure alignments--or at least it shouldn't be, in an ideal world).

In my use case, I already have determined all the sizes that gcc had for these structures--so indeed, I can just use those instead of trusting nyacc in this.

If bytestructures don't support zero-sized files, support could be added there.

I've tried a few things, and indeed, gcc aligns the member just as if it actually had a size.

For example, struct A { char b; long long c[] }; is 8 Byte, but struct A {char b; } is 1 Byte in gcc.

Danny Milosavljevic <dannym>
Thu 29 Oct 2020 02:11:29 PM UTC, comment #3: 

I don't see how the present behavior could cause a problem, as the use case for these structures is to allocate sizeof(struct) + n_arguments*sizeof(ArgBlob).

Matt Wette <mwette>
Project Administrator
Thu 29 Oct 2020 12:47:42 PM UTC, comment #2: 

Generating FFI file yields the problem:  ffi-helper is allocating space for anonymous arrays.  See arguments field below.
;; typedef struct {
;;   SimpleTypeBlob return_type;
;;   guint16 may_return_null : 1;
;;   guint16 caller_owns_return_value : 1;
;;   guint16 caller_owns_return_container : 1;
;;   guint16 skip_return : 1;
;;   guint16 instance_transfer_ownership : 1;
;;   guint16 throws : 1;
;;   guint16 reserved : 10;
;;   guint16 n_arguments;
;;   ArgBlob arguments[];
;; } SignatureBlob;
(define-public SignatureBlob-desc
    (list `(return_type ,SimpleTypeBlob-desc)
          `(may_return_null ,unsigned-short 1)
          `(caller_owns_return_value ,unsigned-short 1)
          `(caller_owns_return_container ,unsigned-short 1)
          `(skip_return ,unsigned-short 1)
          `(instance_transfer_ownership ,unsigned-short 1)
          `(throws ,unsigned-short 1)
          `(reserved ,unsigned-short 10)
          `(n_arguments ,unsigned-short)
          `(arguments ,(fh:pointer ArgBlob-desc)))))

But I'm not sure there is capability to add zero-sized element to a bytestructure bs:struct.

Matt Wette <mwette>
Project Administrator
Wed 28 Oct 2020 12:55:04 PM UTC, comment #1: 

You may not know, but there are two project bringing GI to guile:

Matt Wette <mwette>
Project Administrator
Wed 28 Oct 2020 08:24:47 AM UTC, original submission:  


with attached files, I the reported size of SignatureBlob is 16 Byte.  Gcc says it's 8 Byte.

SignatureBlob-size: 16 Byte in nyacc vs 8 Byte in gcc.
ParamTypeBlob-size: 16 Byte in nyacc vs 4 Byte in gcc.
ErrorTypeBlob-size: 16 Byte in nyacc vs 4 Byte in gcc.
EnumBlob-size: 32 Byte in nyacc vs 24 Byte in gcc.
ObjectBlob-size: 72 Byte in nyacc vs 60 Byte in gcc.
InterfaceBlob-size: 48 Byte in nyacc vs 40 Byte in gcc.

Danny Milosavljevic <dannym>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #50150:  gitypelib-internal.h added by dannym (39KiB - text/x-chdr)
file #50151:  gmodule.h added by dannym (757B - text/x-chdr)
file #50152:  girepository.h added by dannym (1B - text/x-chdr)
file #50153:  main.scm added by dannym (5KiB - text/x-scheme)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mwette (Posted a comment)
  • -email is unavailable- added by dannym (Submitted the item)
  • -email is unavailable- added by dannym

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-22 mwette StatusConfirmed => Ready For Test
    2020-10-29 mwette StatusNone => Confirmed
    2020-10-29 mwette Assigned toNone => mwette
    2020-10-28 dannym Attached File- => Added gitypelib-internal.h, #50150
        Attached File- => Added gmodule.h, #50151
        Attached File- => Added girepository.h, #50152
        Attached File- => Added main.scm, #50153
        Carbon-Copy- => Added -email is unavailable-

    Back to the top

    Powered by Savane 3.9