Those are _CONSTANTS_. As the user you're not supposed to either know their actual values or make your code depend on them. In this particular case you are also unable to use such values anyway, since the only errors one can handle are those one knows beforehead.

For debug purposes there is `curl_error` (<https://php.net/manual/function.curl-error.php>).

Note that the upstream itself is not documenting the values on functions' return values, so it would be quite strange for PHP to document them.

Which of curl functions returned you an integer you need to associate with constant name? Like phpman wrote, I'm pretty sure that there is no need to know actual value.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

> As the user you're not supposed to either know their actual values 
> or make your code depend on them.

I was logging the error code just for debugging purposes, and I wanted to "manually" (i.e. as a human being) look up the error that had been logged. As opposed to writing code such as

switch ($myErrorCode) {
  case CONSTANT_FOO: "FOO Error"; break;
  case CONSTANT_BAR: "BAR Error"; break;
  // and so on for a few dozens cases
}

Perhaps curl_error() is the solution in most cases but:
> Which of curl functions returned you an integer
Good question, not sure now. If it was curl_errno, then perhaps I could have used curl_error(), but I was also using curl_multi_exec, which returns an integer error code, so in this case the issue exists.

and secondly, if I'm inspecting existing logs where only error codes have been logged, it's annoying that there's not a reference that I can't look up.

> I'm pretty sure that there is no need to know actual value.

I just demonstarted such need (as I already had in the original report). Which is just the reason why usually constants values in most languages and libraries are usually documented, even when you are not supposed to rely on them, because you know, documentation is for documenting things, you never know when you may need it.

> Note that the upstream itself is not documenting the values on functions'
> return values, so it would be quite strange for PHP to document them.

It would be "strange"? Excellent reason for leaving undocumented.


> No feedback was provided. The bug is being suspended because
> we assume that you are no longer experiencing the problem.

I understand this is an automated message, but this bug shouldn't have been put in the "NeedsFeedback" state in the first place, as the question was completely irrelevant.