"Christian Stapfer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Check your program for _uninitialized_variables_.
good point.
> (Just a guess: but what other side-effect than
> changing the values of uninitialized variables
> - and the program's timing, of course - might
> the
"Lil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I already double checked my C code. It runs perfectly fine in C without
> any errors.
Errr - It runs perfectly fine without *announcing* any errors (while
gleefully urinating all over its memory space).
The programming model for
"Lil" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I already double checked my C code. It runs perfectly fine in C without
> any errors. So in my python program, I added a pdb.set_trace()
> and step through the program and it did not dump. But when i took out
> the tracing, the cor
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Lil wrote:'
>
>>I already double checked my C code. It runs perfectly fine in C without
>> any errors. So in my python program, I added a pdb.set_trace()
>> and step through the program and it did not dump. But when i took out
>> the tracing, the core
Lil wrote:'
>I already double checked my C code. It runs perfectly fine in C without
> any errors. So in my python program, I added a pdb.set_trace()
> and step through the program and it did not dump. But when i took out
> the tracing, the core dump came back. "sigh"
so triple-check it.
if your
I already double checked my C code. It runs perfectly fine in C without
any errors. So in my python program, I added a pdb.set_trace()
and step through the program and it did not dump. But when i took out
the tracing, the core dump came back. "sigh"
--
http://mail.python.org/mailman/listinfo/pyth
"Lil" <[EMAIL PROTECTED]> wrote:
> It's in the C code mainly because the buffer is an input to the
> driver. The driver takes a char* as input and I didn't want to pass a
> char* from python -> swig -> C since swig has memory leaks passing
> pointers.
> Do you think this is a Python issue or
Hi Larry,
It's in the C code mainly because the buffer is an input to the
driver. The driver takes a char* as input and I didn't want to pass a
char* from python -> swig -> C since swig has memory leaks passing
pointers.
Do you think this is a Python issue or a Red Hat issue? I'm going to
try
Question: Why not just use Python to read the file?
f=open(filename, 'rb')
fcontents=f.read()
If you need to manipulate what is in fcontents you
can use struct module and/or slicing.
Larry Bates
Lil wrote:
> Hi Everyone! I've been trying to figure out this weird bug in my
> program. I have a p
Hi Everyone! I've been trying to figure out this weird bug in my
program. I have a python program that calls a C function that reads in
a binary file into a buffer. In the C program, buffer is allocated by
calling malloc. The C program runs perfectly fine but when I use python
to call the C functio
10 matches
Mail list logo
