[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?
Bugs item #1645148, was opened at 2007-01-26 11:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: MIME renderer: wrong header line break with long subject?
Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>
The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :
'6 7 8 \n\t9 1 2 3'
?
as there is also the space preserved in
'6 7 8 9 \n\nhello'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574588 ] ctypes: Pointer-to-pointer unchanged in callback
Bugs item #1574588, was opened at 2006-10-10 17:16
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Albert Strasheim (albertstrasheim)
Assigned to: Thomas Heller (theller)
Summary: ctypes: Pointer-to-pointer unchanged in callback
Initial Comment:
This problem is from another post I made to
ctypes-users that didn't show up in the ctypes-users
archive.
C function:
extern CALLBACK_API void foo(void(*callback)(void**)) {
void* p = 123;
printf("foo calling callback\n");
callback(&p);
printf("callback returned in foo\n");
printf("p = 0x%p\n", p);
}
I figured that while I try to find out why returning
c_void_p from a callback gives an error, I might as
well return the address via a pointer to a pointer.
In the Python code I have:
import sys
print sys.version
from ctypes import *
x_t = c_int*10
x = x_t()
def callback(ptr):
print x
print ptr
ptr.contents = cast(addressof(x), c_void_p)
print ptr.contents
#lib = cdll['libcallback.so']
lib = cdll['callback.dll']
lib.foo.argtypes = [CFUNCTYPE(None, POINTER(c_void_p))]
lib.foo(lib.foo.argtypes[0](callback))
Output when I running this script under Python 2.4.3
with ctypes 1.0.0 (I get identical results with Python
2.5 and ctypes 1.0.1):
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)]
foo calling callback
<__main__.c_long_Array_10 object at 0x00963E90>
c_void_p(10048496)
callback returned in foo
p = 0x007B
For some reason, the value I assigned to ptr.contents
isn't present when we return to the C code.
--
>Comment By: Thomas Heller (theller)
Date: 2007-01-26 12:02
Message:
Logged In: YES
user_id=11105
Originator: NO
Sorry for the late reply.
This is not a bug. To dereference a pointer in ctypes you should index
with 0:
print ptr[0]
ptr[0] =
When you replace 'ptr.contents' with 'ptr[0]' in your code then it works
as expected.
In C, these two idioms are identical:
ptr[0]
*ptr
The sematics of ptr.contents is different although somewhat difficult to
explain.
Changing ptr.contents does not change the value that the pointer points
to, instead
it changes the location that the pointer points to.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574588&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?
Bugs item #1645148, was opened at 2007-01-26 10:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?
Initial Comment:
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>
The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :
'6 7 8 \n\t9 1 2 3'
?
as there is also the space preserved in
'6 7 8 9 \n\nhello'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1645148&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-969718 ] BASECFLAGS are not passed to module build line
Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Comment added) made by marienz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason Beardsley (vaxhacker)
Assigned to: Nobody/Anonymous (nobody)
Summary: BASECFLAGS are not passed to module build line
Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build"). It seems that
only the value of OPT is passed along.
This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).
I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.
--
Comment By: Marien Zwart (marienz)
Date: 2007-01-26 21:47
Message:
Logged In: YES
user_id=857292
Originator: NO
I'm seeing a variation of this bug in python 2.5.
As far as I can tell in python 2.4.3 on linux it passes BASECFLAGS and
OPT, appending CFLAGS from the environment to that if set. In python 2.5 it
passes CFLAGS from the Makefile (which is defined as $(BASECFLAGS) $(OPT)
$(EXTRA_CFLAGS)), or OPT and the CFLAGS from the environment if CFLAGS is
set there (this change was made in revision 45232). That means that if you
run setup.py with CFLAGS set they must include -fno-strict-aliasing if
using python 2.5.
I think it would be preferable to prepend BASECFLAGS instead of OPT if
CFLAGS is set in the environment. On my linux machine after building python
2.5 with CFLAGS set to "-O2 -march=athlon-xp" the Makefile has:
OPT=-DNDEBUG -g -O3 -Wall -Wstrict-prototypes
BASECFLAGS= -fno-strict-aliasing
CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
If I run a setup.py with CFLAGS unset it runs:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC ...
Which is reasonable. If I run it with CFLAGS="-O2 -march=athlon-xp":
gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -O2
-march=athlon-xp -fPIC ...
Which misses -fno-strict-aliasing and still includes all the general flags
that I'm trying to set through CFLAGS.
If it used BASECFLAGS from the Makefile instead of OPT it would be:
gcc -pthread -fno-strict-aliasing -O2 -march=athlon-xp -fPIC ...
Which is what I think is the desired result here.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 10:05
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19
Message:
Logged In: YES
user_id=1426882
This is still a bug in Python 2.4.2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
