Thomas thanks.. useful string ... bob
On 2/1/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Thomas Wouters <[EMAIL PROTECTED]> writes:
>
> > On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
> >> [Thomas Wouters]
> >> > Well, I said 4.0.3, and that was wrong. It's actually a pre-rel
Thomas Wouters <[EMAIL PROTECTED]> writes:
> On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
>> [Thomas Wouters]
>> > Well, I said 4.0.3, and that was wrong. It's actually a pre-release of
>> > 4.0.3
>> > (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
>> >
[Thomas]
> Done,
Thanks!
> although it was nowhere near obvious to me that -1 would be a sane
> sentinel value ;) Not that I don't believe you, but it took some actual
> reading of _PyLong_AsScaledDouble to confirm it.
Nope, the thing to do was to read the docs for _PyLong_AsScaledDouble,
which
On Wed, Feb 01, 2006 at 10:15:15AM -0500, Tim Peters wrote:
> Thomas, for these _PyLong_AsScaledDouble()-caller cases, I suggest doing
> whatever obvious thing manages to silence the warning. For example, in
> PyLong_AsDouble:
>
> int e = -1; /* silence gcc warning */
>
> and then add:
>
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
> [Thomas Wouters]
> > Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
> > (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
> > behaves the same way. The normal make process shows quit
Tim Peters <[EMAIL PROTECTED]> wrote:
> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
>> function
>
>
Tim Peters wrote:
>>It inlines the function to make this determination.
>
>
> Very cool! Is this a new(ish) behavior?
In 3.4:
http://gcc.gnu.org/gcc-3.4/changes.html
# A new unit-at-a-time compilation scheme for C, Objective-C, C++ and
# Java which is enabled via -funit-at-a-time (and implied
Sjoerd Mullender wrote:
> I don't quite understand what's the big deal.
Traditionally, people see two problems with these initializations:
- the extra initialization may cause a performance loss.
- the initialization might hide real bugs later on. For example,
if an additional control flow branc
[Thomas Wouters]
> Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
> (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
> behaves the same way. The normal make process shows quite a lot of output on
> systems that use gcc, so I wouldn't be surpri
Thomas Wouters wrote:
> On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote:
>> Scott Dial <[EMAIL PROTECTED]> writes:
>>
>>> So, either the GCC people have not noticed this problem, or (more
>>> likely) have decided that this is acceptable, but clearly it will cause
>>> spurious warni
[Martin v. Löwis]
> It inlines the function to make this determination.
Very cool! Is this a new(ish) behavior?
> Now, it's not true that e can be uninitialized then, but there
> the gcc logic fails:
That's fine -- there are any number of ways a compiler can reach a
wrong conclusion by making c
On Wed, Feb 01, 2006 at 01:51:03PM +, Michael Hudson wrote:
> Scott Dial <[EMAIL PROTECTED]> writes:
>
> > So, either the GCC people have not noticed this problem, or (more
> > likely) have decided that this is acceptable, but clearly it will cause
> > spurious warnings. Hey, after all, they
Scott Dial <[EMAIL PROTECTED]> writes:
> So, either the GCC people have not noticed this problem, or (more
> likely) have decided that this is acceptable, but clearly it will cause
> spurious warnings. Hey, after all, they are just warnings.
Well, indeed, but "no warnings" is a useful policy --
Thomas Wouters wrote:
> My main problem with fixing the warnings is that I don't see the difference
> between, for example, the 'ssize' variable and the 'nchannels' variable
As was pointed out elsewhere, any variable that is passed by-reference
to another function is ignored for the purposes of t
Thomas Wouters wrote:
> On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote:
>
>
>>Is this version of gcc broken in some way relative to other gcc versions,
>>or newer, or ... ? We certainly don't want to see warnings under gcc,
>>since it's heavily used, but I'm not clear on why other ve
On Tue, Jan 31, 2006 at 08:16:21PM -0500, Tim Peters wrote:
> Is this version of gcc broken in some way relative to other gcc versions,
> or newer, or ... ? We certainly don't want to see warnings under gcc,
> since it's heavily used, but I'm not clear on why other versions of gcc
> aren't produc
Guido van Rossum wrote:
>>Well, that's pretty bizarre. There's _obviously_ no way to get to a
>>reference to `e` without going through
>>
>>x = _PyLong_AsScaledDouble(vv, &e);
>>
>>first. That isn't a useful warning.
>
>
> But how can the compiler know that it is an output-only argument
Tim Peters wrote:
>>I noticed a few compiler warnings, when I compile Python on my amd64 with
>>gcc 4.0.3:
>>
>>Objects/longobject.c: In function 'PyLong_AsDouble':
>>Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
>>function
>
>
> Well, that's pretty bizarre. There's _
Robert Kim Wireless Internet Advisor <[EMAIL PROTECTED]> wrote:
> u guys are way over my head :)
> bob
You seem to be new to the python-dev mailing list. As a heads-up,
python-dev is for the development _of_ python. If you are using Python,
and want help or want to help others using Python, you
On 1/31/06, Robert Kim Wireless Internet Advisor <[EMAIL PROTECTED]> wrote:
> u guys are way over my head :)
> bob
>
>
> --
> Robert Kim
> 2611s Highway 101
> suite 102
> San diego CA 92007
> 206 984 0880
>
Stop spamming our list.
Jeremy
___
Python-Dev
On Jan 31, 2006, at 8:16 PM, Tim Peters wrote:
> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my
>> amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized
>> in
u guys are way over my head :)
bob
--
Robert Kim
2611s Highway 101
suite 102
San diego CA 92007
206 984 0880
http://evdo-coverage.com/cellular-repeater.html
On 1/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/31/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > [Thomas Wouters]
> > > Obj
[Tim]
>> Well, that's pretty bizarre. There's _obviously_ no way to get to a
>> reference to `e` without going through
>>
>> x = _PyLong_AsScaledDouble(vv, &e);
>>
>> first. That isn't a useful warning.
[Guido]
> But how can the compiler know that it is an output-only argument?
In the a
On 1/31/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Thomas Wouters]
> > Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
> > function
>
> Well, that's pretty bizarre. There's _obviously_ no way to get to a
> reference to `e` without going through
>
> x = _PyLong_A
[Thomas Wouters]
> I noticed a few compiler warnings, when I compile Python on my amd64 with
> gcc 4.0.3:
>
> Objects/longobject.c: In function 'PyLong_AsDouble':
> Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
> function
Well, that's pretty bizarre. There's _obviously
On Tue, Jan 31, 2006 at 09:04:39PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > All in all, it seems like a timing issue -- the timing is different because
> > the previous test already imported some modules. The test_logging test uses
> > threads, *ugh*. I tried adding a few Event-w
Thomas Wouters wrote:
> All in all, it seems like a timing issue -- the timing is different because
> the previous test already imported some modules. The test_logging test uses
> threads, *ugh*. I tried adding a few Event-waits and time.sleep()'s at
> strategic places, but it doesn't seem to matte
On Tue, Jan 31, 2006 at 06:04:45PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > I also noticed test_logging is spuriously failing, and not just on my
> > machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
> > yet?
> I looked at it, and I couldn't figure it out.
Thomas Wouters wrote:
> I also noticed test_logging is spuriously failing, and not just on my
> machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
> yet?
I looked at it, and I couldn't figure it out. It appears that the last
line of communication is somehow lost, but I could
I noticed a few compiler warnings, when I compile Python on my amd64 with
gcc 4.0.3:
Objects/longobject.c: In function ‘PyLong_AsDouble’:
Objects/longobject.c:655: warning: ‘e’ may be used uninitialized in this
function
Objects/longobject.c: In function ‘long_true_divide’:
Objects/longobject.c:2
On 1/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Cool. Thanks for the info. It would be nice if Intel would provide
> Python developers with a permanent icc license for Python. Can anyone
> help with that?
I'll try. A dutch friend from long ago (CWI) is now working for
Intel's compiler grou
On 1/6/06, von Löwis Martin <[EMAIL PROTECTED]> wrote:
> I just found that the intel compiler (icc 9.0)
> also supports compiler warnings for portability
> problems.
Cool. Thanks for the info. It would be nice if Intel would provide
Python developers with a permanent icc license for Python. Can
I just found that the intel compiler (icc 9.0)
also supports compiler warnings for portability
problems.
For the file
#include
int foo(size_t x)
{
return x;
}
it says (with -Wall)
a.c(3): remark #1418: external definition with no prior declaration
int foo(size_t x)
^
a.c(5):
33 matches
Mail list logo
