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

Groups > alt.os.development > #8344 > unrolled thread

Re: Smaller C

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-11 20:39 -0700
    Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-12 04:24 -0400
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 03:17 -0700
        Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 03:28 -0400
      Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:12 +0100
        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-12 17:09 -0700
        Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-13 11:10 +0100
          Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:13 -0400
            Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-07-14 09:08 +0100
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:23 -0400
    Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:12 -0700
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:54 -0700
        Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-07 12:19 -0700
          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-07 13:30 -0700
            Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:38 -0700
              Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 19:49 -0700
              Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-09 20:58 -0700
              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 01:45 -0700
                Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-10 10:45 -0700
                  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-10 23:20 -0700
                    Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:26 +0200
                      Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-11 09:50 +0200
                      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-11 00:58 -0700
                        Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 17:38 -0400
                          Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-11 23:39 +0100
                            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 19:39 -0400
                              Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:22 +0100
                          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:21 -0700
                          Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-12 21:53 +0200
                            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:37 -0400
                              Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:49 +0100
                                Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:58 +0200
                                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 07:32 -0400
                                  Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:05 +0100
                                    Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 13:19 +0100
                                      Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-15 00:01 -0400
                                        Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 14:48 +0100
                                          Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-26 16:23 -0400
                                            Re: Smaller C James Harris <james.harris.1@gmail.com> - 2015-09-27 00:23 +0100
                                              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-26 16:37 -0700
                                              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:17 -0400
                                                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:24 -0400
                                                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:46 -0400
                                                Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:14 +0000
                                                  Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
                                                    Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-27 13:52 +0000
                                              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-27 10:28 -0400
                                                Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:31 +0000
                                                  Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:20 -0500
                                      Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-18 16:21 +0100
                                        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-20 17:25 -0700
                              Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 12:43 +0200
                            Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 09:21 +0100
                              Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-09-13 13:02 +0200
                                Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:09 +0100
                    Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 13:32 -0700
                      Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-11 18:51 -0400
                        Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 18:16 -0700
                          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:36 -0700
                        Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-12 11:56 +0100
                          Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:45 -0400
                            Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 10:28 +0100
                              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:53 -0700
                                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:17 -0400
                                  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 16:54 -0700
                                    Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:39 -0400
                                      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 20:31 -0700
                              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 09:03 -0400
                                Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-13 19:48 +0100
                                  Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 21:33 -0400
                                    Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-14 23:17 +0100
                                      Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-20 17:37 -0400
                                        Re: Smaller C "James Harris" <james.harris.1@gmail.com> - 2015-09-20 23:46 +0100
    Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 21:37 -0700
      Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-11 22:29 -0700
        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 03:25 -0700
          Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:18 -0700
            Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 11:39 -0700
            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 03:47 -0400
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
            Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-13 02:00 -0700
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-13 11:31 -0400
              Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-13 09:15 -0700
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-12 02:45 -0700
        Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-12 10:55 -0700
    Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-15 19:23 -0700
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-16 03:03 -0700
        Re: Smaller C "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-09-16 10:17 -0700

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

#8766

On Sat, 12 Sep 2015 06:56:36 -0400, James Harris <james.harris.1@gmail.com> wrote:

> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
> news:op.x4tlsdpnyfako5@localhost...
>> On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt
>> <zfysz@fysnet.net> wrote:

>>> However, at the moment, and probably for some time, I will not
>>> need anything like that in my OS development, and will probably
>>> not pursue it much further than what I have done so far.  At
>>> least not at the moment.  I will be interested to see what you
>>> come up with, whenever you do add this functionality to yours.
>>
>> Well, I rarely use any qualifiers.  They're generally not needed,
>> if you're a cautious programmer.  I've never found a use for 'const'.
>
> I don't use it much but const is a good way to confirm that a certain
> piece of data is not updated in a function.

C supports pass-by-value by default and pass-by-reference via a pointer.
Just how do you modify a value passed-by-value? ...

