php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #49901 changing IMAP_CLOSETIMEOUT through imap_timeout() is not implemented
Submitted: 2009-10-16 14:50 UTC Modified: 2009-10-19 12:12 UTC
From: olivier at oxeva dot fr Assigned:
Status: Not a bug Package: IMAP related
PHP Version: 5.3SVN-2009-10-16 (snap) OS: linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2009-10-16 14:50 UTC] olivier at oxeva dot fr 
Description:
------------
It seems changing IMAP_CLOSETIMEOUT through imap_timeout() function is not implemented. Also, the returned value seems arbitrary (when using imap_timeout with one argument).

If this usage is not implemented, documentation should be updated.


Reproduce code:
---------------
<?php

var_dump(imap_timeout(IMAP_CLOSETIMEOUT));
var_dump(imap_timeout(IMAP_WRITETIMEOUT, 10));
var_dump(imap_timeout(IMAP_CLOSETIMEOUT));

Expected result:
----------------
int(%d)
bool(true)
int(10)


Actual result:
--------------
int(%d)
bool(true) //as you can see, function tells that update was successfull
int(0)  // ... but value has not been updated

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-19 10:41 UTC] jani@php.net 
If you don't pass the timeout parameter, imap_timeout() will only return what it is set to currently. No bug here.
 [2009-10-19 12:12 UTC] olivier at oxeva dot fr 
Hi,
My reproduce code was bogus. You should read IMAP_CLOSETIMEOUT everywhere. That's why I think you did not understand what I was saying:

Changing the close timeout seems to have no effect at all :
var_dump(imap_timeout(IMAP_CLOSETIMEOUT , 10)); //returns TRUE, so change has been commited

//Now, the getter should return 10, right ?
var_dump(imap_timeout(IMAP_CLOSETIMEOUT)); //returns previous default value, as if nothing were changed
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved. 		Last updated: Mon Dec 04 01:01:27 2023 UTC