php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #67893 Values of constants not listed
Submitted: 2014-08-22 20:02 UTC Modified: 2014-12-30 10:42 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: teo8976 at gmail dot com Assigned:
Status: No Feedback Package: Documentation problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: teo8976 at gmail dot com
New email:
PHP Version: OS:

 

 [2014-08-22 20:02 UTC] teo8976 at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/curl.constants
---

The names of the predefined constants are listed, but their values are missing.
This is ridiculous.

I go to that page because I'm being returned an integer from a curl function and I wanted to check to which constant it corresponds, and that's not documented.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-22 23:37 UTC] phpmpan at mpan dot pl
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.
 [2014-09-03 03:28 UTC] sobak@php.net
-Status: Open +Status: Feedback
 [2014-09-03 03:28 UTC] sobak@php.net
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.
 [2014-12-30 10:42 UTC] php-bugs at lists dot php dot net
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.
 [2014-12-30 11:19 UTC] teo8976 at gmail dot com
> 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.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Nov 13 14:01:29 2019 UTC