> Whether you are a cautious
> programmer or not, if you look at a certain function and wonder whether
> a variable, say, is updated anywhere in the function const can confirm
> it without you having to read through and understand the entire function
> (as long as it's not pointed at!).

When would you need that?

I can understand the compiler being able to optimize better if
it's present, but I personally have never had a need for that
with my code or someone else's.

>> I've only used 'static' once for convenience.
>
> C's static can be very useful in compartmentalising code. IIRC from
> discussions we've had before I know you don't favour data hiding so
> it's not surprising that it's not one you use much.

I use what's appropriate (IMO) for the code.  Programming is complicated
enough without making a mess of it.  Extra qualifiers, which most
programmers have difficulty understanding and using correctly, is one
such example.  How many times have you had to fix C code that had
incorrect 'const' and 'static' plastered everywhere?

> In a function static says, essentially, to place the declaree in the
> data section (yet only visible in this function) rather than in the
> function's activation record.

Deja Vu!

Now, technically, C doesn't require an activation record, so
to be proper ...

s/function's activation record/auto storage/

[Sigh, this should really remind you of what I just said to Alexei ...]


AFAIR, C doesn't have any "activation records".  So, what is a
"function's activation record"?  Google says an "activation
record" is the same as a "stack frame".  Deja Vu again!  I'd
swear I posted a similar response in the past ...  Hence, the same
comment as was said to Alexei, but modified for you.  You've used
this term before.  Does this term come from your IBM mainframe
background that you "cut [your] teeth on"? ...  Upon?

That aside.  Yes, use of 'static' on a variable limits usage, i.e.,
scope, to that procedure.  Although, the data is preserved across
procedure calls, just like a file scope variable, instead of being
created and destroyed like a procedure 'auto' variable.  So what
real advantage does a 'static' variable have over a file scope
variable?  (rhetorical, i.e., I think the answer is: 'none'.)
Unfortunately, the 'static' keyword has at least four other uses,
two of which have to do with linking.  That opens up the opportunity
for misuse and errors of the keyword 'static', which can be avoided
by simply not using 'static'.

> Outside a function static says to keep the declaree private and
> not share it with other source files. IME that can be useful
> for variables and functions.

If the other source files are "unaware" of the variable, because
the programmer did not declare said variable as an 'extern' in the
other source files, how would the source file "know" of said variable?
...

>> 'register' was convenient.
>
> I haven't used register for many years. It was useful once, when
> compilers were not smart enough to do sensible register allocation but
> it more often would get in the compiler's way now. The only use for it I
> can think of these days is to tell the compiler that a certain value
> must not have its address taken, and that doesn't seem very useful.
>

If you're coding an interpreter, you'll have a bunch of address
pointers to implement the virtual machine's interpreter.  The
interpreter is likely to be implemented in multiple parts as
multiple functions of form 'void func(void)', which means you'd
have to have said pointers as file scope and should prefer that
they are truly 'register'.  C doesn't support nested functions
which could've been used to make the code cleaner, if available.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8772

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x4v45jxsyfako5@localhost...
> On Sat, 12 Sep 2015 06:56:36 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>> news:op.x4tlsdpnyfako5@localhost...
>>> On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt
>>> <zfysz@fysnet.net> wrote:
>
>>>> However, at the moment, and probably for some time, I will not
>>>> need anything like that in my OS development, and will probably
>>>> not pursue it much further than what I have done so far.  At
>>>> least not at the moment.  I will be interested to see what you
>>>> come up with, whenever you do add this functionality to yours.
>>>
>>> Well, I rarely use any qualifiers.  They're generally not needed,
>>> if you're a cautious programmer.  I've never found a use for 
>>> 'const'.
>>
>> I don't use it much but const is a good way to confirm that a certain
>> piece of data is not updated in a function.
>
> C supports pass-by-value by default and pass-by-reference via a 
> pointer.
> Just how do you modify a value passed-by-value? ...

AIUI in

  int func(int x, const int y) {
    const int w = some expression;
     ....
  }

You can modify your local copy of x in the function but the compiler 
should stop you modifying your y and w (thereby giving you assurance in 
a long function that you can always access the original values anywhere 
in that function knowing that no other part of the function code has 
changed them).

>> Whether you are a cautious
>> programmer or not, if you look at a certain function and wonder 
>> whether
>> a variable, say, is updated anywhere in the function const can 
>> confirm
>> it without you having to read through and understand the entire 
>> function
>> (as long as it's not pointed at!).
>
> When would you need that?

C allows the values passed in to be modified. Sometimes a programmer 
wants the original x that was supplied.

> I can understand the compiler being able to optimize better if
> it's present, but I personally have never had a need for that
> with my code or someone else's.

I don't know about optimisation here but it may apply.

>>> I've only used 'static' once for convenience.
>>
>> C's static can be very useful in compartmentalising code. IIRC from
>> discussions we've had before I know you don't favour data hiding so
>> it's not surprising that it's not one you use much.
>
> I use what's appropriate (IMO) for the code.  Programming is 
> complicated
> enough without making a mess of it.  Extra qualifiers, which most
> programmers have difficulty understanding and using correctly, is one
> such example.  How many times have you had to fix C code that had
> incorrect 'const' and 'static' plastered everywhere?

I haven't had to fix such code but I don't often work on the code that 
others have written. By "plastered everywhere" (LOL) perhaps you are 
weighting the argument with an emotional pejorative. ;-)

>> In a function static says, essentially, to place the declaree in the
>> data section (yet only visible in this function) rather than in the
>> function's activation record.
>
> Deja Vu!
>
> Now, technically, C doesn't require an activation record, so
> to be proper ...

AFIACS all programs with callable functions require the use of 
activation records so that they can execute. The C *standard* may not 
refer to them because it is a lanuage definition but a C *compiler* will 
certainly generate them.

> s/function's activation record/auto storage/

When a function is called its autos (and other things) will be stored in 
an activation record.

> [Sigh, this should really remind you of what I just said to Alexei 
> ...]
>
>
> AFAIR, C doesn't have any "activation records".  So, what is a
> "function's activation record"?  Google says an "activation
> record" is the same as a "stack frame".

It often is a stack frame but an activation record does not *need* to 
sit on a stack. If a function cannot be called recursively then, 
technically, its activation record could be a preassigned place in 
memory. I think Fortran works that way.

Further, if a function can be called recursively (directly by it calling 
itself or indirectly by it calling something else which eventually leads 
to it being called again *before* the thing it called returns) its 
activation record can be placed in some arbitrary place in memory and 
linked to other activation records to form a chain. The ARs are still 
processed in a FIFO fashion so even though the implementation is a 
linked list you could see this as a stack of ARs.

> Deja Vu again!  I'd
> swear I posted a similar response in the past ...  Hence, the same
> comment as was said to Alexei, but modified for you.  You've used
> this term before.  Does this term come from your IBM mainframe
> background that you "cut [your] teeth on"? ...  Upon?

No, I think it comes from studying compilers. Do you have another name 
for activation records?

> That aside.  Yes, use of 'static' on a variable limits usage, i.e.,
> scope, to that procedure.  Although, the data is preserved across
> procedure calls, just like a file scope variable, instead of being
> created and destroyed like a procedure 'auto' variable.  So what
> real advantage does a 'static' variable have over a file scope
> variable?  (rhetorical, i.e., I think the answer is: 'none'.)

I'll answer anyway! In

  int f(....) {
    static int aa;

the variable aa is protected against modification from any other 
function. It's like a global but one that no other function can change.

> Unfortunately, the 'static' keyword has at least four other uses,

Four *other* uses? I thought you had four in total. You've now found 
*five*! ;-(

> two of which have to do with linking.  That opens up the opportunity
> for misuse and errors of the keyword 'static', which can be avoided
> by simply not using 'static'.

On the contrary, use of "static" helps prevent misuse.

>> Outside a function static says to keep the declaree private and
>> not share it with other source files. IME that can be useful
>> for variables and functions.
>
> If the other source files are "unaware" of the variable, because
> the programmer did not declare said variable as an 'extern' in the
> other source files, how would the source file "know" of said variable?

Consider

  file1.c
    int aa;
    static int bb;
    void ff(....) { .... }
    static void gg(....) { .... }

  file2.c
    int aa; <== error
    static int bb; <== no error
    void ff(....) { .... } <== error
    static void gg(....) { .... } <== no error

Untested but AIUI the names bb and gg will be local to the files they 
are defined in. They can never conflict with names in other files, no 
matter how large the project gets or how many programmers are working on 
it. I find that's particularly useful for functions. If I write a helper 
function in one file I can declare it static to make sure its name 
doesn't leak out and it cannot be referenced from other files.

James

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

#8774

On Sunday, September 13, 2015 at 2:28:47 AM UTC-7, James Harris wrote:
...
[James wrote in reponse to Rod]

> Consider
> 
>   file1.c
>     int aa;
>     static int bb;
>     void ff(....) { .... }
>     static void gg(....) { .... }
> 
>   file2.c
>     int aa; <== error
>     static int bb; <== no error
>     void ff(....) { .... } <== error
>     static void gg(....) { .... } <== no error
> 
> Untested but AIUI the names bb and gg will be local to the files they 
> are defined in. They can never conflict with names in other files, no 
> matter how large the project gets or how many programmers are working on 
> it. I find that's particularly useful for functions. If I write a helper 
> function in one file I can declare it static to make sure its name 
> doesn't leak out and it cannot be referenced from other files.

Rod has mentioned a few style guides and they touch this topic:

1. Avoid names that might conflict with various standard library
names. Some systems will include more library code than you want.
Also, your program may be extended someday.

2. Name space pollution: Minimize the number of global symbols
in the application. One of the benefits is the lower probability
that any conflicts will arise with system-defined functions.

I wonder if Rod writes code without any global and static
variables or he simply chooses what good advice to adopt and what
to ignore.

The same applies to const, especially in C++, where things are
an order of magnitude more complex. Again, I don't know what kind
of projects Rod has worked on, but I do from time to time have
to join an existing unfamiliar and large project with a lot of
code and these consts serve not only as road blocks on my way
of modifying anything I feel like to, but also as a hint.
If they weren't there, I would not know if I can modify something
or if something else can modify it without me being aware of it
until things break horribly.

My verdict: const is useful.
Addendum: it too can be abused and it too can create problems.

Alex

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

#8784

On Sun, 13 Sep 2015 05:53:34 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Sunday, September 13, 2015 at 2:28:47 AM UTC-7, James Harris wrote:
> ...
> [James wrote in reponse to Rod]

>> Consider
>>
>>   file1.c
>>     int aa;
>>     static int bb;
>>     void ff(....) { .... }
>>     static void gg(....) { .... }
>>
>>   file2.c
>>     int aa; <== error
>>     static int bb; <== no error
>>     void ff(....) { .... } <== error
>>     static void gg(....) { .... } <== no error
>>
>> Untested but AIUI the names bb and gg will be local to the files they
>> are defined in. They can never conflict with names in other files, no
>> matter how large the project gets or how many programmers are working on
>> it. I find that's particularly useful for functions. If I write a helper
>> function in one file I can declare it static to make sure its name
>> doesn't leak out and it cannot be referenced from other files.
>
> Rod has mentioned a few style guides and they touch this topic:
>
> 1. Avoid names that might conflict with various standard library
> names.

Compilers warn of this.

> Some systems will include more library code than you want.
...

> Also, your program may be extended someday.

Yes, by you.  Typically, not by others.

> 2. Name space pollution: Minimize the number of global symbols
> in the application.

This is good for programs broken into multiple files and
managed by groups of people.  This is not a concern for
single file applications or programs written and maintained
by a singular author in private.

> One of the benefits is the lower probability
> that any conflicts will arise with system-defined functions.

This is an exceptionally low probability as is.  Most programmers
know the names of all or nearly all system functions or know the
types of names to avoid.

> I wonder if Rod writes code without any global and static
> variables

I write C code without any static variables, except once.
I write C code with globals and pass variables as is needed
by the code.  If the data or variable is being passed among
many procedures and/or speed is an issue, it makes more sense
to use globals than it does to keep passing the variables
around slowly or repeatedly.  If speed is not a concern and/or
there is minimal passing, then locals are used.  If it makes
no sense to pass the data because it is simply too large an
amount of data to pass, then it'll be global too.  I also
prefer to have all file pointers be global so they can be
used wherever they are needed.  All except a few of my personal
programs are single file.  I.e., no linking with other files
except the C libraries.  Only a few are comprised of multiple
files.  I don't intentionally keep the name spaces of the
variables separate.  This generally happens by through
happenstance and through use of locals.  Of course, coding
in a professional environment such as for work likely has
a set of rules for naming, use of qualifiers, and all sorts
of other things, like the MISRA and Safer C rules I provided
links for, to which I simply don't have to comply with for
my personal code.

> or he simply chooses what good advice to adopt and what
> to ignore.

I adopt good advice.  That's why I only adopted one practice
 from the C style guides.  Unfortunately, most people's IQs are
below mine, so I don't generally get much good advice from
people which is good for me.  I get their best advice, for
their IQ, but it's just not good enough for mine.  And, I
definately chose to avoid bad advice because it's a quick way
to mess up everything.  One of the things I learned many, many
years ago is that people can only accept advice that is just
slighly more intelligent than what they came up with on their
own.  They simply can't comprehend anything more intelligent
than that.  So, they don't recognize it's value.

> The same applies to const, especially in C++, where things are
> an order of magnitude more complex. Again, I don't know what kind
> of projects Rod has worked on, but I do from time to time have
> to join an existing unfamiliar and large project with a lot of
> code and these consts serve not only as road blocks on my way
> of modifying anything I feel like to, but also as a hint.

Well, I've never coded on a public C project or used C in a
work environment.  I have worked on public C code in private
which is how I know 'const' and 'static' are plastered throughout
some of them.

I learned C in the early 1990's, self-taught, from a number of
C books I purchased, but primarily Harbison & Steele's book,
which was the leading C reference at the time.  I already had
experience in Pascal and Fortran (high school and university),
and, before that, BASIC and 6502 assembly (self-taught).  I
wrote my first computer program using Logo in 1981 at a night
class.

The largest project I worked on was a private code base of 5MLoc
in a PL/I variant (Stratus PL/1) for a brokerage.  We had four T1s
feeding quotes and trade data to a real-time, online transaction
procesing application (OLTP) and in-memory database which had
transaction protection for proprietary trading in stocks which
ran on two fault-tolerant Stratus Continuum 600s.  I maintained
the code, complied with NYSE and Nasdaq regulatory changes,
implemented applications from scratch to create federal regulatory
reports, maintained corporate financial reports, and modified
one of their line handlers to handle updated Nasdaq protocols,
wrote a variety of utilities, etc.  That was over a decade ago.

I planned on becoming an electrical engineer (EE) since I had
a fanatical interest in electronics since middle school.  I
learned how to read schematics on my own.  I bought an
oscilloscope and taught myself how to use it.  I knew probably
about as much about electronics as a someone with a masters in
EE, if not a PhD, coming out of high school.  But, for reasons
still unknown to me, my life perspective and interests changed
rapidly and unexpectedly.  I completely lost all interest in
electronics immediately after graduating from high school.  It
was like a light switch turned off for which I couldn't turn
back on.  Then, somewhat lost as to what I wanted to do or
become, I bounced around universities and colleges.  I decided
I wanted to try computer programming, but was told the market
was non-existant here, which it was at the time.  It improved
much just a few years later, but it's still not a great place
to be a programmer.  So, I became an electronic technician for
a while working with analog audio and DSPs, for which I was
overskilled and educated, but loved the extremely underpaid
work.  Next, I caught a lucky break and moved into computer
programming, which became another job I loved and after a
bit it became well-paying.

One of the other guys in my high-school class who was roughly
of similar intellect has a PhD in chemistry and is now a
university professor.  Back then, I was very strong in math,
physics, chemistry, and electronics.  Programming was just a
hobby.  However, I had no interest in chemistry, and wasn't
all that interested in being a physicist.  Today, I'm strong
in programming, and have interests in finance, economics, the
discoveries of physics and genetics, and many other things not
so academic or intellectual or mathematical.  I still have a
trivial interest in electronics, and an in-depth understanding
of electronics well beyond what any non-EE should ...  Of course,
my math skills are far too rusty to solve any of those types of
problems today, except for the most trivial.  I have well above
average spatial-relations.  I once had a perfect score on the
spatial-relations portion of a standardized test in high school
for which no one had ever scored above 47%.  It's like I have
AutoCad in my head, but without dimensions.  I used to solve
20 geometry problems in 2 minutes and could solve about 60
physics problems in an hour because of this ability.

So, that's who I am.  Who are you?


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8797

On Sunday, September 13, 2015 at 8:17:45 AM UTC-7, Rod Pemberton wrote:
> On Sun, 13 Sep 2015 05:53:34 -0400, Alexei A. Frounze <...@gmail.com> wrote:
> 
> > On Sunday, September 13, 2015 at 2:28:47 AM UTC-7, James Harris wrote:
> > ...
> > [James wrote in reponse to Rod]
> 
> >> Consider
> >>
> >>   file1.c
> >>     int aa;
> >>     static int bb;
> >>     void ff(....) { .... }
> >>     static void gg(....) { .... }
> >>
> >>   file2.c
> >>     int aa; <== error
> >>     static int bb; <== no error
> >>     void ff(....) { .... } <== error
> >>     static void gg(....) { .... } <== no error
> >>
> >> Untested but AIUI the names bb and gg will be local to the files they
> >> are defined in. They can never conflict with names in other files, no
> >> matter how large the project gets or how many programmers are working on
> >> it. I find that's particularly useful for functions. If I write a helper
> >> function in one file I can declare it static to make sure its name
> >> doesn't leak out and it cannot be referenced from other files.
> >
> > Rod has mentioned a few style guides and they touch this topic:
> >
> > 1. Avoid names that might conflict with various standard library
> > names.
> 
> Compilers warn of this.

Maybe they do that for functions defined in the C standard, but I
doubt they go any further (POSIX APIs) without explicit help from
fellow programmers (e.g. by using some compiler extensions teach
the compiler to frown upon redefinition of OS-specific functions).
I have not seen that happen yet. Dunno, maybe I was just lucky.

I find it awkward that some POSIX APIs define functions and
global variables that it's easy to collide with. Take, for example,
environ. I rarely use POSIX stuff and for a long time I didn't
know of this variable. I now know that defining envrion in my
code is not a clever idea, unless it's a static variable and the
containing source file does not include POSIX headers (in case
for some reason it could be a macro).

> > Some systems will include more library code than you want.
> ...
> 
> > Also, your program may be extended someday.
> 
> Yes, by you.  Typically, not by others.

"Your" doesn't mean your's alone here. Sorry, if that wasn't
obvious.

> > 2. Name space pollution: Minimize the number of global symbols
> > in the application.
> 
> This is good for programs broken into multiple files and
> managed by groups of people.  This is not a concern for
> single file applications or programs written and maintained
> by a singular author in private.

It probably wasn't obvious. I have worked on C/C++ projects in
teams of 10 or more people since 2001. So, what is good or good
enough for a personal project, is not necessarily good for a
project modified by many engineers.

> > One of the benefits is the lower probability
> > that any conflicts will arise with system-defined functions.
> 
> This is an exceptionally low probability as is.  Most programmers
> know the names of all or nearly all system functions or know the
> types of names to avoid.

Like I said, there are unfortunate things like environ and while
one may be proficient in C, they may not know of things like this
in APIs available on other OSes. The same way a Linux programmer
may run into issues with e.g. defining OpenFile, which exist in
Win32 APIs.

> > I wonder if Rod writes code without any global and static
> > variables
> 
> I write C code without any static variables, except once.
> I write C code with globals and pass variables as is needed
> by the code.  If the data or variable is being passed among
> many procedures and/or speed is an issue, it makes more sense
> to use globals than it does to keep passing the variables
> around slowly or repeatedly.  If speed is not a concern and/or
> there is minimal passing, then locals are used.  If it makes
> no sense to pass the data because it is simply too large an
> amount of data to pass, then it'll be global too.  I also
> prefer to have all file pointers be global so they can be
> used wherever they are needed.  All except a few of my personal
> programs are single file.  I.e., no linking with other files
> except the C libraries.  Only a few are comprised of multiple
> files.  I don't intentionally keep the name spaces of the
> variables separate.  This generally happens by through
> happenstance and through use of locals.  Of course, coding
> in a professional environment such as for work likely has
> a set of rules for naming, use of qualifiers, and all sorts
> of other things, like the MISRA and Safer C rules I provided
> links for, to which I simply don't have to comply with for
> my personal code.

No problem with personal projects. IOW, those problems are
not someone else's, they are only yours. In shared projects
people need to be aware of not being alone and that their
changes may adversely affect someone.

> > or he simply chooses what good advice to adopt and what
> > to ignore.
> 
> I adopt good advice.  That's why I only adopted one practice
>  from the C style guides.  Unfortunately, most people's IQs are
> below mine, so I don't generally get much good advice from
> people which is good for me.  I get their best advice, for
> their IQ, but it's just not good enough for mine.  And, I
> definately chose to avoid bad advice because it's a quick way
> to mess up everything.  One of the things I learned many, many
> years ago is that people can only accept advice that is just
> slighly more intelligent than what they came up with on their
> own.  They simply can't comprehend anything more intelligent
> than that.  So, they don't recognize it's value.

What's happened to experience and domain-specific knowledge?
If you get to work with a very junior programmer and they write
crap of a code in terms of style, logic bugs and language-
specific bugs, would you blame all that on their low IQ and
render them as incorrigible and unable to learn? You probably
shouldn't as most of the required things can be and are
learned over time. And attitude/work ethics can be adjusted as
well (or they lose the job). If someone does not know or learn
this or that, is it just about their IQ or can there be other
things at play? What if they don't want to and it doesn't seem
like they really need to? What if they don't know what they
don't know and someone needs to educate them before they can
appreciate a new idea, tool or technique? What if they simply
don't like or trust you for whatever reason and you have to
solve that problem first before you can hear each other?

> > The same applies to const, especially in C++, where things are
> > an order of magnitude more complex. Again, I don't know what kind
> > of projects Rod has worked on, but I do from time to time have
> > to join an existing unfamiliar and large project with a lot of
> > code and these consts serve not only as road blocks on my way
> > of modifying anything I feel like to, but also as a hint.
> 
> Well, I've never coded on a public C project or used C in a
> work environment.  I have worked on public C code in private
> which is how I know 'const' and 'static' are plastered throughout
> some of them.
> 
> I learned C in the early 1990's, self-taught, from a number of
> C books I purchased, but primarily Harbison & Steele's book,
> which was the leading C reference at the time.  I already had
> experience in Pascal and Fortran (high school and university),
> and, before that, BASIC and 6502 assembly (self-taught).  I
> wrote my first computer program using Logo in 1981 at a night
> class.
> 
> The largest project I worked on was a private code base of 5MLoc
> in a PL/I variant (Stratus PL/1) for a brokerage.  We had four T1s
> feeding quotes and trade data to a real-time, online transaction
> procesing application (OLTP) and in-memory database which had
> transaction protection for proprietary trading in stocks which
> ran on two fault-tolerant Stratus Continuum 600s.  I maintained
> the code, complied with NYSE and Nasdaq regulatory changes,
> implemented applications from scratch to create federal regulatory
> reports, maintained corporate financial reports, and modified
> one of their line handlers to handle updated Nasdaq protocols,
> wrote a variety of utilities, etc.  That was over a decade ago.
> 
> I planned on becoming an electrical engineer (EE) since I had
> a fanatical interest in electronics since middle school.  I
> learned how to read schematics on my own.  I bought an
> oscilloscope and taught myself how to use it.  I knew probably
> about as much about electronics as a someone with a masters in
> EE, if not a PhD, coming out of high school.  But, for reasons
> still unknown to me, my life perspective and interests changed
> rapidly and unexpectedly.  I completely lost all interest in
> electronics immediately after graduating from high school.  It
> was like a light switch turned off for which I couldn't turn
> back on.  Then, somewhat lost as to what I wanted to do or
> become, I bounced around universities and colleges.  I decided
> I wanted to try computer programming, but was told the market
> was non-existant here, which it was at the time.  It improved
> much just a few years later, but it's still not a great place
> to be a programmer.  So, I became an electronic technician for
> a while working with analog audio and DSPs, for which I was
> overskilled and educated, but loved the extremely underpaid
> work.  Next, I caught a lucky break and moved into computer
> programming, which became another job I loved and after a
> bit it became well-paying.
> 
> One of the other guys in my high-school class who was roughly
> of similar intellect has a PhD in chemistry and is now a
> university professor.  Back then, I was very strong in math,
> physics, chemistry, and electronics.  Programming was just a
> hobby.  However, I had no interest in chemistry, and wasn't
> all that interested in being a physicist.  Today, I'm strong
> in programming, and have interests in finance, economics, the
> discoveries of physics and genetics, and many other things not
> so academic or intellectual or mathematical.  I still have a
> trivial interest in electronics, and an in-depth understanding
> of electronics well beyond what any non-EE should ...  Of course,
> my math skills are far too rusty to solve any of those types of
> problems today, except for the most trivial.  I have well above
> average spatial-relations.  I once had a perfect score on the
> spatial-relations portion of a standardized test in high school
> for which no one had ever scored above 47%.  It's like I have
> AutoCad in my head, but without dimensions.  I used to solve
> 20 geometry problems in 2 minutes and could solve about 60
> physics problems in an hour because of this ability.
> 
> So, that's who I am.  Who are you?

Alex. Pleased to meet you, Rod. :) I mean, that was nice but
wasn't asked about/for.

Without going into details I can say that I hold a masters in
physics, that I've done some basic electronics stuff (radios,
amplifiers, etc) at school and then moved from analog stuff
into the digital domain of embedded devices. Since 2001 worked
full time on C/C++ projects in teams of ~10 or more engineers
in embedded/telecom and kernel/virtualization areas. Smaller C,
experience and past achievements landed me a job, where I'm now
working on a backend/code generator of a compiler. Still C/C++/
asm, still low level, still ~10 people that I interact with
while working on the project. Need to catch up with the ever
changing project and put up with guidelines, sometimes too
strict, sometimes too vague, and even some arbitrariness on
code reviews. But there are rational and useful things too.
Like I said earlier, things like const do help and guide.
Proper modularity helps a lot in large projects. You don't
really want to have to spend too much time studying everything
or debug some other code when your stuff should be relatively
isolated.

Alex

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

#8800

On Sun, 13 Sep 2015 19:54:10 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> Smaller C, experience and past achievements landed me a job,
> where I'm now working on a backend/code generator of a compiler.

There's no conflict here between the work compiler project and
your Smaller C project?

I thought most employers today will lay claim to an employee's
work in the same field, even during off work hours, via their
employment agreements.  I hope that doesn't happen to you.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8802

On Sunday, September 13, 2015 at 6:39:23 PM UTC-7, Rod Pemberton wrote:
> On Sun, 13 Sep 2015 19:54:10 -0400, Alexei A. Frounze <...@gmail.com> wrote:
> 
> > Smaller C, experience and past achievements landed me a job,
> > where I'm now working on a backend/code generator of a compiler.
> 
> There's no conflict here between the work compiler project and
> your Smaller C project?
> 
> I thought most employers today will lay claim to an employee's
> work in the same field, even during off work hours, via their
> employment agreements.  I hope that doesn't happen to you.

Well, for one thing, they are completely different compilers
(for different use, for different languages, with different
performance) and can't compete. Secondly, neither is closed
source or a commercial product. And even if the above wasn't
true, why would anyone want to claim rights to something like
Smaller C when there exist better things? Just to reap some
bad PR? There's no money in it.

Alex

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

#8783

On Sun, 13 Sep 2015 05:28:45 -0400, James Harris <james.harris.1@gmail.com> wrote:

> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
> news:op.x4v45jxsyfako5@localhost...
>> On Sat, 12 Sep 2015 06:56:36 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:
>>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>>> news:op.x4tlsdpnyfako5@localhost...
>>>> On Fri, 11 Sep 2015 16:32:14 -0400, Benjamin David Lunt
>>>> <zfysz@fysnet.net> wrote:

>>>>> However, at the moment, and probably for some time, I will not
>>>>> need anything like that in my OS development, and will probably
>>>>> not pursue it much further than what I have done so far.  At
>>>>> least not at the moment.  I will be interested to see what you
>>>>> come up with, whenever you do add this functionality to yours.
>>>>
>>>> Well, I rarely use any qualifiers.  They're generally not needed,
>>>> if you're a cautious programmer.  I've never found a use for
>>>> 'const'.
>>>
>>> I don't use it much but const is a good way to confirm that a certain
>>> piece of data is not updated in a function.
>>
>> C supports pass-by-value by default and pass-by-reference via a
>> pointer.  Just how do you modify a value passed-by-value? ...
>
> AIUI in
>
>   int func(int x, const int y) {
>     const int w = some expression;
>      ....
>   }
>
> You can modify your local copy of x in the function but the compiler
> should stop you modifying your y and w (thereby giving you assurance in
> a long function that you can always access the original values anywhere
> in that function knowing that no other part of the function code has
> changed them).

s/updated/changed/

I take issue with your use of "updated" when you meant "changed" here.
To me, "updated" means being modified and returned from the function.

I personally have no use for this whatsoever.  I expect the variables
to be modified within the function, and usually be passed back modified.
If I want the variable's value to be preserved, it's preserved in the
calling function, not the callee.

If I did need to preserve the value within the called function, my
solutions would be, in order of my preference:

1) don't assign anything to said variable or modify it

