php-general-digest-helplists.php.net
Date: Sun Jul 03 2005 - 00:34:03 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 3 Jul 2005 05:34:03 -0000 Issue 3546

Topics (messages 218027 through 218046):

Re: Conversion of period and space for $_GET, $_REQUEST,etc. is rather senseless
        218027 by: Joe Krahn
        218028 by: Joe Krahn
        218041 by: Richard Lynch

mail()===false but msg is sent!
        218029 by: Andy Pieters
        218033 by: Jasper Bryant-Greene
        218039 by: Manuel Lemos
        218040 by: Richard Lynch

Delivery reports about your e-mail
        218030 by: Mail Delivery Subsystem

x years old
        218031 by: Ryan A
        218034 by: Jasper Bryant-Greene
        218035 by: Colin Ross
        218036 by: disguised.jedi.gmail.com
        218037 by: Ryan A
        218038 by: Ryan A
        218042 by: Matthew Weier O'Phinney

Re: Currency stored as cents
        218032 by: Jasper Bryant-Greene
        218046 by: Tom Rogers

auto reply framework
        218043 by: Nate Tanner
        218044 by: Rodolfo Gonzalez Gonzalez

Re: memcached and objects.
        218045 by: Rodolfo Gonzalez Gonzalez

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
        php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

Richard Lynch wrote:
> On Thu, June 30, 2005 8:47 pm, Joe Krahn said:
>
>>PHP imports GET and POST data to array elements by senselessly
>>converting periods and spaces to underscore. The intent is to make
>>strings variable-name compatible for conversion directly into global
>>variables via import_request_variables or register_globals.
>
>
> Honestly?...
>
> Why in the world would you have variable names or even array keys with
> such weird keys anyway, other than the imagemaps, of course?
>
> [shrug]
I was trying to create a form whose value names would match key names
from a database. To avoid conflict, I decided to prefix the other form
values with a period, and was surprised that it didn't work. The easy
fix was to use another 'special character', but PHP documentation did
not make it clear which characters are 'special', so I tested all 256. I
was even more surprised that a period is special, but control characters
are not.

>
>
>>String-to-variable name mangling should only occur when being converted
>>to variable names, but should be left as is when accessed as array
>>elements. The current implementation is particularly bad because it
>>mangles only periods and spaces, but leaves alone other special/unusual
>>characters. Furthermore, the direct conversion into global name space is
>>discouraged for security reasons.
>>
>>A feature-request was made related to this, but it was marked as "Won't
>>Fix", primarily due to compatibility concerns. However, I think it's a
>>poor design, and there must be some compatible way to move beyond this
>>misfeature.
>
>
> You'd break an awful lot of backwards-compatibility, for anybody actually
> relying on it...
>
> The biggest one being for INPUT TYPE="IMAGE" and image map ,x and ,y
> variables.
>
> If it weren't for those, I'd day go ahead and change it. There probably
> aren't THAT many users affected by anything else.
>
> It would be nice if the original design had only mangled the variable
> names and not the array keys, but changing it now...
>
> Just too many applications are gonna get broken big-time.
...
> I'm not unsympathic to your plight, and you're absolutely right it would
> have been a better Design had somebody thought to do it that way, oh, 10
> years ago...
Well, I I think PHP will be around for a long time, so we're still in
the early days of PHP.

How's this for a trvial backwards-compatible fix -- for array keys,
populate both mangled and unmangled keys.

> HEY!
> Just noticed your email address...
>
> Can you turn off that stupid auto-responder thingie from rr.com that keeps
> spamming the list about viruses it deleted? Thanks. [I think it's rr.com,
> right?...]
It's the admin people... I have no control. They probably think it's
safer to let list people know of a virus than to avoid the extra spam.

Well, I'll send them an email anyhow.

Joe Krahn

attached mail follows:

Richard Lynch wrote:
> On Thu, June 30, 2005 8:47 pm, Joe Krahn said:
>
>>PHP imports GET and POST data to array elements by senselessly
>>converting periods and spaces to underscore. The intent is to make
>>strings variable-name compatible for conversion directly into global
>>variables via import_request_variables or register_globals.
>
>
> Honestly?...
>
> Why in the world would you have variable names or even array keys with
> such weird keys anyway, other than the imagemaps, of course?
>
> [shrug]
I was trying to create a form whose value names would match key names
from a database. To avoid conflict, I decided to prefix the other form
values with a period, and was surprised that it didn't work. The easy
fix was to use another 'special character', but PHP documentation did
not make it clear which characters are 'special', so I tested all 256. I
was even more surprised that a period is special, but control characters
are not.

