Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #142549 > unrolled thread

C Translator

Back to article view | Back to comp.lang.c

Contents

  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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#142604

Bart <bc@freeuk.com> writes:

> 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.

You shouldn't see edge case code like either.  When you do, it often
requires a definitive reference.  But I agree that C has cases that
should be more obvious than they are.  Organic growth and a long history
can do that.

> 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

So why are you using C?  What is so great about C that you can't stop
using it no matter how much you hate it?

> 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).

You are shoe-horning C into your own categories.  That does not usualy
end well (for any language).  C does not have modules, imports, exports
or local functions.  It's easier to write C if you do things the C way.
I won't explain how C does all this stuff, because you either already
know or don't what to know what that is.

> The trick is have a language that is easy to explain.

You do don't you?  It's a shame it is not popular, but you at least need
not complain about C ever again.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142606

On 29/03/2019 20:02, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

> So why are you using C?  What is so great about C that you can't stop
> using it no matter how much you hate it?

ATM, the translator project I'm attempting was to help get an 
interesting source of test programs of which there is a massively bigger 
supply in C than of my own stuff.

I'm working on my first significant 1200-line program and a lot more 
things are coming up. I'm trying as much as possible to cater for them 
in the translator to minimise the amount of manual tweaking that is needed.

Another related project, currently stalled, was to take APIs specified 
via C header files, and to automatically generate an import file for my 
language. Some is straightforward, but it's the macros that are the 
biggest problem.

Here's an example output file generated from the 600 C header files 
comprising the GTK interface:

    https://raw.githubusercontent.com/sal55/qx/master/gtk.m

(1.5MB/23000 lines) It looks good until from around line 19000 which 
lists all the macros that would need to be fixed.

So there's some interesting stuff I would like to use, but it's on the 
other side of this giant obstacle called the C language.

> You are shoe-horning C into your own categories.

No. They are categories that people will expect any language to have.

[toc] | [prev] | [next] | [standalone]

#142613

On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:

>On 29/03/2019 20:02, Ben Bacarisse wrote:
>> You are shoe-horning C into your own categories.
>
>No. They are categories that people will expect any language to have.

Your talent for contradicting yourself in the space of one sentence is
remarkable.

[toc] | [prev] | [next] | [standalone]

#142615

On 30/03/2019 04:52, Scott wrote:
> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
> 
>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>> You are shoe-horning C into your own categories.
>>
>> No. They are categories that people will expect any language to have.
> 
> Your talent for contradicting yourself in the space of one sentence is
> remarkable.
> 

And yours seem to be in not making sense. In what way have I 
contradicted myself? What weird categories of function scope do /you/ 
have in mind?

Here's how Nasm, which can represent the code of any static language, 
deals with the various scopes:

Local:

     F:

Exported:

     GLOBAL G
     G:

Imported:

     EXTERN H


What else is there?

[toc] | [prev] | [next] | [standalone]

#142618

On Sat, 30 Mar 2019 11:03:20 +0000, Bart <bc@freeuk.com> wrote:

>On 30/03/2019 04:52, Scott wrote:
>> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
>> 
>>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>>> You are shoe-horning C into your own categories.
>>>
>>> No. They are categories that people will expect any language to have.
>> 
>> Your talent for contradicting yourself in the space of one sentence is
>> remarkable.
>
>And yours seem to be in not making sense. In what way have I 
>contradicted myself?

(1) C is in the set of any 'language'; (2) I am in the set of
'people'; but (3) I do not expect C to have the categories you
describe. Your claim disproves itself.

Not to say that C doesn't have analogous features, but by different
mnemonics, and not working the way you think they ought to. But C not
working the way you think it ought to is, well, not news.

[toc] | [prev] | [next] | [standalone]

#142619

On 30/03/2019 16:17, Scott wrote:
> On Sat, 30 Mar 2019 11:03:20 +0000, Bart <bc@freeuk.com> wrote:
> 
>> On 30/03/2019 04:52, Scott wrote:
>>> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
>>>
>>>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>>>> You are shoe-horning C into your own categories.
>>>>
>>>> No. They are categories that people will expect any language to have.
>>>
>>> Your talent for contradicting yourself in the space of one sentence is
>>> remarkable.
>>
>> And yours seem to be in not making sense. In what way have I
>> contradicted myself?
> 
> (1) C is in the set of any 'language'; (2) I am in the set of
> 'people'; but (3) I do not expect C to have the categories you
> describe. Your claim disproves itself.

