Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #8799
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: Smaller C |
| Date | 2015-09-13 21:33 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.x4xiljipyfako5@localhost> (permalink) |
| References | (15 earlier) <mt109k$kje$1@dont-email.me> <op.x4v45jxsyfako5@localhost> <mt3fgt$jot$1@dont-email.me> <op.x4wjvxy0yfako5@localhost> <mt4ga8$gku$1@dont-email.me> |
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?
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