buggperf - Bugs: bug #54343, gperf 3.1 regression - generated...

 
 

bug #54343: gperf 3.1 regression - generated code with 'size_t' fails to build

Submitter:  Peter Wu <lekensteyn>
Submitted:  Fri 20 Jul 2018 05:16:42 PM UTC
   
 
Category:  Generated code Severity:  3 - Normal
Item Group:  None Status:  Not a Bug
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 26 Jul 2018 01:49:06 PM UTC, comment #4: 


> libcap fails to compile due to this issue


Please see the answer in https://lists.gnu.org/archive/html/bug-gperf/2018-07/msg00001.html

Bruno Haible <haible>
Group administrator
Thu 26 Jul 2018 10:30:10 AM UTC, comment #3: 


> Furthermore, the prototype is not consistent with the actual function definition.


Even with gperf --includes, libcap fails to compile due to this issue:


./_caps_output.gperf:201:1: error: conflicting types for ‘__cap_lookup_name’
 __cap_lookup_name (register const char *str, register size_t len)
 ^~~~~~~~~~~~~~~~~
In file included from <command-line>:
./_caps_output.gperf:33:29: note: previous declaration of ‘__cap_lookup_name’ was here
 const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
                             ^~~~~~~~~~~~~~~~~


Peter Wu <lekensteyn>
Sat 21 Jul 2018 12:19:31 AM UTC, comment #2: 


> the generated code uses "size_t" without including stddef.h.


The code that includes the generated code is supposed to include <string.h> (unless the option %includes has been used. This is documented in the manual https://www.gnu.org/software/gperf/manual/gperf.html.

> the prototype is not consistent with the actual function definition.
> This was previously reported in https://lists.gnu.org/archive/html/bug-gperf/2017-01/msg00004.html


I have now answered this on the mailing list; see https://lists.gnu.org/archive/html/bug-gperf/2018-07/threads.html

But thanks for the reminder.

Bruno Haible <haible>
Group administrator
Fri 20 Jul 2018 07:45:20 PM UTC, comment #1: 

@bruno: What do you think? I would vote to keep the size_t and fix the prototype definition.

Any comments are welcome!

Marcel Schaible <marcelschaible>
Fri 20 Jul 2018 05:16:42 PM UTC, original submission:  

Since gperf 3.1, applications such as "libcap" fail to compile. The reason is that the generated code uses "size_t" without including stddef.h. Furthermore, the prototype is not consistent with the actual function definition.

This is likely a regression introduced with v3.0.4-47-gd519d1a ("Change the 'len' parameter type to 'size_t'.").

This was previously reported in https://lists.nongnu.org/archive/html/bug-gperf/2017-01/msg00004.html

What about reverting this change? If applications actually need to handle "size_t" data, what about adding a new option for it (but default to the old behavior)?

Peter Wu <lekensteyn>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by marcelschaible (Posted a comment)
  • -email is unavailable- added by lekensteyn (Submitted the item)
  • -email is unavailable- added by lekensteyn
  • -email is unavailable- added by lekensteyn
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-26 marcelschaible StatusNone Not a Bug
        Open/ClosedOpen Closed
    2018-07-20 lekensteyn Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code