Am I the only one that find it weird that /LIST and /MAP are default
when building in batch?

Arne

> Am I the only one [...]

You might be. I might not have done it that way, but it's documented
behavior, and not a recent change.

I dimly recall being surprised (many years ago) by the loss of free
disk space when I used SUBMIT instead of @ to build some non-trivial
project. Since then, I've tried to remember to put explicit /NOLIST and
/NOMAP options into my builders.

On 2023-10-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
> Am I the only one that find it weird that /LIST and /MAP are default
> when building in batch?
>

Not really, given the batch/non-interactive processing model I understand
was common elsewhere when this was implemented.

I suspect the next stage would have been to print the listings from
the batch job for archiving.

As Steven points out, the default with the SUBMIT command is to print
the job output.

I do vaguely remember however having an impression of finding the
behaviour antiquated even when I first encountered it.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-10-20, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2023-10-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Am I the only one that find it weird that /LIST and /MAP are default
>> when building in batch?
>>
>
> Not really, given the batch/non-interactive processing model I understand
> was common elsewhere when this was implemented.
>
> I suspect the next stage would have been to print the listings from
> the batch job for archiving.
>
> As Steven points out, the default with the SUBMIT command is to print
> the job output.
>

Sorry, Steven didn't say that. He was just talking about the compilers.
However, the fact SUBMIT prints the job output by default speaks to the
culture at the time these compiler options were being implemented.

> I do vaguely remember however having an impression of finding the
> behaviour antiquated even when I first encountered it.
>

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/20/2023 2:00 AM, Steven Schweda wrote:
>> Am I the only one [...]
>
> You might be. I might not have done it that way, but it's documented
> behavior, and not a recent change.

I suspect that is has always been there like since VMS 1.0.

> I dimly recall being surprised (many years ago) by the loss of free
> disk space when I used SUBMIT instead of @ to build some non-trivial
> project. Since then, I've tried to remember to put explicit /NOLIST and
> /NOMAP options into my builders.

It is not difficult to work around.

But does it make sense to change behavior when changing from
interactive to batch?

And does this specific behavior change make sense? My expectations
would be that an interactive build can be early development and
errors requiring LIS or MAP could be present while a batch build
is when it is known to work and LIS and MAP are not needed.

But again - I could be wrong.

Arne

On 10/20/2023 8:37 AM, Simon Clubley wrote:
> On 2023-10-20, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2023-10-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> Am I the only one that find it weird that /LIST and /MAP are default
>>> when building in batch?
>>>
>>
>> Not really, given the batch/non-interactive processing model I understand
>> was common elsewhere when this was implemented.
>>
>> I suspect the next stage would have been to print the listings from
>> the batch job for archiving.
>>
>> As Steven points out, the default with the SUBMIT command is to print
>> the job output.
>
> Sorry, Steven didn't say that. He was just talking about the compilers.
> However, the fact SUBMIT prints the job output by default speaks to the
> culture at the time these compiler options were being implemented.

(we discussed that some months ago)

Yes. It is all old times.

And backwards compatibility is always a concern.

But some changes like making /NOPRINT default for SUBMIT
and keeping /NOLIST and /NOMAP default for batch seems
like not so bad breaking changes to me.

Arne

On 10/20/2023 9:33 AM, Arne Vajhøj wrote:
> On 10/20/2023 8:37 AM, Simon Clubley wrote:
>> On 2023-10-20, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> wrote:
>>> On 2023-10-19, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> Am I the only one that find it weird that /LIST and /MAP are default
>>>> when building in batch?
>>>>
>>>
>>> Not really, given the batch/non-interactive processing model I understand
>>> was common elsewhere when this was implemented.
>>>
>>> I suspect the next stage would have been to print the listings from
>>> the batch job for archiving.
>>>
>>> As Steven points out, the default with the SUBMIT command is to print
>>> the job output.
>>
>> Sorry, Steven didn't say that. He was just talking about the compilers.
>> However, the fact SUBMIT prints the job output by default speaks to the
>> culture at the time these compiler options were being implemented.
>
> (we discussed that some months ago)
>
> Yes. It is all old times.
>
> And backwards compatibility is always a concern.
>
> But some changes like making /NOPRINT default for SUBMIT
> and keeping /NOLIST and /NOMAP default for batch seems
> like not so bad breaking changes to me.
>
> Arne
>
>

This is actually a bit amusing ...