Then I'm curious: what categories of function scopes do you expect a 
language to have?

(This is specific to functions but the categories apply also to other 
top-level entities which name a shared resource (eg. variables) as well 
as to other more abstract named entities (eg. types) although C handling 
of the latter is primitive.)

[toc] | [prev] | [next] | [standalone]

#142620

Bart <bc@freeuk.com> writes:

> On 30/03/2019 16:17, Scott wrote:
>> On Sat, 30 Mar 2019 11:03:20 +0000, Bart <bc@freeuk.com> wrote:
>>
>>> On 30/03/2019 04:52, Scott wrote:
>>>> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
>>>>
>>>>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>>>>> You are shoe-horning C into your own categories.
>>>>>
>>>>> No. They are categories that people will expect any language to have.
>>>>
>>>> Your talent for contradicting yourself in the space of one sentence is
>>>> remarkable.
>>>
>>> And yours seem to be in not making sense. In what way have I
>>> contradicted myself?
>>
>> (1) C is in the set of any 'language'; (2) I am in the set of
>> 'people'; but (3) I do not expect C to have the categories you
>> describe. Your claim disproves itself.
>
> Then I'm curious: what categories of function scopes do you expect a
> language to have?

Please!  Functions do not have scopes -- names have scopes.  OK, you may
well consider that nit-picking, but even so, you are not talking about
/scope/ at all but about /linkage/.  C's linkage rules (and even some of
its scope rules) were designed to match what assemblers and linkers used
to do (any most still do).  I would expect only the corner cases to be
surprising to someone from an assembler background.  Someone who knows
only, say, Haskell might be more likely to be surprised.  If they know
Haskell, Prolog, Snobol, Lisp and COLBOL, they might have a very open
mind about what to expect of C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142624

On 30/03/2019 20:32, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 30/03/2019 16:17, Scott wrote:
>>> On Sat, 30 Mar 2019 11:03:20 +0000, Bart <bc@freeuk.com> wrote:
>>>
>>>> On 30/03/2019 04:52, Scott wrote:
>>>>> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
>>>>>
>>>>>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>>>>>> You are shoe-horning C into your own categories.
>>>>>>
>>>>>> No. They are categories that people will expect any language to have.
>>>>>
>>>>> Your talent for contradicting yourself in the space of one sentence is
>>>>> remarkable.
>>>>
>>>> And yours seem to be in not making sense. In what way have I
>>>> contradicted myself?
>>>
>>> (1) C is in the set of any 'language'; (2) I am in the set of
>>> 'people'; but (3) I do not expect C to have the categories you
>>> describe. Your claim disproves itself.
>>
>> Then I'm curious: what categories of function scopes do you expect a
>> language to have?
> 
> Please!  Functions do not have scopes -- names have scopes.

You snipped the bit where I say that other names have scopes, but I was 
asking about function names only.

>  OK, you may
> well consider that nit-picking, but even so, you are not talking about
> /scope/ at all but about /linkage/.

I consider scope to be a more general concept of which linkage is part.

   C's linkage rules (and even some of
> its scope rules) were designed to match what assemblers and linkers used
> to do (any most still do).

Yes, probably those three categories I listed, and demonstrated with 
Nasm. That's why I said people will expect a language to have some way 
of expressing those kinds of scope.

(These days anyway. Some languages from the 70s either didn't 
acknowledge separate modules, or used some crude approaches to make 
achieve what was needed.)

   I would expect only the corner cases to be
> surprising to someone from an assembler background.  Someone who knows
> only, say, Haskell might be more likely to be surprised.  If they know
> Haskell, Prolog, Snobol, Lisp and COLBOL, they might have a very open
> mind about what to expect of C.

Yeah, some of those. I suppose compared with 1970s languages, C was 
ahead of its time.

[toc] | [prev] | [next] | [standalone]

