> Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front
> with https://code.9front.org/hg/plan9front/rev/7cf7079502a7
for 8c/6c only. but its not portable as charles pointed out. this needs a
proper fix.
--
cinap
Oh. I meant that I'd fix it.
On Thu, 2 Aug 2018 at 01:29, Bakul Shah wrote:
> On Aug 1, 2018, at 4:35 PM, Charles Forsyth
> wrote:
>
> > even so, the format and intention of the example seems practical (with
> the correct cast to uintptr) and "An implementation may accept other forms
> of
On Aug 1, 2018, at 4:35 PM, Charles Forsyth wrote:
> even so, the format and intention of the example seems practical (with the
> correct cast to uintptr) and "An implementation may accept other forms of
> constant expressions".
> it should be fairly easy to add as an extension with consistent
Consider:
% cat x.c
#include
uintptr foo[3];
uintptr bar=[2];
% 8c -c x.c # this works.
% 5c -c x.c # this fails
x.c:3 initializer is not a constant: bar
If I change the last line to
uintptr* bar=[2];
Both compilers compile it fine. But if I change the last line
to
uintptr
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
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
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
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,
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
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
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
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
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:
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?
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?
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
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
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).
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.
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
0 -0x8000 == 1 with 5c.
the problem is caused by this:
if(a == ACMP f1-op == OCONST p-from.offset 0) {
p-as = ACMN;
p-from.offset = -p-from.offset;
}
because 0x8000 == -0x8000
adding the following
Good catch.
2's complement integers are generally useful but it's easy to
forget that they don't quite obey normal algebraic rules.
The assumption that
(a 0) = (-a 0)
is the cause of many easily-missed bugs.
On Wed Jan 2 04:07:28 EST 2013, cinap_len...@gmx.de wrote:
0 -0x8000 == 1 with 5c.
i get the same results for all compilers:
0 -0x8000..yes
1 == -0x8000..no
0 -0x8000 == 1..yes
for [568]c. the last one is correct since the order of
those are being done at compile time.
On 2 January 2013 15:07, erik quanstrom quans...@quanstro.net wrote:
i get the same results for all compilers:
Is this related to the bug I found in python on arm?
On Jan 2, 2013, at 4:05, cinap_len...@gmx.de wrote:
0 -0x8000 == 1 with 5c.
the problem is caused by this:
if(a == ACMP f1-op == OCONST p-from.offset 0) {
p-as = ACMN;
p-from.offset =
On Wed Jan 2 13:32:30 EST 2013, mve...@gmail.com wrote:
Is this related to the bug I found in python on arm?
it would be much more helpful if the bug and python code
were replaced with specific references.
- erik
yes.
--
cinap
the offending line that triggered it is in Python/getargs.c
in the convertsimple() function (the ival INT_MIN comparsion):
case 'i': {/* signed int */
int *p = va_arg(*p_va, int *);
long ival;
if (float_argument_error(arg))
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
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.
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;
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
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
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
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
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
36 matches
Mail list logo