Ya all seem to think I'm sloppy for not declaring variables, but, then ya all
seem to accept defaults elsewhere, when specifying what you actually want isn't
much different than declaring variables.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/20/2023 5:32 PM, Dave Froble wrote:
> On 10/20/2023 9:33 AM, Arne Vajhøj wrote:
>> On 10/20/2023 8:37 AM, Simon Clubley wrote:
>>> On 2023-10-20, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>>> wrote:
>>>> As Steven points out, the default with the SUBMIT command is to print
>>>> the job output.
>>>
>>> Sorry, Steven didn't say that. He was just talking about the compilers.
>>> However, the fact SUBMIT prints the job output by default speaks to the
>>> culture at the time these compiler options were being implemented.
>>
>> (we discussed that some months ago)
>>
>> Yes. It is all old times.
>>
>> And backwards compatibility is always a concern.
>>
>> But some changes like making /NOPRINT default for SUBMIT
>> and keeping /NOLIST and /NOMAP default for batch seems
>> like not so bad breaking changes to me.
>
> This is actually a bit amusing ...
>
> Ya all seem to think I'm sloppy for not declaring variables, but, then
> ya all seem to accept defaults elsewhere, when specifying what you
> actually want isn't much different than declaring variables.
>
> :-)

:-)

Or maybe build scripts, web pages, ERP applications and
embedded controllers managing an airplanes rudders have
different requirements.

But note that even though type by suffix (Basic) and
prefix (Fortran) is totally out of fashion today, then
no explicit specification on type is very much in
fashion. The majority of code written today is in
languages with either dynamic typing or in languages
using type inference.

Arne

On Friday, October 20, 2023 at 4:34:45 PM UTC-7, Arne Vajhøj wrote:

(snip)

> Or maybe build scripts, web pages, ERP applications and
> embedded controllers managing an airplanes rudders have
> different requirements.

Many Unix programs work differently when stdout is a terminal instead
of a file. That often makes sense. Also, many people are used to them
working that way, and know what to do about it.

Seems that many should also know how VMS BATCH works, and
know what to do about it.

> But note that even though type by suffix (Basic) and
> prefix (Fortran) is totally out of fashion today, then
> no explicit specification on type is very much in
> fashion. The majority of code written today is in
> languages with either dynamic typing or in languages
> using type inference.

While using default typing in Fortran is discourage, and
even though it used to be true in C, isn't any more, it does
seem that many like to use i, j, k, l, m, and n for the
first letter of integer variables in C and other languages,
following the Fortran convention of over 60 years ago.

On 10/21/2023 1:45 AM, gah4 wrote:
> On Friday, October 20, 2023 at 4:34:45 PM UTC-7, Arne Vajhøj wrote:
>
> (snip)
>
>> Or maybe build scripts, web pages, ERP applications and
>> embedded controllers managing an airplanes rudders have
>> different requirements.
>
> Many Unix programs work differently when stdout is a terminal instead
> of a file. That often makes sense. Also, many people are used to them
> working that way, and know what to do about it.
>
> Seems that many should also know how VMS BATCH works, and
> know what to do about it.
>
>> But note that even though type by suffix (Basic) and
>> prefix (Fortran) is totally out of fashion today, then
>> no explicit specification on type is very much in
>> fashion. The majority of code written today is in
>> languages with either dynamic typing or in languages
>> using type inference.
>
> While using default typing in Fortran is discourage and
And then there were those of us who ever believed in default
anything.

> even though it used to be true in C, isn't any more, it does

When did C ever have "default typing" like Fortran?

> seem that many like to use i, j, k, l, m, and n for the
> first letter of integer variables in C and other languages,
> following the Fortran convention of over 60 years ago.

I have also never seen this. Except for entries in the
obfuscated C contest the norm for C program, in my experience,
has always been to use meaningful names for variables and not
some old convention from a different language.

bill

>
>
>
>
>

On 10/21/2023 8:45 AM, bill wrote:
> On 10/21/2023 1:45 AM, gah4 wrote:
>> On Friday, October 20, 2023 at 4:34:45 PM UTC-7, Arne Vajhøj wrote:
>>> But note that even though type by suffix (Basic) and
>>> prefix (Fortran) is totally out of fashion today, then
>>> no explicit specification on type is very much in
>>> fashion. The majority of code written today is in
>>> languages with either dynamic typing or in languages
>>> using type inference.
>>
>> While using default typing in Fortran is discourage and
> And then there were those of us who ever believed in default
> anything.
>
>> even though it used to be true in C, isn't any more, it does
>
> When did C ever have "default typing" like Fortran?