This isn't difficult to do.  It's easy to check too.
There likely won't be many uses even within a larger
function.  Simply don't assign to said variable or
perform any arithmetic, bitwise, etc operations upon it.

2) make a copy to a local and use it

The passed-in value (preserved through non-use) can be used
to compare or verify the value of the local (changeable), or
to reset the the variable that might be modified.  If you're
unsure that you haven't modified the variable, you can temporarily
install a #error or #pragma warning and compare the two during
actual execution.  Copying passed-in value to a local is frequently
a good idea even if you don't need to preserve the original value.
Many compilers optimize locals better than parameters, especially
for larger functions.

3) use 'const' because it's required for safety, i.e., for
professional work code, regulatory requirements, capable to
endanger a human life, etc.

>>>> I've only used 'static' once for convenience.
>>>
>>> C's static can be very useful in compartmentalising code. IIRC from
>>> discussions we've had before I know you don't favour data hiding so
>>> it's not surprising that it's not one you use much.
>>
>> I use what's appropriate (IMO) for the code.  Programming is
>> complicated enough without making a mess of it.  Extra qualifiers,
>> which most programmers have difficulty understanding and using
>> correctly, is one such example.  How many times have you had to
>> fix C code that had incorrect 'const' and 'static' plastered
>> everywhere?
>
> I haven't had to fix such code but I don't often work on the code that
> others have written. By "plastered everywhere" (LOL) perhaps you are
> weighting the argument with an emotional pejorative. ;-)

