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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-31 23:54 +0200 |
| Message-ID | <q7rcue$l6c$1@dont-email.me> |
| In reply to | #142652 |
On 31/03/2019 21:58, Bart wrote:
> 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?
People like both words "scope" and "linkage". But we prefer them to be
used correctly, rather than randomly.
Yes, it is a declaration. It is not a declaration that tells you the
linkage, except by default (if no other declaration tells you the
linkage, it will be external).
Like any other declaration, you get the scope of the identifier from
where the declaration is found - it will be either file scope or block
scope.
>
> 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).
If your translator assumes that the declaration alone gives all the
linkage information, without looking for other possible declarations in
the file, then your translator is broken.
You can dislike the C rules if you want to, but if you are making a
translator that is supposed to handle C, you have to follow those rules.
Whining about them will not make your program work.
>
> 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?
>
As long as "fred" is not used in the file (except for a sizeof or
_Alignof), that is not a problem.
If it is used, it seems to me to be a constraint violation - 6.9p3:
"""
There shall be no more than one external definition for each identifier
declared with internal linkage in a translation unit. Moreover, if an
identifier declared with internal linkage is used in an expression
(other than as a part of the operand of a sizeof or _Alignof operator
whose result is an integer constant), there shall be exactly one
external definition for the identifier in the translation unit.
"""
The definition can, of course, come later in the file - "static int
fred(void);" is a perfectly good "forward declaration".
> 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).
I think it is mistake that this is allowed in C compilers, but it is
commonly supported. I have already said as much. (The C standard does
not define this use of "int abc;", but compilers can.)
You can certainly feel free to assume that "int abc;" (at file scope) is
a definition, not an import.
>
> 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.
C is not slack here - C compilers are slack.
Your two choices would be to do as the C standards say ("int abc;" is a
definition, and only one definition of the same external linkage
identifier is allowed in the linked program), or do as many C compilers
do (put them in a "common" section).
>
> 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'.
>
gcc will complain (or the linker will) if you use "-fno-common", as will
other toolchains with appropriate flags. I wish this were the standard,
default setting.
>
>
>> - 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.
I see a mixture of not knowing what the standards say, failing to
understand some of C's flexibility, and sloppy C programming (with
correspondingly lenient C compilers, allowing the sloppy coding practice
to continue).
I agree with you that "int abc;" should /not/ be allowed in more than
one file - and the C standards, AFAIUI, also agree. But compilers
accept it because people write code that way.
>
> (Understandable in 1970s, but we're not in the 1970s any more.)
There are many features that are obsoleted in modern C, but which are
still accepted by tools - backwards compatibility is king in the C
world. I'd prefer that compilers put more emphasis on code quality by
default, and rejected several outdated and "sloppy" features, unless
specific compiler flags were used to enable them.
>
>
>>> 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;
>
>
More context is needed - they may be affected by other declarations.
(I'm not saying I like that - I'd be happier if every declaration of the
same identifier in a file had to be identical. It would avoid confusion
for readers, and the somewhat bizarre possibility of declaring something
as "static" and then later as "extern". But that's the rules of C.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-01 02:16 +0100 |
| Message-ID | <_DdoE.513530$7F3.198430@fx30.am4> |
| In reply to | #142664 |
On 31/03/2019 22:54, David Brown wrote:
> On 31/03/2019 21:58, Bart wrote:
>> 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?
>
> People like both words "scope" and "linkage". But we prefer them to be
> used correctly, rather than randomly.
>
> Yes, it is a declaration. It is not a declaration that tells you the
> linkage, except by default (if no other declaration tells you the
> linkage, it will be external).
In which direction? That part is rather vital! Although C doesn't like
to pin it down, it can be done like this:
Declarations:
extern T fn(void); // imported unless defined in this file
// then it will exported
static T fn(void); // local function defined later
T fn(void) // exported function defined later
The conditional 'extern' form is expected to be used in a header, so
that the same header file can be used for all source files including
fn's 'home' source file.
Definitions will be like this:
static T fn(void){} // local function defined here
T fn(void) // exported function defined here
The trouble is that no one writes to precise guidelines like this, as I
do (eg. https://github.com/sal55/qx/blob/master/bignum.h,
https://github.com/sal55/qx/blob/master/bignum.c)
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-04-01 06:42 +0000 |
| Message-ID | <slrn3rfoqa3cms.c2u.ike@iceland.freeshell.org> |
| In reply to | #142669 |
On 2019-04-01, Bart <bc@freeuk.com> wrote:
> On 31/03/2019 22:54, David Brown wrote:
>> On 31/03/2019 21:58, Bart wrote:
>
>>> 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?
>>
>> People like both words "scope" and "linkage".? But we prefer them to be
>> used correctly, rather than randomly.
>>
>> Yes, it is a declaration.? It is not a declaration that tells you the
>> linkage, except by default (if no other declaration tells you the
>> linkage, it will be external).
>
> In which direction? That part is rather vital! Although C doesn't like
> to pin it down, it can be done like this:
>
> Declarations:
>
> extern T fn(void); // imported unless defined in this file
> // then it will exported
> static T fn(void); // local function defined later
> T fn(void) // exported function defined later
In C there is no difference between the declarations
extern T fn(void);
and
T fn(void);
> The conditional 'extern' form is expected to be used in a header, so
> that the same header file can be used for all source files including
> fn's 'home' source file.
>
> Definitions will be like this:
>
> static T fn(void){} // local function defined here
> T fn(void) // exported function defined here
It looks like in the second line the function body is missing.
Did you mean
T fn(void){} // exported function defined here
?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-01 11:35 +0200 |
| Message-ID | <q7sm0e$mpm$2@dont-email.me> |
| In reply to | #142669 |
On 01/04/2019 03:16, Bart wrote:
> On 31/03/2019 22:54, David Brown wrote:
>> On 31/03/2019 21:58, Bart wrote:
>
>>> 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?
>>
>> People like both words "scope" and "linkage". But we prefer them to
>> be used correctly, rather than randomly.
>>
>> Yes, it is a declaration. It is not a declaration that tells you the
>> linkage, except by default (if no other declaration tells you the
>> linkage, it will be external).
>
> In which direction? That part is rather vital!
It may be vital to you in your language, but it is not vital to C. (Of
course, it makes sense to have this clear to human readers of the C code
- but the language and the compiler don't need it.)
> Although C doesn't like
> to pin it down, it can be done like this:
>
> Declarations:
>
> extern T fn(void); // imported unless defined in this file
> // then it will exported
> static T fn(void); // local function defined later
> T fn(void) // exported function defined later
>
> The conditional 'extern' form is expected to be used in a header, so
> that the same header file can be used for all source files including
> fn's 'home' source file.
>
> Definitions will be like this:
>
> static T fn(void){} // local function defined here
> T fn(void) // exported function defined here
>
> The trouble is that no one writes to precise guidelines like this, as I
> do (eg. https://github.com/sal55/qx/blob/master/bignum.h,
> https://github.com/sal55/qx/blob/master/bignum.c)
>
You think you are the only person that writes coding guidelines? What
planet do you live on?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-01 16:54 +0100 |
| Message-ID | <UuqoE.446198$P_2.104203@fx26.am4> |
| In reply to | #142677 |
On 01/04/2019 10:35, David Brown wrote: > On 01/04/2019 03:16, Bart wrote: >> The trouble is that no one writes to precise guidelines like this, as I >> do > You think you are the only person that writes coding guidelines? What > planet do you live on? A planet where I encounter other people's code. Lots of it. What guidelines do you think this program is using: https://github.com/sal55/qx/blob/master/lisp.c (This works with some compilers, but not mine. The first problem is that it's comparing pointers with ints (ie. ptr<int) which I don't allow, and I'm not prepared to change that. There are others, but I now no longer get drawn into pointless exercises like this where the other side - the author of the code - is not prepared to make some effort to write decent code.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-01 21:01 +0100 |
| Message-ID | <p6uoE.997090$Apg.431620@fx36.am4> |
| In reply to | #142697 |
On 01/04/2019 16:54, Bart wrote: > On 01/04/2019 10:35, David Brown wrote: >> On 01/04/2019 03:16, Bart wrote: > >>> The trouble is that no one writes to precise guidelines like this, as I >>> do > >> You think you are the only person that writes coding guidelines? What >> planet do you live on? > > > A planet where I encounter other people's code. Lots of it. > > What guidelines do you think this program is using: > > https://github.com/sal55/qx/blob/master/lisp.c > (This works with some compilers, but not mine. This manages to get through my translator, which relaxes type checking, to produce this visualisation using my syntax: https://github.com/sal55/qx/blob/master/lisp.m (Not working code as it still needs C's array/pointer handling etc etc to be manually fixed up throughout the program.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-04-01 13:41 -0700 |
| Message-ID | <ln4l7ha26w.fsf@kst-u.example.com> |
| In reply to | #142697 |
Bart <bc@freeuk.com> writes:
> On 01/04/2019 10:35, David Brown wrote:
>> On 01/04/2019 03:16, Bart wrote:
>>> The trouble is that no one writes to precise guidelines like this, as I
>>> do
>
>> You think you are the only person that writes coding guidelines? What
>> planet do you live on?
>
> A planet where I encounter other people's code. Lots of it.
>
> What guidelines do you think this program is using:
>
> https://github.com/sal55/qx/blob/master/lisp.c
>
> (This works with some compilers, but not mine. The first problem is that
> it's comparing pointers with ints (ie. ptr<int) which I don't allow, and
> I'm not prepared to change that.
I'll probably regret asking this, but how is that code relevant?
(It's 503 lines of obfuscated C code that results in dozens of
diagnostic messages when I compile it. Most of the warnings are for bad
integer/pointer casts. It also fails to include the required headers
for write() and waitpid(), and uses a function I've never heard of
called "strf".)
> There are others, but I now no longer get drawn into pointless exercises
> like this where the other side - the author of the code - is not
> prepared to make some effort to write decent code.)
Bad code exists. So what?
--
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-04-01 22:40 +0100 |
| Message-ID | <uzvoE.997630$Apg.19823@fx36.am4> |
| In reply to | #142703 |
On 01/04/2019 21:41, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > I'll probably regret asking this, but how is that code relevant? Because DB seems to think that everyone follows coding guidelines. This is one example of many that doesn't. Not clear coding guidelines anyway. >> There are others, but I now no longer get drawn into pointless exercises >> like this where the other side - the author of the code - is not >> prepared to make some effort to write decent code.) > > Bad code exists. So what? That doesn't tell you anything? To me a lot of this bad code exists because of a language that allows too much freedom, and because of compilers that don't take errors seriously. And I mean taking them seriously without having to twist their arm. Even if compilers allowed integer/pointer compares last century, there is no reason to still allow it now. That means having a hard error. There should be options to allow old programs to still compile, but it needs to take some effort to write such code now. (And, if you look at the syntax-translated version I posted, it is clear from that that every function and every variable outside a function is global (ie. with 'external linkage' so that it is visible to other translation units), which is probably not what is wanted here. In the C however, even if laid out better, that would not be obvious.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-04-01 16:25 -0700 |
| Message-ID | <lnzhp98g15.fsf@kst-u.example.com> |
| In reply to | #142706 |
Bart <bc@freeuk.com> writes:
> On 01/04/2019 21:41, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> I'll probably regret asking this, but how is that code relevant?
>
> Because DB seems to think that everyone follows coding guidelines. This
> is one example of many that doesn't. Not clear coding guidelines anyway.
David Brown said no such thing. Here's his statement to which you
responded:
You think you are the only person that writes coding guidelines?
What planet do you live on?
Learn to read.
[...]
>> Bad code exists. So what?
>
> That doesn't tell you anything?
Nothing that I didn't already know.
[...]
> Even if compilers allowed integer/pointer compares last century, there
> is no reason to still allow it now. That means having a hard error.
You know how to get a C compiler to treat it as a hard error.
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-02 00:50 +0100 |
| Message-ID | <87o95p5lps.fsf@bsb.me.uk> |
| In reply to | #142714 |
Keith Thompson <kst-u@mib.org> writes: > Bart <bc@freeuk.com> writes: >> On 01/04/2019 21:41, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> I'll probably regret asking this, but how is that code relevant? >> >> Because DB seems to think that everyone follows coding guidelines. This >> is one example of many that doesn't. Not clear coding guidelines anyway. > > David Brown said no such thing. Here's his statement to which you > responded: > > You think you are the only person that writes coding guidelines? > What planet do you live on? > > Learn to read. I think there has been a genuine misunderstanding on both sides. David Brown read "no one writes to precise guidelines" as "no one writes precise guidelines". Bart then misread David's remark as also being about writing to guidelines rather than writing the guidelines themselves. Reading with care on both sides would have helped, but it's easy to miss a word like "to" both when it's there and when you think it must be there. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-04-01 17:45 -0700 |
| Message-ID | <lnv9zx8cbl.fsf@kst-u.example.com> |
| In reply to | #142717 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Bart <bc@freeuk.com> writes:
>>> On 01/04/2019 21:41, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> I'll probably regret asking this, but how is that code relevant?
>>>
>>> Because DB seems to think that everyone follows coding guidelines. This
>>> is one example of many that doesn't. Not clear coding guidelines anyway.
>>
>> David Brown said no such thing. Here's his statement to which you
>> responded:
>>
>> You think you are the only person that writes coding guidelines?
>> What planet do you live on?
>>
>> Learn to read.
>
> I think there has been a genuine misunderstanding on both sides. David
> Brown read "no one writes to precise guidelines" as "no one writes
> precise guidelines". Bart then misread David's remark as also being
> about writing to guidelines rather than writing the guidelines
> themselves.
>
> Reading with care on both sides would have helped, but it's easy to miss
> a word like "to" both when it's there and when you think it must be
> there.
Sure, but even allowing for that, I don't see how David's statement
could reasonably be interpreted to imply that he thinks *everyone*
does anything.
Not everyone writes coding guidelines, but some do.
Not everyone writes *to* coding guidelines (i.e., writes code that
conforms to some guidelines) but some do.
Presenting a chunk of code that presumably was not written to conform
to any particular guidelines does not refute anything that anyone
actually said or implied.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-02 11:28 +0100 |
| Message-ID | <87ef6k66qo.fsf@bsb.me.uk> |
| In reply to | #142720 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Bart <bc@freeuk.com> writes: >>>> On 01/04/2019 21:41, Keith Thompson wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>>> I'll probably regret asking this, but how is that code relevant? >>>> >>>> Because DB seems to think that everyone follows coding guidelines. This >>>> is one example of many that doesn't. Not clear coding guidelines anyway. >>> >>> David Brown said no such thing. Here's his statement to which you >>> responded: >>> >>> You think you are the only person that writes coding guidelines? >>> What planet do you live on? >>> >>> Learn to read. >> >> I think there has been a genuine misunderstanding on both sides. David >> Brown read "no one writes to precise guidelines" as "no one writes >> precise guidelines". Bart then misread David's remark as also being >> about writing to guidelines rather than writing the guidelines >> themselves. >> >> Reading with care on both sides would have helped, but it's easy to miss >> a word like "to" both when it's there and when you think it must be >> there. > > Sure, but even allowing for that, I don't see how David's statement > could reasonably be interpreted to imply that he thinks *everyone* > does anything. > > Not everyone writes coding guidelines, but some do. > > Not everyone writes *to* coding guidelines (i.e., writes code that > conforms to some guidelines) but some do. > > Presenting a chunk of code that presumably was not written to conform > to any particular guidelines does not refute anything that anyone > actually said or implied. Agreed. I think made the same point in another post. Bart often argues by taking an extreme position and tries to justify it with inadequate examples: no one does this, look, here's an example. I was nit-picking a detail: telling one person to learning to read when two parties had misread, and no amount of learning can prevent occasional misreadings. However, David Brown tell me he did not misread the post so I am now baffled but both sides. I should have stayed out of it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 13:18 +0200 |
| Message-ID | <q7vgdf$oel$1@dont-email.me> |
| In reply to | #142729 |
On 02/04/2019 12:28, Ben Bacarisse wrote: > > Agreed. I think made the same point in another post. Bart often argues > by taking an extreme position and tries to justify it with inadequate > examples: no one does this, look, here's an example. > > I was nit-picking a detail: telling one person to learning to read when > two parties had misread, and no amount of learning can prevent > occasional misreadings. However, David Brown tell me he did not misread > the post so I am now baffled but both sides. I should have stayed out > of it. > First, I don't think telling Bart to "learn to read" will help because I think he read fine - his extreme position was intentional, AFAICS. And I expect it to have been the same regardless of whether I included a "to" or not, or how he read my post. Such "what if's" are, of course, always speculative. I didn't misread Bart's post (again, AFAICS). Nor did I miswrite my own post - but I could certainly have been clearer. I'm sorry if that left you baffled. I think it's fine that you made your comments - just because they were not quite correct does not mean they were not worth the try. If we all waited until we were absolutely sure of our facts, nothing would ever be posted. Still, I am not sure this topic is going anywhere productive. I hope we can assume Bart understands that many people write code based on careful guidelines - sometimes explicitly written coding standards, sometimes just by a knowledge of good coding practices, and often assisted by good tools and good use of said tools (appropriate warning flags, standards choices, etc.). And I hope that he understands that we all know some people write poor quality C code, and we all know that most C compilers are very lax in what they accept by default - and that none of us have said that we particularly like that, even if we understand why tools are written that way.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-04-02 19:15 +0000 |
| Message-ID | <slrnqa7d5s.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #142731 |
On Tue, 2019-04-02, David Brown wrote: > On 02/04/2019 12:28, Ben Bacarisse wrote: ... >> I should have stayed out of it. > ... > Still, I am not sure this topic is going anywhere productive. The Bart threads never did, and never will. It should be obvious to everybody by now. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-02 21:14 +0100 |
| Message-ID | <goPoE.1264542$RBa.61247@fx15.am4> |
| In reply to | #142745 |
On 02/04/2019 20:15, Jorgen Grahn wrote: > On Tue, 2019-04-02, David Brown wrote: >> On 02/04/2019 12:28, Ben Bacarisse wrote: > ... >>> I should have stayed out of it. >> > ... >> Still, I am not sure this topic is going anywhere productive. > > The Bart threads never did, and never will. It should be obvious to > everybody by now. This is NOT my sub-thread. Usually I don't comment on discussions I have no interest in or their relative productivity, but this like many descended into squabbling about someone's throwaway turn of phrase and what exactly may have been meant. My actual thread was about machine translating C into another language, which can be a rich source of discussion for those who are interested, some of which necessarily has to involve criticism of features that make that difficult. Clearly, most people here are not into anything like that, and they are free to ignore the thread. As are you. In other words, .
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-02 13:28 +0100 |
| Message-ID | <8736n06178.fsf@bsb.me.uk> |
| In reply to | #142729 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > I was nit-picking a detail: telling one person to learning to read when > two parties had misread, and no amount of learning can prevent > occasional misreadings. However, David Brown tell me he did not misread > the post so I am now baffled but both sides. I should have stayed out > of it. Oh my. More incorrect words than correct ones. Oh well, it's not an important post. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 10:49 +0200 |
| Message-ID | <q7v7n7$6ec$1@dont-email.me> |
| In reply to | #142717 |
On 02/04/2019 01:50, Ben Bacarisse wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Bart <bc@freeuk.com> writes: >>> On 01/04/2019 21:41, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> I'll probably regret asking this, but how is that code relevant? >>> >>> Because DB seems to think that everyone follows coding guidelines. This >>> is one example of many that doesn't. Not clear coding guidelines anyway. >> >> David Brown said no such thing. Here's his statement to which you >> responded: >> >> You think you are the only person that writes coding guidelines? >> What planet do you live on? >> >> Learn to read. > > I think there has been a genuine misunderstanding on both sides. David > Brown read "no one writes to precise guidelines" as "no one writes > precise guidelines". No, I did not read it that way - but I can see how it looks a bit like that. To my mind, the reason people write coding guidelines is because people code to those guidelines. MISRA, Google coding standards, JSF coding standards, and the countless company-specific coding standards that are written are rarely "write-only" documents. As I see it, writing a coding guideline is step one towards /using/ a coding guideline, and that second step was implied. However, I could have been more explicit. > Bart then misread David's remark as also being > about writing to guidelines rather than writing the guidelines > themselves. Bart claimed /no one/, except him alone, writes C code to precise guidelines. I said that other people make coding standards - implying that these are used by people writing C code. Bart intentionally misinterpreted that to mean I claimed that /all/ C code is well written, following precise guidelines. (I believe it was intentional - Bart is smart enough to understand what I wrote. Past history shows he is quite happy to make such misinterpretations if it gives him an excuse to complain about some C code.) So he posted a link to some bad C code to disprove this "claim". > > Reading with care on both sides would have helped, but it's easy to miss > a word like "to" both when it's there and when you think it must be > there. > I agree that I could have been clearer. But I don't think it would have hindered Bart from his misinterpretation.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-02 01:58 +0100 |
| Message-ID | <xsyoE.465108$0_.172284@fx19.am4> |
| In reply to | #142714 |
On 02/04/2019 00:25, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> That doesn't tell you anything?
>
> Nothing that I didn't already know.
So how do people end up writing programs that fail with all those
warnings when /you/ try and compile them>
> [...]
>
>> Even if compilers allowed integer/pointer compares last century, there
>> is no reason to still allow it now. That means having a hard error.
>
> You know how to get a C compiler to treat it as a hard error.
You keep saying that. But:
* All C compilers are different
* Not everyone knows how to do it
* Not everyone is aware that that is what needs to be done.
* Not everyone is bothered
* Not everyone tests their code across multiple compilers
* If a compiler is so lax, people might genuinely think that their C
code is fine
There must be a reason why there is so much poor code in the first
place, and I think it's a combination of the above.
And actually, you have a bit of a cheek to suggest that if I knew
everything there was to know about C compiler options, then somehow such
code would not exist.
IT IS NOT MY FAULT because I didn't write it and I wasn't there when it
was compiled.
This bit of code is from the Monads thread; it has a missing return value:
object seq( object p, object q ){
}
Some C compilers will report a warning, some will say nothing, others
will only say something depending on options.
Do you think that function would have survived like that if every C
compiler gave a fatal error? No. This is why there is some poor quality
software around.
(I actually only noticed when I translated the code to my language.
There this is a blatant error, at which point I checked back on the C
compilers as I hadn't noticed any problem.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-04-01 19:13 -0700 |
| Message-ID | <lnr2al889f.fsf@kst-u.example.com> |
| In reply to | #142721 |
Bart <bc@freeuk.com> writes:
> On 02/04/2019 00:25, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> That doesn't tell you anything?
>>
>> Nothing that I didn't already know.
>
> So how do people end up writing programs that fail with all those
> warnings when /you/ try and compile them>
I have no idea where that code (lisp.c) came from. I can only assume
that author wrote it in a different environment, using a different
compiler, than the one I use, likely with a pre-C99 compiler on 32-bit
system. The code appears to be non-portable and written in a very
questionable style. I can imagine that there might have been valid
reasons to write it that way, but I'm not sufficiently interested to
look into it.
>> [...]
>>
>>> Even if compilers allowed integer/pointer compares last century, there
>>> is no reason to still allow it now. That means having a hard error.
>>
>> You know how to get a C compiler to treat it as a hard error.
>
> You keep saying that. But:
>
> * All C compilers are different
> * Not everyone knows how to do it
> * Not everyone is aware that that is what needs to be done.
> * Not everyone is bothered
> * Not everyone tests their code across multiple compilers
> * If a compiler is so lax, people might genuinely think that their C
> code is fine
Yes, we both know all of this.
> There must be a reason why there is so much poor code in the first
> place, and I think it's a combination of the above.
Quite possibly.
> And actually, you have a bit of a cheek to suggest that if I knew
> everything there was to know about C compiler options, then somehow such
> code would not exist.
I did not suggest any such thing. I pointed out some problems with
the code, while wondering why you posted it. I didn't think you
had written it.
> IT IS NOT MY FAULT because I didn't write it and I wasn't there when it
> was compiled.
Fine, I never implied otherwise.
> This bit of code is from the Monads thread; it has a missing return value:
>
> object seq( object p, object q ){
> }
>
> Some C compilers will report a warning, some will say nothing, others
> will only say something depending on options.
>
> Do you think that function would have survived like that if every C
> compiler gave a fatal error? No. This is why there is some poor quality
> software around.
C does not require a diagnostic for a missing return statement in a
non-void function. (The behavior is undefined only if the caller uses
the returned value.) This is, I think, because a lot of pre-ANSI code
used int functions as a stand-in for void functions, which didn't exist
yet, and requiring a diagnostic would break old code.
If you think I'm saying that I *like* the fact that no diagnostic is
required, I invite you to re-read the previous paragraph as many times
as it takes for you to realize that I didn't say that.
I just took a look at that article. The seq function is never called.
I don't know what the intent was, but my guess is that both the body of
the function and any code that calls it is to be filled in later. If
you wanted to point out a problem with the seq() function, you could
have posted in that thread. The author might even have explained.
[...]
--
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-04-02 11:13 +0100 |
| Message-ID | <pBGoE.607872$M53.329707@fx31.am4> |
| In reply to | #142723 |
On 02/04/2019 03:13, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> Do you think that function would have survived like that if every C >> compiler gave a fatal error? No. This is why there is some poor quality >> software around. > > C does not require a diagnostic for a missing return statement in a > non-void function. (The behavior is undefined only if the caller uses > the returned value.) This is, I think, because a lot of pre-ANSI code > used int functions as a stand-in for void functions, which didn't exist > yet, and requiring a diagnostic would break old code. > > If you think I'm saying that I *like* the fact that no diagnostic is > required, I invite you to re-read the previous paragraph as many times > as it takes for you to realize that I didn't say that. The function is exported (ie. it has 'external linkage' and could be called from other modules (ie. other 'translation units')). So a compiler cannot know if it is called or not (or not easily; it would need to do a careful analysis as to whether any external functions are called that could then call seq()). If there is a problem with it, then it must be reported. If the reason for not reporting is because 40 years ago C had no procedures or subroutines, then surely that loophole should long have been fixed. Have /one/ legacy option for ancient code that you can't touch, and that's taken care of. > > I just took a look at that article. The seq function is never called. > I don't know what the intent was, but my guess is that both the body of > the function and any code that calls it is to be filled in later. > If > you wanted to point out a problem with the seq() function, you could > have posted in that thread. The author might even have explained. It would be off-topic and be seen as pedantic nit-picking, as I'd be looking at it as an example of C code, rather than whatever the hell it does (I've no idea). (BTW here's a version of that program that doesn't use designated initialisers: https://github.com/sal55/qx/blob/master/norah.c. I wanted to try translating it, but those initialisers weren't supported (also I couldn't see how that part worked), so removing them was necessary. However there were some other problems. Among them the use of "int", "Int" and "INT" in a target language that is case-insensitive...)
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web