I don't think C ever allowed undeclared variables
giving them a type.

C does default return type of functions to int. It is
horrible, but it does.

>
>> seem that many like to use i, j, k, l, m, and n for the
>> first letter of integer variables in C and other languages,
>> following the Fortran convention of over 60 years ago.
>
> I have also never seen this.  Except for entries in the
> obfuscated C contest the norm for C program, in my experience,
> has always been to use meaningful names for variables and not
> some old convention from a different language.

Hmmm.

Are you telling me that you have never seen i, j, ...
used as variable in a for loop in C?

Arne

On 10/21/2023 1:45 AM, gah4 wrote:
> Many Unix programs work differently when stdout is a terminal instead
> of a file. That often makes sense. Also, many people are used to them
> working that way, and know what to do about it.

If being a terminal activates some fancy color highlightning
then fine.

I still don't like changing behavior.

It is not that hard to add /NOLIST and /NOMAP but it
just irritates me.

> Seems that many should also know how VMS BATCH works, and
> know what to do about it.

Not easy to change anything.

https://xkcd.com/1172/

Arne

On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
> On 10/21/2023 8:45 AM, bill wrote:
>> On 10/21/2023 1:45 AM, gah4 wrote:
>>> On Friday, October 20, 2023 at 4:34:45 PM UTC-7, Arne Vajhøj wrote:
>>>> But note that even though type by suffix (Basic) and
>>>> prefix (Fortran) is totally out of fashion today, then
>>>> no explicit specification on type is very much in
>>>> fashion. The majority of code written today is in
>>>> languages with either dynamic typing or in languages
>>>> using type inference.
>>>
>>> While using default typing in Fortran is discourage and
>> And then there were those of us who ever believed in default
>> anything.
>>
>>> even though it used to be true in C, isn't any more, it does
>>
>> When did C ever have "default typing" like Fortran?
>
> I don't think C ever allowed undeclared variables
> giving them a type.
>
> C does default return type of functions to int. It is
> horrible, but it does.
>
>>
>>> seem that many like to use i, j, k, l, m, and n for the
>>> first letter of integer variables in C and other languages,
>>> following the Fortran convention of over 60 years ago.
>>
>> I have also never seen this.  Except for entries in the
>> obfuscated C contest the norm for C program, in my experience,
>> has always been to use meaningful names for variables and not
>> some old convention from a different language.
>
> Hmmm.
>
> Are you telling me that you have never seen i, j, ...
> used as variable in a for loop in C?
>

Probably, but if someone is going to use a single letter variable
for a loop index more likely would be a, b, x, y, z. But I'm sure
an i would show up more for it being the first letter of the word
index than any influence from Fortran. Can't say I have ever seen
j used.

bill

On Saturday, October 21, 2023 at 4:40:02 PM UTC+1, bill wrote:
> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
> > On 10/21/2023 8:45 AM, bill wrote:
> >> On 10/21/2023 1:45 AM, gah4 wrote:
> >>> On Friday, October 20, 2023 at 4:34:45 PM UTC-7, Arne Vajhøj wrote:
> >>>> But note that even though type by suffix (Basic) and
> >>>> prefix (Fortran) is totally out of fashion today, then
> >>>> no explicit specification on type is very much in
> >>>> fashion. The majority of code written today is in
> >>>> languages with either dynamic typing or in languages
> >>>> using type inference.
> >>>
> >>> While using default typing in Fortran is discourage and
> >> And then there were those of us who ever believed in default
> >> anything.
> >>
> >>> even though it used to be true in C, isn't any more, it does
> >>
> >> When did C ever have "default typing" like Fortran?
> >
> > I don't think C ever allowed undeclared variables
> > giving them a type.
> >
> > C does default return type of functions to int. It is
> > horrible, but it does.
> >
> >>
> >>> seem that many like to use i, j, k, l, m, and n for the
> >>> first letter of integer variables in C and other languages,
> >>> following the Fortran convention of over 60 years ago.
> >>
> >> I have also never seen this. Except for entries in the
> >> obfuscated C contest the norm for C program, in my experience,
> >> has always been to use meaningful names for variables and not
> >> some old convention from a different language.
> >
> > Hmmm.
> >
> > Are you telling me that you have never seen i, j, ...
> > used as variable in a for loop in C?
> >
> Probably, but if someone is going to use a single letter variable
> for a loop index more likely would be a, b, x, y, z. But I'm sure
> an i would show up more for it being the first letter of the word
> index than any influence from Fortran. Can't say I have ever seen
> j used.
>
> bill

