* [9fans] APE: a further note.
@ 2010-04-15 18:26 tlaronde
2010-04-15 18:30 ` erik quanstrom
0 siblings, 1 reply; 10+ messages in thread
From: tlaronde @ 2010-04-15 18:26 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-15 18:26 [9fans] APE: a further note tlaronde
@ 2010-04-15 18:30 ` erik quanstrom
2010-04-15 18:51 ` Federico G. Benavento
2010-04-16 7:27 ` tlaronde
0 siblings, 2 replies; 10+ messages in thread
From: erik quanstrom @ 2010-04-15 18:30 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-15 18:30 ` erik quanstrom
@ 2010-04-15 18:51 ` Federico G. Benavento
2010-04-15 18:57 ` erik quanstrom
2010-04-16 7:27 ` tlaronde
1 sibling, 1 reply; 10+ messages in thread
From: Federico G. Benavento @ 2010-04-15 18:51 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
-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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-15 18:51 ` Federico G. Benavento
@ 2010-04-15 18:57 ` erik quanstrom
2010-04-16 9:20 ` ron minnich
0 siblings, 1 reply; 10+ messages in thread
From: erik quanstrom @ 2010-04-15 18:57 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-15 18:30 ` erik quanstrom
2010-04-15 18:51 ` Federico G. Benavento
@ 2010-04-16 7:27 ` tlaronde
2010-04-16 12:15 ` erik quanstrom
1 sibling, 1 reply; 10+ messages in thread
From: tlaronde @ 2010-04-16 7:27 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-15 18:57 ` erik quanstrom
@ 2010-04-16 9:20 ` ron minnich
2010-04-16 9:36 ` Steve Simon
2010-04-16 12:04 ` erik quanstrom
0 siblings, 2 replies; 10+ messages in thread
From: ron minnich @ 2010-04-16 9:20 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
-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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-16 9:20 ` ron minnich
@ 2010-04-16 9:36 ` Steve Simon
2010-04-17 17:09 ` C H Forsyth
2010-04-16 12:04 ` erik quanstrom
1 sibling, 1 reply; 10+ messages in thread
From: Steve Simon @ 2010-04-16 9:36 UTC (permalink / raw)
To: 9fans
> -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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-16 9:20 ` ron minnich
2010-04-16 9:36 ` Steve Simon
@ 2010-04-16 12:04 ` erik quanstrom
1 sibling, 0 replies; 10+ messages in thread
From: erik quanstrom @ 2010-04-16 12:04 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-16 7:27 ` tlaronde
@ 2010-04-16 12:15 ` erik quanstrom
0 siblings, 0 replies; 10+ messages in thread
From: erik quanstrom @ 2010-04-16 12:15 UTC (permalink / raw)
To: 9fans
> > 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] APE: a further note.
2010-04-16 9:36 ` Steve Simon
@ 2010-04-17 17:09 ` C H Forsyth
0 siblings, 0 replies; 10+ messages in thread
From: C H Forsyth @ 2010-04-17 17:09 UTC (permalink / raw)
To: 9fans
> -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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-04-17 17:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-15 18:26 [9fans] APE: a further note tlaronde
2010-04-15 18:30 ` erik quanstrom
2010-04-15 18:51 ` Federico G. Benavento
2010-04-15 18:57 ` erik quanstrom
2010-04-16 9:20 ` ron minnich
2010-04-16 9:36 ` Steve Simon
2010-04-17 17:09 ` C H Forsyth
2010-04-16 12:04 ` erik quanstrom
2010-04-16 7:27 ` tlaronde
2010-04-16 12:15 ` erik quanstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).