You'll think that, until you see some code with it plastered everywhere.

>> Deja Vu again!  I'd
>> swear I posted a similar response in the past ...  Hence, the same
>> comment as was said to Alexei, but modified for you.  You've used
>> this term before.  Does this term come from your IBM mainframe
>> background that you "cut [your] teeth on"? ...  Upon?
>
> No, I think it comes from studying compilers.
> Do you have another name for activation records?

No.

It's not a term I use.  It's not a term I learned of until a few years
ago in reference to ancient mainframes which didn't have stacks.  It's
not a term I've seen used in any of the programming groups on Usenet.
I.e., who is all that familiar with the term?  You use it.

So, how about "unlinked, non-contiguous, and distributed stack frames"?
UNCDSF for short.  No?  ;-)

>> That aside.  Yes, use of 'static' on a variable limits usage, i.e.,
>> scope, to that procedure.  Although, the data is preserved across
>> procedure calls, just like a file scope variable, instead of being
>> created and destroyed like a procedure 'auto' variable.  So what
>> real advantage does a 'static' variable have over a file scope
>> variable?  (rhetorical, i.e., I think the answer is: 'none'.)
>
> I'll answer anyway! In
>
>   int f(....) {
>     static int aa;
>
> the variable aa is protected against modification from any other
> function. It's like a global but one that no other function can change.

Um, why would another function, one which you most likely coded,
modify your own variable, when you had no need whatsoever to modify
said variable in the other function and were aware it shouldn't be?
(It's like you don't trust yourself.)

Similarly, why would another function, one which someone else likely
coded prior to you coding your function, modify your variable when
they didn't even know about said variable existed at the time?
(It's like you believe the "god's" are sabotaging you.)

Similarly, why would someone coding another function after you coded
your function, take a look at your function's variable names, copy
the name intentionally while knowing that an name collision is likely
to cause a crash or corruption?  (It's like they're sabotaging you.)

etc

All of these uses of 'const' and 'static' look like solutions
searching for a problem to fix or overcompensation for an unlikely
event or situation.  It's simply not certain that said problems
will occur and in general they won't.  I can understand doing
said things if you're designing something mission critical.  However,
most applications aren't remotely mission critical, aren't capable
of crashing a machine, and aren't capable of endangering lives.
OS code may be able to crash the machine and is mission critical,
but a user can't link to it.

>> Unfortunately, the 'static' keyword has at least four other uses,
>
> Four *other* uses? I thought you had four in total. You've now found
> *five*! ;-(

s/other//

(Do you realize that every time you correct me, you present me with
an opportunity or two to correct you?  I'm just curious if you do.
I.e., see "lanuage", snipped.)

>> two of which have to do with linking.  That opens up the opportunity
>> for misuse and errors of the keyword 'static', which can be avoided
>> by simply not using 'static'.
>
> On the contrary, use of "static" helps prevent misuse.

Misuse by whom exactly?  You coded it.  Why did you misuse it?
It's called self-control and self-awareness.  Or, your coworkers
have linked to it.  It's called competence.

>>> Outside a function static says to keep the declaree private and
>>> not share it with other source files. IME that can be useful
>>> for variables and functions.
>>
>> If the other source files are "unaware" of the variable, because
>> the programmer did not declare said variable as an 'extern' in the
>> other source files, how would the source file "know" of said variable?
>
> Consider
>
>   file1.c
>     int aa;
>     static int bb;
>     void ff(....) { .... }
>     static void gg(....) { .... }
>
>   file2.c
>     int aa; <== error
>     static int bb; <== no error
>     void ff(....) { .... } <== error
>     static void gg(....) { .... } <== no error

So, you have to use file scope variables, which someone using 'static'
likely won't do  AT ALL, and create an intentional name collision, which
is unlikely for someone using 'static' since they most likely are also
required to use naming conventions which  PROHIBIT  using names which
could collide, in order to prove there is a slim chance of such an issue
occurring, which clearly wouldn't happen to a singular author who is aware
of every name being used, but which may happen to a group that is coding
rather sloppily and not following naming conventions.  Even if the group
used file scope variables, if they were using naming conventions to prevent
name collisions, this wouldn't occur.  I.e., ISTM to be totally irrelevant,
except to present it as a possibility of occurrence which doesn't need to
be compensated for, AFAICT, typically.

> Untested but AIUI the names bb and gg will be local to the files they
> are defined in. They can never conflict with names in other files, no
> matter how large the project gets or how many programmers are working on
> it. I find that's particularly useful for functions. If I write a helper
> function in one file I can declare it static to make sure its name
> doesn't leak out and it cannot be referenced from other files.

Yes, it's possible to make mistakes coding in C.  Don't make them.
That's a large part of the solution.  Is it necessary to take the
actions you suggest?  In general, no.  If you're coding for yourself,
then you shouldn't need to do any of that to ensure your code is safe.
If you're coding with others, then there needs to be some coding
standards which when followed will prevent such situations.  Neither
situation requires use of 'const' or 'static'.  Although, 'const' or
'static' might be used for safety reasons anyway, i.e., where it's
possible to endanger human lives.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8793

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x4wjvxy0yfako5@localhost...
> On Sun, 13 Sep 2015 05:28:45 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>> news:op.x4v45jxsyfako5@localhost...

...

>> You can modify your local copy of x in the function but the compiler
>> should stop you modifying your y and w (thereby giving you assurance 
>> in
>> a long function that you can always access the original values 
>> anywhere
>> in that function knowing that no other part of the function code has
>> changed them).
>
> s/updated/changed/
>
> I take issue with your use of "updated" when you meant "changed" here.
> To me, "updated" means being modified and returned from the function.

Semantics nonsense (IMO)! Whether you say that the local copy is 
updated/changed/modified/altered or whatever, all mean the same thing. 
Whichever word you use the local copy is still the one affected, not the 
caller's copy.

> I personally have no use for this whatsoever.  I expect the variables
> to be modified within the function, and usually be passed back 
> modified.
> If I want the variable's value to be preserved, it's preserved in the
> calling function, not the callee.
>
> If I did need to preserve the value within the called function, my
> solutions would be, in order of my preference:
>
> 1) don't assign anything to said variable or modify it
>
> This isn't difficult to do.  It's easy to check too.
> There likely won't be many uses even within a larger
> function.  Simply don't assign to said variable or
> perform any arithmetic, bitwise, etc operations upon it.
>
> 2) make a copy to a local and use it
>
> The passed-in value (preserved through non-use) can be used
> to compare or verify the value of the local (changeable), or
> to reset the the variable that might be modified.  If you're
> unsure that you haven't modified the variable, you can temporarily
> install a #error or #pragma warning and compare the two during
> actual execution.  Copying passed-in value to a local is frequently
> a good idea even if you don't need to preserve the original value.
> Many compilers optimize locals better than parameters, especially
> for larger functions.
>
> 3) use 'const' because it's required for safety, i.e., for
> professional work code, regulatory requirements, capable to
> endanger a human life, etc.

