[9fans] cc nit?

[erik quanstrom]

i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output

; cat > void.c
typedef struct PNOTIFY PNOTIFY

struct PNOTIFY {
void emptiness;
};
<eot>; 8c -a void.c
void.c:1 not a function
void.c:5 syntax error, last name: emptiness
sizeofPNOTIFY = 0;
aggr PNOTIFY
{
T16
};

defn
PNOTIFY(addr) {
complex PNOTIFY addr;
T16
};

[Bakul Shah]

Post by erik quanstrom
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat > void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
void emptiness;
}; ^^^^

Why would you do that?

[erik quanstrom]

Post by Bakul Shah

Post by erik quanstrom
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat > void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
void emptiness;
}; ^^^^

Why would you do that?

because there's nothing that needs to be saved there for the k10
architecture.

- erik

[Bakul Shah]

Post by erik quanstrom

Post by Bakul Shah

Post by erik quanstrom
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat > void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
void emptiness;
}; ^^^^

Why would you do that?

because there's nothing that needs to be saved there for the k10
architecture.

I think this void exension is just plain broken. Try

#include <u.h>
#include <libc.h>
void foo; void bar;
main() { print("%p, %p\n", &foo, &bar);

It fails in the link stage for me.

I would've tried

struct PNOTIFY {
char nothingness[0];
};

as it more directly expresses the intent (at least to me) but
that doesn't work either.

[erik quanstrom]

it's fixable with the following strategy
1. cc: for void's, don't emit anything from the compiler's acid generator
2. acid: accept empty aggrs.

i haven't pushed it to see if i can get acid to crash, and i don't have time
to right now, but this does improve the situation.

- erik

; diff -c /n/dump/2012/0701/sys/src/cmd/acid/dbg.y /sys/src/cmd/acid/dbg.y
/n/dump/2012/0701/sys/src/cmd/acid/dbg.y:75,82 - /sys/src/cmd/acid/dbg.y:75,85
zsemi :
| ';' zsemi

- members : member
- | members member
+ members :
+ {
+ $$ = nil;
+ }
+ | member members
{
$$ = an(OLIST, $1, $2);
}
; diff -c `{yesterday -n2 /sys/src/cmd/cc/acid.c} /sys/src/cmd/cc/acid.c
/n/dump/2012/0629/sys/src/cmd/cc/acid.c:112,117 - /sys/src/cmd/cc/acid.c:112,120
Bprint(&outbuf, " T%d\n", t->etype);
break;

+ case TVOID:
+ break; /* relies on acid being able to handle empty aggrs. */
+
case TIND:
if(s == S)
break;

[erik quanstrom]

Post by erik quanstrom
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat > void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
void emptiness;
};
<eot>; 8c -a void.c
void.c:1 not a function
void.c:5 syntax error, last name: emptiness
...

I'm not sure where this is documented, but, isn't the problem (not just
syntactically) with the above the missing semicolon on the typedef line and
not the void'ness issue?

that's true, i did miss the semicolon. but that was a copypasta problem;
the issue still exists.

- erik

[Comeau At9Fans]

Post by erik quanstrom
i haven't tracked down thie issue yet, but it appears that ?c
generate unparsable acid output
; cat > void.c
typedef struct PNOTIFY PNOTIFY
struct PNOTIFY {
void emptiness;
};
<eot>; 8c -a void.c
void.c:1 not a function
void.c:5 syntax error, last name: emptiness
...

I'm not sure where this is documented, but, isn't the problem (not just
syntactically) with the above the missing semicolon on the typedef line and
not the void'ness issue?

[Charles Forsyth]

instead of trying to make void work as a data type declaration, it might be
clearer to accept an empty struct.

[Comeau At9Fans]

On Sun, Jul 1, 2012 at 4:39 PM, Charles Forsyth

Post by Charles Forsyth
instead of trying to make void work as a data type declaration, it might
be clearer to accept an empty struct.

Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof, initializers,
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero length
objects of this nature for some other reasons.

[Charles Forsyth]

Yes, I was assuming the same approach as for the existing void data
declaration, that the structure is given a nominal size,
for just the reasons you give. (That's what gcc seems to do.)

Post by Comeau At9Fans
Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof, initializers,
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero length
objects of this nature for some other reasons.

[Charles Forsyth]

Even better might be to do neither: eliminate support for void data, and
give the declaration a type that doesn't provoke so much discussion.
It's just a placeholder.

Post by Charles Forsyth
Yes, I was assuming the same approach as for the existing void data
declaration, that the structure is given a nominal size,
for just the reasons you give. (That's what gcc seems to do.)

[Comeau At9Fans]

On Sun, Jul 1, 2012 at 6:34 PM, Charles Forsyth

Post by Charles Forsyth
Even better might be to do neither: eliminate support for void data, and
give the declaration a type that doesn't provoke so much discussion.
It's just a placeholder.

Post by Charles Forsyth
Yes, I was assuming the same approach as for the existing void data
declaration, that the structure is given a nominal size,
for just the reasons you give. (That's what gcc seems to do.)

I don't know where this will lead for 8c et al, so I'll throw it out there
anyway in the spirit of placeholders:

int : 0;

[Comeau At9Fans]

On Sun, Jul 1, 2012 at 6:32 PM, Charles Forsyth

Post by Charles Forsyth
Yes, I was assuming the same approach as for the existing void data
declaration, that the structure is given a nominal size,
for just the reasons you give. (That's what gcc seems to do.)

Post by Comeau At9Fans
Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof, initializers,
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero length
objects of this nature for some other reasons.

Actually gcc gives it (the empty struct) sizeof zero (same as for its zero
length arrays). Comeau mimics that behavior in gcc-mode, but used to/still
can also generate a dummy internal member too (usually a char bringing
forth sizeof 1).

[Charles Forsyth]

You're right. I'd misread the assembly code.

Post by Comeau At9Fans
Actually gcc gives it (the empty struct) sizeof zero (same as for its zero
length arrays).

[Charles Forsyth]

Anyway, for a single use inside a single program, it's probably better just
to do what we'd do
if we couldn't just change the compiler, and change the type to a valid one
for data.

[erik quanstrom]

Post by Comeau At9Fans
Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof, initializers,
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero length
objects of this nature for some other reasons.

actually, kenc is pretty good about all these. if you have

struct fu {void x;};

and take sizeof(struct fu), that will give a diagnostic error.

the reason i avoided it was to not mess with the grammer, but if this is a
common thing, maybe it's no big deal.

though as charles points out, it is a bit of a waste of time.

- erik

[Comeau At9Fans]

Post by Comeau At9Fans

Post by Comeau At9Fans
Many compilers do just that, however, that said, unless the compiler is
prepared for it, since it effectively yields a struct of zero size which
normally is a no-go, it could produce bugs involving sizeof,

initializers,

Post by Comeau At9Fans
pointer addition et al, even some divisions by zero if the compiler is
making certain assumptions already, unless it already can have zero

length

Post by Comeau At9Fans
objects of this nature for some other reasons.

actually, kenc is pretty good about all these. if you have
struct fu {void x;};
and take sizeof(struct fu), that will give a diagnostic error.
the reason i avoided it was to not mess with the grammer, but if this is a
common thing, maybe it's no big deal.
though as charles points out, it is a bit of a waste of time.

If my memory serves, there is some wiggle room in C89 about how the empty
struct works, though generally it wouldn't fly, and C99 disallows it, while
C++ allows it (but it's sizeof > 0). Plus it's a common extension made
prevalent via gcc.