Send Tinycc-devel mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tinycc-devel digest..."
Today's Topics:
1. Re: [bug fix]typeof should ignore some attributes
(Fabrice Bellard)
2. Leading underscore in Windows C identifiers (Fabrice Bellard)
3. $B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B (address@hidden)
4. Re: Free access to Lender Network (Polly Platt)
5. casting bug? (address@hidden)
6. Re: casting bug? (Felix Nawothnig)
7. Re: casting bug? (Dave Dodge)
8. Re: casting bug? (Felix Nawothnig)
9. Re: casting bug? (Dave Dodge)
10. Re: casting bug? (Greg Haerr)
11. Re: casting bug? (Henrik Nordstrom)
----------------------------------------------------------------------
Message: 1
Date: Tue, 05 Jul 2005 23:37:46 +0200
From: Fabrice Bellard <address@hidden>
Subject: Re: [Tinycc-devel] [bug fix]typeof should ignore some
attributes
To: Tao Wu <address@hidden>, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
Tao Wu wrote:
Hi,
I think typeof should ignore some attributes like "external",
otherwise the following code will not compile.
...
#define max(x,y) ({ \
const typeof(x) _x = (x); \
const typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x > _y ? _x : _y; }) ? _x : _y; })
...
extern int a;
int b=max(a,4);
the problem is that compiler can not parse "const extern int _x = (a);"
the following patch should fix it, but I don't know whether I have
ignored some attributes which should not be ignored by "typeof". But I
think "exter"diff -urN tcc-0.9.23/tcc.c tcc-0.9.23-lepton/tcc.c
--- tcc-0.9.23/tcc.c 2005-06-27 23:05:42.000000000 +0800
+++ tcc-0.9.23-lepton/tcc.c 2005-06-27 01:34:12.000000000 +0800
@@ -6690,7 +6690,7 @@
case TOK_ENUM:
struct_decl(&type1, VT_ENUM);
basic_type2:
- u = type1.t;
+ u = type1.t &
(~(VT_EXTERN|VT_STATIC|VT_INLINE|VT_CONST|VT_VOLATILE));
type->ref = type1.ref;
goto basic_type1;
case TOK_STRUCT:
Ignoring const and volatile does not seem correct to me...
Fabrice.
------------------------------
Message: 2
Date: Fri, 08 Jul 2005 00:43:49 +0200
From: Fabrice Bellard <address@hidden>
Subject: [Tinycc-devel] Leading underscore in Windows C identifiers
To: address@hidden
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hi,
Another interesting Windows patch could be to generate underscores at
the beginning of C identifiers. I added the -fleading-underscore option
in TCC, but it is not enabled by default in the Windows case because I
don't know what is the exact convention for exported DLL symbols. I
think it would be easy for you to find a correct fix in the TCC PE file
generator.
Fabrice.
------------------------------
Message: 3
Date: 8 Jul 2005 17:55:02 +0900
From: address@hidden
Subject: [Tinycc-devel] $B40A4L5NA$NAG?M=PD%%[%9%H$N%"%k%P%$%H(B
To: address@hidden
Message-ID: <address@hidden>
$B(.(,(/(.(,(/(.(,(/(.(,(/(B
$B(-AG(-(-?M(-(-=P(-(-D%(-(B
$B(1(,(0(1(,(0(1(,(0(1(,(0(B
http://awg.webchu.com/?freehost
$B"(%[%9%HBgJg=8!J$*;n$740A4L5NAEPO?#O#K!*!K(B
$B"($9$Y$F%(address@hidden;W$$$r$7$F>.8/$$2T$.!*(B
$B"($*Aj<j$O(B10$BBe!&#O#L!&address@hidden&@lLg3X9;@8!&<c:J!&=O=w!&IwB/>n!&#S>n!&#M>n!&(B
$B%J!<%9!&%9%C%A!<$J$I(B
$B(.(,(/(.(,(/(.(,(/(.(,(/(B
$B(-40(-(-A4(-(-L5(-(-NA(-(B
$B(1(,(0(1(,(0(1(,(0(1(,(0(B
http://awg.webchu.com/?freehost
$B(.(,(/(.(,(/(B
$B(-$*;n$7#O#K(-(B
$B(1(,(0(1(,(0(B
$B"(;E;v$N9g4V!"5YF|$rMxMQ$7$F<}F~%"%C%W$r$7$^$;$s$+!*D64JC1$JI{6H$G$9!#(B
$B!y5.J}$b%j%C%A$K$J$j$^$;$s$+!)(B
http://awg.webchu.com/?freehost
$B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B
$B:#8e!"<u?.$r5qH]$9$k>l9g$OJV?.2<$5$$!#(B
address@hidden
$B!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a!&!a(B
18$B:PL$K~$OMxMQ6X;_$G$9!#(B
------------------------------
Message: 4
Date: Sun, 10 Jul 2005 03:19:33 -0100
From: "Polly Platt" <address@hidden>
Subject: [Tinycc-devel] Re: Free access to Lender Network
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Dear Homeowner,
Getting your home-equity loan or consolidating your bills couldn't be easier!
All loans are pre-approved and your credit is not a factor, EVER !!!
1. visit our site with one click.
2. fill out the form in less one minute.
3. receive multiple offers same day !
http://wGYj.m3ssages.net/p1.asp
approval in under 30 seconds !!
lowest rates in years -- only 3.25% !!
$230,000 loans are a mere $340/month !!
http://wGYj.m3ssages.net/p1.asp
You must act now, as this is a limited-time offer.
Join the millions of already satisfied customers.
Find out how much you can get today!
Sincerely,
Polly Platt
---
please visit site to update preferences
------------------------------
Message: 5
Date: Sun, 10 Jul 2005 22:51:04 -0700 (PDT)
From: <address@hidden>
Subject: [Tinycc-devel] casting bug?
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=iso-8859-1
I believe that the example below should compile. "gcc
-Wall -Wextra -ansi -pedantic" compiles it without
warning or error.
Here's what I get,
$ ./tcc -v
tcc version 0.9.23
$ ./tcc test.c
test.c:4: cannot use pointers here
I believe that assignment should be the same as,
x = 0;
Right?
-Charles
int main(void)
{
int x;
x = (char)((void *)0);
return 0;
}
Charles F. Randall, IV
address@hidden (always forwarded)
------------------------------
Message: 6
Date: Mon, 11 Jul 2005 17:37:37 +0200
From: Felix Nawothnig <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: address@hidden, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
address@hidden wrote:
I believe that assignment should be the same as,
x = 0;
No. Casting a pointer to an integer results in undefined behaviour (in
ANSI/ISO C) although I dunno if that includes a compile-time error...
Felix
------------------------------
Message: 7
Date: Mon, 11 Jul 2005 14:59:17 -0400
From: Dave Dodge <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 11, 2005 at 05:37:37PM +0200, Felix Nawothnig wrote:
address@hidden wrote:
I believe that assignment should be the same as,
x = 0;
No. Casting a pointer to an integer results in undefined behaviour (in
ANSI/ISO C)
In C99, the implementation can optionally provide the types intptr_t and
uintptr_t. In that case you can reliably convert a void pointer to one
of those types and back again.
That said, it is unlikely that intptr_t would be the same type as
char. And even if those types are present, the standard still doesn't
guarantee any correspondence between a specific integer value and a
specific pointer value; merely that a pointer can be converted to some
integer value that then converts back to the same pointer again.
The standard definitely does not guarantee that a null pointer is the
same as all-bits-zero. There have been a few real implementations
that used nonzero bits.
http://www.eskimo.com/~scs/C-faq/q5.17.html
-Dave Dodge
------------------------------
Message: 8
Date: Mon, 11 Jul 2005 22:12:45 +0200
From: Felix Nawothnig <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dave Dodge wrote:
The standard definitely does not guarantee that a null pointer is the
same as all-bits-zero. There have been a few real implementations
that used nonzero bits.
So? Casting takes care of that in our case, the only way to get the real
NULL representation is by doing:
void *p = NULL;
int i = *(int *)&p;
Felix
------------------------------
Message: 9
Date: Mon, 11 Jul 2005 19:33:34 -0400
From: Dave Dodge <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
On Mon, Jul 11, 2005 at 10:12:45PM +0200, Felix Nawothnig wrote:
Dave Dodge wrote:
The standard definitely does not guarantee that a null pointer is the
same as all-bits-zero. There have been a few real implementations
that used nonzero bits.
So? Casting takes care of that in our case,
My point was that even when converting a pointer to an intptr_t, the
standard does not guarantee that casting a null pointer will produce
the integer value 0 (which was one of the assumptions in the original
message).
Likewise, given code like this:
intptr_t const i = 0;
void * p1 = (void*)0;
void * p2 = (void*)i;
C guarantees that p1 will be a null pointer, but it does not guarantee
that p2 will be a null pointer.
the only way to get the real NULL representation is by doing:
void *p = NULL;
int i = *(int *)&p;
I think to do it in a defined manner you have to use an unsigned char
array instead of an int. For one thing, sizeof(void*) is much larger
than sizeof(int) on the most common 64-bit architectures. And even if
they're the same size they could have different alignment
requirements, making &p unusable as an int*.
-Dave Dodge
------------------------------
Message: 10
Date: Mon, 11 Jul 2005 17:44:55 -0600
From: "Greg Haerr" <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
: For one thing, sizeof(void*) is much larger
: than sizeof(int) on the most common 64-bit architectures.
Interesting discussion. What's sizeof(void*) on these
common 64-bit architectures?
Out of curiousity, what is
sizeof(unsigned short)
sizeof(unsigned long)
sizeof(unsigned long long)
on these architectures?
Regards,
Greg
------------------------------
Message: 11
Date: Tue, 12 Jul 2005 04:14:24 +0200 (CEST)
From: Henrik Nordstrom <address@hidden>
Subject: Re: [Tinycc-devel] casting bug?
To: address@hidden
Message-ID: <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 11 Jul 2005, Greg Haerr wrote:
: For one thing, sizeof(void*) is much larger
: than sizeof(int) on the most common 64-bit architectures.
Interesting discussion. What's sizeof(void*) on these
common 64-bit architectures?
LP64 platforms commonly has
sizeof(void *) == 8
sizeof(long long) == 8
sizeof(long) == 8
sizeof(int) == 4
sizeof(short) == 2
sizeof(char) == 1
Regards
Henrik
------------------------------
_______________________________________________
Tinycc-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
End of Tinycc-devel Digest, Vol 28, Issue 3
*******************************************