Or

4) Use 'const' where you can so that the compiler will do the check for 
you. (And it makes a useful addition to the documentation for free.)

...

>> Do you have another name for activation records?
>
> No.
>
> It's not a term I use.  It's not a term I learned of until a few years
> ago in reference to ancient mainframes which didn't have stacks.  It's
> not a term I've seen used in any of the programming groups on Usenet.
> I.e., who is all that familiar with the term?  You use it.
>
> So, how about "unlinked, non-contiguous, and distributed stack 
> frames"?
> UNCDSF for short.  No?  ;-)

How about Distributed Automatic Frame Type? ;-)

>>> That aside.  Yes, use of 'static' on a variable limits usage, i.e.,
>>> scope, to that procedure.  Although, the data is preserved across
>>> procedure calls, just like a file scope variable, instead of being
>>> created and destroyed like a procedure 'auto' variable.  So what
>>> real advantage does a 'static' variable have over a file scope
>>> variable?  (rhetorical, i.e., I think the answer is: 'none'.)
>>
>> I'll answer anyway! In
>>
>>   int f(....) {
>>     static int aa;
>>
>> the variable aa is protected against modification from any other
>> function. It's like a global but one that no other function can 
>> change.
>
> Um, why would another function, one which you most likely coded,
> modify your own variable, when you had no need whatsoever to modify
> said variable in the other function and were aware it shouldn't be?
> (It's like you don't trust yourself.)
>
> Similarly, why would another function, one which someone else likely
> coded prior to you coding your function, modify your variable when
> they didn't even know about said variable existed at the time?
> (It's like you believe the "god's" are sabotaging you.)
>
> Similarly, why would someone coding another function after you coded
> your function, take a look at your function's variable names, copy
> the name intentionally while knowing that an name collision is likely
> to cause a crash or corruption?  (It's like they're sabotaging you.)
>
> etc

Or,

Why would you make a function or, worse, a variable accessible to every 
module in your project unless it needed to be?

> All of these uses of 'const' and 'static' look like solutions
> searching for a problem to fix or overcompensation for an unlikely
> event or situation.  It's simply not certain that said problems
> will occur and in general they won't.  I can understand doing
> said things if you're designing something mission critical.  However,
> most applications aren't remotely mission critical, aren't capable
> of crashing a machine, and aren't capable of endangering lives.
> OS code may be able to crash the machine and is mission critical,
> but a user can't link to it.

I don't agree. While the mechanisms are not perfect these do allow C to 
provide a good deal of modularity and protection if used well. I have 
been quite impressed at how helpful they are (static especially) 
particularly in larger projects. Static would be an even bigger boon in 
a project that multiple people were working on.

>>> Unfortunately, the 'static' keyword has at least four other uses,
>>
>> Four *other* uses? I thought you had four in total. You've now found
>> *five*! ;-(
>
> s/other//
>
> (Do you realize that every time you correct me, you present me with
> an opportunity or two to correct you?  I'm just curious if you do.

Ah, but I evidently correct your misleading comments whereas you only 
correct my typos! ;-)

> I.e., see "lanuage", snipped.)
>
>>> two of which have to do with linking.  That opens up the opportunity
>>> for misuse and errors of the keyword 'static', which can be avoided
>>> by simply not using 'static'.
>>
>> On the contrary, use of "static" helps prevent misuse.
>
> Misuse by whom exactly?  You coded it.  Why did you misuse it?

Where it's appropriate you *lose* absolutely nothing by using static at 
file scope. You gain a good deal.

> It's called self-control and self-awareness.  Or, your coworkers
> have linked to it.  It's called competence.

Beware overconfidence...!

>>>> Outside a function static says to keep the declaree private and
>>>> not share it with other source files. IME that can be useful
>>>> for variables and functions.
>>>
>>> If the other source files are "unaware" of the variable, because
>>> the programmer did not declare said variable as an 'extern' in the
>>> other source files, how would the source file "know" of said 
>>> variable?
>>
>> Consider
>>
>>   file1.c
>>     int aa;
>>     static int bb;
>>     void ff(....) { .... }
>>     static void gg(....) { .... }
>>
>>   file2.c
>>     int aa; <== error
>>     static int bb; <== no error
>>     void ff(....) { .... } <== error
>>     static void gg(....) { .... } <== no error
>
> So, you have to use file scope variables, which someone using 'static'
> likely won't do  AT ALL,

No, it's not the case that someone using static for a variable defined 
in a function will never use a file-scope variable. One of the problems 
with static in a function is that the variable thus declared is only 
visible in that function. C doesn't have a way for two or three 
functions to share a private variable as some languages do. The 
alternative is a global. That can be shared between, say, two functions 
but then it is visible to every other function. File-scope statics 
provide a way to have a global that is only visible to the functions in 
the same source file.

> and create an intentional name collision, which
> is unlikely for someone using 'static' since they most likely are also
> required to use naming conventions which  PROHIBIT  using names which
> could collide, in order to prove there is a slim chance of such an 
> issue
> occurring, which clearly wouldn't happen to a singular author who is 
> aware
> of every name being used, but which may happen to a group that is 
> coding
> rather sloppily and not following naming conventions.  Even if the 
> group
> used file scope variables, if they were using naming conventions to 
> prevent
> name collisions, this wouldn't occur.  I.e., ISTM to be totally 
> irrelevant,
> except to present it as a possibility of occurrence which doesn't need 
> to
> be compensated for, AFAICT, typically.

Sure, you can use global naming if you want to. You could still also 
keep some variables and more importanly functions private to the module 
they are defined in.

I am not sure if you are aware or not but in C any name defined at the 
top level is publicly visible by default. You can declare it static to 
make it private to that file. I think that's a good simple rule and easy 
to use appropriately. I set up headers to work precisely with that 
scheme, i.e. public names declared in the .h and private names declared 
in the .c file; and the .c pulls in the .h so that the compiler can 
verify that the public declarations in the .h match those in use in the 
.c. Simple. Robust. Effective. Modular.

>> Untested but AIUI the names bb and gg will be local to the files they
>> are defined in. They can never conflict with names in other files, no
>> matter how large the project gets or how many programmers are working 
>> on
>> it. I find that's particularly useful for functions. If I write a 
>> helper
>> function in one file I can declare it static to make sure its name
>> doesn't leak out and it cannot be referenced from other files.
>
> Yes, it's possible to make mistakes coding in C.  Don't make them.

Is that your advice: don't make mistakes and then you'll not need these 
facilities?

> That's a large part of the solution.  Is it necessary to take the
> actions you suggest?

Needed, no. They are just useful tools. Use them or ignore them as you 
feel is right for you.

> In general, no.  If you're coding for yourself,
> then you shouldn't need to do any of that to ensure your code is safe.
> If you're coding with others, then there needs to be some coding
> standards which when followed will prevent such situations.  Neither
> situation requires use of 'const' or 'static'.  Although, 'const' or
> 'static' might be used for safety reasons anyway, i.e., where it's
> possible to endanger human lives.

I don't agree. I think they are useful tools in any multi-module 
program.

James

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

#8799

On Sun, 13 Sep 2015 14:48:24 -0400, James Harris <james.harris.1@gmail.com> wrote:

> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
> news:op.x4wjvxy0yfako5@localhost...
>> On Sun, 13 Sep 2015 05:28:45 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:
>>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>>> news:op.x4v45jxsyfako5@localhost...

>>> You can modify your local copy of x in the function but the compiler
>>> should stop you modifying your y and w (thereby giving you assurance
>>> in
>>> a long function that you can always access the original values
>>> anywhere
>>> in that function knowing that no other part of the function code has
>>> changed them).
>>
>> s/updated/changed/
>>
>> I take issue with your use of "updated" when you meant "changed" here.
>> To me, "updated" means being modified and returned from the function.
>
> Semantics nonsense (IMO)! Whether you say that the local copy is
> updated/changed/modified/altered or whatever, all mean the same thing.

Well, I'm not looking to provoke an argument on this issue, but I very
**STRONGLY**  disagree with your opinion here.  I just didn't want to
come off as angry or hostile towards you when I take issue with your
opinion ...

I programmed in PL/1 for a number of years and learned from it that
pass-by-reference is all you need.  You don't need pass-by-value at
all.  I literally used pass-by-value only once for PL/1.  One of C's
largest mistakes, if not it's biggest, was pass-by-value being default
instead of pass-by-reference.

> Whichever word you use the local copy is still the one affected,
> not the caller's copy.

IMO, not true.

 From what I've seen, I'm confident that most C programmers use
pass-by-reference which passes the modified value back to the caller.
The exception is if they wish to intentionally preserve the passed
value in the caller, which is rarely needed.  C is most effective
when used as a pointer and integer based language.

>> I personally have no use for this whatsoever.  I expect the variables
>> to be modified within the function, and usually be passed back
>> modified.
>> If I want the variable's value to be preserved, it's preserved in the
>> calling function, not the callee.
>>
>> If I did need to preserve the value within the called function, my
>> solutions would be, in order of my preference:
>>
>> 1) don't assign anything to said variable or modify it
>>
>> This isn't difficult to do.  It's easy to check too.
>> There likely won't be many uses even within a larger
>> function.  Simply don't assign to said variable or
>> perform any arithmetic, bitwise, etc operations upon it.
>>
>> 2) make a copy to a local and use it
>>
>> The passed-in value (preserved through non-use) can be used
>> to compare or verify the value of the local (changeable), or
>> to reset the the variable that might be modified.  If you're
>> unsure that you haven't modified the variable, you can temporarily
>> install a #error or #pragma warning and compare the two during
>> actual execution.  Copying passed-in value to a local is frequently
>> a good idea even if you don't need to preserve the original value.
>> Many compilers optimize locals better than parameters, especially
>> for larger functions.
>>
>> 3) use 'const' because it's required for safety, i.e., for
>> professional work code, regulatory requirements, capable to
>> endanger a human life, etc.
>
> Or
>
> 4) Use 'const' where you can so that the compiler will do the check for
> you. (And it makes a useful addition to the documentation for free.)

