bugmake - Bugs: bug #44464, gmk_add_function retains ptr to...


bug #44464: gmk_add_function retains ptr to name it's given

Submitted by:  Brian Vandenberg <phantal>
Submitted on:  Sat 07 Mar 2015 09:45:42 AM UTC  
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.1 Operating System:  Any
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 08 Mar 2015 12:15:26 PM UTC, comment #3: 

Technically, you are not supposed to hand any pointer to memory to GNU make which is not allocated with gmk_alloc(); the docs say:

Thus you should never pass memory that you’ve allocated directly to any make function, nor should you attempt to directly free any memory returned to you by any make function. Instead, use the gmk_alloc and gmk_free functions.

This is intended to apply to the function name as well, so you're supposed to use gmk_alloc() to duplicate the string containing the function name (maybe writing a utility function like blah_strdup() or something) and pass that to gmk_add_function().

That could be made clearer in the documentation.  Also this rule could be relaxed, and as you suggest GNU make could duplicate the function name itself, for safety.  I'll leave this as an enhancement request.

Paul D. Smith <psmith>
Project Administrator
Sat 07 Mar 2015 09:59:39 AM UTC, comment #2: 

What I'm using it for is a way to create a number of functions that can be used like $(if) but they test a specific condition and only evaluate either the true or false part, not both.  For example:


$(setstate if_something, $(ifdef some_variable, true, false))

# ... later on ...

$(if_something $(info yes), $(error no))


With existing make syntax I'd need to do something like this:


$(if $(filter undefined, $(origin some_variable)), $(info yes), $(error no))


... in order to avoid having $(error) kill the build.

Brian Vandenberg <phantal>
Sat 07 Mar 2015 09:50:21 AM UTC, comment #1: 

In case someone thinks that's a silly thing to want to do, I thought I'd post another example:



extern "C" int blah_gmk_setup( const gmk_floc* floc ) {
  for( some_map_t::iterator iter : some_map ) {
    gmk_add_function( iter->second.c_str(), generic_function, 1, 1, 1 );


Brian Vandenberg <phantal>
Sat 07 Mar 2015 09:45:42 AM UTC, original submission:  

The pointer to the string used to name a function is stored directly instead of being copied when gmk_add_function gets called.

This can be a problem if gmk_add_function is called with a temporary / stack variable; here's a few examples of how this could be an issue:


static char* blah( const char*, unsigned int, char ** ) {
  return NULL;

extern "C" int blah_gmk_setup( const gmk_floc* floc ) {
  char test[] = "something";
  std::string asdf( "something_else" );

  gmk_add_function( test, blah, 1, 0, 0 );
  gmk_add_function( asdf.c_str(), blah, 1, 0, 0 );

  return 1;


Plainly that uses some C++isms, but the issue is the same either way.  The 2nd invocation should be fine since the const string ptr will be valid until that call is complete, but since gmk_add_function stores the pointer directly it'll eventually be pointing at garbage data.

Brian Vandenberg <phantal>


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

Attach Files:

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 psmith (Posted a comment)
  • -email is unavailable- added by phantal (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-08 psmith Item GroupBug => Enhancement

    Back to the top

    Powered by Savane 3.5