#142626

Bart <bc@freeuk.com> writes:

> On 30/03/2019 20:32, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 30/03/2019 16:17, Scott wrote:
>>>> On Sat, 30 Mar 2019 11:03:20 +0000, Bart <bc@freeuk.com> wrote:
>>>>
>>>>> On 30/03/2019 04:52, Scott wrote:
>>>>>> On Fri, 29 Mar 2019 21:10:31 +0000, Bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>>> On 29/03/2019 20:02, Ben Bacarisse wrote:
>>>>>>>> You are shoe-horning C into your own categories.
>>>>>>>
>>>>>>> No. They are categories that people will expect any language to have.
>>>>>>
>>>>>> Your talent for contradicting yourself in the space of one sentence is
>>>>>> remarkable.
>>>>>
>>>>> And yours seem to be in not making sense. In what way have I
>>>>> contradicted myself?
>>>>
>>>> (1) C is in the set of any 'language'; (2) I am in the set of
>>>> 'people'; but (3) I do not expect C to have the categories you
>>>> describe. Your claim disproves itself.
>>>
>>> Then I'm curious: what categories of function scopes do you expect a
>>> language to have?
>>
>> Please!  Functions do not have scopes -- names have scopes.
>
> You snipped the bit where I say that other names have scopes, but I
> was asking about function names only.

The text you refer to has the same confusion.  It says that "this"
(presumably referring to what you said about functions) applies to
other named entities.  I don't see how that removes the confusion.

>>  OK, you may
>> well consider that nit-picking, but even so, you are not talking about
>> /scope/ at all but about /linkage/.
>
> I consider scope to be a more general concept of which linkage is
> part.

By all means consider black to be white, but if you post about that in a
Goth group, people will tell you are using the words wrongly.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142630

On 31/03/2019 03:23, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> I consider scope to be a more general concept of which linkage is
>> part.
> 
> By all means consider black to be white, but if you post about that in a
> Goth group, people will tell you are using the words wrongly.

I see, this is all about using the /precise/ words and meanings from the 
C standard, which not every programmer will have read from cover to cover.

Both scope and linkage are about visibility; hardly black and white.

Sticking to exactly what C says doesn't exactly help the confusion:

* Using 'static' means a function or variable local. Unless (1) it's
   used inside a function. (And (2), sometimes, when it's used with a
   function that is not defined in this unit, then the function can be
   imported. This may or may not be reported as a warning.) And (3), when
   a 'static' function declaration is followed by an 'extern' version of
   the same function, when it becomes imported. (I'm ignoring other uses
   of 'static')

* Using 'extern' makes a function or variable an import. Unless (1)
   when it's actually exported. And (2) when it's used inside a function,
   because there it can simply mean a variable is declared outside the
   function, nothing to do with linkage. And (3) when it's not used at
   all, then a function or variable can be still be imported.

* Since within a unit there can be multiple declarations of the same
   function, of which at most one can be a definition, each can use
   different linkage (ie. static, extern or nothing) so /now/ you have to
   look at the language reference in detail as to whether the result is
   legal or not legal, and if it's legal, what the overall consensus is
   as to whether that function is local, exported or imported.

This is so helpful!

Now maybe you can see how it can be much more useful to think in general 
of 'local', 'exported', 'imported' and list what the hell you have to 
write in this crazy language to apply those attributes.

Unfortunately that doesn't help when reading anyone else's code. There 
as likely as not a declaration won't use 'static' or 'extern' at all, 
but be full of macros, macros whose definitions could be conditional.

(It seems I'm getting sucked in again, sorry. But you might understand 
the attraction of the clean, simple approach I use in my own languages, 
and the desire to help others apply the same to C.

I keep forgetting that people like C to be complicated. Maybe it's a 
status thing...)

[toc] | [prev] | [next] | [standalone]

#142632

Bart <bc@freeuk.com> writes:

> On 31/03/2019 03:23, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> I consider scope to be a more general concept of which linkage is
>>> part.
>>
>> By all means consider black to be white, but if you post about that in a
>> Goth group, people will tell you are using the words wrongly.
>
> I see, this is all about using the /precise/ words and meanings from
> the C standard, which not every programmer will have read from cover
> to cover.