Which is still a waste of time and overcompensation for an event which
you're not even sure has any likelyhood at all that it will ever occur ...

You can call it "proactive" or "cautious" if you wish, and maybe the
cost of doing so is trivial to you, but without having any rational
justification at all for doing this, AFAICT, why would you? ...

>>>> That aside.  Yes, use of 'static' on a variable limits usage, i.e.,
>>>> scope, to that procedure.  Although, the data is preserved across
>>>> procedure calls, just like a file scope variable, instead of being
>>>> created and destroyed like a procedure 'auto' variable.  So what
>>>> real advantage does a 'static' variable have over a file scope
>>>> variable?  (rhetorical, i.e., I think the answer is: 'none'.)
>>>
>>> I'll answer anyway! In
>>>
>>>   int f(....) {
>>>     static int aa;
>>>
>>> the variable aa is protected against modification from any other
>>> function. It's like a global but one that no other function can
>>> change.
>>
>> Um, why would another function, one which you most likely coded,
>> modify your own variable, when you had no need whatsoever to modify
>> said variable in the other function and were aware it shouldn't be?
>> (It's like you don't trust yourself.)
>>
>> Similarly, why would another function, one which someone else likely
>> coded prior to you coding your function, modify your variable when
>> they didn't even know about said variable existed at the time?
>> (It's like you believe the "god's" are sabotaging you.)
>>
>> Similarly, why would someone coding another function after you coded
>> your function, take a look at your function's variable names, copy
>> the name intentionally while knowing that an name collision is likely
>> to cause a crash or corruption?  (It's like they're sabotaging you.)
>>
>> etc
>
> Or,
>
> Why would you make a function or, worse, a variable accessible to
> every module in your project unless it needed to be?

What modules?  As stated elsewhere, most of my programs are
single file.  Those that aren't, don't have namespace collisions
due to the happenstance of having different purposes.

Who or what is going to use them?  Please answer that.  You keep
avoiding defining who or what is going to use them or when.  I.e.,
you seem to be "solving" a problem for which you can't accurately
define or articulably describe to me.

Why would other code use them?  The other code already has access
to the functions which modify these supposed variables.  With all
the emphasis on portable C code in the C community, I find it hard
to believe that you'd believe people would _intentionally_ decide
to use variables they have no need to access.  Obviously, I'm
excluding hackers or other malicious people by default.

If overly cautious or paranoia over "security" or "safety" is your
driving motivation for doing these things, you should say so.

>> I.e., see "lanuage", snipped.)
>>
>>>> two of which have to do with linking.  That opens up the opportunity
>>>> for misuse and errors of the keyword 'static', which can be avoided
>>>> by simply not using 'static'.
>>>
>>> On the contrary, use of "static" helps prevent misuse.
>>
>> Misuse by whom exactly?  You coded it.  Why did you misuse it?
>
> Where it's appropriate you *lose* absolutely nothing by using
> static at file scope. You gain a good deal.

When is it appropriate?  Other code shouldn't be using your code's
variables, unless they were intended to be used as externs.

Yes, you lose time, and perhaps inability to link to a variable that
should've been exportable, but was erronously marked 'static'.

What do you gain?  Lack of access?  Exactly ow is that a gain? ...

>>>>> Outside a function static says to keep the declaree private and
>>>>> not share it with other source files. IME that can be useful
>>>>> for variables and functions.
>>>>
>>>> If the other source files are "unaware" of the variable, because
>>>> the programmer did not declare said variable as an 'extern' in the
>>>> other source files, how would the source file "know" of said
>>>> variable?
>>>
>>> Consider
>>>
>>>   file1.c
>>>     int aa;
>>>     static int bb;
>>>     void ff(....) { .... }
>>>     static void gg(....) { .... }
>>>
>>>   file2.c
>>>     int aa; <== error
>>>     static int bb; <== no error
>>>     void ff(....) { .... } <== error
>>>     static void gg(....) { .... } <== no error
>>
>> So, you have to use file scope variables, which someone using 'static'
>> likely won't do  AT ALL,
>
> No, it's not the case that someone using static for a variable defined
> in a function will never use a file-scope variable. One of the problems
> with static in a function is that the variable thus declared is only
> visible in that function. C doesn't have a way for two or three
> functions to share a private variable as some languages do.

Sure it does.  You just refuse to accept a global as being
sufficiently 'private'.

Who or what is going to link against your code when said who or what
is unaware of what it contains and has little to no use of it except
to use exported functions?  Overcompensation.

> The alternative is a global. That can be shared between, say, two
> functions but then it is visible to every other function. File-scope
> statics provide a way to have a global that is only visible to the
> functions in the same source file.

How "visible" is __My_custom_flag_variable0_funcs or XFFABeq_ to
someone who is unaware of their presence?  Even a variable named
'aa' is of low use ...  Now, 'i', 'j', or 'k' are a different matter,
but who would use them globally?  ...  They're used for local loops.

What is so critical to you that you're wasting time protecting it?
I.e., what is your rationalization for doing so in all instances
when it is only truly needed for a few rare instances?

> I am not sure if you are aware or not but in C any name defined
> at the top level is publicly visible by default.

Irrelevant.

> You can declare it static to make it private to that file.

Why bother?

> I think that's a good simple rule and easy to use appropriately.

What's your justification for doing this?

Honestly, ISTM that you don't have one other than it "feels" right
to you, or perhaps was what you were taught once, or you "see" it
as an easy safety or security measure.

Besides, if you can't link to the OS, what real damage can a hacker
do without that ability?  If the hacker can't attack the file system,
there isn't much of note that they can do.  Reboot.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8806

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x4xiljipyfako5@localhost...
> On Sun, 13 Sep 2015 14:48:24 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>> news:op.x4wjvxy0yfako5@localhost...
>>> On Sun, 13 Sep 2015 05:28:45 -0400, James Harris
>>> <james.harris.1@gmail.com> wrote:
>>>> "Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message
>>>> news:op.x4v45jxsyfako5@localhost...
>
>>>> You can modify your local copy of x in the function but the 
>>>> compiler
>>>> should stop you modifying your y and w (thereby giving you 
>>>> assurance
>>>> in
>>>> a long function that you can always access the original values
>>>> anywhere
>>>> in that function knowing that no other part of the function code 
>>>> has
>>>> changed them).
>>>
>>> s/updated/changed/
>>>
>>> I take issue with your use of "updated" when you meant "changed" 
>>> here.
>>> To me, "updated" means being modified and returned from the 
>>> function.
>>
>> Semantics nonsense (IMO)! Whether you say that the local copy is
>> updated/changed/modified/altered or whatever, all mean the same 
>> thing.
>
> Well, I'm not looking to provoke an argument on this issue, but I very
> **STRONGLY**  disagree with your opinion here.  I just didn't want to
> come off as angry or hostile towards you when I take issue with your
> opinion ...

That's OK. This is a discussion group after all and we have different 
opinions. I recognise that my opinion is just an opinion too. I added 
the "(IMO)" for that reason. The Semantics nonsense! part was just my 
surprise that you had seemed to attach a different semantics to a single 
word and build so much on that different interpretation.

> I programmed in PL/1 for a number of years and learned from it that
> pass-by-reference is all you need.  You don't need pass-by-value at
> all.

Sure.

> I literally used pass-by-value only once for PL/1.

That takes me back. You mean PL/1 let you choose the passing mode? I 
hated PL/1.

> One of C's
> largest mistakes, if not it's biggest, was pass-by-value being default
> instead of pass-by-reference.

Again, I am surprised you feel that way. As you know, any value can 
effectively be passed by reference by passing its address. That doesn't 
work for expressions but if a compiler passed by reference it would 
still have to find space for such results.

>> Whichever word you use the local copy is still the one affected,
>> not the caller's copy.
>
> IMO, not true.
>
> From what I've seen, I'm confident that most C programmers use
> pass-by-reference which passes the modified value back to the caller.

That's easy to do.

> The exception is if they wish to intentionally preserve the passed
> value in the caller, which is rarely needed.

OK. Wow! I wouldn't want a callee to be able to change my vars without 
me specifically letting it do so.

> C is most effective
> when used as a pointer and integer based language.

Interesting view.

...

>> Or
>>
>> 4) Use 'const' where you can so that the compiler will do the check 
>> for
>> you. (And it makes a useful addition to the documentation for free.)
>
> Which is still a waste of time and overcompensation for an event which
> you're not even sure has any likelyhood at all that it will ever occur 
> ...
>
> You can call it "proactive" or "cautious" if you wish, and maybe the
> cost of doing so is trivial to you, but without having any rational
> justification at all for doing this, AFAICT, why would you? ...

