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 | 15 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 4 of 4 — ← Prev page 1 2 3 [4]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 13:49 +0200 |
| Message-ID | <q7vi7m$2ui$1@dont-email.me> |
| In reply to | #142728 |
On 02/04/2019 12:13, Bart wrote: > 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. You have a critical misunderstanding here. The function "seq" may be used in a correct and safe manner. (In this example, of course, it appears that it simply has not be written - the published code is unfinished. Let's assume we are talking in general about a C function that has a declared return type, but does not always return a value.) A C compiler will assume that the programmer is writing valid code, unless it is /sure/ that the code is invalid. So the code containing the definition of "seq" must be accepted by a conforming C compiler (the compiler can warn, but not reject the code), since the function can be used correctly. Similarly, code that contains a call to "seq" but not a definition, must be accepted by the compiler since it is assumed the definition is suitable for that use. (A compiler with link-time optimisation, input of multiple C files, or other cross-file information that can see the call is used in an undefined manner, can reject the program with an error message.) So there is no problem that "must be reported". There is merely a /potential/ problem that a compiler /may/ warn about. (This is how C is defined. Don't take it as an endorsement of those rules - I'd rather C was stricter here, and that this definition of "seq" require a fatal error message.) > > 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 agree with that principle (though I don't think a single option here is enough). It irritates me that some things have been sitting on the C standards "obsolescent features" list for decades, without being properly banned. They haven't even made a level of "deprecated features which a compiler has to accept with a non-fatal diagnostic". The best that can be done is for each C programmer to say that he/she will not write such code or use such features, and use appropriate tools and settings to enforce a stricter C. (But there will be no agreement on exactly /how/ strict, or on many of the details.) >> >> 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). I don't know the context, but many programmers appreciate relevant feedback on code quality. I would expect here you'd get a reply that the function was unfinished - and the author should either finish it, remove it, or at least mark it as unfinished in some way. > > (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]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-04-02 05:15 -0700 |
| Message-ID | <51d749b9-1235-4e19-ab8d-e6708ef923a4@googlegroups.com> |
| In reply to | #142728 |
On Tuesday, 2 April 2019 11:13:51 UTC+1, Bart wrote:
> 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.
>
The reason is that C used to have implicit int. The other factor is that
assemblers had "calling conventions" which mean that a register was
reserved for the return value.
so
bad()
{
}
int foo()
{
int x = bad();
}
would be translated as "load x with contents of return register".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-02 14:50 +0100 |
| Message-ID | <_MJoE.1018328$Apg.984897@fx36.am4> |
| In reply to | #142734 |
On 02/04/2019 13:15, Malcolm McLean wrote:
> On Tuesday, 2 April 2019 11:13:51 UTC+1, Bart wrote:
>> 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.
>>
> The reason is that C used to have implicit int. The other factor is that
> assemblers had "calling conventions" which mean that a register was
> reserved for the return value.
>
> so
>
> bad()
> {
> }
>
> int foo()
> {
> int x = bad();
> }
>
> would be translated as "load x with contents of return register".
Yes, this is the sort of thing I have to do with assembly [not in C]: if
using inline assembly at the end of a function where a return value is
expected, then it is assumed that assembly code is properly setting up a
return value of the right type, and in the right place.
Otherwise it requires a hard return with an expression of a compatible
type to the return value.
So my comment about C being akin to ASM probably wasn't far off the mark.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 16:06 +0200 |
| Message-ID | <q7vqa0$j0l$1@dont-email.me> |
| In reply to | #142736 |
On 02/04/2019 15:50, Bart wrote:
> On 02/04/2019 13:15, Malcolm McLean wrote:
>> On Tuesday, 2 April 2019 11:13:51 UTC+1, Bart wrote:
>
>>> 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.
>>>
>> The reason is that C used to have implicit int. The other factor is that
>> assemblers had "calling conventions" which mean that a register was
>> reserved for the return value.
>>
>> so
>>
>> bad()
>> {
>> }
>>
>> int foo()
>> {
>> int x = bad();
>> }
>>
>> would be translated as "load x with contents of return register".
>
> Yes, this is the sort of thing I have to do with assembly [not in C]: if
> using inline assembly at the end of a function where a return value is
> expected, then it is assumed that assembly code is properly setting up a
> return value of the right type, and in the right place.
C has never specified any kind of inline assembly - that only exists as
compiler-specific extensions. And there are many variations on how it
is handled - many compilers I have used will /not/ make assumptions like
this.
In the early days of C - when "implicit int" was commonly used - I don't
think you would have found inline assemblers at all. You would write
any assembly code in separate assembly files, matching the calling
conventions used by the compiler.
>
> Otherwise it requires a hard return with an expression of a compatible
> type to the return value.
>
> So my comment about C being akin to ASM probably wasn't far off the mark.
>
Yes, it was off the mark - and this does not change it. You can't bring
up assembly in a random context and then use it to retroactively justify
wild claims made earlier about C and assembly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 16:05 +0200 |
| Message-ID | <q7vq7q$ikc$1@dont-email.me> |
| In reply to | #142734 |
On 02/04/2019 14:15, Malcolm McLean wrote:
> On Tuesday, 2 April 2019 11:13:51 UTC+1, Bart wrote:
>> 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.
>>
> The reason is that C used to have implicit int. The other factor is that
> assemblers had "calling conventions" which mean that a register was
> reserved for the return value.
>
> so
>
> bad()
> {
> }
>
> int foo()
> {
> int x = bad();
> }
>
> would be translated as "load x with contents of return register".
>
I can believe the "implicit int" argument.
I cannot see the "return register" argument at all. While the call to
"bad" may well translate roughly to "load x with the contents of the
return register", it is not the call that is of interest here - it is
the definition of "bad" that concerns us. Calling conventions do not
concern us, unless you are going to argue that:
/* implicit int return type */
bad() {
bad_bad();
}
was considered a reasonable alternative to:
/* implicit int return type */
bad() {
return bad_bad();
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-02 00:11 +0100 |
| Message-ID | <87zhp95nja.fsf@bsb.me.uk> |
| 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? (I've commented on what I think is DB's misreading of your words elsewhere.) > A planet where I encounter other people's code. Lots of it. Maybe you meant to say "not everyone" rather than "no one". You can't logically support a "no one does X" argument by showing some examples of people not doing X. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-02 10:35 +0200 |
| Message-ID | <q7v6s2$1sl$1@dont-email.me> |
| In reply to | #142697 |
On 01/04/2019 17: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 > I didn't say /everyone/ writes code according to coding standards or guidelines. I said that /you/ are not the only one who codes to "precise guidelines", as you claimed. If you are having trouble with this basic logic, I recommend watching "Monty Python and the Holy Grail". (Actually, I recommend watching it anyway - it's a great film.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-02 00:06 +0100 |
| Message-ID | <875zrx72cm.fsf@bsb.me.uk> |
| In reply to | #142677 |
David Brown <david.brown@hesbynett.no> writes: <cut> >> The trouble is that no one writes to precise guidelines like this, as I >> do <cut> > You think you are the only person that writes coding guidelines? What > planet do you live on? He said "writes /to/ precise guidelines" (emphasis mine) not "writes guidelines". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-31 21:36 +0100 |
| Message-ID | <877ece93xx.fsf@bsb.me.uk> |
| In reply to | #142636 |
Bart <bc@freeuk.com> writes: > 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. You know I don't agree. Expectations are formed from experience. > 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. Except you used the wrong words for the C part, and assumed the everyone knows what all the other terms you used mean. The world does not agree on what a module is, much less what an import or export really is. I'll accept that you intended to helpful in this case, but I don't think you were. The helpful approach is just to explain what C can do, not to try to match that against something you believe to be universal. >> 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. Sorry, maybe I was not clear. I meant that it looks like an odd way spend /any/ of your time. I am sure you do lots of other things, but you'd have /more/ time for them if you stopped posting confusing "explanations" about C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-31 16:32 +0100 |
| Message-ID | <87v9zz83fs.fsf@bsb.me.uk> |
| In reply to | #142632 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>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.
>
> I try to say that it's a property of /declarations/.
> For example,
It's certainly related to the declaration but it's finer-grained than
that. In
int a = 1, b = a + 1;
the scope of 'a' starts mid-declaration, jasy after the declarator. In
enum {
a = 1,
b = a + 1
};
the scope of 'a' again starts mid declaration. There are lots of other
examples. But you are correct
> #include <stdio.h>
> int n = 2; int main( void ){ int n = 7; printf( "%d", n ); }
>
> 'What is "the scope of the name »n«" above?'
>
> This question possibly cannot be answered directly, if a
> name is understood to be defined by its characters only.
Id' same the name 'n' has two scopes. The question should be: what are
the scopes of the name 'n' above? We often just say "scope" and accept
that sometimes there are more than one.
> 'What is "the scope of »int n = 2;«" above?'
> 'What is "the scope of »int n = 7;«" above?'
>
> These questions possibly can be answered directly.
I prefer to go the other way. A name has one or more scopes. Point to
an occurrence of the name and it is either in one of them or outside all
of them. If it is in scope, you can find out about the name but finding
where that (possible nested) scope starts.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-30 00:37 +0000 |
| Message-ID | <ITynE.955449$RBa.465765@fx15.am4> |
| In reply to | #142604 |
On 29/03/2019 20:02, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > You do don't you? It's a shame it is not popular, but you at least need > not complain about C ever again. You're right. I stopped all my language development at the end of last year. But then started one new project in February as it was an intriguing new language, something different. However, sooner or later C starts getting involved and it always seems to suck me in. I think it's better to look forwards to new stuff, than back to an ancient 1970s language that I don't respect, and which always manages to irritate me. So I will drop all my C-related projects. Everyone, please ignore the thread.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-30 01:00 +0000 |
| Message-ID | <87zhpd9nwb.fsf@bsb.me.uk> |
| In reply to | #142610 |
Bart <bc@freeuk.com> writes: > I stopped all my language development at the end of last year. But > then started one new project in February as it was an intriguing new > language, something different. > > However, sooner or later C starts getting involved and it always seems > to suck me in. That's not healthy. These things should be fun. The usual answer is to bootstrap your language/languages. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-03-30 03:37 -0700 |
| Message-ID | <db4cf2d1-2405-4543-84da-fa52787fa531@googlegroups.com> |
| In reply to | #142610 |
W dniu sobota, 30 marca 2019 01:38:10 UTC+1 użytkownik Bart napisał: > On 29/03/2019 20:02, Ben Bacarisse wrote: > > Bart <bc@freeuk.com> writes: > > > You do don't you? It's a shame it is not popular, but you at least need > > not complain about C ever again. > > You're right. > > I stopped all my language development at the end of last year. But then > started one new project in February as it was an intriguing new > language, something different. > > However, sooner or later C starts getting involved and it always seems > to suck me in. I think it's better to look forwards to new stuff, than > back to an ancient 1970s language that I don't respect, and which always > manages to irritate me. > > So I will drop all my C-related projects. > > Everyone, please ignore the thread. i dont think people want you to stop posting here, or even stop posting about some topics this is more about you angage long sorta-figts sorta-discussions on the base that you got different opinion.. if you got different opinion state it once, twice, 5 times, maybe max 10 times and that should be enough, stating it unlimited times its like killing time, your own time** and also the time of thise who engage into it (as i said it is not even so bad it is like 15 posts, but when it goes to 150 o 1500 posts on that you got different opinion it goes sorta nonsense *** ** i sourta understand you as some years ago (like 2003?) i treated programming groups like only or main chanell of internet life) later i discovered that dedicated chats (full of metal-listeners, imbeciles, 19 year old girls working in british hotels (poland), also young progammers across the world etc) are much more fun in that respect and are real good when it comes to entertainment when you rest when coding too - and usenet i left for much deeper focused c discussion .. there is a problem with chats hoevver in thet times they are not much popular i dont now to much active ones and that is very bad besides i got constant problem with you as you are not so bad as user but also you can put me down at times with not much wise remarks (this means i think that i think youre not so bad but also discusions wih you are a bit tiring, tiremaking sometimes ;c ) *** hovever i could add though its nonsensical i can add that its is good to remember that people can see things in more dpth, i so much often goe shallow and practical last years that i feel like i would deleting/crossing my own brain - vut that is deeper story (still i think going deep in thinking is good, going nonsense is probably separate and bad (im too shallow for it) (im a great sinner of shallownes im afraid, that s the other story) [nin ghosts i-iv]
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-03-30 06:15 -0700 |
| Message-ID | <86ed3094-4fb0-4371-89c0-a407eb419250@googlegroups.com> |
| In reply to | #142614 |
W dniu sobota, 30 marca 2019 11:37:45 UTC+1 użytkownik fir napisał: > W dniu sobota, 30 marca 2019 01:38:10 UTC+1 użytkownik Bart napisał: > > On 29/03/2019 20:02, Ben Bacarisse wrote: > > > Bart <bc@freeuk.com> writes: > > > > > You do don't you? It's a shame it is not popular, but you at least need > > > not complain about C ever again. > > > > You're right. > > > > I stopped all my language development at the end of last year. But then > > started one new project in February as it was an intriguing new > > language, something different. > > > > However, sooner or later C starts getting involved and it always seems > > to suck me in. I think it's better to look forwards to new stuff, than > > back to an ancient 1970s language that I don't respect, and which always > > manages to irritate me. > > > > So I will drop all my C-related projects. > > > > Everyone, please ignore the thread. > > i dont think people want you to stop posting here, or even stop posting about some topics > > this is more about you angage long sorta-figts sorta-discussions on the base that you got different opinion.. if you got different opinion state it once, twice, 5 times, maybe max 10 times and that should be enough, stating it unlimited times its like killing time, your own time** and also the time of thise who engage into it (as i said it is not even so bad it is like 15 posts, but when it goes to 150 o 1500 posts on that you got different opinion it goes sorta nonsense *** > > ** i sourta understand you as some years ago (like 2003?) i treated programming groups like only or main chanell of internet life) later i discovered that dedicated chats (full of metal-listeners, imbeciles, 19 year old girls working in british hotels (poland), also young progammers across the world etc) are much more fun in that respect and are real good when it comes to entertainment when you rest when coding too - and usenet i left for much deeper focused c discussion .. > > there is a problem with chats hoevver in thet times they are not much popular i dont now to much active ones and that is very bad > > besides i got constant problem with you as you are not so bad as user but also you can put me down at times with not much wise remarks (this means i think that i think youre not so bad but also discusions wih you are a bit tiring, tiremaking sometimes ;c ) > > *** hovever i could add though its nonsensical i can add that its is good to remember that people can see things in more dpth, i so much often goe shallow and practical last years that i feel like i would deleting/crossing my own brain - vut that is deeper story (still i think going deep in thinking is good, going nonsense is probably separate and bad (im too shallow for it) (im a great sinner of shallownes im afraid, that s the other story) [nin ghosts i-iv] this last accapite (paragraph) a added beceuse in my guess/understanding it is like youre sorta thinking in more depth than average user (which is tio reckognized by some signs), even probably more deep than me in last years (i sued to think deep beck then but later gone much more practical and shallow - and i tall it to be fair, i dont like to be unfair..[and i always find it as a value as it provokes me to remember that diper thinking is possible, een if i had no time to it..and i faind it as a real value as i said] but in my reckognition you alos make sorta nonsensical threads based on repeating and also sometimes discussing with you is more than tiremaking, [and i would really not want to much times as i know it ends bad way ;c ]..there is also a problem of what i called 'big distraction' if this group would put to discussing more real codes it would be of much more use to anybody in my opinion
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-03-29 07:49 -0700 |
| Message-ID | <73e06293-bd82-4b0d-9444-5b83be9dabd5@googlegroups.com> |
| In reply to | #142578 |
On Thursday, March 28, 2019 at 10:34:20 PM UTC-4, Bart wrote: ... > ... I mean, what does > this mean in a program at module scope: > > int abc; > ... > int abc; > ... > int abc; I don't know - C doesn't have anything called "module scope". If your language has something called "module scope", you should know how your language handles such definitions. In C, at file scope, those would be multiple tentative definitions (6.9.2p2). > Is abc defined in this module or not? If those occur at file scope in C code, yes. There's only two options. If there's a subsequent external definition of abc, that will be the definition, and the tentative definitions will be merged with it. If there's no subsequent external definition, then the tentative definitions are treated as equivalent to "int abc=0;". Either way, there will be a definition for abc in this module. > If it is, then it really needs to > be initialised. It will be - if there's a following external definition, it will explicitly initialize it. If there isn't, it's implicitly initialized with zero. > In practice, if N modules contain those same > uninitialised declarations, They are not uninitialized, so that's not an issue. However, since they have external linkage, if N > 1 then it's undefined behavior (6.9p2). If abc is ever used in an expression, it's also undefined behavior if N < 1. > one implementation might assign ownership of > the variable to one. Another might define multiple copies. True - those are two of the ways that different implmentations handle such things - there's several other ways that are used as well. If the multiple definitions have different types, some implementations treat it as if all of those types were members of an anonymous union. Other implementations set aside enough space for the first (or last) such definition they run into during linking, and make all of those definitions refer to that same memory location, even if they have types too large to fit in the space allocated for the identifier. There's also variations in terms of which it is initialized if the definitions are not all initialized the same way. The existence of different implementations of C that handled multiple definitions differently was the reason why the committee decided to make the behavior undefined. > What a mess! ... At the time when the decision was made, it was commonplace for the only linker on a given platform to be platform-specific and language- independent, not under the control of the same people who were producing C compilers. The C committee was in no position to insist that many different linkers on many different platforms all take the same approach to multiple definitions. So while it is definitely a mess, it's not C's mess. And if you simply avoid providing multiple definitions, it all works quite nicely, regardless of which linker you're using. > ... And if I type: > static int abc; > extern int abc; > > only one compiler picks up on it. According to 6.2.2p4, the extern declaration leaves abc's linkage unchanged. The "one compiler" that "picks up on it" could reasonably issue a warning about such code, but is not allowed to reject it. I'm not sure of the reason for this rule, but it's clearly stated. > But reverse the order, and now it's an > error. In this case, for the "extern" declaration, "If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage." (6.2.2p4). "If the declaration of a file scope identifier for an object or a function contains the storage class specifier static, the identifier has internal linkage." (6.2.2p3). "If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined." (6.2.2p7). > ... What > exactly is the 700 pages of Standard about if it doesn't even pin down > such basics? It does pin down such basics, per the citations given above.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web