Well I've certainly seen i, j and k used as successive loop indices in FORTRAN, C and AWK. I think I've also seen them used in PERL but can't be 100% sure. I know such things used to drive the instructors mad on my COBOL course 40-odd years ago!

Martin

On 10/21/2023 11:39 AM, bill wrote:
> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>> On 10/21/2023 8:45 AM, bill wrote:
>>> On 10/21/2023 1:45 AM, gah4 wrote:
>>>> seem that many like to use i, j, k, l, m, and n for the
>>>> first letter of integer variables in C and other languages,
>>>> following the Fortran convention of over 60 years ago.
>>>
>>> I have also never seen this.  Except for entries in the
>>> obfuscated C contest the norm for C program, in my experience,
>>> has always been to use meaningful names for variables and not
>>> some old convention from a different language.
>>
>> Hmmm.
>>
>> Are you telling me that you have never seen i, j, ...
>> used as variable in a for loop in C?
>
> Probably, but if someone is going to use a single letter variable
> for a loop index more likely would be a, b, x, y, z.  But I'm sure
> an i would show up more for it being the first letter of the word
> index than any influence from Fortran.  Can't say I have ever seen
> j used.

My impression is that:

for(i = 0, ...
for(int i = 0, ...

outnumber:

for(a = 0, ...
for(int a = 0, ...

by a factor 1000.

:-)

Arne

On 10/21/2023 10:58 AM, Arne Vajhøj wrote:
> On 10/21/2023 1:45 AM, gah4 wrote:
>> Many Unix programs work differently when stdout is a terminal instead
>> of a file. That often makes sense. Also, many people are used to them
>> working that way, and know what to do about it.
>
> If being a terminal activates some fancy color highlightning
> then fine.
>
> I still don't like changing behavior.
>
> It is not that hard to add /NOLIST and /NOMAP but it
> just irritates me.

:-)

Just as declaring temp variables for such as loop counters and such irritates
me. We all have our personal crosses to bear.

I also have such as NOLOG, NOLIST, NOMAP, and such in all my build procedures.
If you want something, you got to specify it. Isn't that what programming is
all about?

I remember one request at a DECUS event. "I wish DCL would do what I want, not
what I typed." Amusing ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/21/2023 12:12 PM, Arne Vajhøj wrote:
> On 10/21/2023 11:39 AM, bill wrote:
>> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>>> On 10/21/2023 8:45 AM, bill wrote:
>>>> On 10/21/2023 1:45 AM, gah4 wrote:
>>>>> seem that many like to use i, j, k, l, m, and n for the
>>>>> first letter of integer variables in C and other languages,
>>>>> following the Fortran convention of over 60 years ago.
>>>>
>>>> I have also never seen this.  Except for entries in the
>>>> obfuscated C contest the norm for C program, in my experience,
>>>> has always been to use meaningful names for variables and not
>>>> some old convention from a different language.
>>>
>>> Hmmm.
>>>
>>> Are you telling me that you have never seen i, j, ...
>>> used as variable in a for loop in C?
>>
>> Probably, but if someone is going to use a single letter variable
>> for a loop index more likely would be a, b, x, y, z.  But I'm sure
>> an i would show up more for it being the first letter of the word
>> index than any influence from Fortran.  Can't say I have ever seen
>> j used.
>
> My impression is that:
>
> for(i = 0, ...
> for(int i = 0, ...
>
> outnumber:
>
> for(a = 0, ...
> for(int a = 0, ...
>
> by a factor 1000.
>
> :-)

The gentlemen K & R also use i and j in the C book.

And the gentleman Stroustrup also use i in the C++ book.

Arne

On 10/21/2023 12:22 PM, Dave Froble wrote:
> Just as declaring temp variables for such as loop counters and such
> irritates me.  We all have our personal crosses to bear.

Today that is typical handled via type inference.

Kotlin example:

fun main() {
for(i in 1..3) {
println("${i::class.simpleName} : ${i}")
}
for(c in 'a'..'c') {
println("${c::class.simpleName} : ${c}")
}
}

output:

Int : 1
Int : 2
Int : 3
Char : a
Char : b
Char : c

Arne

On 10/21/2023 12:22 PM, Dave Froble wrote:
> Just as declaring temp variables for such as loop counters and such
> irritates me.  We all have our personal crosses to bear.

Today that is typical handled via type inference.

Kotlin example:

fun main() {
for(i in 1..3) {
println("${i::class.simpleName} : ${i}")
}
for(c in 'a'..'c') {
println("${c::class.simpleName} : ${c}")
}
}

output:

Int : 1
Int : 2
Int : 3
Char : a
Char : b
Char : c

Arne

On 10/21/2023 2:26 PM, Arne Vajhøj wrote:
> On 10/21/2023 12:22 PM, Dave Froble wrote:
>> Just as declaring temp variables for such as loop counters and such
>> irritates me.  We all have our personal crosses to bear.
>
> Today that is typical handled via type inference.
>
> Kotlin example:
>
> fun main() {
>     for(i in 1..3) {
>         println("${i::class.simpleName} : ${i}")
>     }
>     for(c in 'a'..'c') {
>         println("${c::class.simpleName} : ${c}")
>     }
> }
>
> output:
>
> Int : 1
> Int : 2
> Int : 3
> Char : a
> Char : b
> Char : c

Sorry for the duplicate post.

And for the record - it is possible to specify type:

fun main() {
for(i: Int in 1..3) {
println("${i::class.simpleName} : ${i}")
}
for(c: Char in 'a'..'c') {
println("${c::class.simpleName} : ${c}")
}
}

But nobody does that.

Arne

On 2023-10-21 17:39, bill wrote:
> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>> Are you telling me that you have never seen i, j, ...
>> used as variable in a for loop in C?
>>
>
> Probably, but if someone is going to use a single letter variable
> for a loop index more likely would be a, b, x, y, z.  But I'm sure
> an i would show up more for it being the first letter of the word
> index than any influence from Fortran.  Can't say I have ever seen
> j used.

i and j as loop variables probably beats all other letters combined.

If you haven't seen that, then I really wonder what code you have looked at.

Johnny

On 10/21/2023 5:24 PM, Johnny Billquist wrote:
> On 2023-10-21 17:39, bill wrote:
>> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>>> Are you telling me that you have never seen i, j, ...
>>> used as variable in a for loop in C?
>>>
>>
>> Probably, but if someone is going to use a single letter variable
>> for a loop index more likely would be a, b, x, y, z.  But I'm sure
>> an i would show up more for it being the first letter of the word
>> index than any influence from Fortran.  Can't say I have ever seen
>> j used.
>
> i and j as loop variables probably beats all other letters combined.
>
> If you haven't seen that, then I really wonder what code you have looked
> at.
>

My early days doing production programming (In COBOL, Fortran, Pascal, C
and a lot of different assemblers) was all done in an environment with
very strict programming standards. Probably explains a lot about my
style and why I don't have problems with things like over-runs and
bounds violations. :-)

bill

On 10/21/2023 1:48 PM, Arne Vajhøj wrote:
> On 10/21/2023 12:12 PM, Arne Vajhøj wrote:
>> On 10/21/2023 11:39 AM, bill wrote:
>>> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>>>> On 10/21/2023 8:45 AM, bill wrote:
>>>>> On 10/21/2023 1:45 AM, gah4 wrote:
>>>>>> seem that many like to use i, j, k, l, m, and n for the
>>>>>> first letter of integer variables in C and other languages,
>>>>>> following the Fortran convention of over 60 years ago.
>>>>>
>>>>> I have also never seen this.  Except for entries in the
>>>>> obfuscated C contest the norm for C program, in my experience,
>>>>> has always been to use meaningful names for variables and not
>>>>> some old convention from a different language.
>>>>
>>>> Hmmm.
>>>>
>>>> Are you telling me that you have never seen i, j, ...
>>>> used as variable in a for loop in C?
>>>
>>> Probably, but if someone is going to use a single letter variable
>>> for a loop index more likely would be a, b, x, y, z.  But I'm sure
>>> an i would show up more for it being the first letter of the word
>>> index than any influence from Fortran.  Can't say I have ever seen
>>> j used.
>>
>> My impression is that:
>>
>> for(i = 0, ...
>> for(int i = 0, ...
>>
>> outnumber:
>>
>> for(a = 0, ...
>> for(int a = 0, ...
>>
>> by a factor 1000.
>>
>> :-)
>
> The gentlemen K & R also use i and j in the C book.
>
> And the gentleman Stroustrup also use i in the C++ book.

What can I say. The places where I worked frowned on (read
that as forbid) single letter variables for any use at any
time. They also frowned on the concept of IMPLICIT. Define
everything and explain it in comments and the documentation.

bill

On 10/21/2023 7:22 PM, bill wrote:
> On 10/21/2023 5:24 PM, Johnny Billquist wrote:
>> On 2023-10-21 17:39, bill wrote:
>>> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>>>> Are you telling me that you have never seen i, j, ...
>>>> used as variable in a for loop in C?
>>>>
>>>
>>> Probably, but if someone is going to use a single letter variable
>>> for a loop index more likely would be a, b, x, y, z.  But I'm sure
>>> an i would show up more for it being the first letter of the word
>>> index than any influence from Fortran.  Can't say I have ever seen
>>> j used.
>>
>> i and j as loop variables probably beats all other letters combined.
>>
>> If you haven't seen that, then I really wonder what code you have
>> looked at.
>>
>
> My early days doing production programming (In COBOL, Fortran, Pascal, C
> and a lot of different assemblers) was all done in an environment with
> very strict programming standards.  Probably explains a lot about my
> style and why I don't have problems with things like over-runs and
> bounds violations.  :-)

C coding standards often allow or even encourage i and j.

A few random examples:

Linux kernel coding style:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

<quote>
LOCAL variable names should be short, and to the point. If you have some
random integer loop counter, it should probably be called i. Calling it
loop_counter is non-productive, if there is no chance of it being
mis-understood. Similarly, tmp can be just about any type of variable
that is used to hold a temporary value.
</quote>

FreeBSD style guide:

https://man.freebsd.org/cgi/man.cgi?style(9)

<quote>
A for loop may declare and initialize its counting variable.

for (int i = 0; i < 15; i++) {
</quote>

Gnome coding style:

https://developer.gnome.org/documentation/guidelines/programming/coding-style.html

<quote>
for (i = 0; i < num_elements; i++) {
</quote>

Arne

On 10/21/2023 7:44 PM, Arne Vajhøj wrote:
> On 10/21/2023 7:22 PM, bill wrote:
>> On 10/21/2023 5:24 PM, Johnny Billquist wrote:
>>> On 2023-10-21 17:39, bill wrote:
>>>> On 10/21/2023 10:55 AM, Arne Vajhøj wrote:
>>>>> Are you telling me that you have never seen i, j, ...
>>>>> used as variable in a for loop in C?
>>>>>
>>>>
>>>> Probably, but if someone is going to use a single letter variable
>>>> for a loop index more likely would be a, b, x, y, z.  But I'm sure
>>>> an i would show up more for it being the first letter of the word
>>>> index than any influence from Fortran.  Can't say I have ever seen
>>>> j used.
>>>
>>> i and j as loop variables probably beats all other letters combined.
>>>
>>> If you haven't seen that, then I really wonder what code you have
>>> looked at.
>>>
>>
>> My early days doing production programming (In COBOL, Fortran, Pascal, C
>> and a lot of different assemblers) was all done in an environment with
>> very strict programming standards.  Probably explains a lot about my
>> style and why I don't have problems with things like over-runs and
>> bounds violations.  :-)
>
> C coding standards often allow or even encourage i and j.
>
> A few random examples:
>
> Linux kernel coding style:
>
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
> <quote>
> LOCAL variable names should be short, and to the point. If you have some
> random integer loop counter, it should probably be called i. Calling it
> loop_counter is non-productive, if there is no chance of it being
> mis-understood. Similarly, tmp can be just about any type of variable
> that is used to hold a temporary value.
> </quote>
>
> FreeBSD style guide:
>
> https://man.freebsd.org/cgi/man.cgi?style(9)
>
> <quote>
> A for loop may declare and initialize its counting variable.
>
>            for (int    i = 0; i < 15; i++) {
> </quote>
>
> Gnome coding style:
>
> https://developer.gnome.org/documentation/guidelines/programming/coding-style.html
>
> <quote>
> for (i = 0; i < num_elements; i++) {
> </quote>
>

To each his own. I was taught with a much stricter standard
and I think it has done me well over my career. I will admit
that I have used i and variants like i1 and i2 for loops when
writing something quick and dirty that I will only be using
myself, but even then I know deep inside that I am doing
something basically wrong. :-)

bill