[9fans] c compiler bug

[9fans] c compiler bug

[erik quanstrom]

i don't think this should link, since wrongaddr calls
fn with an Outer* not an Inner*.

#include <u.h>
#include <libc.h>

typedef	struct	Inner	Inner;
typedef	struct	Outer	Outer;

struct Inner {
	int	x;
};

struct Outer {
	char	buf[0x1000];
	Inner;
};

void
wrongaddr(Outer *o)
{
	static void fn(Outer*);

	fn(o);
}

void
main(void)
{
	Outer *o;

	o = malloc(sizeof *o);
	memset(o, 0, sizeof *o);
	print("addr o	%#p\n", o);
	print("addr o.x	%#p\n", &o->x);
	wrongaddr(o);
}

static void
fn(Inner *i)
{
	print("fn addr i.x	%#p\n", &i->x);
}
; 6.cbug
addr o	0x4018f0
addr o.x	0x4028f0
fn addr i.x	0x4018f0

Re: [9fans] c compiler bug

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Sat, Feb 16, 2013 at 9:38 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> i don't think this should link, since wrongaddr calls
> fn with an Outer* not an Inner*.
> ...


Normally in more mainstream C the nested "static void fn(Outer*);"
declaration would produce a diagnostic and instead what it (the compiler
and the code) seems to be doing is setting up allowing the call to compile
and once that is satisfied then the subsequent definition "has" to match
it, as perhaps a way to do type punning.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1315 bytes --]

Re: [9fans] c compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On 18 February 2013 13:02, Comeau At9Fans <comeauat9fans@gmail.com> wrote:

> seems to be doing is setting up allowing the call to compile and once that
> is satisfied then the subsequent definition "has" to match it, as perhaps a
> way to do type punning.


