[9fans] gcc/plan9

[9fans] gcc/plan9

[pac]

Hi, friends,

I've got several questions considering GCC on Plan9:

i)

if (sscanf(str+(*pos),"%d",&tag))   [ on gcc/linux]
 ###    !=    ###
if (sscanf(str+(*pos),"%d",&tag)1)   [ on gcc/plan9]
 ###    instead ==    ###
if (sscanf(str+(*pos),"%d",&tag)==1)   [ on gcc/plan9]
is this okay?

ii)

//is this possible/safe???
#ifndef Plan9
#include <strings.h>
#else
#include <string.h>
// otherwise, what to do ?

iii)

in case ii), where does string.h come from (it isn't in /sys/include/gnu/)?
/sys/include/ape/??


Thanks, regards,

++pac.



---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.476 / Virová báze: 273 - datum vydání: 24.4.2003

Re: [9fans] gcc/plan9

[Geoff Collyer]

Testing that *scanf found exactly the number of items you expected is
usually the right thing to do.  scanf and fscanf can return EOF (-1),
so a test against zero will usually be inappropriate.
So the last example you gave,

	if (sscanf(str+(*pos),"%d",&tag)==1)

should be used everywhere, including linux (and tag should be an int,
not a long nor a short).

strings.h is an archaism and shouldn't be needed nor included.  All
ANSI C implementations (hosted ones, anyway) must provide string.h,
and it's been 13 years since the first ANSI C standard, so everybody
really ought to have string.h by now.

GNU configure and much GNU software go out of their way to support
aged or deficient C implementations.  I think it's no longer worth
worrying about pre-ANSI implementations, except for amusement (e.g.,
running V7 on a PDP-11 simulator).  As for broken implementations,
with C News, we found that it was generally better not to contort our
code to accommodate bugs in somebody's C implementation, but to
publish the bug (perhaps including a pointer to the section of the
current C standard that forbids the erroneous behaviour), a test case
to demonstrate it, and a workaround, and to distribute the whole
bundle widely.  Once a vendor realises that it really is his bug and
the customers know it and demand a fix, he tends to fix the bug pretty
quickly.  We found astonishing bugs in production C implementations,
some of which had been around for a long time, and I think helped to
get them fixed.

Re: [9fans] gcc/plan9

[boyd, rounin]

never use scanf

Re: [9fans] gcc/plan9

[Geoff Collyer]

Good point; I rarely use scanf myself.  I have implemented it as part
of a larger stdio implementation though, and didn't take it too
seriously at first, since I don't really use it and I hadn't seen it
used much (e.g., if you grep the V7 source tree for it, there are few
or no uses of it).  One of my early testers countered that scanf was
used `everywhere'; it turns out that X11 uses it heavily.

Speaking of scanners, I found that somebody has modified flex to scan
Unicode input (and cranked up the table sizes appropriately).  I'm
wondering if it's worth modifying it further to scan UTF-8 instead so
it could be used instead of the sorts of tricks I've used to make lex
scan UTF-8.

Re: [9fans] gcc/plan9

[boyd, rounin]

> Good point; I rarely use scanf myself.

i've only even used scanf() when i new no better, after reading K&R.

for toy tools [not programs] i've used sscanf() when i _knew_ what
i was expecting, but a construct like:

     if (*scanf(...))
         ;    /* do something stupid */

well, crash and burn ... can i be more contrary?

gimme a _final solution_ ...

Re: [9fans] gcc/plan9

[Russ Cox]

> Speaking of scanners, I found that somebody has modified flex to scan
> Unicode input (and cranked up the table sizes appropriately).  I'm
> wondering if it's worth modifying it further to scan UTF-8 instead so
> it could be used instead of the sorts of tricks I've used to make lex
> scan UTF-8.

I did a lot of the work toward this, without cranking table sizes
too much, but I didn't really want to deal with the lex syntax.

Russ

Re: [9fans] gcc/plan9

[Dan Cross]

I really would like to see lex (or an evolution of it) brought up
to speed with respect to the modern world.  The idea of a lexical
analyser generator is a good one, even if the implementation is a
little behind the times.

	- Dan C.

Re: [9fans] gcc/plan9

[William Josephson]

On Wed, Jul 16, 2003 at 10:22:02PM -0400, Dan Cross wrote:
> I really would like to see lex (or an evolution of it) brought up
> to speed with respect to the modern world.  The idea of a lexical
> analyser generator is a good one, even if the implementation is a
> little behind the times.

I suppose, but who uses lex with C anymore?

Re: [9fans] gcc/plan9

[Dan Cross]

> I suppose, but who uses lex with C anymore?

Well, probably no one.  But the question is whether this is due to it
being a bad idea, or because lex fell out of maintenance and suffered
bitrot?  I think if the syntax were revamped and it were extended to
deal with utf-8, it'd be a powerful tool and gain favor once again.

	- Dan C.

Re: [9fans] gcc/plan9

[boyd, rounin]

> > I suppose, but who uses lex with C anymore?
>
> Well, probably no one.

i think it was an interesting idea, but didn't really give you anything
much over coding it my hand.  yacc gave you a lot, but the error
recovery was awful.

however, given that rc's grammar was implemented in yacc it
described the 'language'.  iirc many 'normal' bourne shell
constructions worked, but nobody knew why, and then there
was the shell-gol.

Re: [9fans] gcc/plan9

[Skip Tavakkolian]

> I suppose, but who uses lex with C anymore?

I cut/paste/modify the lexer out of awk or something else
(8c, etc).  It seems like at times lex forces you to unnaturally fit
things into its model.  I've often wondered if an specialized language
with an expression syntax that lends itself to this type of work
wouldn't be better.  Awk is nearly there.

Re: [9fans] gcc/plan9

[Clint Olsen]

In article <200307170222.h6H2M2715827@augusta.math.psu.edu>, Dan Cross wrote:
> I really would like to see lex (or an evolution of it) brought up to
> speed with respect to the modern world.  The idea of a lexical analyser
> generator is a good one, even if the implementation is a little behind
> the times.

Lex for the most part has been displaced by flex ["He's dead, Jim"].  In
past projects I've used re2c, which is considerably more lightweight and
more akin to hand-generated scanners.  Be warned that while re2c generates
ANSI C, it is written in C++.  Some folks on the YASM project took it and
rewrote it in ANSI C but they Borg-ified it into their YASM build system.
Some cord cutting would be required, but it wouldn't be that difficult to
do.

The maintainer of re2c apears to have taken the source from his site, but
it's a port on FreeBSD and many Linux distributions.  Here's a link for the
lazy:

http://www.0lsen.net/re2c-0.9.1.tar.gz

-Clint

Re: [9fans] gcc/plan9

[boyd, rounin]

> Lex for the most part has been displaced by flex ["He's dead, Jim"].  In
> past projects I've used re2c, which is considerably more lightweight and
> more akin to hand-generated scanners.  Be warned that while re2c generates
> ANSI C, it is written in C++.  Some folks on the YASM project took it and
> rewrote it in ANSI C but they Borg-ified it into their YASM build system.
> Some cord cutting would be required, but it wouldn't be that difficult to
> do.

mvs lives ... almost.

Re: [9fans] gcc/plan9

[boyd, rounin]

> Some folks on the YASM ...

YASM?  Yet Another Stupid Module?

Re: [9fans] gcc/plan9

[Clint Olsen]

In article <00a801c34d0d$c96bbaa0$b9844051@insultant.net>, boyd, rounin wrote:
>
> YASM?  Yet Another Stupid Module?

Having not used it, I cannot say :)  I'll let you have a looksee and decide
for yourself:

http://www.tortall.net/projects/yasm

-Clint

Re: [9fans] gcc/plan9

[boyd, rounin]

> http://www.tortall.net/projects/yasm

    The goal of the YASM project is to write an assember that takes over
    NASM's current and future user base.

goody gumdrops [brick top] ... i just love dicking around with assembler.

movc5 anyone?

Re: [9fans] gcc/plan9

[Jack Johnson]

boyd, rounin wrote:
> movc5 anyone?

2. d4

Take your Sicilian somewhere else!

(my apologies if we have any real Sicilians on the list)

-Jack

Re: [9fans] gcc/plan9

[northern snowfall]

> (my apologies if we have any real Sicilians on the list)


 >:[

Don

http://www.7f.no-ip.com/~north_

>

Re: [9fans] gcc/plan9

[Douglas A. Gwyn]

Jack Johnson wrote:
> (my apologies if we have any real Sicilians on the list)

They never will be missed.

Re: [9fans] gcc/plan9

[William Josephson]

On Wed, Jul 16, 2003 at 05:35:02PM -0700, Geoff Collyer wrote:
> Speaking of scanners, I found that somebody has modified flex to scan
> Unicode input (and cranked up the table sizes appropriately).  I'm
> wondering if it's worth modifying it further to scan UTF-8 instead so
> it could be used instead of the sorts of tricks I've used to make lex
> scan UTF-8.

Per usual, both Russ and I have very similar code that
will deal with this without bloating the tables too much.
I was using it for a different, more specialized purpose
and since I never use lex with C, I didn't actually bother
to update lex:

       "The asteroid to kill this dinosaur is still in orbit."

Re: [9fans] gcc/plan9

[boyd, rounin]

to quote Pere Ubu:

    But I don't need a cure
    D-don't need a cure
    D-don't need a cure
    I need a final solution

        -- http://www.secraterri.com/final.html

write a lexical analyser and a parser, from scratch.

_never cheat_ -- it will come back and bite you.

Re: [9fans] gcc/plan9

[boyd, rounin]

> GNU configure and much GNU software go out of their way to support
> aged or deficient C implementations.  I think it's no longer worth
> worrying about pre-ANSI implementations, except for amusement (e.g.,
> running V7 on a PDP-11 simulator).

weird, i re-wrote ps(1) for 32V [vax] and V7 [pdp-11] and with a few ifdefs
the code was pretty much the same.  it even dealt with _lnodes_, which is
specific to one site.

it really wasn't that hard.  finding the pages (the segment was trivial) for
the stack was a bit interesting so you could print the args but infinitely
better than that pus they put into SysVile.

u.u_comm i can cope with, but that other crap ...

[9fans] gcc/plan9

[pac]

Thanks, folks!

It was a terrible bug to catch in a code that was not mine. (Remember, I'm
almost a non-programmer). I will ask the authors
to adopt the proposed changes. However, I'm happy I have a new port
completed, good training. And, step-by-step, getting rid of
linux on my standalone box!!!

Thanks for patience with my often ignorant questions,
cheers,
++pac.




---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.476 / Virová báze: 273 - datum vydání: 24.4.2003