There's no way of knowing. Please don't change the API of exported functions. If you feel the need for a function with a different API, please call it something else.

Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:

...

Is there a reason why quick_add_integer_constant takes a char* and a length, instead of a (much quicker and cleaner) struct pike_string* which would enable it to work more efficiently in collaboration with MK_STRING() ?

The quick* functions in program.c are typically called via the corresponding ADD_*() macros (in this case ADD_INT_CONSTANT()). The "quick" in the name has mostly to do with the string-lengths being calculated statically, and probably ought to have been "simple", since the functions are intended to be easy to use from C-code.

Yes, well, figured that out, eventually; however, these are all one-time calls, for fairly short strings as identifiers. I'm having a hard time justifying why someone insisted on creating the quick_ versions just to be able to use make_shared_binary_string instead of make_shared_string. It will save one pass over the string to find the trailing \0, yes, but since it's all initialisation, and the string in most cases fits in the cache (and this is true now, and would have been equally true 20 years ago), there is close to no speed benefit.

If you already have a struct pike_string, you would probably want to call add_constant() directly rather than {quick_,}add_integer_constant().

Well, I have a proposed cleanup which keeps the current binary interface intact.