No, the compiler is simply applying scope rules. Without that inner
declaration explicitly overriding the outer declaration--whether static or
extern is used--
it will not compile (eg, if you put "static void fn(Outer*);" or "extern
void fn(Outer*);" and remove static from fn in the file scope).

The behaviour is undefined in ANSI C if two declarations that refer to the
same object or function do not have compatible types
(normally, you're protected by another rule that you can't have
incompatible declarations *in the same scope*).

ANSI C does, however, forbid the inner static declaration (which surprised
me)
"The declaration of an identifier for a function that has block scope shall
have no explicit storage-class specifier other than extern." (6.7.1)

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

Re: [9fans] c compiler bug

[erik quanstrom]

> No, the compiler is simply applying scope rules.  Without that inner
> declaration explicitly overriding the outer declaration--whether
> static or extern is used-- it will not compile (eg, if you put "static
> void fn(Outer*);" or "extern void fn(Outer*);" and remove static from
> fn in the file scope).

since nested functions are not allowed, applying nested scope seems
a bit odd.  anyway, ...

if the declaration were in the same place but the referenced
function were in another file, the -T would have prevented the
link.  my question is, why doesn't the c compiler internally
apply the same rule?

- erik

Re: [9fans] c compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

On 18 February 2013 15:02, erik quanstrom <quanstro@quanstro.net> wrote:

> since nested functions are not allowed, applying nested scope seems
> a bit odd.
>

Nevertheless, that is what it is.

[-- Attachment #2: Type: text/html, Size: 511 bytes --]

Re: [9fans] c compiler bug

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth
<charles.forsyth@gmail.com>wrote:

> On 18 February 2013 13:02, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
>
>> seems to be doing is setting up allowing the call to compile and once
>> that is satisfied then the subsequent definition "has" to match it, as
>> perhaps a way to do type punning.
>
>
> No, the compiler is simply applying scope rules. Without that inner
> declaration explicitly overriding the outer declaration--whether static or
> extern is used--
> it will not compile (eg, if you put "static void fn(Outer*);" or "extern
> void fn(Outer*);" and remove static from fn in the file scope).
>
> The behaviour is undefined in ANSI C if two declarations that refer to the
> same object or function do not have compatible types
> (normally, you're protected by another rule that you can't have
> incompatible declarations *in the same scope*).
>
> ANSI C does, however, forbid the inner static declaration (which surprised
> me)
> "The declaration of an identifier for a function that has block scope
> shall have no explicit storage-class specifier other than extern." (6.7.1)
>

We're probably saying the same thing.  As you say ANSI C forbids it hence
my comment about normally a diagnostic from a so-called mainstream
compiler.   And as you say without a declaration it would not compile
either.  The declaration should normally be in global scope (it could have
been), which would have also produced a diagnostic since Inner/Outer don't
match.  That leaves the declaration where Eric showed it, which the Plan 9
compiler obviously allowed.  As you note the net effect is it's undefined
(if we're using ANSI C as the metric) hence created a kind of type pun
(even if the original code did it as a mistake).

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 3150 bytes --]

Re: [9fans] c compiler bug

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Mon, Feb 18, 2013 at 10:02 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > No, the compiler is simply applying scope rules.  Without that inner
> > declaration explicitly overriding the outer declaration--whether
> > static or extern is used-- it will not compile (eg, if you put "static
> > void fn(Outer*);" or "extern void fn(Outer*);" and remove static from
> > fn in the file scope).
>
> since nested functions are not allowed, applying nested scope seems
> a bit odd.  anyway, ...
>

It's often to be refrained from even if it were extern and not static.


> if the declaration were in the same place but the referenced
> function were in another file, the -T would have prevented the
> link.  my question is, why doesn't the c compiler internally
> apply the same rule?
>

Wild guessing that it's probably an oversight that it got allowed.

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1760 bytes --]

Re: [9fans] c compiler bug

[hiro]

can you please stop sending html mails? thanks

On 2/21/13, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth
> <charles.forsyth@gmail.com>wrote:
>
>> On 18 February 2013 13:02, Comeau At9Fans <comeauat9fans@gmail.com>
>> wrote:
>>
>>> seems to be doing is setting up allowing the call to compile and once
>>> that is satisfied then the subsequent definition "has" to match it, as
>>> perhaps a way to do type punning.
>>
>>
>> No, the compiler is simply applying scope rules. Without that inner
>> declaration explicitly overriding the outer declaration--whether static
>> or
>> extern is used--
>> it will not compile (eg, if you put "static void fn(Outer*);" or "extern
>> void fn(Outer*);" and remove static from fn in the file scope).
>>
>> The behaviour is undefined in ANSI C if two declarations that refer to
>> the
>> same object or function do not have compatible types
>> (normally, you're protected by another rule that you can't have
>> incompatible declarations *in the same scope*).
>>
>> ANSI C does, however, forbid the inner static declaration (which
>> surprised
>> me)
>> "The declaration of an identifier for a function that has block scope
>> shall have no explicit storage-class specifier other than extern."
>> (6.7.1)
>>
>
> We're probably saying the same thing.  As you say ANSI C forbids it hence
> my comment about normally a diagnostic from a so-called mainstream
> compiler.   And as you say without a declaration it would not compile
> either.  The declaration should normally be in global scope (it could have
> been), which would have also produced a diagnostic since Inner/Outer don't
> match.  That leaves the declaration where Eric showed it, which the Plan 9
> compiler obviously allowed.  As you note the net effect is it's undefined
> (if we're using ANSI C as the metric) hence created a kind of type pun
> (even if the original code did it as a mistake).
>
> --
> Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
> Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
>

Re: [9fans] c compiler bug

[John Floren]

I think his mail client is just too world-class,  breathtaking,
amazing, and fabulous--have you tried it?

On Thu, Feb 21, 2013 at 10:13 AM, hiro <23hiro@gmail.com> wrote:
> can you please stop sending html mails? thanks
>
> On 2/21/13, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
>> On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth
>> <charles.forsyth@gmail.com>wrote:
>>
>>> On 18 February 2013 13:02, Comeau At9Fans <comeauat9fans@gmail.com>
>>> wrote:
>>>
>>>> seems to be doing is setting up allowing the call to compile and once
>>>> that is satisfied then the subsequent definition "has" to match it, as
>>>> perhaps a way to do type punning.
>>>
>>>
>>> No, the compiler is simply applying scope rules. Without that inner
>>> declaration explicitly overriding the outer declaration--whether static
>>> or
>>> extern is used--
>>> it will not compile (eg, if you put "static void fn(Outer*);" or "extern
>>> void fn(Outer*);" and remove static from fn in the file scope).
>>>
>>> The behaviour is undefined in ANSI C if two declarations that refer to
>>> the
>>> same object or function do not have compatible types
>>> (normally, you're protected by another rule that you can't have
>>> incompatible declarations *in the same scope*).
>>>
>>> ANSI C does, however, forbid the inner static declaration (which
>>> surprised
>>> me)
>>> "The declaration of an identifier for a function that has block scope
>>> shall have no explicit storage-class specifier other than extern."
>>> (6.7.1)
>>>
>>
>> We're probably saying the same thing.  As you say ANSI C forbids it hence
>> my comment about normally a diagnostic from a so-called mainstream
>> compiler.   And as you say without a declaration it would not compile
>> either.  The declaration should normally be in global scope (it could have
>> been), which would have also produced a diagnostic since Inner/Outer don't
>> match.  That leaves the declaration where Eric showed it, which the Plan 9
>> compiler obviously allowed.  As you note the net effect is it's undefined
>> (if we're using ANSI C as the metric) hence created a kind of type pun
>> (even if the original code did it as a mistake).
>>
>> --
>> Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
>> Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
>> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
>> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
>>
>

Re: [9fans] c compiler bug

[erik quanstrom]

On Thu Feb 21 13:23:26 EST 2013, john@jfloren.net wrote:
> I think his mail client is just too world-class,  breathtaking,
> amazing, and fabulous--have you tried it?
>
> On Thu, Feb 21, 2013 at 10:13 AM, hiro <23hiro@gmail.com> wrote:
> > can you please stop sending html mails? thanks

why does this bother anybody?  i hadn't even noticed, and i
use nedmail to read my mail.  which is somewhat of an
admission of failure.  i used to just bring up my mail box in
acme until google started base64ing heavily.  which is oddly
another admission of defeat.  after 40 years of trying, we still don't
have 8-bit clean email.

- erik

Re: [9fans] c compiler bug

[Comeau At9Fans]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> On Thu Feb 21 13:23:26 EST 2013, john@jfloren.net wrote:
> > I think his mail client is just too world-class,  breathtaking,
> > amazing, and fabulous--have you tried it?
> >
> > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23hiro@gmail.com> wrote:
> > > can you please stop sending html mails? thanks
>
> why does this bother anybody?  i hadn't even noticed, and i
> use nedmail to read my mail.  which is somewhat of an
> admission of failure.  i used to just bring up my mail box in
> acme until google started base64ing heavily.  which is oddly
> another admission of defeat.  after 40 years of trying, we still don't
> have 8-bit clean email.


It's "just" gmail, perhaps my own admission of failure? :)

--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Re: [9fans] c compiler bug

[Kurt H Maier]

On Thu, Feb 21, 2013 at 01:39:14PM -0500, erik quanstrom wrote:
> On Thu Feb 21 13:23:26 EST 2013, john@jfloren.net wrote:
> > I think his mail client is just too world-class,  breathtaking,
> > amazing, and fabulous--have you tried it?
> >
> > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23hiro@gmail.com> wrote:
> > > can you please stop sending html mails? thanks
>
> why does this bother anybody?  i hadn't even noticed, and i
> use nedmail to read my mail.  which is somewhat of an
> admission of failure.  i used to just bring up my mail box in
> acme until google started base64ing heavily.  which is oddly
> another admission of defeat.  after 40 years of trying, we still don't
> have 8-bit clean email.
>
> - erik
>

Are you seriously marking this request WORKSFORME

Re: [9fans] c compiler bug

[John Floren]

On Thu, Feb 21, 2013 at 10:46 AM, Comeau At9Fans
<comeauat9fans@gmail.com> wrote:
> On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom <quanstro@quanstro.net>
> wrote:
>>
>> On Thu Feb 21 13:23:26 EST 2013, john@jfloren.net wrote:
>> > I think his mail client is just too world-class,  breathtaking,
>> > amazing, and fabulous--have you tried it?
>> >
>> > On Thu, Feb 21, 2013 at 10:13 AM, hiro <23hiro@gmail.com> wrote:
>> > > can you please stop sending html mails? thanks
>>
>> why does this bother anybody?  i hadn't even noticed, and i
>> use nedmail to read my mail.  which is somewhat of an
>> admission of failure.  i used to just bring up my mail box in
>> acme until google started base64ing heavily.  which is oddly
>> another admission of defeat.  after 40 years of trying, we still don't
>> have 8-bit clean email.
>
>
> It's "just" gmail, perhaps my own admission of failure? :)
>

Gmail has interesting ideas sometimes about when it should send HTML.
I seem to have figured out how to make it always send plain-text, but
unfortunately I can't remember how exactly I did that.


john

Re: [9fans] c compiler bug

[hiro]

Sorry, google's inconsistent mail interface made me post to the list
instead of private. I didn't mean to make this a discussion of
google's web technolgy, I just want to promote the sending of certain
compatible formats that everyone can read without problems.

My gmail only sends

Content-Type: text/plain; charset=UTF-8

Your's can, too.

Re: [9fans] c compiler bug

[andrey mirtchovski]

good day. is this the p9p on osx help forum?

Re: [9fans] c compiler bug

[Matthew Veety]

No.

On Feb 21, 2013, at 14:58, andrey mirtchovski <mirtchovski@gmail.com> wrote:

> good day. is this the p9p on osx help forum?
>

Re: [9fans] c compiler bug

[David Leimbach]

Can I run it on my iPhone?

Sent from my iPhone

On Feb 21, 2013, at 11:58 AM, andrey mirtchovski <mirtchovski@gmail.com> wrote:

> good day. is this the p9p on osx help forum?
> 

Re: [9fans] c compiler bug

[steve]

no, but drawterm will (i believe).


On 21 Feb 2013, at 20:27, David Leimbach <leimy2k@gmail.com> wrote:

> Can I run it on my iPhone?
> 
> Sent from my iPhone
> 
> On Feb 21, 2013, at 11:58 AM, andrey mirtchovski <mirtchovski@gmail.com> wrote:
> 
>> good day. is this the p9p on osx help forum?
>> 

Re: [9fans] c compiler bug

[Charles Forsyth]

>and then an appropriate sequence of byte-by-byte loads (or stores) will be
>used to access it,

for static references such as s.c there's an optimisation that allows the nearest
aligned values to be loaded, shifted & masked, and or'd together to save accesses
by byte, but that doesn't seem to be possible for an unaligned pointer reference.

Re: [9fans] c compiler bug

[Charles Forsyth]

actually, it gets worse. i looked up the stuff for ARM, and it was much
as i expected, but they also pointed out another problem, obvious in retrospect.
you say you want structure assignments to work, or at least not
fail. fair enough, but what about this:

	S s;
	int *p = &s.c;
	*p = 1;
	int x = *p;

the point is that in general given an int*, there's no way to know that
the target is misaligned. ARM thoughtfully provides a __packed attribute,
as in
	__packed int *p;
and then an appropriate sequence of byte-by-byte loads (or stores) will be
used to access it, but a normal int* will produce an alignment trap.

Re: [9fans] c compiler bug

[Charles Forsyth]

>Example: Xen 2 used __attribute__ packed heavily, realized at some
>point it was a bad idea, and took another path.

at the time, gcc on arm didn't generate the code to fetch or store the values a byte
at a time, which probably came as a surprise. i haven't tried it myself with gcc
more recently.

Re: [9fans] c compiler bug

[Charles Forsyth]

>It's the compiler's prerogative to decide just how
>the fields should be packed so therefore, the construct is never portable.

it's worse than that: you can't use them to access hardware structures, since
(especially if values are misaligned) there's no guarantee that the generated
code will access them as the hardware requires. you can use them to access existing
software structures from another system, which is why they were added originally,
but even then i'm sceptical, because misaligned accesses only work on x86
(and then only if the kernel doesn't set the alignment trap).
on sparc, arm, and powerpc, you'll get a trap. it was much the same with gcc
last time i checked (but that was some time ago). i remember seeing that
linux on arm handles misaligned traps by interpreting code in the kernel.
(it wasn't for the gcc equivalent of pragma packed, but to support rotten code
from x86.) either way, this seems unlikely to encourage good performance.

it might be better to write a sed or sam script to transform incoming
structure definitions into uchar x[] style.

Re: [9fans] c compiler bug

[Sape Mullender]

I agree; packed data structures are a really bad idea.  They're used
to match some hardware representation of some data structures and
that's not good: It's the compiler's prerogative to decide just how
the fields should be packed so therefore, the construct is never portable.
This is why we have nhgets, nhgetl, nhgetv and hnputs, hnputl, hnputv.

Packed data structures are for lazy people and lazy people get punished.

	Sape

> From: rminnich@gmail.com
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Tue Sep 14 23:09:35 CES 2010
> Subject: Re: [9fans] c compiler bug
>
> On Tue, Sep 14, 2010 at 1:59 PM, Brantley Coile <brantley@coraid.com> wrote:
> > I've a need for the pragma.  We're using it.  That's how I found the problem.
> > bwc
>
>
> I can tell you that people who use this sort of thing at some point
> discover it's not really what they wanted. They end up writing
> functions to more or less do the same thing. I'm not sure you want to
> go down this path.
>
> Example: Xen 2 used __attribute__ packed heavily, realized at some
> point it was a bad idea, and took another path.
>
> ron

Re: [9fans] c compiler bug

[ron minnich]

On Tue, Sep 14, 2010 at 1:59 PM, Brantley Coile <brantley@coraid.com> wrote:
> I've a need for the pragma.  We're using it.  That's how I found the problem.
> bwc


I can tell you that people who use this sort of thing at some point
discover it's not really what they wanted. They end up writing
functions to more or less do the same thing. I'm not sure you want to
go down this path.

Example: Xen 2 used __attribute__ packed heavily, realized at some
point it was a bad idea, and took another path.

ron

Re: [9fans] c compiler bug

[Brantley Coile]

I've a need for the pragma.  We're using it.  That's how I found the problem.
bwc

On Sep 14, 2010, at 4:20 PM, Charles Forsyth wrote:

> since it's a pragma, i suppose it shouldn't affect correctness.
> still, i don't know how far down this route i'd like to go.
> i'd actually plump for disabling the pragma.
> (realistically, most of the original reasons for it have vanished,
> since so much stuff is in gcc or c++.)
> still, what are you using it for?
> 

Re: [9fans] c compiler bug

[Charles Forsyth]

since it's a pragma, i suppose it shouldn't affect correctness.
still, i don't know how far down this route i'd like to go.
i'd actually plump for disabling the pragma.
(realistically, most of the original reasons for it have vanished,
since so much stuff is in gcc or c++.)
still, what are you using it for?

[9fans] c compiler bug

[erik quanstrom]

it appears that ?c do not properly do structure
assignment if the structure is packed.

i've included a patch just for 8c and a sample
program that generates two "packed assignment"
warnings with the modified compiler.

feedback appreciated unless it's "don't do that."

if this looks entirely reasonable, i'll submit a patch
for all the compilers.

- erik

---

; diffy -c /sys/src/cmd/8c/cgen.c
/n/dump/2010/0914/sys/src/cmd/8c/cgen.c:1824,1829 - /sys/src/cmd/8c/cgen.c:1824,1836
  	gins(ACLD, Z, Z);
  	gins(AREP, Z, Z);
  	gins(AMOVSL, Z, Z);
+ 	if(x = w & SZ_LONG-1){
+ 		warn(n, "packed assignment");
+ 		gins(AMOVL, nodconst(x), &nod3);
+ 	//	gins(ACLD, Z, Z);
+ 		gins(AREP, Z, Z);
+ 		gins(AMOVSB, Z, Z);
+ 	}
  	if(c & 4) {
  		gins(APOPL, Z, &nod3);
  		reg[D_CX]--;

---

#include <u.h>
#include <libc.h>

#pragma pack on
typedef struct S S;
struct	S
{
	uchar	a;
	ushort	b;
	uint	c;
};
#pragma pack off

S
func(void)
{
	S s;

	s.a = 1;
	s.b = 2;
	s.c = 3;
	return s;
}

void
main(void)
{
	S s, t;

	memset(&s, 0xff, sizeof s);
	print("sizeof s = %d\n", sizeof s);
	s = func();
	memset(&t, 0xff, sizeof t);
	t = s;
	print("a=%d b=%d c=%d\n", t.a, t.b, t.c);
	exits(nil);
}