No one is saying that.  Many people cope just fine by learning C some
other way.  I suspect they often know what scope is (not your "scope")
to start with, since it's an almost universal property of names in
programming languages.

> Both scope and linkage are about visibility; hardly black and white.

Yes, they are related, just as black and white about reflectivity.  But
black and white are rather too similar to be a good analogy.  Scope and
linkage are not opposite ends of the same scale, that are on entirely
different axes.

Anyway, I can't stop you writing deliberately confusing descriptions of
how C works, nor is it likely that I can get you stick to using the
conventional terms, but it does look like a rather odd way for you to
spend your time.  Most people prefer to clarify and explain rather then
obfuscate and confuse.

I won't correct what you go on to write.  There's no point.  I don't
think anyone learning C will take your posts as a reliable source.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142636

On 31/03/2019 15:07, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 31/03/2019 03:23, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> I consider scope to be a more general concept of which linkage is
>>>> part.
>>>
>>> By all means consider black to be white, but if you post about that in a
>>> Goth group, people will tell you are using the words wrongly.
>>
>> I see, this is all about using the /precise/ words and meanings from
>> the C standard, which not every programmer will have read from cover
>> to cover.
> 
> No one is saying that.  Many people cope just fine by learning C some
> other way.  I suspect they often know what scope is (not your "scope")
> to start with, since it's an almost universal property of names in
> programming languages.

Yes, that's what I said; it's what people expect in any language. So it 
would be useful to provide a mapping from those universal concepts to 
how they can be expressed in C. I believe I attempted that.

> Anyway, I can't stop you writing deliberately confusing descriptions of
> how C works, nor is it likely that I can get you stick to using the
> conventional terms, but it does look like a rather odd way for you to
> spend your time.

I spend some of my time devising clear and unambiguous language syntax. 
in C, if you see this at file scope:

     int fred(void);

You can't tell just from that whether fred is:

(1) an imported function

(2) an exported function

(3) a local function (because of a prior declaration using 'static')

That's a poor show in my opinion. You will just say I'm making it 
deliberately confusing, but are my observations actually wrong?

> I won't correct what you go on to write.  There's no point.  I don't
> think anyone learning C will take your posts as a reliable source.

Part of the point is that if I can get it wrong, then so can anybody.

[toc] | [prev] | [next] | [standalone]

#142647

On 31/03/2019 17:21, Bart wrote:
> On 31/03/2019 15:07, Ben Bacarisse wrote:

>> Anyway, I can't stop you writing deliberately confusing descriptions of
>> how C works, nor is it likely that I can get you stick to using the
>> conventional terms, but it does look like a rather odd way for you to
>> spend your time.
> 
> I spend some of my time devising clear and unambiguous language syntax. 
> in C, if you see this at file scope:
> 
>      int fred(void);
> 
> You can't tell just from that whether fred is:
> 
> (1) an imported function
> 
> (2) an exported function
> 
> (3) a local function (because of a prior declaration using 'static')
> 
> That's a poor show in my opinion. You will just say I'm making it 
> deliberately confusing, but are my observations actually wrong?
> 

It simply says "fred is a function that takes no parameters and returns 
an int".  You are trying to read more into it than the declaration says 
- thus you are getting yourself confused.

In some languages, you have to be more explicit.  That's fine - but it 
doesn't mean C has a problem here.

>> I won't correct what you go on to write.  There's no point.  I don't
>> think anyone learning C will take your posts as a reliable source.
> 
> Part of the point is that if I can get it wrong, then so can anybody.

No, I think you have an outstanding ability to get things wrong in your 
understanding of C, surpassed only be your ability to exaggerate and lie 
about the bits that /are/ hard.  I don't think I've met anyone that can 
compete with you in that category - not even the famous Bill Cunningham 
reaches up to your stature.

[toc] | [prev] | [next] | [standalone]

#142652

