> -T is great. But Python can't be built with it. Python explicitly
> creates functions with type signatures that don't match and this makes
> -T very unhappy.
the examples i had to fix (that didn't simply require
#pragma incomplete) were errors, for instance something like the following:
one func
> > compile with -FVTw. -T causes type signatures to be
> > emitted. the linker won't link mismatched type signatures.
> > i've found this to be very useful.
>
> Thanks: I will add the flags by default in the Plan9 parameter file
> in my framework. Even if it does not catch all, it will help.
-
On Fri Apr 16 05:23:38 EDT 2010, rminn...@gmail.com wrote:
> -T is great. But Python can't be built with it. Python explicitly
> creates functions with type signatures that don't match and this makes
> -T very unhappy.
why would they do that?
> Just a warning: it's good to turn it on, but there a
> -T is great. But Python can't be built with it. Python explicitly
> creates functions with type signatures that don't match and this makes
> -T very unhappy.
Is there a #pragma to turn off type checking on a symbol,
somthing like #pragma incomplete?
-Steve
-T is great. But Python can't be built with it. Python explicitly
creates functions with type signatures that don't match and this makes
-T very unhappy.
Just a warning: it's good to turn it on, but there are cases where it
will lead to an error that is not an error (depending on how you
define er
On Thu, Apr 15, 2010 at 02:30:15PM -0400, erik quanstrom wrote:
> > gcc(1) is very verbose (well: I always set -Wall). ken-cc
> > is---surprise---more laconic; but when he was saying: no! he was right,
> > for things that were going silently under NetBSD.
>
> compile with -FVTw. -T causes type si
On Thu Apr 15 14:52:12 EDT 2010, benave...@gmail.com wrote:
> -T with in APE for lunix code doesn't cut it without hand
> editing tons of it, there's always a function prototype
> missing or even conflicting... hand depending on the
> size of the project it can be unmanageable...
excellent reason
-T with in APE for lunix code doesn't cut it without hand
editing tons of it, there's always a function prototype
missing or even conflicting... hand depending on the
size of the project it can be unmanageable...
On Thu, Apr 15, 2010 at 3:30 PM, erik quanstrom wrote:
>> gcc(1) is very verbose (we
> gcc(1) is very verbose (well: I always set -Wall). ken-cc
> is---surprise---more laconic; but when he was saying: no! he was right,
> for things that were going silently under NetBSD.
compile with -FVTw. -T causes type signatures to be
emitted. the linker won't link mismatched type signatures.
Still fixing things for correct compilation of TeX and al. under Plan9,
I stumbled upon this one.
Traditional lex(1) uses: char yytext[];
The code (main code for translation between Pascal and C), was declaring
in the external units: char *yytext;
The result is no problem at compilation/linkage,
10 matches
Mail list logo