...

>> Or,
>>
>> Why would you make a function or, worse, a variable accessible to
>> every module in your project unless it needed to be?
>
> What modules?

Different source code files.

> As stated elsewhere, most of my programs are
> single file.  Those that aren't, don't have namespace collisions
> due to the happenstance of having different purposes.

Sure. Your choice.

> Who or what is going to use them?  Please answer that.  You keep
> avoiding defining who or what is going to use them or when.  I.e.,
> you seem to be "solving" a problem for which you can't accurately
> define or articulably describe to me.

I am not avoiding anything. Use different source files? Use variables 
and functions which are private to a single module, you mean? Me for 
one. I can only speak for myself.

> Why would other code use them?  The other code already has access
> to the functions which modify these supposed variables.  With all
> the emphasis on portable C code in the C community, I find it hard
> to believe that you'd believe people would _intentionally_ decide
> to use variables they have no need to access.  Obviously, I'm
> excluding hackers or other malicious people by default.

Some would! Others might introduce conflicts by accident. I might even 
do that myself if I went back to a piece of code after 6 months or more.

> If overly cautious or paranoia over "security" or "safety" is your
> driving motivation for doing these things, you should say so.

No. Sensible precautions, though.

...

>> Where it's appropriate you *lose* absolutely nothing by using
>> static at file scope. You gain a good deal.
>
> When is it appropriate?  Other code shouldn't be using your code's
> variables, unless they were intended to be used as externs.

Do you leave your front door unlocked because other people shouldn't be 
coming in without your say so? Do the countries of Europe open their 
borders because migrants and refugees won't cross freely? Er, strike 
that last one!

> Yes, you lose time, and perhaps inability to link to a variable that
> should've been exportable, but was erronously marked 'static'.

If it was erroneously marked then you can unmark it.

...

I have snipped the rest as it seems to go over similar ground. The 
bottom line is that I know from past discussions and here that you like 
large open projects, single source files, to be able to bypass 
interfaces etc. That's your choice. I prefer modularity.

James

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

#8821

On Mon, 14 Sep 2015 18:17:05 -0400, James Harris <james.harris.1@gmail.com> wrote:

>> I programmed in PL/1 for a number of years and learned from it that
>> pass-by-reference is all you need.  You don't need pass-by-value at
>> all.
>
> Sure.
>
>> I literally used pass-by-value only once for PL/1.
>
> That takes me back. You mean PL/1 let you choose the passing mode? I
> hated PL/1.

It was an early form of PL/1 based on one of the first standards.
It was not IBM's PL/I which was a much later version.  IBM uses the
letter I, they used the number 1.  It looked more like Pascal with
pointers and PL/1 data structures, etc.  IIRC, you just put paren's
around the value in the procedure call to pass-by-value.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8822

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x496chtgyfako5@localhost...
> On Mon, 14 Sep 2015 18:17:05 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>>> I programmed in PL/1 for a number of years and learned from it that
>>> pass-by-reference is all you need.  You don't need pass-by-value at
>>> all.
>>
>> Sure.
>>
>>> I literally used pass-by-value only once for PL/1.
>>
>> That takes me back. You mean PL/1 let you choose the passing mode? I
>> hated PL/1.
>
> It was an early form of PL/1 based on one of the first standards.
> It was not IBM's PL/I which was a much later version.  IBM uses the
> letter I, they used the number 1.  It looked more like Pascal with
> pointers and PL/1 data structures, etc.  IIRC, you just put paren's
> around the value in the procedure call to pass-by-value.

Oh, OK. I had an idea that PL/I allowed the passing mode to be defined 
in the function or procedure definition's parameter list so that the 
caller had no idea what mode would be used and could end up getting its 
variables changed secretly. That is, admittedly, a very vague 
recollection, though, and apparently for a different language than the 
one you were talking about.

James

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

#8750

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:39da71f8-7e21-4fcb-84da-263d5c81059f@googlegroups.com...
> One more improvement for Ben's 50+K executable. :)
> Actually, I've had a couple of requests for this.
>
> Anyway, the prologue/epilogue parts are now shorter.
>
> This is what Smaller C used to generate:
> _foo:
>  push bp
>  mov  bp, sp
>  jmp  L1
> L2:
>  ...
>  leave
>  ret
> L1:
>  sub  sp, size_of_locals
>  jmp  L2
>
> This is what it generates now:
> _foo:
>  push bp
>  mov  bp, sp
>  sub  sp, size_of_locals
>  ...
>  leave
>  ret
>
> If there are no locals, there's no sub either. This shaves ~500 bytes
> off a 64KB 16-bit code section.
>
> The trick? fgetpos()/fsetpos() majic.
> The price? Must always supply the output assembly file name to smlrc.

Alex,

I hope you don't mind, may I make a small suggestion for your above
code?

@@ -6965,7 +6965,7 @@
 #endif
 #endif
         GenFxnProlog();
-        CurFxnEpilogLabel = LabelCnt++;
+        CurFxnEpilogLabel = 0;

         AddFxnParamSymbols(lastSyntaxPtr);

@@ -6997,7 +6997,9 @@
           GenExpr();
         }

-        GenNumLabel(CurFxnEpilogLabel);
+        // only need to include the label if we used it
+        if (CurFxnEpilogLabel > 0)
+          GenNumLabel(CurFxnEpilogLabel);

 #ifndef MIPS
 #ifdef CAN_COMPILE_32BIT
@@ -7460,7 +7462,7 @@
       // If this return is the last statement in the function, the epilogue 
immediately
       // follows and there's no need to jump to it.
       if (!(tok == '}' && ParseLevel == 1 && !Main))