On 31/03/2019 20:19, David Brown wrote:
> On 31/03/2019 17:21, Bart wrote:
>> On 31/03/2019 15:07, Ben Bacarisse wrote:
> 
>>> Anyway, I can't stop you writing deliberately confusing descriptions of
>>> how C works, nor is it likely that I can get you stick to using the
>>> conventional terms, but it does look like a rather odd way for you to
>>> spend your time.
>>
>> I spend some of my time devising clear and unambiguous language 
>> syntax. in C, if you see this at file scope:
>>
>>      int fred(void);
>>
>> You can't tell just from that whether fred is:
>>
>> (1) an imported function
>>
>> (2) an exported function
>>
>> (3) a local function (because of a prior declaration using 'static')
>>
>> That's a poor show in my opinion. You will just say I'm making it 
>> deliberately confusing, but are my observations actually wrong?
>>
> 
> It simply says "fred is a function that takes no parameters and returns 
> an int".  You are trying to read more into it than the declaration says 

Yes, I am, because I'm trying to find out what its linkage is (if people 
don't like the word 'scope'). It /is/ a declaration, yes?

If I feed a program containing only that to my translator, it will give 
this output (this line appears in an import block; C functions are 
always imported):

     clang function fred()int32

but that is with the knowledge of the entire program. But a casual 
reader cannot be expected to do scan the whole program to find out 
fred's linkage (something that is very easy from the output, since it 
uses the novel idea of using exactly ONE definitive declaration of fred).

With input of:

     static int fred(void);

my translator says that 'fred' is not defined; but all C compilers pass 
it with no warnings (using default options in all cases) and treat it as 
an import. Is my translator wrong, or those compilers?

With input of:

     int abc;

my translator gives output of:

     global int32 abc

(ie. assumes it is exported.). However, 'int abc;' is commonly used in C 
programs to declare that 'abc' is imported from elsewhere. This 
generally gets sorted out in a linker (which either fixes the problem, 
or reports a multiple definition).

My translator however has to give valid output given only one C module, 
and only what is declared in that module.

Is 'abc' imported or exported? Because C is so slack in requiring that 
imports need 'extern', this becomes a real problem. There is not enough 
information in the source module.

Here, all C compilers I tried accepted 'int abc;' to declare an imported 
'abc' initialised in another module (although Pelles C displayed the 
wrong result, so it may have had two versions of 'abc').

EXCEPT my own C compiler which reported multiple definitions of 'abc'.



> - thus you are getting yourself confused.

> In some languages, you have to be more explicit.  That's fine - but it 
> doesn't mean C has a problem here.

See above, where I demonstrate several actual problems due to C treating 
this whole thing so sloppily.

