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

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

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 30 May 2022 02:35:23 PM UTC, comment #8: 

see examples/ffi/bug59374.ffi

Matt Wette <mwette>
Group administrator
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>
Group 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>
Group 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>
Group 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>
Group 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
  (bs:struct
    (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>
Group 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:
github.com/spk121/guile-gi
www.gnu.org/s/g-golf

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

Hi,

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:
   
   
Comment:
   

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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-30 mwette StatusReady For Test Fixed
        Open/ClosedOpen Closed
    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.13-758e.
    Corresponding source code