Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #142549 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-03-28 16:16 +0000 |
| Last post | 2019-03-29 07:49 -0700 |
| Articles | 20 on this page of 75 — 12 participants |
Back to article view | Back to comp.lang.c
C Translator Bart <bc@freeuk.com> - 2019-03-28 16:16 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 00:01 +0000
Re: C Translator Robert Wessel <robertwessel2@yahoo.com> - 2019-03-28 20:31 -0500
Re: C Translator Keith Thompson <kst-u@mib.org> - 2019-03-28 19:02 -0700
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 02:34 +0000
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-03-29 10:58 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 12:47 +0000
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-03-29 14:57 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 14:57 +0000
Re: C Translator fir <profesor.fir@gmail.com> - 2019-03-29 15:08 -0700
Re: C Translator fir <profesor.fir@gmail.com> - 2019-03-29 15:42 -0700
Re: C Translator scott@slp53.sl.home (Scott Lurndal) - 2019-03-29 15:16 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 15:30 +0000
Re: C Translator fir <profesor.fir@gmail.com> - 2019-03-29 14:47 -0700
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-29 10:42 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 11:57 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 13:04 +0000
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-03-29 14:58 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 14:29 +0000
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-29 20:06 +0000
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-29 20:02 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-29 21:10 +0000
Re: C Translator nobody@example.org (Scott) - 2019-03-30 04:52 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-30 11:03 +0000
Re: C Translator nobody@example.org (Scott) - 2019-03-30 16:17 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-30 18:36 +0000
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-30 20:32 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-30 22:44 +0000
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-31 03:23 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-31 12:39 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-31 15:07 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-31 16:21 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-03-31 21:19 +0200
Re: C Translator Bart <bc@freeuk.com> - 2019-03-31 20:58 +0100
Re: C Translator Ike Naar <ike@iceland.freeshell.org> - 2019-03-31 20:33 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-03-31 22:06 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-31 22:37 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-31 23:33 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-01 02:35 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-01 11:33 +0200
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-03-31 23:54 +0200
Re: C Translator Bart <bc@freeuk.com> - 2019-04-01 02:16 +0100
Re: C Translator Ike Naar <ike@iceland.freeshell.org> - 2019-04-01 06:42 +0000
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-01 11:35 +0200
Re: C Translator Bart <bc@freeuk.com> - 2019-04-01 16:54 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-04-01 21:01 +0100
Re: C Translator Keith Thompson <kst-u@mib.org> - 2019-04-01 13:41 -0700
Re: C Translator Bart <bc@freeuk.com> - 2019-04-01 22:40 +0100
Re: C Translator Keith Thompson <kst-u@mib.org> - 2019-04-01 16:25 -0700
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 00:50 +0100
Re: C Translator Keith Thompson <kst-u@mib.org> - 2019-04-01 17:45 -0700
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 11:28 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 13:18 +0200
Re: C Translator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-04-02 19:15 +0000
Re: C Translator Bart <bc@freeuk.com> - 2019-04-02 21:14 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 13:28 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 10:49 +0200
Re: C Translator Bart <bc@freeuk.com> - 2019-04-02 01:58 +0100
Re: C Translator Keith Thompson <kst-u@mib.org> - 2019-04-01 19:13 -0700
Re: C Translator Bart <bc@freeuk.com> - 2019-04-02 11:13 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 13:49 +0200
Re: C Translator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-04-02 05:15 -0700
Re: C Translator Bart <bc@freeuk.com> - 2019-04-02 14:50 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 16:06 +0200
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 16:05 +0200
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 00:11 +0100
Re: C Translator David Brown <david.brown@hesbynett.no> - 2019-04-02 10:35 +0200
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 00:06 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-31 21:36 +0100
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-31 16:32 +0100
Re: C Translator Bart <bc@freeuk.com> - 2019-03-30 00:37 +0000
Re: C Translator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-30 01:00 +0000
Re: C Translator fir <profesor.fir@gmail.com> - 2019-03-30 03:37 -0700
Re: C Translator fir <profesor.fir@gmail.com> - 2019-03-30 06:15 -0700
Re: C Translator James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-29 07:49 -0700
Page 1 of 4 [1] 2 3 4 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-28 16:16 +0000 |
| Subject | C Translator |
| Message-ID | <Dr6nE.1476625$Xct1.1108593@fx12.am4> |
On 28/03/2019 13:01, already5chosen@yahoo.com wrote:
> I don't know either Algol 60 or Algol 68, but I read that two
> languages had very little in common except of basic syntax.
> So it's quite possible that if Algol 86 was ever invented, it again
> wouldn't be any more similar to Algol 68 than any of the languages of
> the same era that had algolish syntax. And there were many of later in
> the 1980s.
My own languages from that time were loosely based on Algol 68 syntax.
This project:
https://github.com/sal55/qx/blob/master/ccm.c
is a program (auto-translated from my language) that converts a C file
to the version of that syntax that I currently use.
The translation is a rough and very loose source to source conversion.
it was intended to produce a first 'draft' of a program that I then had
to finish manually. As there are too many differences in the languages,
their type systems, semantics etc.
But it can also be used for an alternate visualisation of a C program.
If nothing else, it can translate complex C type declarations. A program
containing this (example from K&R2):
static char (*(*x[3])())[5];
produces a file containing:
var [3]ref clang function()ref [5]byte x
The 'var' is a piece of syntax I've recently introduced, which helps
make variable declarations stand out. The 'clang' is because this is
viewed as a foreign function from my language.
That leaves:
[3]ref function()ref [5]byte x
which is an Algol 68-style left-to-right type-spec. The English
translation in K&R2 page 122 says:
array[2] of pointer to function returning pointer to
array[5] of char.
Since 'ref' means 'pointer to', this matches pretty much exactly. (My
syntax doesn't need 'array'.)
[toc] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 00:01 +0000 |
| Message-ID | <xfdnE.427090$0_.110498@fx19.am4> |
| In reply to | #142549 |
On 28/03/2019 16:16, Bart wrote:
> https://github.com/sal55/qx/blob/master/ccm.c
>
> is a program (auto-translated from my language) that converts a C file
> to the version of that syntax that I currently use.
>
> ... there are too many differences in the languages,
> their type systems, semantics etc.
Here are some weird constructs that I didn't know you could do:
switch (len & 31) {
do {
case 0: dest[pos - 1] = src[pos - 1];
case 31: dest[pos - 2] = src[pos - 2];
....
case 2: dest[pos - 31] = src[pos - 31];
case 1: dest[pos - 32] = src[pos - 32];
} while ((pos -= 32) != 0);
What the ... ? I guess it's just jumping into a loop, via a switch; a
switch statement that overlaps into a nested while statement...
I expect that a 'break' might be somewhat confusing in this example!
A much milder example using switch:
...
default:
case 1334:
<code>
I knew that switch/case was funny, but didn't realise people actually
wrote stuff like this. (Both cause problems in my translator; I need to
find a way of dealing with such things, then carrying on.)
Compared to those, this is nothing:
extern fn(void) {....}
A function is marked as 'extern', but is defined here anyway. Since such
a definition must only be visible in one module, what is the point of
'extern'?
(Apparently the point is that there is a macro added to the start of
both a function declaration AND its definition, and that macro happens
to include 'extern'. That no one will ever see 'extern' because it's
hidden, doesn't matter. This sort of goings on doesn't seem to be meant
for anyone to read.)
Can anyone blame me for considering C a crude language little different
from assembly? In assembly, also, you can write chaotic code with no
logical structure.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-03-28 20:31 -0500 |
| Message-ID | <79tq9epfv1ombpcngomq6gkgvu3pgadkb3@4ax.com> |
| In reply to | #142574 |
On Fri, 29 Mar 2019 00:01:32 +0000, Bart <bc@freeuk.com> wrote:
>On 28/03/2019 16:16, Bart wrote:
>
>> https://github.com/sal55/qx/blob/master/ccm.c
>>
>> is a program (auto-translated from my language) that converts a C file
>> to the version of that syntax that I currently use.
>>
>
>> ... there are too many differences in the languages,
>> their type systems, semantics etc.
>
>Here are some weird constructs that I didn't know you could do:
>
> switch (len & 31) {
> do {
> case 0: dest[pos - 1] = src[pos - 1];
> case 31: dest[pos - 2] = src[pos - 2];
> ....
> case 2: dest[pos - 31] = src[pos - 31];
> case 1: dest[pos - 32] = src[pos - 32];
> } while ((pos -= 32) != 0);
>
>What the ... ? I guess it's just jumping into a loop, via a switch; a
>switch statement that overlaps into a nested while statement...
https://en.wikipedia.org/wiki/Duff%27s_device
Dates back to the early 1980s.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-03-28 19:02 -0700 |
| Message-ID | <lnk1gia152.fsf@kst-u.example.com> |
| In reply to | #142574 |
Bart <bc@freeuk.com> writes:
[...]
> Here are some weird constructs that I didn't know you could do:
>
> switch (len & 31) {
> do {
> case 0: dest[pos - 1] = src[pos - 1];
> case 31: dest[pos - 2] = src[pos - 2];
> ....
> case 2: dest[pos - 31] = src[pos - 31];
> case 1: dest[pos - 32] = src[pos - 32];
> } while ((pos -= 32) != 0);
Do a web search for "Duff's Device".
[SNIP]
> Compared to those, this is nothing:
>
> extern fn(void) {....}
Missing return type. Are you compiling in C90 mode, or did you just
leave it out?
> A function is marked as 'extern', but is defined here anyway. Since such
> a definition must only be visible in one module, what is the point of
> 'extern'?
The syntax for an function-definition permits a storage-class-specifier.
A constraint requires it to be either "extern" or "static" (6.9.1p4).
A function-definition has external linkage by default. Adding the
"extern" keyword is redundant but harmless (like adding "auto" to a
block-scope object declaration). Which means that you can declare it
and refer to it in another translation unit. (With "static" you
couldn't do that.)
> (Apparently the point is that there is a macro added to the start of
> both a function declaration AND its definition, and that macro happens
> to include 'extern'. That no one will ever see 'extern' because it's
> hidden, doesn't matter. This sort of goings on doesn't seem to be meant
> for anyone to read.)
Did this inconvenience you in some way? Did you implement your own C
compiler without paying attention to the C standard?
> Can anyone blame me for considering C a crude language little different
> from assembly? In assembly, also, you can write chaotic code with no
> logical structure.
I don't blame you for considering it any way you like. I do blame you
for endlessly whining about it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 02:34 +0000 |
| Message-ID | <DufnE.1219230$OGY.973445@fx08.am4> |
| In reply to | #142577 |
On 29/03/2019 02:02, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> extern fn(void) {....}
>
> Missing return type. Are you compiling in C90 mode, or did you just
> leave it out?
It's a typo. The important thing is the 'extern' at one end and '{...}'
at the other.
> A function-definition has external linkage by default.
Functions (in my world anyway) are of three kinds: local, exported, and
imported, usually indicated in C by 'static', <nothing> and 'extern'
respectively. Notice the last two are exclusive, so they shouldn't both
have 'extern'.
>> (Apparently the point is that there is a macro added to the start of
>> both a function declaration AND its definition, and that macro happens
>> to include 'extern'. That no one will ever see 'extern' because it's
>> hidden, doesn't matter. This sort of goings on doesn't seem to be meant
>> for anyone to read.)
>
> Did this inconvenience you in some way? Did you implement your own C
> compiler without paying attention to the C standard?
The C compiler is fine. It gave trouble in the translator because it had
to use random logic to figure out which of those categories it might be
(plus, for that project, whether it is additionally a standard library
function).
So, yes, it's incovenient due to C being so messy in not being able to
cleanly specify this stuff.
>> Can anyone blame me for considering C a crude language little different
>> from assembly? In assembly, also, you can write chaotic code with no
>> logical structure.
>
> I don't blame you for considering it any way you like. I do blame you
> for endlessly whining about it.
I recently got pulled up for calling C a trumped-up assembler, that's
why I mentioned it. I'd forgotten the details of Duff's device, and I'd
forgotten all the issues with variables and functions. I mean, what does
this mean in a program at module scope:
int abc;
...
int abc;
...
int abc;
Is abc defined in this module or not? If it is, then it really needs to
be initialised. If it isn't, then because none is static, at least one
needs to have 'extern'. In practice, if N modules contain those same
uninitialised declarations, one implementation might assign ownership of
the variable to one. Another might define multiple copies.
What a mess! And if I type:
static int abc;
extern int abc;
only one compiler picks up on it. But reverse the order, and now it's an
error.
Aren't you lot embarrassed to be working with such a language? What
exactly is the 700 pages of Standard about if it doesn't even pin down
such basics?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-29 10:58 +0100 |
| Message-ID | <q7kq7h$j7u$1@dont-email.me> |
| In reply to | #142578 |
On 29/03/2019 03:34, Bart wrote:
> On 29/03/2019 02:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> extern fn(void) {....}
>>
>> Missing return type. Are you compiling in C90 mode, or did you just
>> leave it out?
>
> It's a typo. The important thing is the 'extern' at one end and '{...}'
> at the other.
>
>
>> A function-definition has external linkage by default.
>
> Functions (in my world anyway) are of three kinds: local, exported, and
> imported, usually indicated in C by 'static', <nothing> and 'extern'
> respectively. Notice the last two are exclusive, so they shouldn't both
> have 'extern'.
That is quite common practice. In my code, a C file contains function
definitions - they are either local to the C file and declared "static",
or exported and have a matching "extern" in the appropriate header.
There are (almost) never "extern" declarations in my C files - functions
are imported by #include. (Headers can also have static inline
functions.) To my mind, this gives a clear distinction between
exportable, internal, and imported functions, makes it easy to correlate
declarations and definitions, and makes it easy to have automatic
checking that the declarations and definitions match up.
But that is not the only way to do it. C gives a good deal of freedom
here. One of the things that it is quite free about is redundancy. For
the compiler, this does not matter - it is for programmer convenience.
Any "extern" on a function declaration or definition is unnecessary, but
programmers may think it makes the code clearer. And in your example,
the extra "extern" is from macros - it is no harm to the programmer, and
no harm to the compiler.
>
>>> (Apparently the point is that there is a macro added to the start of
>>> both a function declaration AND its definition, and that macro happens
>>> to include 'extern'. That no one will ever see 'extern' because it's
>>> hidden, doesn't matter. This sort of goings on doesn't seem to be meant
>>> for anyone to read.)
>>
>> Did this inconvenience you in some way? Did you implement your own C
>> compiler without paying attention to the C standard?
>
> The C compiler is fine. It gave trouble in the translator because it had
> to use random logic to figure out which of those categories it might be
> (plus, for that project, whether it is additionally a standard library
> function).
>
It is up to you to decide what your translator should do. If it needs
to handle any valid C program, then it needs to support all C syntax.
If it is only for some C code (such as code you write yourself), then it
is sufficient to support a subset. You can't honestly be blaming the
language for the limitations of /your/ tools?
> So, yes, it's incovenient due to C being so messy in not being able to
> cleanly specify this stuff.
C specifies this perfectly well. It's right there in 6.9.1, with a
summary in Annex A. There is quite a bit involved in the grammar of C,
and you are welcome to dislike it, but you cannot possibly claim it is
not cleanly or clearly specified.
>
>>> Can anyone blame me for considering C a crude language little different
>>> from assembly? In assembly, also, you can write chaotic code with no
>>> logical structure.
>>
>> I don't blame you for considering it any way you like. I do blame you
>> for endlessly whining about it.
>
> I recently got pulled up for calling C a trumped-up assembler, that's
> why I mentioned it.
That's because C is in no way a "trumped-up assembler". And in terms of
its structure and syntax, it doesn't bear the slightest resemblance to
assembler - and thus the comparison makes no sense at all in this context.
> I'd forgotten the details of Duff's device, and I'd
> forgotten all the issues with variables and functions. I mean, what does
> this mean in a program at module scope:
>
> int abc;
> ...
> int abc;
> ...
> int abc;
>
> Is abc defined in this module or not?
6.9.2p2.
Repeating the blindingly obvious, how is it possible to even consider
thinking about writing a C compiler or C interpreter without familiarity
with the C standards?
<https://en.wikipedia.org/wiki/English_As_She_Is_Spoke>
I don't claim the standards are particularly "readable", and I think it
would be easier if the document was organised a bit differently. But if
you are writing tools for working with general C code, you need to be
massively familiar with it. When you read a post like this, which
contains references to the standards, you should be adding them to your
notes or bookmarks in the standard.
(For the benefit of other c.l.c. readers, since we know Bart will
immediately forget the answer here, "int abc;" is called a "tentative
definition". It can be repeated as often as you like in a file. If
there is no initialised definition, like "int abc = 1;" in the file,
then this acts like a single definition "int abc = 0;" with external
linkage.)
> If it is, then it really needs to
> be initialised.
No, it is considered equivalent to "int abc = 0;" if no explicit
initialiser is given.
> If it isn't, then because none is static, at least one
> needs to have 'extern'.
No, because external linkage is the default.
> In practice, if N modules contain those same
> uninitialised declarations, one implementation might assign ownership of
> the variable to one. Another might define multiple copies.
>
Here I agree with you. But it is not the fault of the language - it is
the fault of tools and old practice.
If module "a.c" has "int x;", and module "b.c" has "int x;", then you
should get a linker error when combining these modules, because "x" is
defined in both of them. That is the way the language works.
In terms of commonly used linker sections, "int x;" will result in an
entry "x" reserving space in ".bss". If you have a non-zero
initialiser, "int x = 1;", you'll get an entry in ".data" with the
initialiser.
Clearly, two "x" labels in ".bss" in two modules will give a linker failure.
(C itself doesn't talk about or define such sections, but they are
familiar to some people, and helpful for illustration.)
However, from before C was standardised, people had been using "int x;"
for /common/ symbols. This concept, I believe, comes from the Fortran
world. The intention is that "int x;" (with no initialiser) creates a
symbol "x" in ".common", with the appropriate space. When the linker
meets two common symbols with the same identifier, it merges them.
A lot of C compilers behave this way, because some C programmers think
this is how it is supposed to behave - and their code assumes it. It
is, IMHO, a /serious/ mistake and a glaring cause of potential errors
that are extremely hard to trace. C has a weak system for import and
export of symbols - this concept makes it much weaker. So one of the
things I do whenever I start using a new compiler is identifying
switches to ensure this misfeature is disabled. (It's "-fno-common" in
gcc and clang. I have a bug filed with gcc asking for this to be the
default.)
The C language does not specify this feature - it's tools that provide
it. But I agree it is a mess.
> What a mess! And if I type:
>
> static int abc;
> extern int abc;
>
> only one compiler picks up on it.
A compiler should not mark that as an error (but it can give a warning -
something I would like to see), as it is allowed in C. The second
"extern" declaration is effectively ignored (See 6.2.2p4). I don't know
why this is the case, and it seems bizarre to me - maybe someone else
can explain the reasoning. But the rules are there in the standard, and
it seems that your one compiler is mistaken in giving it as an error.
(gcc will warn about it with -Wredundant-decls, which I use on my own
code.)
> But reverse the order, and now it's an
> error.
Yes, I believe that is an error. (I haven't found a reference for you
here.)
>
> Aren't you lot embarrassed to be working with such a language? What
> exactly is the 700 pages of Standard about if it doesn't even pin down
> such basics?
>
It /does/ pin them down. Are you not embarrassed to be making
complaints about a document you've never read or even looked at closely?
Are you not embarrassed to be claiming to have written a compiler for a
language without reading the specifications and syntax for the language?
If I were writing a C-like language, there is a fair bit I would change
compared to C. I would insist on being a lot more consistent about
declarations and definitions, and ban a fair amount of the redundancy
that is allowed. I would organise the standards document in a
significantly different manner. I would have the massive advantage of
designing the language and writing the standards from scratch, not based
on existing practice, multiple existing tools, and huge quantities of
existing code.
But I didn't create the C language, nor did I write the C standards.
Why on earth would I be embarrassed about them?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 12:47 +0000 |
| Message-ID | <FtonE.887048$Apg.569682@fx36.am4> |
| In reply to | #142579 |
On 29/03/2019 09:58, David Brown wrote:
> On 29/03/2019 03:34, Bart wrote:
>> I recently got pulled up for calling C a trumped-up assembler, that's
>> why I mentioned it.
>
> That's because C is in no way a "trumped-up assembler". And in terms of
> its structure and syntax, it doesn't bear the slightest resemblance to
> assembler - and thus the comparison makes no sense at all in this context.
Yes it does.
I realised that some of problems I faced in translation in doing a full
translation of C to my language, are similar to those of trying to
translate ASM to HLL.
Some are doable by looking at patterns or idioms that match one in the
target language (eg. a for-loop that does a simple A to B iteration),
others are just too chaotic (eg. 'switch' with jumbled-up case labels).
Another big one is to do with types; C plays fast and loose with arrays
and pointers; the target language doesn't. Again, this is like ASM which
doesn't have a type system at all.
Yet another is to do with macros (macros are very common in ASM):
#define A 144
#define B 144
#define C 144
rather than have 144 all over the output code, and not know which 144
it's referring to, I'd rather have A, B or C. But if I suppress macro
expansion, it causes other problems (mainly in things like '#if
A==144'). Actually, I would probably have fewer problems translating ASM
in this case!
The answer would have been to use something like 'enum' for such integer
constants, which have fewer such problems. But '#define' for named
constants is still used everywhere.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-29 14:57 +0100 |
| Message-ID | <q7l87n$1vv$1@dont-email.me> |
| In reply to | #142582 |
On 29/03/2019 13:47, Bart wrote: > On 29/03/2019 09:58, David Brown wrote: >> On 29/03/2019 03:34, Bart wrote: > >>> I recently got pulled up for calling C a trumped-up assembler, that's >>> why I mentioned it. >> >> That's because C is in no way a "trumped-up assembler". And in terms of >> its structure and syntax, it doesn't bear the slightest resemblance to >> assembler - and thus the comparison makes no sense at all in this >> context. > > Yes it does. No, it doesn't. I'm not sure whether you think this because you have little experience and understanding of assembly, or because you have little experience and understanding of C. Or maybe it is because you write your assembly code in a very limited fashion - as you do for your C code - and thus the structures resemble each other vaguely. For other programmers, assembly and C are not remotely similar languages. > > I realised that some of problems I faced in translation in doing a full > translation of C to my language, are similar to those of trying to > translate ASM to HLL. > > Some are doable by looking at patterns or idioms that match one in the > target language (eg. a for-loop that does a simple A to B iteration), > others are just too chaotic (eg. 'switch' with jumbled-up case labels). I'll happily agree that mixed-up switch and loop statements is going to be a pain to translate. It is the kind of feature that was very nice in the old days of weaker C compilers, and could be used for some efficient implementations of certain kinds of code. But with modern compilers, you are better letting the compiler handle this kind of thing based on simple, clear code, and such mixes are going to be difficult for the compiler to optimise well. > > Another big one is to do with types; C plays fast and loose with arrays > and pointers; the target language doesn't. Again, this is like ASM which > doesn't have a type system at all. Repeating the same shite several hundred times does not make it true. C has arrays, and it has pointers. You might not like the way arrays are handled in C - the system has advantages and disadvantages compared to, say, Pascal's handling of arrays. But it works fine, and is not "fast and loose" - there are clear rules if only you could be bothered to learn them. > > Yet another is to do with macros (macros are very common in ASM): > > #define A 144 > #define B 144 > #define C 144 > > rather than have 144 all over the output code, and not know which 144 > it's referring to, I'd rather have A, B or C. But if I suppress macro > expansion, it causes other problems (mainly in things like '#if > A==144'). Actually, I would probably have fewer problems translating ASM > in this case! > What a shame - life is so hard for you. How nasty all these C people have been, designing a language without any consideration for poor Bart and his troubles. Back here in reality, translating between significantly different languages is an extremely difficult task, especially if you are aiming for efficiency, or aiming for an output that is clearly readable and keeps the structure of the original - and even worse if you want both. This is not a problem with C, or the way people write C - it is the nature of the problem. > The answer would have been to use something like 'enum' for such integer > constants, which have fewer such problems. But '#define' for named > constants is still used everywhere. > C has several ways of making constants, with different tradeoffs. I agree that enum can often be a neater method, but it is not always a suitable choice. And you don't get to choose how other people write their code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 14:57 +0000 |
| Message-ID | <tnqnE.243058$Qp2.145938@fx11.am4> |
| In reply to | #142584 |
On 29/03/2019 13:57, David Brown wrote:
> On 29/03/2019 13:47, Bart wrote:
>> On 29/03/2019 09:58, David Brown wrote:
>>> On 29/03/2019 03:34, Bart wrote:
>>
>>>> I recently got pulled up for calling C a trumped-up assembler, that's
>>>> why I mentioned it.
>>>
>>> That's because C is in no way a "trumped-up assembler". And in terms of
>>> its structure and syntax, it doesn't bear the slightest resemblance to
>>> assembler - and thus the comparison makes no sense at all in this
>>> context.
>>
>> Yes it does.
>
> No, it doesn't.
>
> I'm not sure whether you think this because you have little experience
> and understanding of assembly, or because you have little experience and
> understanding of C. Or maybe it is because you write your assembly code
> in a very limited fashion - as you do for your C code - and thus the
> structures resemble each other vaguely.
>
> For other programmers, assembly and C are not remotely similar languages.
I'm pointing out ways in which C and assembly have in common in being
hard to translate to a stricter, more structured language.
(1) Unstructured switch-case labels
(2) Lack of strong type info: does a int* parameter represent an array
of int in the caller, or a pointer to an isolated int?
(3) Unspecified function params as in 'void fn()' which can then be
called with /any/ number and types of arguments.
(4) Module-wide, unscoped, untyped names as used in #define
(5) Arbitrary control-flow via 'goto'. (This one not so much a problem,
but only because all my targets support goto.)
C's case-sensitivity doesn't help either, not when the target is
case-insensitive, nor its block scopes when the target doesn't have
block scopes:
typedef struct A {int A;}A;
typedef struct a {int A;}a;
int main(void) {
struct A A;
a a;
{int A,a;
}
}
(BTW the program I linked to in my OP will also move all declarations in
a function to the top of the function. ATM that will create duplicate
declarations in some cases.
However, it also intended for viewing or browsing C code, with a lot of
preprocessing clutter removed, as well as removing mixed declarations
and 'const'.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-03-29 15:08 -0700 |
| Message-ID | <8b48bb47-76ef-47a2-94a9-8be76681228b@googlegroups.com> |
| In reply to | #142591 |
W dniu piątek, 29 marca 2019 15:57:39 UTC+1 użytkownik Bart napisał:
>
> I'm pointing out ways in which C and assembly have in common in being
> hard to translate to a stricter, more structured language.
>
> (1) Unstructured switch-case labels
>
recent experience in writing proto c compiler teached me some things and i may say for example
1) c in act is MUCH closer by its nature
to assembler than people who not wrote compiler in a way like me probably think
c is "fully mixable" with assembler, you would only want to know some things that im to tired now to enumerate (one is that in assembly you use labels which are the same as labels in c (array names, variable names, function names, spot labels etc) so you may easily mix it)
> (2) Lack of strong type info: does a int* parameter represent an array
> of int in the caller, or a pointer to an isolated int?
>
thats true, this is a lack in c (this is not what i learned by writing compiler, it was observed and known before)
> (3) Unspecified function params as in 'void fn()' which can then be
> called with /any/ number and types of arguments.
>
this is agan what i learned when writing compiler, every cdecl function (as it seems mingv here all my function makes cdecl it means in short "all functions" (except like winapi stdcall) are vararg ones that are simply aclled with fixed sets - but this is big advantage not disadantage
yu simply may call functions with more parameters thay they take and nothing bad will happen..this most probably means that you can use this mechanism to return back as many values as you want, different number of reat values each call
> (4) Module-wide, unscoped, untyped names as used in #define
>
i never use defines though i program in c until 2001/2002
hovever i sometimes thinked (even incidentally today but also some n weaks before) on introducing aliases,
alias MessageBoxA to mba;
mba("title", "caption");
unalias mba ; //eventually
this could produce bad code but might have limited usage in cirricumstances whan you code for size (or when protatotype code for typing speed)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-03-29 15:42 -0700 |
| Message-ID | <1129dbeb-8383-4edf-8015-05daa20d2e80@googlegroups.com> |
| In reply to | #142608 |
W dniu piątek, 29 marca 2019 23:09:09 UTC+1 użytkownik fir napisał:
> W dniu piątek, 29 marca 2019 15:57:39 UTC+1 użytkownik Bart napisał:
> >
> > I'm pointing out ways in which C and assembly have in common in being
> > hard to translate to a stricter, more structured language.
> >
> > (1) Unstructured switch-case labels
> >
>
> recent experience in writing proto c compiler teached me some things and i may say for example
>
> 1) c in act is MUCH closer by its nature
> to assembler than people who not wrote compiler in a way like me probably think
>
> c is "fully mixable" with assembler, you would only want to know some things that im to tired now to enumerate (one is that in assembly you use labels which are the same as labels in c (array names, variable names, function names, spot labels etc) so you may easily mix it)
>
>
>
> > (2) Lack of strong type info: does a int* parameter represent an array
> > of int in the caller, or a pointer to an isolated int?
> >
>
> thats true, this is a lack in c (this is not what i learned by writing compiler, it was observed and known before)
>
> > (3) Unspecified function params as in 'void fn()' which can then be
> > called with /any/ number and types of arguments.
> >
>
> this is agan what i learned when writing compiler, every cdecl function (as it seems mingv here all my function makes cdecl it means in short "all functions" (except like winapi stdcall) are vararg ones that are simply aclled with fixed sets - but this is big advantage not disadantage
>
> yu simply may call functions with more parameters thay they take and nothing bad will happen..this most probably means that you can use this mechanism to return back as many values as you want, different number of reat values each call
>
this specificaly meand that cdecl (default c calling convention) is simply ready to handle many return values
i not checked it yet physically but it simply seems so - i will be coding that in my protocompiler probabl;y soon
i mean such call as:
int x, y, z = foo(2,3);
is banal to compile, you simply generate such code
push 0 //z
push 0 //y
push 0 //x
push 3
push 2
call foo
pop eax
pop eax
where foo
foo:
mov eax (esp+4) //to read 1 arg
mov eax (esp+8) //to read 2 arg
mov (esp +12) eax //to write x
mov (esp +16) eax //to write y
mov (esp +20) eax //to write z
//....
ret
amd you eben may make foo to return variable amount of veriables (you would
like to pass how many you want back hovevere like in some of its arg like
x = foo(1)
x,y = foo(2)
x,y,z = foo(3)
no problem cdecl supports that
note: i was already talken on this, i mean that it is possible and can be done, i only possibly was not being fully aware that cdecl supports that
if im not wrong it simply means that you can read retvalues mixing asm and c
voif foo();
foo(2, 0, 0); //n, x, y
asm eax (esp-4) //read y
asm eax (esp-8) //read x
hovever it is simply better to write it in compiler tham putting asm stubs (yawn)
> > (4) Module-wide, unscoped, untyped names as used in #define
> >
> i never use defines though i program in c until 2001/2002
>
> hovever i sometimes thinked (even incidentally today but also some n weaks before) on introducing aliases,
>
> alias MessageBoxA to mba;
>
> mba("title", "caption");
>
> unalias mba ; //eventually
>
>
> this could produce bad code but might have limited usage in cirricumstances whan you code for size (or when protatotype code for typing speed)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-03-29 15:16 +0000 |
| Message-ID | <5FqnE.541140$h85.238779@fx37.iad> |
| In reply to | #142584 |
David Brown <david.brown@hesbynett.no> writes: >On 29/03/2019 13:47, Bart wrote: >> On 29/03/2019 09:58, David Brown wrote: >>> On 29/03/2019 03:34, Bart wrote: >> >>>> I recently got pulled up for calling C a trumped-up assembler, that's >>>> why I mentioned it. >>> >>> That's because C is in no way a "trumped-up assembler". And in terms of >>> its structure and syntax, it doesn't bear the slightest resemblance to >>> assembler - and thus the comparison makes no sense at all in this >>> context. >> >> Yes it does. > >No, it doesn't. > >I'm not sure whether you think this because you have little experience >and understanding of assembly, or because you have little experience and >understanding of C. He's saying it to be provocative and to continue a ridiculous conversation and you've fallen into his trap, yet again.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 15:30 +0000 |
| Message-ID | <jSqnE.438041$Qs7.390091@fx09.am4> |
| In reply to | #142594 |
On 29/03/2019 15:16, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 29/03/2019 13:47, Bart wrote:
>>> On 29/03/2019 09:58, David Brown wrote:
>>>> On 29/03/2019 03:34, Bart wrote:
>>>
>>>>> I recently got pulled up for calling C a trumped-up assembler, that's
>>>>> why I mentioned it.
>>>>
>>>> That's because C is in no way a "trumped-up assembler". And in terms of
>>>> its structure and syntax, it doesn't bear the slightest resemblance to
>>>> assembler - and thus the comparison makes no sense at all in this
>>>> context.
>>>
>>> Yes it does.
>>
>> No, it doesn't.
>>
>> I'm not sure whether you think this because you have little experience
>> and understanding of assembly, or because you have little experience and
>> understanding of C.
>
> He's saying it to be provocative and to continue a ridiculous conversation
> and you've fallen into his trap, yet again.
>
There is an actual translator from C:
https://github.com/sal55/qx/blob/master/ccm.c
These /are/ actual issues.
And I can have an opinion on those issues and the similarity with trying
to do a translation of asm.
So there.
I suggest you work on a similar project, and you can find out for
yourself whether C makes the process harder or otherwise.
Bear in mind that some of the analysis that is needed is not dissimilar
to what a human reader needs to do to make sense of code.
Lessons can be learned for writing clearer code.
Although I understand that you are keener to not only keep things
cryptic, but to make them more sof.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-03-29 14:47 -0700 |
| Message-ID | <eeaa466b-0d3d-4497-8901-9bb3b83071eb@googlegroups.com> |
| In reply to | #142594 |
W dniu piątek, 29 marca 2019 16:16:26 UTC+1 użytkownik Scott Lurndal napisał: > David Brown <david.brown@hesbynett.no> writes: > >On 29/03/2019 13:47, Bart wrote: > >> On 29/03/2019 09:58, David Brown wrote: > >>> On 29/03/2019 03:34, Bart wrote: > >> > >>>> I recently got pulled up for calling C a trumped-up assembler, that's > >>>> why I mentioned it. > >>> > >>> That's because C is in no way a "trumped-up assembler". And in terms of > >>> its structure and syntax, it doesn't bear the slightest resemblance to > >>> assembler - and thus the comparison makes no sense at all in this > >>> context. > >> > >> Yes it does. > > > >No, it doesn't. > > > >I'm not sure whether you think this because you have little experience > >and understanding of assembly, or because you have little experience and > >understanding of C. > > He's saying it to be provocative and to continue a ridiculous conversation > and you've fallen into his trap, yet again. as to my personal opinion bartc is a fellow who likes kill its life time from psychological reasons (there is some deeper explanation here probably but im not into it) for me its to much "big distraction" hovever many posts on thsi group is big distraction not only those by bartc yetr about this repetable threads (post streams) of bartc imo it is not a problem when he would limit himself in posting it at a dose of 15-posts one time (by one time i mean few-days time spot).. if he is going in 150-posts about it it is to much ;c
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-29 10:42 +0000 |
| Message-ID | <87y34yc67j.fsf@bsb.me.uk> |
| In reply to | #142578 |
Bart <bc@freeuk.com> writes: > Functions (in my world anyway) are of three kinds: local, exported, > and imported, usually indicated in C by 'static', <nothing> and > 'extern' respectively. Notice the last two are exclusive, so they > shouldn't both have 'extern'. I'm not exactly sure what your kinds are, but it looks likely that C's view of functions is not the same as yours. (I note that only because it's of what follows -- I don't need to know how you view functions.) > So, yes, it's incovenient due to C being so messy in not being able to > cleanly specify this stuff. You found some C code that did not cleanly specify the distinctions that matter to you. There's lots of messy C out there and almost all of it won't meet your expectations. > I mean, what does this mean in a program at module scope: It's called file scope in C. > int abc; > ... > int abc; > ... > int abc; > > Is abc defined in this module or not? Yes, it is. > If it is, then it really needs to be initialised. Yes, and it is. > If it isn't, then because none is static, at least one needs to have > 'extern'. No. You could find out what's needed by reading the language standard. > In practice, if N modules contain those same uninitialised > declarations, That's fuzzy wording but it explains why you might have thought the object defined above was not initialised. Objects are (or are not) initialised; declarations on the other hand might (or might not) contain an initialiser. The definitions above do not include an initialiser, but the object is initialised. > one implementation might assign ownership of the > variable to one. Another might define multiple copies. It might. That situation is "undefined" and the implementation can do what it likes. This is for historical reasons. C did not want to say what a linker /must/ do in this situation since C often relied the system's linker. So it was left open. This is not the first time I've written essentially the same thing in a reply to you (I post mainly in case anyone else finds it useful). But, to be fair, you did say that did not want to learn anything more about C quite a while ago, so I don't expect you to take any of it onboard. > Aren't you lot embarrassed to be working with such a language? No. The fact that it is probably the single most important programming language ever, softens the blow a bit. It's also probably the most widely implemented programming language. That's likely to be why you use it. > What exactly is the 700 pages of Standard about if it doesn't even pin > down such basics? And yet I was able to answer your questions. Where things are not pined down it is almost always to give implementations some leeway. That's not a bad thing where you want fast code. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 11:57 +0000 |
| Message-ID | <MKnnE.266499$kh.234296@fx27.am4> |
| In reply to | #142580 |
On 29/03/2019 10:42, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> If it isn't, then because none is static, at least one needs to have
>> 'extern'.
>
> No. You could find out what's needed by reading the language standard.
You shouldn't need to delve into the standard for such basics. One
example of usage and you should be set for both writing and reading code.
>> What exactly is the 700 pages of Standard about if it doesn't even pin
>> down such basics?
>
> And yet I was able to answer your questions. Where things are not pined
> down it is almost always to give implementations some leeway. That's
> not a bad thing where you want fast code.
Here are how those kinds of functions are defined in one language of
mine (although one kind has to be split, so really four categories not
three):
local function F:T = ...
export global function G:T = ...
import (same lang) (done via 'import' stmt)
import (FF) clang function "I":T
This is how it is inside my assembler:
local F:
export G::
import (same lang) H* used in situ (no decl needed)
import (FF) `I* (back-tick = case-insensitive)
This is how I would do it when writing C, this version split between
header and main module (assume imports will also be shared):
Header:
export T G(void);
import (same lang) extern T H(void);
import (FF) X extern T I(void); (implementation-defined X)
Module:
local static T F(void);
...
local static T F(void){}
export T G(void){}
It's possible to have no header (each module declares what it needs).
Already, there is variability, duplication and segregation, even
following my fairly solid guidelines. But as I said, all these rules
seem to be broken by other code. Multiple declarations are tolerated.
Mixed linkage is sometimes tolerated. Different modules can privately
declare the same global name, with different specs.
Yes, maybe the standard manages to somehow convey all the possibilities,
but so what. The trick is have a language that is easy to explain.
I won't go into the possibilities for variables as there seem to be even
more combinations, in C (in my own examples it's just the same pattern).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 13:04 +0000 |
| Message-ID | <TJonE.563659$uD1.114738@fx33.am4> |
| In reply to | #142581 |
On 29/03/2019 11:57, Bart wrote:
> Here are how those kinds of functions are defined..
> This is how I would do it when writing C...
> Header:
> export T G(void);
I think this requires 'extern' here, for when the header is compiled
from another module.
> export T G(void){}
So both 'extern' and non-'extern' versions must be allowed in one module.
(Note this does not stop G also being defined in another module, a clash
detected at link-time.)
(My translator /to/ C never generates shared headers which are visible
from elsewhere, so 'extern' is never used.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-29 14:58 +0100 |
| Message-ID | <q7l8an$1vv$2@dont-email.me> |
| In reply to | #142581 |
On 29/03/2019 12:57, Bart wrote: > On 29/03/2019 10:42, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> If it isn't, then because none is static, at least one needs to have >>> 'extern'. >> >> No. You could find out what's needed by reading the language standard. > > You shouldn't need to delve into the standard for such basics. One > example of usage and you should be set for both writing and reading code. > Fair enough. You /don't/ need to delve into it - most C programmers understand it fine without having read the standards. But you are a compiler writer, and making a translator - you /should/ be delving into the standards. >>> What exactly is the 700 pages of Standard about if it doesn't even pin >>> down such basics? >> >> And yet I was able to answer your questions. Where things are not pined >> down it is almost always to give implementations some leeway. That's >> not a bad thing where you want fast code. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-29 14:29 +0000 |
| Message-ID | <%YpnE.295670$AZ5.254021@fx13.am4> |
| In reply to | #142585 |
On 29/03/2019 13:58, David Brown wrote: > On 29/03/2019 12:57, Bart wrote: >> On 29/03/2019 10:42, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> If it isn't, then because none is static, at least one needs to have >>>> 'extern'. >>> >>> No. You could find out what's needed by reading the language standard. >> >> You shouldn't need to delve into the standard for such basics. One >> example of usage and you should be set for both writing and reading code. >> > > Fair enough. You /don't/ need to delve into it - most C programmers > understand it fine without having read the standards. > > But you are a compiler writer, and making a translator - you /should/ be > delving into the standards. The C standard will probably tell you that 'extern' is never really needed. So why bother?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-29 20:06 +0000 |
| Message-ID | <87ftr5bg3c.fsf@bsb.me.uk> |
| In reply to | #142588 |
Bart <bc@freeuk.com> writes: > On 29/03/2019 13:58, David Brown wrote: >> On 29/03/2019 12:57, Bart wrote: >>> On 29/03/2019 10:42, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>>> If it isn't, then because none is static, at least one needs to have >>>>> 'extern'. >>>> >>>> No. You could find out what's needed by reading the language standard. >>> >>> You shouldn't need to delve into the standard for such basics. One >>> example of usage and you should be set for both writing and reading code. >>> >> >> Fair enough. You /don't/ need to delve into it - most C programmers >> understand it fine without having read the standards. >> >> But you are a compiler writer, and making a translator - you /should/ be >> delving into the standards. > > The C standard will probably tell you that 'extern' is never really > needed. So why bother? What an extraordinary thing to say. You get an edge case wrong, someone says you can find the answer in the C standard, and you say the C standard is probably wrong so why bother? It's beyond bizarre. No, the C standard will /not/ tell you that extern is never really needed, so you /should/ bother to read it (on the off chance you want to know the language). -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web