Introduce a C Compiler ucc

[dreamAnders]

Your files all have DOS line endings, not good for a cross platform project.

Thank you for your suggestion.

Personally, I like unnamned union in structs so much and most
compilers support it. So I want to support it too.

 

[Bart]

So what line ending should be used for a cross-pltform project?

What /is/ a DOS line ending anyway?

Personally, I like unnamned union in structs so much and most
compilers support it. So I want to support it too.

Well said.

There's a whole bunch of these minor but extremely useful little
extensions, that really should be available on every compiler. And
they should be available now, no excuses.

 

[Kenny McCormack]

So what line ending should be used for a cross-pltform project?

What /is/ a DOS line ending anyway?


Well said.

There's a whole bunch of these minor but extremely useful little
extensions, that really should be available on every compiler. And
they should be available now, no excuses.

Uh Oh.

(You're going to get it now...)

 

[santosh]

So what line ending should be used for a cross-pltform project?

What /is/ a DOS line ending anyway?

It's the ASCII sequence CR-LF, i.e., the ASCII character code 13
followed by the ASCII character code 10. It's the standard line
separator under CP/M, DOS and Windows; maybe other system too.

The Unix world just uses a LF and MacOS uses just a CR. There are
utilities availbale to convert a file between these formats. It's also
trivial to write a standard C program to do the job.

 

[noagbodjivictor]

So what line ending should be used for a cross-pltform project?

What /is/ a DOS line ending anyway?


Well said.

There's a whole bunch of these minor but extremely useful little
extensions, that really should be available on every compiler. And
they should be available now, no excuses.

Windows/Dos : \n\r
Unix/Linux : \n
Mac OS X : \r

OS makers want us to believe this... and we are believers.

 

[santosh]

Windows/Dos : \n\r
Unix/Linux : \n
Mac OS X : \r

OS makers want us to believe this... and we are believers.

The C escape sequence '\n' is translated by the C compiler and the
runtime library into whatever sequence the target platform uses for
separating lines. Thus on Windows a '\n' in an output operation is
translated into a CRLF sequence, while under Unix it is replaced by a
LF character, and so on.

So the platform specific end-of-line sequences are independent of the C
escape sequences.

 

[Richard Tobin]

ucc is an ANSI C Compiler.

I tried compiling some code of mine, and ran into a few problems:

The -D option doesn't seem to have any effect - the macro is
not defined.

Typedefs like "typedef void fv(int);" don't seem to work; when it
later encounters "fv *foo" it reports "Typedef name cannot be used as
variable". "typedef void (*fv)(int);" is ok.

It rejects conditional operators where one result is a pointer and the
other is 0. For example, "int *i, j=2; i = j > 1 ? &j : 0;".
It should treat the 0 as a null pointer of the type of the other result.

-- Richard

 

[Richard Tobin]

The Unix world just uses a LF and MacOS uses just a CR.

Old MacOS used CR. MacOS X is unix and uses LF as you would expect.

-- Richard

 

[dreamAnders]

I tried compiling some code of mine, and ran into a few problems:

The -D option doesn't seem to have any effect - the macro is
not defined.

Typedefs like "typedef void fv(int);" don't seem to work; when it
later encounters "fv *foo" it reports "Typedef name cannot be used as
variable".   "typedef void (*fv)(int);" is ok.

It rejects conditional operators where one result is a pointer and the
other is 0.  For example, "int *i, j=2; i = j > 1 ? &j : 0;".
It should treat the 0 as a null pointer of the type of the other result.

-- Richard

Thank you very much for tesing the compiler. I have corrected the bugs.

 

[Keith Thompson]

I tried compiling some code of mine, and ran into a few problems:

[snip]

Thank you very much for tesing the compiler. I have corrected the bugs.

Thank you for providing an excellent example of how to respond to
bug reports. I hope that any other compiler implementers who hang
out here will take it to heart.

 

[Flash Gordon]

dreamAnders wrote, On 12/05/08 11:10:

And yes, ucc supports anonymous union. Personally, I like anonymous
union so much,
and most compilers support it. So I want to support it too.

There is nothing wrong with supporting extensions. However, you should
also provide a mode which conforms to the standard including issuing all
required diagnostics (a diagnostic could be, WARNING: Extension fred used").

Also you should understand that by using extensions where they are not
required you are limiting the portability of your code more than
necessary and also preventing your compiler from being compiled with the
maximum warning levels supported by compilers. Try using gcc options
"-ansi -pedantic -Wall -Wextra" and see what it says. MS Visual Studio
also can be configured to give a lot of useful warnings.

 

[jacob navia]

That was quick!

But I still find the conditional operator doesn't work when the
second operand is 0 and the third is a pointer. (It now works
with them the other way round.)

I also have a problem with files that include sys/socket.h (this
is on Linux). I don't know if it's a problem with your compiler as
such or with the compatibility of the header files. I get this
error:

(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,165):error:Expect ;
(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,166):error:Undeclared identifier: __uint64_t

-- Richard

Most include files under linux are unusable by anything else but gcc

 

[Richard Tobin]

Thank you very much for tesing the compiler. I have corrected the bugs.

That was quick!

But I still find the conditional operator doesn't work when the
second operand is 0 and the third is a pointer. (It now works
with them the other way round.)

I also have a problem with files that include sys/socket.h (this
is on Linux). I don't know if it's a problem with your compiler as
such or with the compatibility of the header files. I get this
error:

(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,165):error:Expect ;
(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,166):error:Undeclared identifier: __uint64_t

-- Richard

 

[Richard Tobin]

Another problem: the program below reports

(test.c,10):error:struct or union member key doesn't exsist
(test.c,10):warning:conversion between pointer and integer without a cast

The error goes away if the "const" in the declaration of hp is
removed.

typedef struct hash_entry {
void *key;
} HashEntryStruct;

HashEntryStruct h;

int main(void)
{
const HashEntryStruct *hp = &h;
void *key = hp->key;

return 0;
}

-- Richard

 

[Richard Tobin]

Most include files under linux are unusable by anything else but gcc

Yes, but the ucc documentation says it uses gcc's headers.

I suspect the problem is something about 64-bit types.

-- Richard

 

[santosh]

dreamAnders wrote, On 12/05/08 11:10:



There is nothing wrong with supporting extensions. However, you should
also provide a mode which conforms to the standard including issuing
all required diagnostics (a diagnostic could be, WARNING: Extension
fred used").

Also you should understand that by using extensions where they are not
required you are limiting the portability of your code more than
necessary and also preventing your compiler from being compiled with
the maximum warning levels supported by compilers. Try using gcc
options "-ansi -pedantic -Wall -Wextra" and see what it says. MS
Visual Studio also can be configured to give a lot of useful warnings.

I have found that the Intel C compiler generally tends to print more
diagnostics than either gcc or MSVC. With the -Wall option it's
almost "lint-like" in it's diagnostic verbosity.

 

[Spiros Bousbouras]

dreamAnders wrote, On 12/05/08 11:10:



There is nothing wrong with supporting extensions. However, you should
also provide a mode which conforms to the standard including issuing all
required diagnostics (a diagnostic could be, WARNING: Extension fred used").

It occurs to me that the opening poster did not say to
which standard he tries to conform. Unless "ANSI C"
has only one interpretation.

 

[Spiros Bousbouras]

The C escape sequence '\n' is translated by the C compiler and the
runtime library into whatever sequence the target platform uses for
separating lines. Thus on Windows a '\n' in an output operation is
translated into a CRLF sequence, while under Unix it is replaced by a
LF character, and so on.

Of course all that applies if the file was opened in
text mode.

 

[Ian Collins]

Of course all that applies if the file was opened in
text mode.

Not on a Unix systems, where there isn't a "text mode".

 

[Ian Collins]

Thank you for your suggestion.

And yes, ucc supports anonymous union. Personally, I like anonymous
union so much,
and most compilers support it. So I want to support it too.

My point was one of the claims for the source was it "will help you to
master the C language.". Anonymous unions aren't part of the C
language, they are an extension offered by some compilers.