On Mon, 6 Aug 2001, Andy wrote:
>I didn't think that opening a bug report just to
>put a patch in it was correct. Patches are
>supposed to be sent to the php-dev mailing list.
>Was I wrong?
Yes and no. There are no (that I know of) guidelines
for this. But if a bug report with a patch to a bug
is as valid as a report without a patch, it's even more valuable.
'Duplicate' would be more correct status. In this case,
make the report without a patch the duplicate one.
Ideal solution (IMO) is to have the patch sender to submit a bug report
but have them put the patches somewhere where they can be downloaded.
This way the patch files won't get garbled.
--Jani
>On Sun, 05 Aug 2001, Jani Taskinen wrote:
>> Could you please tell me what is the 'Bogus' in this report?
>> It's a bug report which happens to have a patch for the bug too.
>> This is far from bogus report. Reopened.
>>
>> --Jani
>>
>>
>> On 5 Aug 2001 [EMAIL PROTECTED] wrote:
>>
>> >ID: 12581
>> >Updated by: andy
>> >Reported By: [EMAIL PROTECTED]
>> >Old Status: Open
>> >Status: Bogus
>> >Bug Type: dBase related
>> >Operating System: Linux 2.2.16-3
>> >PHP Version: 4.0.6
>> >New Comment:
>> >
>> >status -> bogus
>> >
>> >Previous Comments:
>> >------------------------------------------------------------------------
>> >
>> >[2001-08-05 16:18:03] [EMAIL PROTECTED]
>> >
>> >this is not a bug...already forwarded to [EMAIL PROTECTED]
>> >
>> >Thanks for your help, but next time just send it to [EMAIL PROTECTED]
>> >and don't open a bug about it.
>> >
>> >------------------------------------------------------------------------
>> >
>> >[2001-08-05 16:17:47] [EMAIL PROTECTED]
>> >
>> >The file name to which the patches apply is ext/dbase/dbase.c.
>> >
>> >------------------------------------------------------------------------
>> >
>> >[2001-08-05 16:16:32] [EMAIL PROTECTED]
>> >
>> >Below are patches that fix the problem reported 10/20/2000 in bug report #7374.
>The problem is that when boolean (TRUE or FALSE) fields are present in an imported
>Dbase file, the value is always imported as FALSE (0). This problem has been present
>since 4.0.3. The patches below were generated using distribution 4.0.6.
>> >
>> >466,467c466
>> >< case 'N': /* FALLS THROUGH */
>> >< case 'L': /* FALLS THROUGH */
>> >---
>> >> case 'N':
>> >473a473,486
>> >> case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
>> >> and insert 1 or 0, respectively. db_fdc is the number of
>> >> decimals, which we don't care about. 3/14/01 LEW */
>> >> if ( (*str_value == 'T') || ( *str_value == 'Y' ) ){
>> >> add_next_index_long(return_value, strtol("1", NULL, 10));
>> >> } else {
>> >> if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
>> >> add_next_index_long(return_value, strtol("0", NULL, 10));
>> >> }
>> >> else {
>> >> add_next_index_long(return_value, strtol(" ", NULL, 10));
>> >> }
>> >> }
>> >> break;
>> >544,545c557
>> >< case 'N': /* FALLS THROUGH */
>> >< case 'L': /* FALLS THROUGH */
>> >---
>> >> case 'N':
>> >551a564,578
>> >> case 'L': /* we used to FALLS THROUGH, but now we check for T/Y and F/N
>> >> and insert 1 or 0, respectively. db_fdc is the number of
>> >> decimals, which we don't care about. 3/14/01 LEW */
>> >> if ( (*str_value == 'T') || ( *str_value == 'Y') ){
>> >> add_assoc_long(return_value, cur_f->db_fname, strtol("1",
>NULL, 10));
>> >> } else {
>> >> if ( (*str_value == 'F') || ( *str_value == 'N' ) ){
>> >> add_assoc_long(return_value, cur_f->db_fname,strtol("0",
>NULL, 10));
>> >> }
>> >> else {
>> >> add_assoc_long(return_value, cur_f->db_fname,strtol(" ",
>NULL, 10));
>> >> }
>> >> }
>> >> break;
>> >>
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >
>> >
>> >Edit this bug report at http://bugs.php.net/?id=12581&edit=1
>> >
>> >
>> >
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