-        GenJumpUncond(CurFxnEpilogLabel);
+        GenJumpUncond(CurFxnEpilogLabel = LabelCnt++);
     }
     else if (tok == tokWhile)
     {

Currently, whether the label is needed or not, your/my code supplies
the ending label 'CurFxnEpilogLabel'.  No big deal, the output assembles
just fine.  However, one less label to see/process/store/etc., if
you make the above change.

Hope you don't mind me sending you a diff and a suggestion.

Please let me know if the above change will break anything though.

Thanks,
Ben

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

#8751

Alex,

Just another comment, I hope you don't mind.

I don't remember ever seeing the following until tonight.

  int some_int[5] = {[0]=1, [2]=3, [4]=5};

I guess it is C99 only.
 https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Designated-Inits.html

This would make it quite useful when setting flags in an ascii
chart.  e.g.:

  int whitespace[256] = { [' '] = 1, ['\t'] = 1, ['\n'] = 1 };

It looks like GCC also supports

  int some_int[5] = {[0...3]=1, [4]=5};

which is probably not C89 or C99 compliant.

Anyway, I am just curious, do you have interest in implementing
at least:

  int some_int[5] = {[0]=1, [2]=3, [4]=5};

I guess if you did, you would have to check for '[' in
InitScalar() just before ParseExpr(), if found, call
ParseExpr() to return the index value (ex: [0] or [' '] ),
then call ParseExpr() as normal.

However, InitScalar() is called incrementally for each
element of the array within InitArray().  Some how you
would have to keep track of which element index you
were initializing, so that if [2] = 1 is found and you
have not initialized [0] or [1] yet, you would initialize
those to zero and increment to [2] before setting it to 1.

Also, how about

  int some_int[5] = {[1]=1, [2]=3, 22, 33};

This would initialize index 0 to 0, 1 to 1, 2 to 3, and then
4 to 22 and 5 to 33, correct?

What about?

  int some_int[10] = {[3]=1, 22, 33, [7]=3, [8]=5};

This should be valid code, where as

  int some_int[10] = {[3]=1, 22, 33, [4]=3, [5]=5};

should return a parsing error since elements (indexes)
4 and 5 have already been initialized and the parser is
expecting at least index 6 to be next after the 33.

Anyway, just a thought.  Hope you don't mind me asking
these questions.  It is more for my sake, "talking" it out
kind of helps visualize it for me.

Thanks,
Ben

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

#8756

On Friday, September 11, 2015 at 10:29:36 PM UTC-7, Benjamin David Lunt wrote:
> Alex,
> 
> Just another comment, I hope you don't mind.
> 
> I don't remember ever seeing the following until tonight.
> 
>   int some_int[5] = {[0]=1, [2]=3, [4]=5};
> 
> I guess it is C99 only.
>  https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Designated-Inits.html
> 
> This would make it quite useful when setting flags in an ascii
> chart.  e.g.:
> 
>   int whitespace[256] = { [' '] = 1, ['\t'] = 1, ['\n'] = 1 };
> 
> It looks like GCC also supports
> 
>   int some_int[5] = {[0...3]=1, [4]=5};
> 
> which is probably not C89 or C99 compliant.
> 
> Anyway, I am just curious, do you have interest in implementing
> at least:
> 
>   int some_int[5] = {[0]=1, [2]=3, [4]=5};
> 
> I guess if you did, you would have to check for '[' in
> InitScalar() just before ParseExpr(), if found, call
> ParseExpr() to return the index value (ex: [0] or [' '] ),
> then call ParseExpr() as normal.
> 
> However, InitScalar() is called incrementally for each
> element of the array within InitArray().  Some how you
> would have to keep track of which element index you
> were initializing, so that if [2] = 1 is found and you
> have not initialized [0] or [1] yet, you would initialize
> those to zero and increment to [2] before setting it to 1.
> 
> Also, how about
> 
>   int some_int[5] = {[1]=1, [2]=3, 22, 33};
> 
> This would initialize index 0 to 0, 1 to 1, 2 to 3, and then
> 4 to 22 and 5 to 33, correct?
> 
> What about?
> 
>   int some_int[10] = {[3]=1, 22, 33, [7]=3, [8]=5};
> 
> This should be valid code, where as
> 
>   int some_int[10] = {[3]=1, 22, 33, [4]=3, [5]=5};
> 
> should return a parsing error since elements (indexes)
> 4 and 5 have already been initialized and the parser is
> expecting at least index 6 to be next after the 33.
> 
> Anyway, just a thought.  Hope you don't mind me asking
> these questions.  It is more for my sake, "talking" it out
> kind of helps visualize it for me.

This is one of those features that require keeping potentially
a lot of data in the memory of the compiler, which isn't
something I'm happy about. Nor am I happy about restructuring
the code in order to be able to go back in the input or the
output. I've made two small exceptions for very common and
limited cases: switch cases (the constants and the labels are
accumulated internally in the compiler, but usually there are
not too many of them) and function prolog(ue)s (the structure/
layout of this code is known beforehand and its size is small,
so, over/re-writing it in the output file is easy and cheap).
Arrays, OTOH, can be pretty big. And this feature is especially
useful with big arrays. IOW, it asks for a full implementation,
needing either a lot of memory potentially or complicating the
code. I've repeatedly stated that I'm not making yet another
full and good compiler, I'm making a relatively small and
simple one, non-optimizing and without some languages or
usability features. If you want this feature, you will have to
implement it yourself.

Alex

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

#8762

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:d372f8e1-159d-4c24-8d70-f08b14891c98@googlegroups.com...
> On Friday, September 11, 2015 at 10:29:36 PM UTC-7, Benjamin David Lunt 
> wrote:
>> Alex,
>>
>> Just another comment, I hope you don't mind.

<snip code>

>> Anyway, just a thought.  Hope you don't mind me asking
>> these questions.  It is more for my sake, "talking" it out
>> kind of helps visualize it for me.
>
> This is one of those features that require keeping potentially
> a lot of data in the memory of the compiler, which isn't
> something I'm happy about. Nor am I happy about restructuring
> the code in order to be able to go back in the input or the
> output. I've made two small exceptions for very common and
> limited cases: switch cases (the constants and the labels are
> accumulated internally in the compiler, but usually there are
> not too many of them) and function prolog(ue)s (the structure/
> layout of this code is known beforehand and its size is small,
> so, over/re-writing it in the output file is easy and cheap).
> Arrays, OTOH, can be pretty big. And this feature is especially
> useful with big arrays. IOW, it asks for a full implementation,
> needing either a lot of memory potentially or complicating the
> code. I've repeatedly stated that I'm not making yet another
> full and good compiler, I'm making a relatively small and
> simple one, non-optimizing and without some languages or
> usability features.

I completely understand.  I was going through some C compiler
sights looking for example source to test a given compiler and
found the article I mentioned before.

Of course my compiler spit up on the declaration line and so I
looked through it a bit to see what it would take to implement
this feature.

If it is only implemented on non-structure/union declares, then
it shouldn't be to difficult to implement.

As for the structure declares, such as

struct SOMESTRUCT {
  int foo;
  int bar;
} = s[100] {
  [40].foo = 1,
  [50].bar = 2
};

this may take a little more work, though maybe not too much,
since .foo and .bar are simply offsets from the [40] element
anyway.

Just thought I would comment.

> ...you will have to implement it yourself.

The only concern I have, and it only concerns myself on this, is
if I implement it in my code, if I ever need to compare your
additions, it is a lot more work to work around my implementation
compared to your implementation/additions/enhancements.

If I start to implement things of this sort, I then have
to pull away from keeping my code somewhat relative to yours.
I don't know if I am ready to do that yet :-)

Thanks,
Ben

P.S. What I was looking for were snippets of code that implement
techniques that most people don't use.

For example, the following technique is seldom used but makes
for an excellent syntax check on the coder's point of view.

  if (2 == i)

which, by the way, your compiler compiles just fine.

The above technique, for those who have not seen it, makes
sure that the coder doesn't accidentally forget the second
'=' sign as in

  if (i = 2)  // <-- coder should have done  'if (i == 2)'

The above will produce a TRUE response every time no matter
what 'i' contains.  The compiler won't catch it as a syntax
mistake since it is valid syntax.  It would be up to the
coder to catch it.  However, if the immediate is first,
the compiler will catch it every time.

By the way Alex, SmallerC gives an error for

  if (2 = i)

where as my compiler crashes.  I must have a null-pointer
or something.  I will have to look into that.

See, this is why I was looking for code like this :-)

Anyway, thanks.  Ben

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

#8763

"Benjamin David Lunt" <zfysz@fysnet.net> wrote in message 
news:mt1qa9$gsp$2@speranza.aioe.org...

> By the way Alex, SmallerC gives an error for
>
>  if (2 = i)
>
> where as my compiler crashes.  I must have a null-pointer
> or something.  I will have to look into that.

Exactly what it was.  I was setting the value of 2 as being
initialized, instead of checking first if it was a tokIdent.

Ben

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

#8767

On Sat, 12 Sep 2015 14:18:50 -0400, Benjamin David Lunt <zfysz@fysnet.net> wrote:

> For example, the following technique is seldom used but makes
> for an excellent syntax check on the coder's point of view.
>
>   if (2 == i)
>
> which, by the way, your compiler compiles just fine.
>
> The above technique, for those who have not seen it, makes
> sure that the coder doesn't accidentally forget the second
> '=' sign as in
>
>   if (i = 2)  // <-- coder should have done  'if (i == 2)'
>
> The above will produce a TRUE response every time no matter
> what 'i' contains.  The compiler won't catch it as a syntax
> mistake since it is valid syntax.  It would be up to the
> coder to catch it.  However, if the immediate is first,
> the compiler will catch it every time.

I've seen it, but not in any code after the early 1990's ...
I recall older C coding guidelines having examples like that.
AFAIR, the only recommendation I ever chose to use was to
#define a mask and use with bitwise operators instead of using
C's bitfields.  Supposedly, bitfields weren't implemented
properly in some of the older C compilers.

You might also look for MISRA and Safer C which have a bunch
of rules for safer C coding.

"Indian Hill C Style and Coding Standards", an updated version
http://ieng9.ucsd.edu/~cs30x/indhill-cstyle.html

Ten C Commandments
http://www.quut.com/c/ten-commandments.html

Portable C
http://web.archive.org/web/20110725164734/http://www.chris-lott.org/resources/cstyle/portableC.html

Some C9X webpages on C99 changes via Wayback archive:
http://web.archive.org/web/20070119191725/http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/newinc9x.htm
http://web.archive.org/web/20070807074051/http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html

MISRA coding rules etc
http://www.knosof.co.uk/misracom.html
http://www.leshatton.org/index_SA.html

Safer C
http://www.saferc.com/
http://www.saferc.com/safer-c-toolset/


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

#8786

On Sun, 13 Sep 2015 03:47:01 -0400, Rod Pemberton <boo@fasdfrewar.cdm> wrote:

> "Indian Hill C Style and Coding Standards", an updated version
> http://ieng9.ucsd.edu/~cs30x/indhill-cstyle.html
>
> Ten C Commandments
> http://www.quut.com/c/ten-commandments.html
>
> Portable C
> http://web.archive.org/web/20110725164734/http://www.chris-lott.org/resources/cstyle/portableC.html
>
> Some C9X webpages on C99 changes via Wayback archive:
> http://web.archive.org/web/20070119191725/http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/newinc9x.htm
> http://web.archive.org/web/20070807074051/http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
>
> MISRA coding rules etc
> http://www.knosof.co.uk/misracom.html
> http://www.leshatton.org/index_SA.html
>
> Safer C
> http://www.saferc.com/
> http://www.saferc.com/safer-c-toolset/
>

Also,

Incompatibilities between ISO C and ISO C++
http://david.tribble.com/text/cdiffs.htm


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?

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

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

Back to top | Article view | alt.os.development

csiph-web