Results 1 to 3 of 3

Thread: IcePHP fails to use php.ini variables correctly (PHP CLI)

  1. #1
    grembo is offline Registered User
    Name: Michael Gmelin
    Organization: Grem Equity GmbH
    Project: E-Commerce platform
    Join Date
    Jan 2009
    Posts
    85

    IcePHP fails to use php.ini variables correctly (PHP CLI)

    Hello,

    after upgrading from Ice 3.3.0 to 3.4.1 I realized that the php.ini configuration mechanism changed, but whatever I tried, I couldn't get our systems up and running.

    The example code used to demonstrate the problem is:
    PHP Code:
    <?php
    require 'Ice.php';

    $initData = new Ice_InitializationData;
    $initData->properties Ice_getProperties();
    $ICE Ice_initialize($initData);
      
    $ICE->stringToProxy("test:ssl -h 127.0.0.1 -p 10000");
    print(
    "OK\n");
    ?>
    The ice config entry is:
    Code:
    ice.config=/etc/ice.config
    And /etc/ice.config contains:
    Code:
    Ice.Plugin.IceSSL=IceSSL:createIceSSL
    Execution of this fails:
    Code:
    [dev ~/test]$ php t.php
    PHP Fatal error:  Uncaught exception ::Ice::EndpointParseException
    {
        str = invalid endpoint `ssl -h 127.0.0.1 -p 10000' in `test:ssl -h 127.0.0.1 -p 10000'
    }
      thrown in /tmp/t.php on line 8
    So I checked the ini values (<?php print_r(ini_get_all()); ?>) and realized that the identifiers had been mangled to 8 bytes max (this is on a 64bit platform):

    Code:
        [ice.con] => Array
            (
                [global_value] => ^@basic_
                [local_value] => ^@basic_
                [access] => 4
            )
    
        [ice.hid] => Array
            (
                [global_value] => 1^@Ice v
                [local_value] => 1^@Ice v
                [access] => 4
            )
    
        [ice.opt] => Array
            (
                [global_value] => ^@basic_
                [local_value] => ^@basic_
                [access] => 4
            )
    
        [ice.pro] => Array
            (
                [global_value] => ^@basic_
                [local_value] => ^@basic_
                [access] => 4
            )
    I checked the plugin source and found const_cast<char*>(string literal) lines in the code. I removed those, which basically results in the following patch:

    Code:
    --- /tmp/Init.cpp       2010-12-03 02:35:20.000000000 +0000
    +++ Init.cpp    2010-12-03 02:37:09.000000000 +0000
    @@ -58,10 +58,10 @@
     // Declare initialization file entries.
     //
     PHP_INI_BEGIN()
    -  PHP_INI_ENTRY(const_cast<char*>("ice.config"), const_cast<char*>(""), PHP_INI_SYSTEM, 0)
    -  PHP_INI_ENTRY(const_cast<char*>("ice.options"), const_cast<char*>(""), PHP_INI_SYSTEM, 0)
    -  PHP_INI_ENTRY(const_cast<char*>("ice.profiles"), const_cast<char*>(""), PHP_INI_SYSTEM, 0)
    -  PHP_INI_ENTRY(const_cast<char*>("ice.hide_profiles"), const_cast<char*>("1"), PHP_INI_SYSTEM, 0)
    +  PHP_INI_ENTRY("ice.config", "", PHP_INI_SYSTEM, 0)
    +  PHP_INI_ENTRY("ice.options", "", PHP_INI_SYSTEM, 0)
    +  PHP_INI_ENTRY("ice.profiles", "", PHP_INI_SYSTEM, 0)
    +  PHP_INI_ENTRY("ice.hide_profiles", "1", PHP_INI_SYSTEM, 0)
     PHP_INI_END()
     
     extern "C"
    Now the output of ini_get_all changed to:

    Code:
        [ice.config] => Array
            (
                [global_value] => /etc/ice.config
                [local_value] => /etc/ice.config
                [access] => 4
            )
    
        [ice.hide_profiles] => Array
            (
                [global_value] => 1
                [local_value] => 1
                [access] => 4
            )
    
        [ice.options] => Array
            (
                [global_value] => 
                [local_value] => 
                [access] => 4
            )
    
        [ice.profiles] => Array
            (
                [global_value] => 
                [local_value] => 
                [access] => 4
            )
    Much better, but unfortunately execution still failed as above.

    Checking Communicator.cpp I stumbled over two more const_casts of char* using the INI_STR macro. I corrected those as well, as seen in this patch:

    Code:
    --- /tmp/Communicator.cpp       2010-12-03 02:38:04.000000000 +0000
    +++ Communicator.cpp    2010-12-03 02:39:25.000000000 +0000
    @@ -1322,12 +1322,12 @@
         // Create the profiles from configuration settings.
         //
         const char* empty = "";
    -    const char* config = INI_STR(const_cast<char*>("ice.config"));
    +    const char* config = INI_STR("ice.config");
         if(!config)
         {
             config = empty;
         }
    -    const char* options = INI_STR(const_cast<char*>("ice.options"));
    +    const char* options = INI_STR("ice.options");
         if(!options)
         {
             options = empty;
    @@ -1337,7 +1337,7 @@
             return false;
         }
     
    -    const char* profiles = INI_STR(const_cast<char*>("ice.profiles"));
    +    const char* profiles = INI_STR("ice.profiles");
         if(!profiles)
         {
             profiles = empty;
    @@ -1349,7 +1349,7 @@
                 return false;
             }
     
    -        if(INI_BOOL(const_cast<char*>("ice.hide_profiles")))
    +        if(INI_BOOL("ice.hide_profiles"))
             {
                 memset(const_cast<char*>(profiles), '*', strlen(profiles));
                 //
    After this change, the code executes as expected:
    Code:
    [dev ~/test]$ php t.php
    OK
    Platform is FreeBSD 7.x and 8.x amd64
    Gcc 4.2.1
    Ice 3.4.1

    Even so this is on FreeBSD I'm convinced that this problem isn't limited to the platform, I've seen various outputs showing that on the net, as e.g. in
    Ice with PHP

    Not certain if there are more const_cast problems in the code - there are comments wondering about ini_get_all crashing in it which might be related - and removing them adds some deprecated warnings - but still much better than having it not work at all.

    Cheers
    Michael

  2. #2
    mes's Avatar
    mes
    mes is offline ZeroC Staff
    Name: Mark Spruiell
    Organization: ZeroC, Inc.
    Project: Ice Developer
    Join Date
    Feb 2003
    Location
    California
    Posts
    1,441
    Thanks for the bug report. We recently discovered these issues ourselves. Needless to say, they'll be fixed in the next release.

    Regards,
    Mark

  3. #3
    grembo is offline Registered User
    Name: Michael Gmelin
    Organization: Grem Equity GmbH
    Project: E-Commerce platform
    Join Date
    Jan 2009
    Posts
    85
    Hi Mark,

    thanks for your quick response, good to hear that this will be fixed soon. Is there any "known issues" section on your webpage I might have missed? Would be great time saver.

    cheers
    Michael

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. couldn't compile IcePHP (Ice 3.3.1) with php 5.3.0
    By nickfan in forum Help Center
    Replies: 5
    Last Post: 11-08-2009, 11:42 AM
  2. Php 5.3
    By Kochleffel in forum Help Center
    Replies: 3
    Last Post: 09-23-2009, 02:42 PM
  3. gentoo icephp 3.2.0 & dev-lang/php-5.1.6-r8
    By mutschaedi in forum Comments
    Replies: 0
    Last Post: 06-04-2007, 08:05 AM
  4. IcePHP doesn't work (nor compile) with PHP 5.1.4
    By g00fy in forum Bug Reports
    Replies: 0
    Last Post: 06-19-2006, 03:05 AM
  5. PHP Ice
    By xorg in forum Comments
    Replies: 1
    Last Post: 05-11-2004, 09:03 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •