Re: [9fans] c compiler bug
On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth charles.fors...@gmail.comwrote: On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@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
On Mon, Feb 18, 2013 at 10:02 AM, erik quanstrom quans...@quanstro.netwrote: 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?
Re: [9fans] c compiler bug
can you please stop sending html mails? thanks On 2/21/13, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth charles.fors...@gmail.comwrote: On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@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
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 23h...@gmail.com wrote: can you please stop sending html mails? thanks On 2/21/13, Comeau At9Fans comeauat9f...@gmail.com wrote: On Mon, Feb 18, 2013 at 9:38 AM, Charles Forsyth charles.fors...@gmail.comwrote: On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@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
On Thu Feb 21 13:23:26 EST 2013, j...@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 23h...@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
On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom quans...@quanstro.netwrote: On Thu Feb 21 13:23:26 EST 2013, j...@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 23h...@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?
Re: [9fans] c compiler bug
On Thu, Feb 21, 2013 at 01:39:14PM -0500, erik quanstrom wrote: On Thu Feb 21 13:23:26 EST 2013, j...@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 23h...@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
On Thu, Feb 21, 2013 at 10:46 AM, Comeau At9Fans comeauat9f...@gmail.com wrote: On Thu, Feb 21, 2013 at 1:39 PM, erik quanstrom quans...@quanstro.net wrote: On Thu Feb 21 13:23:26 EST 2013, j...@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 23h...@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
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
Can I run it on my iPhone? Sent from my iPhone On Feb 21, 2013, at 11:58 AM, andrey mirtchovski mirtchov...@gmail.com wrote: good day. is this the p9p on osx help forum?
Re: [9fans] c compiler bug
no, but drawterm will (i believe). On 21 Feb 2013, at 20:27, David Leimbach leim...@gmail.com wrote: Can I run it on my iPhone? Sent from my iPhone On Feb 21, 2013, at 11:58 AM, andrey mirtchovski mirtchov...@gmail.com wrote: good day. is this the p9p on osx help forum?
Re: [9fans] c compiler bug
On Sat, Feb 16, 2013 at 9:38 PM, erik quanstrom quans...@quanstro.netwrote: 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?
Re: [9fans] c compiler bug
On 18 February 2013 13:02, Comeau At9Fans comeauat9f...@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)
Re: [9fans] c compiler bug
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
On 18 February 2013 15:02, erik quanstrom quans...@quanstro.net wrote: since nested functions are not allowed, applying nested scope seems a bit odd. Nevertheless, that is what it is.
[9fans] c compiler bug
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 {
charbuf[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.x0x4028f0
fn addr i.x 0x4018f0
Re: [9fans] c compiler bug
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
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
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
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.
[9fans] c compiler bug
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;
uintc;
};
#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);
}
Re: [9fans] c compiler bug
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
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
On Tue, Sep 14, 2010 at 1:59 PM, Brantley Coile brant...@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
