Robert Bradshaw [EMAIL PROTECTED] wrote:
>I second the fact that Pyrex should never generate invalid C code.
:)
>If there are errors, it probably won't be fixed by changing the pyx
>file, rather the compiler itself needs fixing.
My concern was again more about warnings from things in user-level pyx code
that do not necessarily constitute "invalid code", but *could* constitute it.
You know, cases end users are better judges of, ultimately, which usually is
close to tantamount to a "good warning use case".
Examples I'm thinking of are things like expressions "always being true due
to the range of an unsigned type" (or for other reasons), or "using variables
before they're initialized", and that sort of thing. { I've actually found
a few bugs in my own code this way, though only with mucking about in the
generated code or doing a "cython-demangle" in my brain, but such things are
less friendly to more casual users. }
>(but I'm still not convinced that it should be on by default).
Yes, for tracking down bugs in Cython you probably don't want #file/#line, but
the typical user (hopefully!) isn't in that business. Like Linus defaulting
drivers in Linux to what he likes, you surely have the discretionary power to
pick what Cython debuggers particularly want/use most of the time. :) More
seriously, it might make sense at this stage of Cython to default to not
emitting #line and at a later stage to default to emitting it. The choice
also interacts with meta-programs that could generate bogus C, too. It would
probably be best to just import Cython compiler flags from a $CYTHON_FLAGS,
$HOME/.cythonrc, etc., so that it could just be very easy to switch around.
Anyway, I'm less interested in the default setting process or default value
than the feature itself.
>Short of invalid extern declarations, have you ever had any C errors/
>warnings that were due to bad Pyrex/Cython code?
I have seen some innocuous warnings. Things that come to mind are unsigned
being greater than 0 (in checks on index bounds I think), code that can never
be reached due to the goto/label layout, and un-filled-in initializers...just
off the top of my head. These were all innocuous. There are enough unused
variable warnings that I had to put -Wno-unused in my CFLAGS.
The un-filled-in init thing happens with classes (for a while I had a 1-line
patch to add an EmptySlot("tp_del") to slot_table in Compiler/TypeSlots.py.
The default args impl also triggers this, and possibly other impl things.
More significantly Cython has no field initializer syntax (so correlating it
to pyx code is not meaningful anyway). Hence -Wno-missing-field-initializers
makes sense in CFLAGS, too. { Often it makes great sense to elide fields in
C code anyway for portability across versions of the structs. }
>Thanks. I'll definitely plan to take a look, and I will certainly add
>#file and #line output to Cython
Fabulous! :) Thanks.
cb
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