>
>
>>String-to-variable name mangling should only occur when being converted
>>to variable names, but should be left as is when accessed as array
>>elements. The current implementation is particularly bad because it
>>mangles only periods and spaces, but leaves alone other special/unusual
>>characters. Furthermore, the direct conversion into global name space is
>>discouraged for security reasons.
>>
>>A feature-request was made related to this, but it was marked as "Won't
>>Fix", primarily due to compatibility concerns. However, I think it's a
>>poor design, and there must be some compatible way to move beyond this
>>misfeature.
>
>
> You'd break an awful lot of backwards-compatibility, for anybody actually
> relying on it...
>
> The biggest one being for INPUT TYPE="IMAGE" and image map ,x and ,y
> variables.
>
> If it weren't for those, I'd day go ahead and change it. There probably
> aren't THAT many users affected by anything else.
>
> It would be nice if the original design had only mangled the variable
> names and not the array keys, but changing it now...
>
> Just too many applications are gonna get broken big-time.
...
> I'm not unsympathic to your plight, and you're absolutely right it would
> have been a better Design had somebody thought to do it that way, oh, 10
> years ago...
Well, I I think PHP will be around for a long time, so we're still in
the early days of PHP.

How's this for a trvial backwards-compatible fix -- for array keys,
populate both mangled and unmangled keys.

> HEY!
> Just noticed your email address...
>
> Can you turn off that stupid auto-responder thingie from rr.com that keeps
> spamming the list about viruses it deleted? Thanks. [I think it's rr.com,
> right?...]
It's the admin people... I have no control. They probably think it's
safer to let list people know of a virus than to avoid the extra spam.

Well, I'll send them an email anyhow.

Joe Krahn

attached mail follows:

On Sat, July 2, 2005 11:35 am, Joe Krahn said:
> Richard Lynch wrote:
>> I'm not unsympathic to your plight, and you're absolutely right it would
>> have been a better Design had somebody thought to do it that way, oh, 10
>> years ago...
> Well, I I think PHP will be around for a long time, so we're still in
> the early days of PHP.

You may be. I'm pretty old in PHP :-)

> How's this for a trvial backwards-compatible fix -- for array keys,
> populate both mangled and unmangled keys.

Seems good...

Except it would break a few zillion scripts that iterate through all of
$_POST and spew off an email with it all.

Yeah, maybe they should only accept expected keys, but who cares for an
email to admin?

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:

Hi all

I have this situation where mail() returns a false status but the message is
actually accepted AND reaches destination!

The PHP Version is 4.3.10, the OS Linux

