[9fans] APE: a further note.

[9fans] APE: a further note.

[tlaronde]

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, but a suicide at first
yytext external access. And I wandered with acid(1) and sam(1) to try
to understand what was going on. Of course, I suspected UTF/Rune and the
like, before suspecting a problem on the linkage.

So APE is a very good POSIX environment for verification, since, until
now, when Plan9 was not agreeing, it was right.

So for Plan9 lex(1), yytext is an array. And you can specify "%array" in
the first definition of your *.l for flex(1) so that it handles an
array too.

A side note.

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.

And I like sam(1) too... Regexp and the mouse, that's it!
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] APE: a further note.

[erik quanstrom]

> 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.
i've found this to be very useful.

- erik

Re: [9fans] APE: a further note.

[Federico G. Benavento]

-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 <quanstro@quanstro.net> 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 signatures to be
> emitted.  the linker won't link mismatched type signatures.
> i've found this to be very useful.
>
> - erik
>
>



-- 
Federico G. Benavento

Re: [9fans] APE: a further note.

[erik quanstrom]

On Thu Apr 15 14:52:12 EDT 2010, benavento@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 to avoid linux code.  if there are specific
problems with ape that don't allow -T to work correctly,
they should be fixed.  i haven't done much with ape recently,
except getting an updated version of the One True Awk
working with no spurious floating point exceptions.

- erik

Re: [9fans] APE: a further note.

[ron minnich]

-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 error).

ron

Re: [9fans] APE: a further note.

[Steve Simon]

> -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

Re: [9fans] APE: a further note.

[C H Forsyth]

> -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 function expecting a value in the middle
of a structure that was #ifdef'd out for another function's compilation,
because different #defines were in scope.

Re: [9fans] APE: a further note.

[erik quanstrom]

On Fri Apr 16 05:23:38 EDT 2010, rminnich@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 are cases where it
> will lead to an error that is not an error (depending on how you
> define error).

of course the type signature is based on the c type, not the
machine type.  in the case of all supported architechtures,
long and int produce the same code.  so, for example,
-T will be unhappy if you say long and mean int,
program won't crash.  but neither will it be portable.

long is now a vestigial type.

- erik

Re: [9fans] APE: a further note.

[tlaronde]

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 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.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] APE: a further note.

[erik quanstrom]

> > 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.

-T is absolutely a lifesaver when working together.  i updated
libthread with chanisclosed(2) support recently.  i forgot to warn
everyone that the Channel structure had changed and everything
using the thread library needed to be recompiled.  the bad news
was i got a week's reports of linker errors.  the good news was
nothing that linked broke in mysterious ways.  it would be nearly
impossible to make changes like that in a production environment
without -T.

- erik