Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8783
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Smaller C |
| Date | 2015-09-13 09:03 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x4wjvxy0yfako5@localhost> (permalink) |
| References | (15 earlier) <msvds4$ig1$1@speranza.aioe.org> <op.x4tlsdpnyfako5@localhost> <mt109k$kje$1@dont-email.me> <op.x4v45jxsyfako5@localhost> <mt3fgt$jot$1@dont-email.me> |
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?
Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web