(Understandable in 1970s, but we're not in the 1970s any more.)


>> Part of the point is that if I can get it wrong, then so can anybody.
> 
> No, I think you have an outstanding ability to get things wrong in your 
> understanding of C, surpassed only be your ability to exaggerate and lie 
> about the bits that /are/ hard.  I don't think I've met anyone that can 
> compete with you in that category - not even the famous Bill Cunningham 
> reaches up to your stature.

I assume you're quite good at this stuff. So in each of these complete 
programs of my examples, is fred or abc local, exported or imported, or 
is there a bug in the program, or is there a bug in every C compiler I 
tried:

     int fred(void);

     static int fred(void);

     int abc;

[toc] | [prev] | [next] | [standalone]

#142657

On 2019-03-31, Bart <bc@freeuk.com> wrote:
> With input of:
>
>      static int fred(void);
>
> my translator says that 'fred' is not defined; but all C compilers pass 
> it with no warnings (using default options in all cases) and treat it as 
> an import. Is my translator wrong, or those compilers?

C compilers can warn about this, if told to.
For instance, gcc has the option -Wunused-function for this purpose.

How do you know that C compilers treat is as an import?
That would seem a strange thing to do with a function declared static,
it's far more plausible that the declaration is simply ignored, which is
fine if the function is never called.

If the function is called, gcc gives an error (undefined reference to `fred').
I don't know what other C compilers do in that case.

[toc] | [prev] | [next] | [standalone]

#142660

On 31/03/2019 21:33, Ike Naar wrote:
> On 2019-03-31, Bart <bc@freeuk.com> wrote:
>> With input of:
>>
>>       static int fred(void);
>>
>> my translator says that 'fred' is not defined; but all C compilers pass
>> it with no warnings (using default options in all cases) and treat it as
>> an import. Is my translator wrong, or those compilers?
> 
> C compilers can warn about this, if told to.
> For instance, gcc has the option -Wunused-function for this purpose.
> 
> How do you know that C compilers treat is as an import?
> That would seem a strange thing to do with a function declared static,
> it's far more plausible that the declaration is simply ignored, which is
> fine if the function is never called.
> 
> If the function is called, gcc gives an error (undefined reference to `fred').
> I don't know what other C compilers do in that case.
> 

I used these two test files to form one program:

---------------------------
c.c
---------------------------
static int fred(void);

int main(void){
     fred();
}

---------------------------
d.c
---------------------------
#include <stdio.h>

int fred(void){
     puts("FRED");
     return 0;
}
---------------------------

In this case, gcc will warn about 'fred', but only when it is used. It 
will not warn (under default options) when fred is not used.

Anyway the above program links and displays "FRED". So it is being used 
as an import. clang and tcc are the same. But other compilers vary.

[toc] | [prev] | [next] | [standalone]

#142663

Bart <bc@freeuk.com> writes:

> With input of:
>
>     static int fred(void);
>
> ... all C compilers pass it with no warnings

That's correct.  A function need only be defined if it is used.

> (using default options in all cases)

Please stop doing this.  At least ask for the code to be treated as C
(e.g. -std=c11 for gcc) rather than whatever language the compiler is
pushing.

> and treat it as an import. Is my translator wrong, or those compilers?

That I don't know, because (and I know you probably won't believe me), I
don't know what "treat it as an import" means.  I say a bit more about
that later on.

> With input of:
>
>     int abc;
>
> my translator gives output of:
>
>     global int32 abc
>
> (ie. assumes it is exported.). However, 'int abc;' is commonly used in
> C programs to declare that 'abc' is imported from elsewhere. This
> generally gets sorted out in a linker (which either fixes the problem,
> or reports a multiple definition).

This again!  I should assume you don't remember.  If you did, you would
explain what is going on, yes?

> I assume you're quite good at this stuff. So in each of these complete
> programs of my examples, is fred or abc local, exported or imported,
> or is there a bug in the program, or is there a bug in every C
> compiler I tried:
>
>     int fred(void);
>
>     static int fred(void);
>
>     int abc;

I think there are some typos in the question, but as I read it, if each
line is taken as a complete program, they are all undefined.  The
compiler can do anything it likes because there is no main function.
With a null main, all of these

  int fred(void); int main(void) {}

  static int fred(void); int main(void) {}

  int abc; int main(void) {}

should compile and none requires a diagnostic.  Since the named entities
are not used, the implementation can ignore them, but in so far as it
makes any sense to say so in a complete program, the two 'fred's and
'abc' have external, internal and external linkage respectively.

Adding a main that uses the declared entities we can say more:

  int fred(void); int main(void) { return fred(); }

Undefined.  A function is used but there is no definition of it.  fred
has external linkage (I don't know if that is local, exported or
imported -- you could tell me).

  static int fred(void); int main(void) { return fred(); }

Also undefined, but fred has internal linkage this time.

  int abc; int main(void) { return abc; }

Fine.  The program returns 0 (a "successful termination status") to the
host environment.  abc has external linkage, though it makes no
difference since this is a complete program.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142665

On 31/03/2019 22:37, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> programs of my examples,

I meant a complete source file such as is submitted to a C compiler.

>    static int fred(void); int main(void) {}

> should compile and none requires a diagnostic.

So, a source file can have any number of forward, static function 
declarations (and each can be repeated any number of times). But none 
needs to be actually defined, provided it is not referenced? Ok...

>    int fred(void); int main(void) { return fred(); }
> 
> Undefined.  A function is used but there is no definition of it.  fred
> has external linkage (I don't know if that is local, exported or
> imported -- you could tell me).

Really?

Let me give you a hint: if I was running a business and buying goods 
from overseas, I would be importing. If I was producing goods to sell 
overseas, then I'd be exporting.

The same with functions in a source file; either they're defined here 
and marked static (local), or defined here without static (exported), or 
declared here but defined elsewhere (imported).

Or it might be that I'm just being wound up because I can't believe a 
programmer cannot be aware of what 'importing' and 'exporting' a 
function might mean inside a source file.

Or, it could really be (as nothing about this language surprises me any 
more), that for C, 'external linkage' is all that is needed. Shared 
functions are just considered to be floating around unattached to any 
particular source file.


That certainly appears to be the case with variables, in that ownership 
of a variable is not fully established until link-time. You can't 
determine it purely from one source file.

Which means a translation from one C source file at a time into another 
language is impossible, if the target language demands that a shared 
variable must be classed as either imported or exported.

It seems C leaves that open, even if technically it doesn't. Since one 
of my tests had one file initialising 'abc' to 0 via 6.9.2p2, and 
another initialising it explicitly, yet all C compilers (except mine) 
compiled without comment:

-----------------------
c.c
-----------------------
#include <stdio.h>

int abc;

int main(void){
     printf("%d\n",abc);
}
-----------------------
d.c
-----------------------
int abc=7788;
-----------------------

Transcript:

   C:\c>gcc -std=c11 c.c d.c

   C:\c>a
   7788

[toc] | [prev] | [next] | [standalone]

#142670

Bart <bc@freeuk.com> writes:

> On 31/03/2019 22:37, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> programs of my examples,
>
> I meant a complete source file such as is submitted to a C compiler.

Oh well, I took a shot and guessing what you meant by programs.

>>    static int fred(void); int main(void) {}
>
>> should compile and none requires a diagnostic.
>
> So, a source file can have any number of forward, static function
> declarations (and each can be repeated any number of times). But none
> needs to be actually defined, provided it is not referenced?

It's not a forward declaration if the thing is not referenced.  At least
that what I take forward to mean.

> Ok...

Yes.  C could have added a rule to forbid that but it seems simpler not
to bother.

>>    int fred(void); int main(void) { return fred(); }
>>
>> Undefined.  A function is used but there is no definition of it.  fred
>> has external linkage (I don't know if that is local, exported or
>> imported -- you could tell me).
>
> Really?
>
> Let me give you a hint: if I was running a business and buying goods
> from overseas, I would be importing. If I was producing goods to sell
> overseas, then I'd be exporting.
>
> The same with functions in a source file; either they're defined here
> and marked static (local), or defined here without static (exported),
> or declared here but defined elsewhere (imported).

Or they are declared here and defined nowhere (with or without static),
or defined hare /and/ elsewhere with static, or declared here and also
defined here.  That last one is very common.  I think it's simpler just
to learn what C's declarations do.

> Or it might be that I'm just being wound up because I can't believe a
> programmer cannot be aware of what 'importing' and 'exporting' a
> function might mean inside a source file.

The problem is not that I don't know what the terms usually mean, it's
that I don't find the analogy helpful.  What's more, if someone knows
some other module system they maybe confused by it.  There are just too
many things that don't carry across.

> Or, it could really be (as nothing about this language surprises me
> any more), that for C, 'external linkage' is all that is
> needed. Shared functions are just considered to be floating around
> unattached to any particular source file.

Of course.  You know that.  An import is often "from" somewhere, but an
extern declaration can be linked with a definition from anywhere (or
nowhere if the function is not used yet).

> Which means a translation from one C source file at a time into
> another language is impossible, if the target language demands that a
> shared variable must be classed as either imported or exported.

Even simple import and export mechanisms are higher-level constructs
than C's linkage, and translating "up" is almost always impossible.
Certainly it's harder than translating down.

> It seems C leaves that open, even if technically it doesn't. Since one
> of my tests had one file initialising 'abc' to 0 via 6.9.2p2, and
> another initialising it explicitly, yet all C compilers (except mine)
> compiled without comment:

I'm guessing you don't want this explained again.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#142676

On 01/04/2019 00:33, Bart wrote:
> On 31/03/2019 22:37, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
> 
>>> programs of my examples,
> 
> I meant a complete source file such as is submitted to a C compiler.
> 
>>    static int fred(void); int main(void) {}
> 
>> should compile and none requires a diagnostic.
> 
> So, a source file can have any number of forward, static function
> declarations (and each can be repeated any number of times). But none
> needs to be actually defined, provided it is not referenced? Ok...

Yes, that's right.

Again, that kind of flexibility can be convenient, and can make the
language simpler to specify.  But it also means that you can't make
assumptions that a static declaration is always matched with a definition.

Flexibility has its advantages and disadvantages.  But remember, C was
designed primarily for the people who write C programs - not for people
who write C tools.  Any difficulties there might be in writing C
compilers were of minor concern - and any difficulties in automatically
translating C to other languages would have been irrelevant.

> 
>>    int fred(void); int main(void) { return fred(); }
>>
>> Undefined.  A function is used but there is no definition of it.  fred
>> has external linkage (I don't know if that is local, exported or
>> imported -- you could tell me).
> 
> Really?
> 
> Let me give you a hint: if I was running a business and buying goods
> from overseas, I would be importing. If I was producing goods to sell
> overseas, then I'd be exporting.

I think we all know what the words "import" and "export" mean.  We also
all know how C works.  But what we /don't/ know, is how /you/ think C
works, and why you think C should have ways to say exactly what /you/
think it should say, or why you think C should not allow people to say
things /you/ think it should not allow.

C is not "Bart's own language".  You don't get to make the rules.  You
can't expect other languages to fit the rules you like in your
languages.  You can dislike the C rules if you want - but only if you
understand them enough to give a qualified opinion (this is often not
the case).  I don't know of anyone in this group, myself included, who
like all the rules of C.  But we understand the need to learn them,
understand them, and work with them.

> 
> The same with functions in a source file; either they're defined here
> and marked static (local), or defined here without static (exported), or
> declared here but defined elsewhere (imported).
> 
> Or it might be that I'm just being wound up because I can't believe a
> programmer cannot be aware of what 'importing' and 'exporting' a
> function might mean inside a source file.

You are wound up because C does not fit your simplistic rules - and
other people understand that, while you don't.  C does not have a
concept of "import" and "export" - it has a concept of "internal
linkage" and "external linkage" (and also "no linkage").  These don't
match "import" and "export".  They can be used to provide something
equivalent to "import" and "export, but they are not limited to that.

(I personally prefer my code to make clean divisions between "import",
"export", and "local to the file".  But that is how I choose to use C,
not how C is limited.)

> 
> Or, it could really be (as nothing about this language surprises me any
> more), that for C, 'external linkage' is all that is needed. Shared
> functions are just considered to be floating around unattached to any
> particular source file.
> 

That is, in fact, closer to the truth.

> 
> That certainly appears to be the case with variables, in that ownership
> of a variable is not fully established until link-time. You can't
> determine it purely from one source file.

I've explained this already.  Why do you ask questions, if you have no
intention of reading the answers?

> 
> Which means a translation from one C source file at a time into another
> language is impossible, if the target language demands that a shared
> variable must be classed as either imported or exported.

I don't expect it to be impossible, but I expect it to be rather
difficult unless you restrict the C you accept, or duplicate the effects
of it.

But why is that a surprise?  Why would you expect to be able to
translate one language completely and directly to another language?  C
was designed to be compiled to assembly - it was not designed to be
translated into arbitrary other languages.  No programming language is
designed for that.

> 
> It seems C leaves that open, even if technically it doesn't. Since one
> of my tests had one file initialising 'abc' to 0 via 6.9.2p2, and
> another initialising it explicitly, yet all C compilers (except mine)
> compiled without comment:
> 
> -----------------------
> c.c
> -----------------------
> #include <stdio.h>
> 
> int abc;
> 
> int main(void){
>     printf("%d\n",abc);
> }
> -----------------------
> d.c
> -----------------------
> int abc=7788;
> -----------------------
> 
> Transcript:
> 
>   C:\c>gcc -std=c11 c.c d.c
> 
>   C:\c>a
>   7788
> 

Credit where credit is due - I am happy to see a reference to the C
standard.  I think this is a first for you!

However, you have failed to read or understand the explanation I gave in
another post.  It seems pointless to repeat here.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web