So what I do is (

$header="header for multipart mime message";
$body="body with multipart mime message";
$result=mail("Name Firstname <$address>","Subject",$message,$header);
echo ($result?"ok":"bogus");

So anyone got any ideas?

With kind regards

Andy

--
Registered Linux User Number 379093
-- --BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT/O/>E$ d-(---)>+ s:(+)>: a--(-)>? C++++$(+++) UL++++>++++$ P-(+)>++
L+++>++++$ E---(-) W+++>+++$ !N o? !K? W--(---) !O !M- V-- PS++(+++)
PE--(-) Y+ PGP++(+++) t+(++) 5-- X++ R*(+) !tv b-() DI(+) D+(+++) G(+)
e>++++$ h++(*) r-->++ y--()>++++
-- ---END GEEK CODE BLOCK------
--
Check out these few php utilities that I released
 under the GPL2 and that are meant for use with a
 php cli binary:
 
 http://www.vlaamse-kern.com/sas/
--

--

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCxxES2GLGPJ3Q07wRArntAKCd2fvuoR3DXfXYlWRUnN7fNV5rUgCgqw6K
IZhjGETFadG1JZKxSCufLvQ=
=vj/Q
-----END PGP SIGNATURE-----

attached mail follows:

Andy Pieters wrote:
> So what I do is (
>
> $header="header for multipart mime message";
> $body="body with multipart mime message";
> $result=mail("Name Firstname <$address>","Subject",$message,$header);
> echo ($result?"ok":"bogus");

Well, firstly your subject does not match what you're doing. PHP is
weakly-typed, so $result may be a value that evaluates to FALSE while
not actually being a boolean value.

In your subject you use the === operator to check types, but you're not
doing it in the code sample.

You should use

echo ($result === false) ? 'bogus' : 'ok';

or similar.

Jasper

attached mail follows:

Hello,

on 07/02/2005 07:11 PM Andy Pieters said the following:
> Hi all
>
> I have this situation where mail() returns a false status but the
message is
> actually accepted AND reaches destination!
>
> The PHP Version is 4.3.10, the OS Linux
>
> So what I do is (
>
> $header="header for multipart mime message";
> $body="body with multipart mime message";
> $result=mail("Name Firstname <$address>","Subject",$message,$header);
> echo ($result?"ok":"bogus");
>
>
> So anyone got any ideas?

The mail function practically never fails under Linux because it just
handles the message to sendmail program or equivalent. This may be a
mail() function bug.

In any case, you may want to try this class that comes with a wrapper
function named sendmail_mail(). It works like mail() and takes the same
arguments but it calls sendmail program directly. If it also fails, it
may be a problem in your sendmail installation. Otherwise, it is a
problem in the mail() function.

http://www.phpclasses.org/mimemessage

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

attached mail follows:

On Sat, July 2, 2005 3:11 pm, Andy Pieters said:
> I have this situation where mail() returns a false status but the message
> is
> actually accepted AND reaches destination!
>
> The PHP Version is 4.3.10, the OS Linux
>
> So what I do is (
>
> $header="header for multipart mime message";
> $body="body with multipart mime message";
> $result=mail("Name Firstname <$address>","Subject",$message,$header);

Not that it's relevant (almost for sure), but in this example, you use
$message where you probably want $body...

> echo ($result?"ok":"bogus");

> So anyone got any ideas?

You'd have to read the PHP source code to be certain, but let's assume
that PHP just uses whatever your sendmail setting in php.ini returns.

It's possible, though very unlikely, that you've done something silly
there like:

sendmail = "/usr/bin/sendmail -t ; return -1";

What's more likely is that something in the command line of sendmail is
returning some kind of warning, but it's still managing to send the
message.

If you can, su to the PHP user (see User directive in httpd.conf) and then
run some test sendmail commands from the shell.

Odds are really good you'll get a more detailed feedback than PHP's
simplistic true/false return value.

--
Like Music?
http://l-i-e.com/artists.htm

attached mail follows:

ALERT!

This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.
Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the Road Runner Abuse Department, at abuserr.com.

The original message was received at Sat, 2 Jul 2005 18:44:05 -0400
from [80.125.99.107]

----- The following addresses had permanent fatal errors -----
<php-generallists.php.net>

----- Transcript of the session follows -----
... while talking to 139.222.195.214:
550 5.1.2 <php-generallists.php.net>... Host unknown (Name server: host not found)

attached mail follows:

Hey guys,
This is the code I am using to display a persons age from the mysql db:

$day1=strtotime($age);
$day2 = strtotime(date("Y-m-d"));
$dif_s = ($day2-$day1);
$dif_d = ($dif_s/60/60/24);
$age = round(($dif_d/365.24));

but when someone entered their birth day($age) as 1988-07-06 it is showing
it as
17 years old instead of 16...any idea whats wrong in the above code?

Thanks,
Ryan

attached mail follows:

Ryan A wrote:
> Hey guys,
> This is the code I am using to display a persons age from the mysql db:
>
> $day1=strtotime($age);
> $day2 = strtotime(date("Y-m-d"));
> $dif_s = ($day2-$day1);
> $dif_d = ($dif_s/60/60/24);
> $age = round(($dif_d/365.24));
>
> but when someone entered their birth day($age) as 1988-07-06 it is showing
> it as
> 17 years old instead of 16...any idea whats wrong in the above code?

Use floor() instead of round(). Using the round() function will round
anyone whose age is above 16.5 to 17, while floor() always rounds down.

Jasper

attached mail follows:

and for completeness of the topic, ceil() will round fractions up.
i.e.

ceil(16.00001) = 17
ceil(16.00000) = 16

<attempted-humor>
I think the Credit Card Industry using ceil() alot ;P
</attempted-humor>

On 7/2/05, Jasper Bryant-Greene <jasperbryant-greene.name> wrote:
>
> Ryan A wrote:
> > Hey guys,
> > This is the code I am using to display a persons age from the mysql db:
> >
> > $day1=strtotime($age);
> > $day2 = strtotime(date("Y-m-d"));
> > $dif_s = ($day2-$day1);
> > $dif_d = ($dif_s/60/60/24);
> > $age = round(($dif_d/365.24));
> >
> > but when someone entered their birth day($age) as 1988-07-06 it is
> showing
> > it as
> > 17 years old instead of 16...any idea whats wrong in the above code?
>
> Use floor() instead of round(). Using the round() function will round
> anyone whose age is above 16.5 to 17, while floor() always rounds down.
>
> Jasper
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:

> <attempted-humor>
> I think the Credit Card Industry using ceil() alot ;P
> </attempted-humor>

<attempted-laugh>
HAHAHAHAHAHAHAHAHAHA....ah.....*sigh*
</attempted-laugh>

....

--
PHP rocks!
"Knowledge is Power. Power Corrupts. Go to school, become evil"

Disclaimer: Any disclaimer attached to this message may be ignored.
However, I must say that the ENTIRE contents of this message are
subject to other's criticism, corrections, and speculations.

This message is Certified Virus Free

attached mail follows:

Hey,

On 7/3/2005 2:12:35 AM, Colin Ross (colinrossgmail.com) wrote:
> and for completeness of the topic, ceil() will round fractions up.
> i.e.
>
> ceil(16.00001) = 17
> ceil(16.00000) = 16

> <attempted-humor>
> I think the Credit Card Industry using ceil() alot ;P
> </attempted-humor>

Well, either i am dumb or that is pretty good humour coz I found it funny
:-)

Cheers,
Ryan

attached mail follows:

> Use floor() instead of round(). Using the round() function will round
> anyone whose age is above 16.5 to 17, while floor() always rounds down.

Thanks mate...silly me.

Cheers,
Ryan

attached mail follows:

* "Ryan A" <ryancoinpass.com>:
> This is the code I am using to display a persons age from the mysql db:
>
> $day1=strtotime($age);
> $day2 = strtotime(date("Y-m-d"));

Just to be pedantic... just use time() for the above statement; no
reason to do extra work here. (date() will actually call time() anyways)

> $dif_s = ($day2-$day1);
> $dif_d = ($dif_s/60/60/24);
> $age = round(($dif_d/365.24));

And, as someone else mentioned, you want to do floor() here, as somebody
is 16 until their 17th birthday.

--
Matthew Weier O'Phinney
Zend Certified Engineer
http://weierophinney.net/matthew/

attached mail follows:

Satyam wrote:
> I would rather use native data types and functions. This is a good idea
> when you have to deal with the balance sheet of a corporation, where you
> have to handle huge numbers and still be precise up to the last cent. For
> most retail business, where the largest amount can still be expressed in
> cents within the range of a 32 bit integer, the bcmath package is like
> overkill.

Please don't top-post. You make a fair point though. Have you looked at
the "precision" configuration directive [1]?

In my applications I just let PHP store as many significant digits as it
likes during processing, and use number_format() whenever displaying to
limit it to 2 decimal places. That, coupled with storing them as
decimals with 2 decimal places in my MySQL databases, achieves
everything I need.

Jasper

attached mail follows:

Hi,

Saturday, July 2, 2005, 6:57:07 PM, you wrote:
S> The lack of a specific type to store monetary values is something of a
S> problem with commercial applications. Be it that you have value added tax
S> or sales tax to add per-item to an invoice or any other calculation like
S> commissions, discounts and such, you end up with an endless number of
S> insignificant decimals which cause trouble. If you forget to round off the
S> extra decimals, comparing for equality doesn't always work, if you carry a
S> running total with the whole decimals, the total of the invoice might not
S> always come good, as the rounding of the total might differ from the total
S> of the rounded individual values. Been there, wrecked that. I've been
S> avoiding this traps out of discipline and hard work, but it is really
S> tiresome.

S> Thus, I was thinking, is there a better way? Even Microsoft added a
S> currency data type to its Visual Basic long ago. Shall we wait?

S> In the meantime, how about storing monetary values as integers, and storing
S> them in the database as integers as well. You see, to show them in the
S> screen, I always pass them through a formatting function. Whenever I read
S> them from the user input, I do it through a parsing function. If those
S> functions scale the value the appropriate number of decimal places, nobody
S> cares how it is used internally. And currency values, no matter what you do
S> with them, they always scale the same way. You will never multiply two
S> currency values together. There is no such a thing as dollars-squared. If
S> you have two positions for cents, it will always be so, no matter what you
S> do with them.

S> I guess, it would be prudent to have a scaling factor to allow for, for
S> example, tenths of cents. Several kind of businesses express their unit
S> prices in fraction of cents, because they never actually sell units and the
S> difference does add up in the total. So, you might set that factor to zero,
S> for those currencies that use no cents (as was the case with the Italian
S> Lira or the Spanish Peseta), two, as for the Euro or Dollar, or even three
S> or four, for certain specific business. Anyhow, the only functions that
S> would care about this scaling factor would be the user input/output
S> functions, internally within the application, you wouldn't care. Actually,
S> it would need to values, the scaling factor (which might be three) and the
S> number of decimal places (which might be two).

S> Of course, integers have a range limit, and the type of business has to be
S> the kind that manages with only that.

S> Now, am I missing something in all this? Please comment. Thanks

S> Satyam

I store dollar amounts as integers and use this function to convert

function dollars2cents($value){
  $value = sprintf("%0.2f",trim($value));
  list($a,$b) = explode('.',$value);
  if(floatval($value)<0) $b = $b*-1; //negative amount?
  return intval($a)*100 + intval($b);
}

--
regards,
Tom

attached mail follows:

I'm working on the design of a program for sending automatic messages to users, based on certain conditions. It seems like there should be some sort of framework for this sort of thing, but I'm not sure what it would be called, besides "auto-reply framework." I didn't find anything when searching for that.

Here's an example of what I'm talking about:

Message M0 should be sent to
- all current users of service S
- where membership expiration is in 30 days from today

Message M1 should be sent to
- all current users of service S
- where membership level == "premium"
- where signup date was 45 days ago

Message M2 should be sent to
- former users of service S
- where membership expiration was at least 30 days ago

Message M3 should be sent to
- former users of service S
- where membership expiration was at least 60 days ago
- where user already got message M2 at least 30 days ago

Etc. Etc.

So the point is that I need to be able to set up rules for what each message contains, and when each message should be sent, based on selected conditions.

Is there anything out there (PHP/Mysql solution preferably) that might give some help with something like this?

Thanks,
Nate

attached mail follows:

On Sat, 2 Jul 2005, Nate Tanner wrote:

> I'm working on the design of a program for sending automatic messages to
> users, based on certain conditions. It seems like there should be some
> So the point is that I need to be able to set up rules for what each message contains, and when each message should be sent, based on selected conditions.
> Is there anything out there (PHP/Mysql solution preferably) that might give some help with something like this?

Hi Nate,

maybe something here could help you:
http://freshmeat.net/search/?q=membership&section=projects&Go.x

I have done similar things with perl (could be also php from cli) and
crontab, and a web interface for setting up things, but all handmade.

attached mail follows:

On Sat, 2 Jul 2005, Jochem Maas wrote:
>> I would like to use PHP's memcached extension to store objects. However I
>> keep getting the "incomplete object" everytime I try to operate on an
>
> load the class definition BEFORE you try to extract the object from the
> cache.

Thanks to Jochem and Brad for your answers. I see now where my problem is.

I forgot to post that the objects I want to cache are recordsets generated
by Adodb. However, since the recordset class is generated by Adodb with a
(I guess) factory class, and the object's class is not defined in a file
with the same name as the class, how to figure out which file to load
:-S ? ... I've googled to see if there's some sample code for caching
adodb recordsets, without success so far. Is someone aware of some class
to cache Adodb recordsets in memcached?.

Thanks again,
Rodolfo.

• text/plain attachment: DELETED0.TXT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]