php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79576 "TYPE *" shows unhelpful message when type is not defined
Submitted: 2020-05-08 18:52 UTC Modified: 2021-09-15 10:35 UTC
From: grzegorz129 at gmail dot com Assigned: dmitry (profile)
Status: Closed Package: *Extensibility Functions
PHP Version: 7.4.5 OS: macOS 10.15.4
Private report: No CVE-ID: None
 [2020-05-08 18:52 UTC] grzegorz129 at gmail dot com
Description:
------------
When parsing function declarations containing "const CUSTOM_TYPE *" the FFI modules wrongly states that unsupported specifier combination was used. When type is properly defined the FFI module is able to parse them without a problem.

Test script:
---------------
<?php

//Result: no error
\FFI::cdef('
    typedef	unsigned long u_long;
    typedef u_long oid;
    struct tree    *get_tree(const oid *, size_t, struct tree *);
');

//vs.

//Result: FFI\ParserException: unsupported type specifier combination at line 1
\FFI::cdef('struct tree    *get_tree(const oid *, size_t, struct tree *);');


Expected result:
----------------
FFI\ParserException: undefined C type 'oid'

Actual result:
--------------
FFI\ParserException: unsupported type specifier combination

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-08 19:11 UTC] nikic@php.net
-Status: Open +Status: Feedback
 [2020-05-08 19:11 UTC] nikic@php.net
Is the "bug" here that the error message should be improved? GCC reports this as:

> test.c:4:29: error: unknown type name ‘oid’

which is more obvious.
 [2020-05-08 19:23 UTC] grzegorz129 at gmail dot com
Yes, in this example (since I'm only slightly familiar with C) it took ma a longer while to realize that the definition is correct but the type is missing.

However, another example where I've got the same error about unsupported type was much more complex and really made me believe it's not supported (while in reality it was just missing "netsnmp_variable_list" typedef):

struct tree {
#...
int             (*printomat) (u_char **, size_t *, size_t *, int,
                                      const netsnmp_variable_list *,
                                      const struct enum_list *, const char *,
                                      const char *);
#...
}
 [2020-05-09 12:16 UTC] cmb@php.net
-Status: Feedback +Status: Open
 [2020-05-09 12:16 UTC] cmb@php.net
This is closely related to bug #78253, if not a duplicate.
 [2020-06-17 21:03 UTC] alexdowad@php.net
Just hacked up a little patch which improves the error messages in this (and similar) cases. I'm sure there are other cases which it doesn't cover, but anyways, I'll submit it and see what the maintainers say.
 [2021-09-14 15:09 UTC] cmb@php.net
The following pull request has been associated:

Patch Name: In FFI, assume that identifier is a typedef if followed by '*' in parameter list
On GitHub:  https://github.com/php/php-src/pull/5733
Patch:      https://github.com/php/php-src/pull/5733.patch
 [2021-09-14 15:26 UTC] cmb@php.net
-Summary: "const TYPE *" is not parsed properly when type is not defined +Summary: "TYPE *" shows unhelpful message when type is not defined
 [2021-09-15 10:30 UTC] dmitry@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: dmitry
 [2021-09-15 10:35 UTC] dmitry@php.net
A better fix https://github.com/php/php-src/pull/7496

Unfortunately, it disclose memory leaks caused by incomplete clenup after parser error.
 [2021-09-15 12:01 UTC] git@php.net
Automatic comment on behalf of dstogov
Revision: https://github.com/php/php-src/commit/0badc7de9681b3bafefd88c79603e1929b2918aa
Log: Fixed bug #79576 (&quot;TYPE *&quot; shows unhelpful message when type is not defined)
 [2021-09-15 12:01 UTC] git@php.net
-Status: Assigned +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC