Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

[Holloway Kean Ho]

> I think the amount of hair-splitting over what is an object oriented 
language is reason to say it *isn't* an Object Oriented language at all.

Given the FAQ header's "Is Go an object-oriented language? emphasizing that 
"object-oriented" is in lowercase, not the titlecase "Object-Oriented" that 
generally points to OOP context: it is why I treat the FAQ "yes and no" as 
an acceptable answer. 

My exhibits:

   1. Linux kernel is mainly based on C, but it managed to grouped its 
   driver data into an object-oriented way (various types of IO IP products) - 
   See (https://elixir.bootlin.com/linux/latest/source/drivers)
   2. Go's various standard packages like (url, strings, http, etc), 
   they're oriented to a specific data type. See URL package 
   (https://pkg.go.dev/net/url@go1.19.3#URL)
   3. Unlike C, Go and Rust has interface methods that behaves similar to 
   an OOP Class (see URL in #2).

Therefore, you can't say they aren't OO but you certainly can say they 
incompatible with the conventional OOP.

If an amendment is required, I believe the missing context (OO in plain 
English or OO in OOP) has to be explictly clarified.  As far as definitions 
goes, they are 2 different contexts. OOP is an implementation/subset of OO.

One thing for sure: I agreed that the mentioned FAQ header is a bit cheesy.




>> Cars do not fly. Planes don’t use roads. Classes are abstractions that 
model required attributes that in turn compose a system to do useful work. 
Both boats and cars move. You can use a boat to get from a to b if there is 
no water. 
>> If someone said “I have a car for sale”, and you showed up and it had no 
wheels but a hull and a sail - you might be a bit upset.
>> Whether Go is a car or a boat is up to the experts.
> Labels/common language is what allows societies to exist. As in this 
case, I believe your ESL has caused you to issue some statements above that 
make it difficult for people to understand what you are trying to say and 
may even interpret them to mean you are a rude person that should be 
ignored.
> If you claim that labels are only useful when “it’s obvious what it is” - 
how do you determine it is obvious? Your personal experience/knowledge? An 
accepted “reference guide”?

If I re-phrase one of your example, it would be:

"I have a car (object) for sale" -> "Toyota Camry" (label) vs. "Tesla Model 
S" (label) vs "AeroMobil 3.0" (label)

   1. They are all unilaterally labelled as "car". Can you say all 3 of 
   them are not object-oriented towards "car" definition? (OO)
   2. When and how should we specify a "car" across automobile and 
   aeronautics industries? Electric motors vs ICE engine? engine capable of 
   flying + on the road? defined, ratified, and enforced by who or whom? (OOP)

I still don't see the examples ("car vs boat", "Acme1000 vs Beta1000") 
relevancies. However, given the tone and the frames of those examples, I 
did observed a known burnt-out pattern of a developer overworked for a long 
time to the point where a "car" and a "boat" can no longer be cognitively 
differentiable eventhough their clearly different in nature, unrelated to 
the labelligng topic at all. This is a severe symptom and I called out the 
psychological matter.

Given the recent mass layoffs, I'm not surpirsed some managers can pressure 
the team to perform beyond limits. No ill intent. Sorry if you take it 
another way.

Peace. Cheers!


Regards,
Holloway

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/730c3130-e4e9-4db5-87f6-589567f86fben%40googlegroups.com.

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

[Holloway Kean Ho]

> If the answer to that question is "yes and no," it'd be less ambiguous to 
simply say, "no."  And that would be a definitive way of indicating that it 
woul be inappropriate to apply many patterns from object oriented languages 
to Go -- and to encourage people to accept Go for what it is.
Go does facilitate data grouping towards a subject or an object. In fact, 
even C does that. By grouping your data and methods towards an object, you 
attained OO. Hence, that's the "yes" part. It's all down to your languages' 
mastery.

The "No" part is that Go, C, and even Rust are not honoring "polymorphism" 
where this contradicts 1/6 main traits of the OOP (thanks god but that's 
not a dare). Polymorphism had been a known problem for bloating and causing 
unwanted spaghettied data definitions all over the places AND confuse basic 
programming paradigm like "bloating class vs when to use modules" case. 
These problems had been plaguing known languages like Ruby.

Since the "Car" object is mentioned, try updating "Car" definition after 
you defined 2000+ car derivatives and its sub-derivatives using 
polymorphism, deployed across the world. I'm pretty sure various depts will 
come after you (either by their incompetence in OOP or your update broke 
their derived definitions). Therefore, Go, C, Rust, and similar, as an 
improvement measure, all work towards OOP's compositions heavily.

Bottomline: it depends on how deep you understand OO paradigm and how far 
you mastered a programming language OR be blindly religious about OOP.

Site-note: fanatism never ends well anywhere in this world; it had been 
proven and tested by time.



> Cars do not fly. Planes don’t use roads. Classes are abstractions that 
model required attributes that in turn compose a system to do useful work. 
Both boats and cars move. You can use a boat to get from a to b if there is 
no water. 
> If someone said “I have a car for sale”, and you showed up and it had no 
wheels but a hull and a sail - you might be a bit upset.
> Whether Go is a car or a boat is up to the experts.
Your examples have something to do with the developer's psychological 
problem for failing to distingush between objects; not OO, OOP, or any 
programming languages. Neither Java or Go can rescue your situation. You 
should consider:

   1. Review his/her manager's work ethics for possible abusement.
   2. Get psychological help online for him/her.
   3. Communicate with your PM for porject's risk mitigation.
   4. Help him/her find a comaptible job.


Regards,
Holloway
On Thursday, November 24, 2022 at 9:44:54 AM UTC+8 ren...@ix.netcom.com 
wrote:

> Human beings survive by classifications and compartmentalizing. Applying a 
> label associates it with certain traits.
>
> If someone said “I have a car for sale”, and you showed up and it had no 
> wheels but a hull and a sail - you might be a bit upset.
>
> Whether Go is a car or a boat is up to the experts.
>
> On Nov 23, 2022, at 7:27 PM, Rob Pike  wrote:
>
> Let me ask, because I'm genuinely curious: Why does it matter? The labels 
> we apply to things do not affect their function. Perhaps it affects how we 
> think about them. Is that it?
>
> -rob
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOXNBZS1vuSVcuHHgybwQH6e39ZRFH1eZaBUw%3D6nUj5sbpij%3DA%40mail.gmail.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8aaff17a-2462-46f4-8d01-9737234393c7n%40googlegroups.com.

[go-nuts] Re: Which one is the latest optimization: ASM/Pure Go implementations?

[Holloway Kean Ho]

Hi Keith,

>  The stdlib is organized to take advantage of hardware instructions when 
they are available and falls back to portable Go code when they aren't.
You actually answered my question == the ASM is the latest optimization 
direction. So the desgin sequences are always:

1. Pure software solution first
2. Abstract some Step #1 and then optimize parts of it to ASM when 
resources permits / requirement requires

The reason I'm asking is to make sure I'm won't end up like "Go vs cGo" 
case where the efforts are always pure Go whenever possible and only use 
cGo in absolute no-choice situation.


> It sounds to me like you're more interested in portability, so I suggest 
you just use the portable code (e.g. promote `floor` to `Floor` and get rid 
of all the other wrapping code (the existing `Floor`, `haveArchFloor`, 
`archFloor`, the .s files, etc.).
Nahh, I'm not going to throw away stable and tested codes. It's very rude 
considering these efforts were backed by a lot of research papers and 
efforts.

The good news is that I managed to find a "zen" way with gobuild flags to 
calm my heart and head yesterday. What I did was to offer the portable Go 
codes and hardware accelerated one as 2 different API and it's up to the 
customer to decide (It's their design call anyway, not ours).


Regards,
Holloway
On Friday, November 11, 2022 at 7:41:54 AM UTC+8 k...@google.com wrote:

> I'm not sure exactly what the question is that you're asking here. "latest 
> and right optimization direction" doesn't make any sense to me.
>
> The stdlib is organized to take advantage of hardware instructions when 
> they are available and falls back to portable Go code when they aren't.
> It sounds to me like you're more interested in portability, so I suggest 
> you just use the portable code (e.g. promote `floor` to `Floor` and
> get rid of all the other wrapping code (the existing `Floor`, 
> `haveArchFloor`, `archFloor`, the .s files, etc.).
>
> On Wednesday, November 9, 2022 at 10:21:09 PM UTC-8 hollowa...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> To clarify, which one is latest and right optimization development 
>> direction?
>>
>>
>> Example case:
>>
>> (floor_asm.go <--> floor_amd64.s VS floor_noasm.go)
>>
>> 1) 
>> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_asm.go;bpv=0;bpt=0
>>
>> 2) 
>> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_amd64.s;bpv=0;bpt=0
>>
>> 3) 
>> https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor.go;l=21;bpv=0;bpt=0
>>
>>
>> Context:
>>
>> 1) I'm currently adopt+modifying the standard library to facilitate 
>> TinyGo and translatable to Rust. => 1 peaceful standard library 
>> complementing the existing standard libraries.
>>
>> 2) The objective is support coverage (e.g. works on as many hardware as 
>> possible) over some performance sacrifice.
>>
>>
>> 3) My heart tells me noasm.go is the latest because:
>>
>> 3.1) ultimately Go developer can achieve consistent results independnet 
>> of hardware; thus, does not restrict one to sell kidney for getting MYR10k+ 
>> hardware. TinyGo can operate with this at no issue (tested as well).
>>
>> 3.2) Heartbleed bug case proven that relying hardware can cause 
>> inconsistency results despite proper software.
>>
>>
>> 4) My head tells me asm.go is the latest because:
>>
>> 4.1) why self-impose limits when hardware can perform better.
>>
>>
>> Thanks in advanced.
>>
>>
>> Regards,
>>
>> Holloway
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9e16ef35-1669-46ca-89e2-96a1952003b2n%40googlegroups.com.

[go-nuts] Which one is the latest optimization: ASM/Pure Go implementations?

[Holloway Kean Ho]

Hi all,

To clarify, which one is latest and right optimization development 
direction?


Example case:

(floor_asm.go <--> floor_amd64.s VS floor_noasm.go)

1) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_asm.go;bpv=0;bpt=0

2) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor_amd64.s;bpv=0;bpt=0

3) 
https://cs.opensource.google/go/go/+/refs/tags/go1.19.2:src/math/floor.go;l=21;bpv=0;bpt=0


Context:

1) I'm currently adopt+modifying the standard library to facilitate TinyGo 
and translatable to Rust. => 1 peaceful standard library complementing the 
existing standard libraries.

2) The objective is support coverage (e.g. works on as many hardware as 
possible) over some performance sacrifice.


3) My heart tells me noasm.go is the latest because:

3.1) ultimately Go developer can achieve consistent results independnet of 
hardware; thus, does not restrict one to sell kidney for getting MYR10k+ 
hardware. TinyGo can operate with this at no issue (tested as well).

3.2) Heartbleed bug case proven that relying hardware can cause 
inconsistency results despite proper software.


4) My head tells me asm.go is the latest because:

4.1) why self-impose limits when hardware can perform better.


Thanks in advanced.


Regards,

Holloway

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5a5eb0d8-6071-4698-93ad-c352f8870622n%40googlegroups.com.

[go-nuts] Unicode AzeriCase == TurkishCase?

[Holloway Kean Ho]

Hi all,

Just to confirm, is the unicode special case "AzeriCase"  == "TurkishCase"?

Location: 
https://cs.opensource.google/go/go/+/go1.19.1:src/unicode/letter.go;l=64

I don't know about Turkish so help is needed just in case their charsets 
are different. Stumbled upon this while developing my own standard library 
and reading through the source codes.

Regards,
Holloway

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/884090ec-e4f8-4898-b3bb-e6ce76ddc361n%40googlegroups.com.

Re: [go-nuts] Is Go a security malware risk?

[Holloway Kean Ho]

On Thursday, August 25, 2022 at 4:58:18 PM UTC+8 Gopher-Insane wrote:

> Thank you kortschak, yes that was all I was doing. Seeking advice from 
> people who have better knowledge than me in this area. Again, very grateful 
> for everyone's help. 
>
> On Thursday, 25 August 2022 at 09:54:13 UTC+1 kortschak wrote:
>
>> On Thu, 2022-08-25 at 01:47 -0700, Holloway Kean Ho wrote: 
>> > What exactly you're trying to achieve by taking a very elaborated, 
>> > crystal-clear, good-willed security-related article way out of its 
>> > context with your thread title here and agitate some of the Go 
>> > maintainers here? 
>>
>> I don't think that's what the OP was doing. Bill Kennedy suggested they 
>> ask here, and I think that they have enough information/ideas to take 
>> back to their security team to address the misconceptions that they 
>> have. 
>>
>> All right. In that case, you can point the same article's 2nd last 
paragraph which is very self-explainatory.

This book (§1, §2, and §7.5) should give you a quick 
basic: 
https://www.cs.ox.ac.uk/andrew.ker/docs/computersecurity-lecture-notes-mt2014.pdf

This book should you give you a rough idea about introduction to 
specifically computing security technical aspect. Security itself has a lot 
of 
aspects.: 
http://www.uoitc.edu.iq/images/documents/informatics-institute/exam_materials/Introduction%20to%20Computer%20Security%20pdf%20DONE.pdf

This manual alone 
(https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html) 
can give you an idea that a system security (hardware+software) is about 
controlling quite a large number of aspects and considerations than being 
picky with a programming language is the very last thing to consider.

1 additional point to counter to the counter-argument is: neither one 
(within computing security scope alone) mention specifically of a 
programming language being a threat since most of contents are theorems, 
threat model + countermeasures, practices, etc etc.

The argument about behavorial detection in consumer-product 
AV: https://usa.kaspersky.com/resource-center/definitions/heuristic-analysis
And difference between behavorial detection vs heuristic 
analyis: 
https://security.stackexchange.com/questions/157797/what-is-the-difference-between-heuristic-based-and-behaviour-based-virus-scannin

Of course, given the current geo-political situation, you can search 
"heuristic analysis" of the AV of your choice and find out when they 
started the implementation. For Kas (I used to use it when I was on Windows 
OS long time ago), if I'm not mistaken, it was implemented all the way back 
since the transition from Windows XP to Windows 7 era. The rest of the 
competitors: I'm not aware of it.


> Apologies if this caused offense. That was never the intention. I am a 
big fan of Go myself, and this was raised to me by our Security team. I was 
seeking the advice of experts in the field to help me build an argument. I 
do fully appreciate everyone's help. 
Nahh, no worries. Be careful with framing the title next time. Some forums' 
zealots will skin you alive with that kind of touch.
 

Regards,
Holloway

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cda12c2d-d24b-447b-a8dd-72009c62e8bdn%40googlegroups.com.

Re: [go-nuts] Is Go a security malware risk?

[Holloway Kean Ho]

Hi,

I be very blunt here:

   1. What exactly you're trying to achieve by taking a very elaborated, 
   crystal-clear, good-willed security-related article way out of its context 
   with your thread title here and agitate some of the Go maintainers here?
   
Why I'm asking:

   - AFAIK, behavior scanning technique was long implemented in their AV 
   runtime detection (some time ago, comsumer product AV was requested to tone 
   down such method because it took so much resources to the point where the 
   CPU is too busy to the point of unsable) alongside the common signature 
   pattern matching technique.
   - I still hear Go developers on Windows complaining about their AV 
   blindly deleting their compiled Go binaries during their development.
   - The article specifically mention Go because Go had long achieved one 
   of its 'ease of use' strength so it's not surprising that it will become a 
   staple language for both good and maliciously motivated software in near 
   future.
   - Security is about constant learning, exploring, testing (including 
   outside the box thinking), and sharing. It's a habit and an attitude; not a 
   job. Go, Rust, C, C++, POSIX Shell, etc are merely tools. In fact, if you 
   comprehend the article correctly (2nd last paragraph), it implies that you 
   should and shall acquire these new tools and then upgrade your arsenals 
   ASAP collaobratively.
   - Security is a constant "cat chasing mouse" aspect. Sometimes the sword 
   is better than shield; sometimes the other way round; sometimes some 
   people misconfigured a pizza as a shield; sometimes you encounter manager 
   brought a properly configured shield offline for the sake of "convinence" 
   and "too much to learn". Given so many probability of disaster, the last 
   thing is to actively denying innovation (as in birth of new tools like Go, 
   Rust, etc) that builds better sword and shield.

I believe you already have you answer from the get-go.  Peace.

Regards,
Holloway

On Thursday, August 25, 2022 at 1:54:47 PM UTC+8 Amnon wrote:

> I learned a few things from the article.
> Apparently Go is an "unconventional language".  So Languages are divided 
> into "conventional" and "unconventional"
> languages. 
> I know a few languages. Some are statically typed, some have dynamic 
> typing. Some are interpreted and some are compiled.
> But I don't really know how one defines a conventional vs an 
> unconventional language, and how we distinguish between them,
> and what its properties are.
>
> The other thing I learned was that Go is a relatively new language. 
> I was under the mistaken impression that Go has existed for quite a while 
> - for over a decade.
> I thought that Go was first publicly launched in 2009 - an eternity ago in 
> the fast paced world 
> of software engineering. But perhaps the world of corporate security 
> software moves at a more 
> glacial pace, building systems and scanners which deal with languages 
> threats from decades ago. Perhaps their 
> definition of "new" is different from that of people in the rest of the 
> tech world. This may explain the ineffectiveness
> of corporate security systems in preventing a whole series of devastating 
> ransomware attacks on high profile organisations.
>
> More seriously, I do agree with the conclusion of the article, that 
> security tools need to focus on the behaviour of software
> rather than looking for signatures in a list of known pre-existing 
> malware. 
>
> On Wednesday, 24 August 2022 at 10:15:43 UTC+1 Gopher-Insane wrote:
>
>> Thanks, everyone for your replies. This will really help. 
>>
>> On Wednesday, 24 August 2022 at 06:28:04 UTC+1 Ian Lance Taylor wrote:
>>
>>> On Tue, Aug 23, 2022 at 2:23 PM Robert Engels  
>>> wrote: 
>>> > 
>>> > Doesn’t a different structure as per the Go FAQ imply a specialized 
>>> loader /runtime linker? I just assumed it did. 
>>>
>>> Go has a different program linker that generates the statically linked 
>>> executable, but a statically linked executable does not require a 
>>> loader or runtime linker. 
>>>
>>> Ian 
>>>
>>> > > On Aug 23, 2022, at 1:47 PM, Ian Lance Taylor  
>>> wrote: 
>>> > > 
>>> > > On Tue, Aug 23, 2022 at 9:29 AM Robert Engels  
>>> wrote: 
>>> > >> 
>>> > >> I did not read the analysis - just the thread here and earlier 
>>> threads on this subject. My understanding that even though Go is statically 
>>> linked the loader does relocations that confuse virus scanners. 
>>> > > 
>>> > > I'm not sure precisely what you mean, but I don't think that's 
>>> > > accurate. There is no Go loader. The statically linked binary 
>>> > > produced for a pure Go executable has no run-time relocations at 
>>> all. 
>>> > > 
>>> > > My assumption--and it is just an assumption--is roughly the reverse: 
>>> > > because pure Go programs are statically linked, and because the 
>>> symbol 
>>> > > table does not use the same names as a default C symbol table, a 
>>> virus 
>>> > > scanner ha

[go-nuts] Re: what is //go:build difference from //+build?

[Holloway Kean Ho]

They are build-constraints for cross platform support. 
Doc: https://pkg.go.dev/cmd/go#hdr-Build_constraints

I believe to-date is only using go:build. +build was for Go 1.16 and before 
so only use that if you plans to support legacy compiler.

On Thursday, June 16, 2022 at 10:37:16 AM UTC+8 cuiw...@gmail.com wrote:

> about when these feature add to golang?
> and is all we can do with //go:build can do with //+build, and vice versa?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d220284d-2500-451d-89f8-078806bdfc24n%40googlegroups.com.

Re: [go-nuts] how to protect source code

[Holloway Kean Ho]

>I want to encrypt my algorithm library, is there any good way in Go.  My 
library is used in both Windows and Linux
I'm assuming you're doing it for scalable distribution since Zhaoxun 
already answered local development environment. In this case it makes no 
sense as I can still use disassembler to reassemble your source codes after 
the decryption, either by software or many ways of reverse engineering 
techniques. Moreover, you will attract A LOT of insider threats (as in 
legit customers paid to reverse engineer your stuff, out of profits or 
curiosity). There were technologies in the past but highly I doubt they 
will work: hardware lock fuse bit and now TPM.

The only option I can see is host your library inside your own 
infrastructure and offer to client as an API services via network. That you 
can secure both binary and source codes forms within your own control while 
your customer enjoys your algorithm services. Otherwise, your business and 
marketing strategy have to step in. You can consult Spotify, and Google 
Cloud Key Management idea.

Don't rely on legal filing or copyright pursue unless you got 7 digits 
budget cash-ready to pay your attorney. It's not cheap and is a 
time-consuming process.


Regards,
Holloway
On Friday, March 18, 2022 at 10:33:21 AM UTC+8 yan.z...@gmail.com wrote:

> I think it is best to run your code on an encrypted disk. So it cannot be 
> stolen by taking away the hard-drive.
> Furthermore if the config and log files are in other folders, it is okay 
> to shut down the encrypted drive I guess.
> In that case even it is running in memory, the hacker cannot get access to 
> the program file on removed encrypted disk.
>
> Beyond that, there is  few software in the world up till now I believe, 
> could decode your program back to go source code.
> And it is a better practice to put all the codes together rather then 
> dividing it to smaller pieces to make more complexity.
>
> Zhaoxun
>
> 在2022年3月18日星期五 UTC+8 09:30:21 写道：
>
>> On Thu, Mar 17, 2022 at 6:46 AM bbb tt  wrote: 
>> > 
>> > I want to encrypt my algorithm library, is there any good way in Go. My 
>> library is used in both Windows and Linux 
>>
>> For a security issue like this it's essential to define the attack you 
>> want to defend against. 
>>
>> The nature of Go is such that against a sophisticated attacker the 
>> best you can do in practice is to hide source code comments, or to run 
>> your program only as a secure service that is only accessible over a 
>> network. And to do that you don't need to do anything special at all. 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57c781c1-2453-4ee6-bcf9-7cea740e31abn%40googlegroups.com.

Re: [go-nuts] Pointer to a pointer

[Holloway Kean Ho]

HI all, 

> Does anyone know what the upper bound on this could be?

Interesting question. I have a thought experiment theory: "LIMIT_MAX = 
(TOTAL_MEMORY - OTHER_SERVICES - DATA) / MBIT"

Explanation:
1. Assuming you're using 64-bit OS and memory structure is aligned using 
64-bit memory, your MBIT should be `uint64` for each memory address as a 
value.
2. Each level of pointer (e.g. pointer of pointer ) shall only consume 1 
`uint64` memory space.
3. Iterate the thinking recursively and you eventually ran out of memory 
available on a given system.
4. Hence, the upper limit, LIMIT_MAX shall be the remaining free memory 
after subtracting other services consuming the memory space 
(OTHER_SERVICES)  and the initial data size, the value of the first degree 
pointer (DATA).

Note:
1. For 32-bit memory addressing, it's at max 4GB at `uint32` per iteration 
due to the addressing capacity limit, which is why 64-bit CPU is created at 
the first place.


I may be wrong but I'm curious to know. As for how to prove it, I have no 
idea and I don't intend to crash my laptop at the moment. Besides, I never 
use pointer of pointer beyond 3 degree deep. =p

Regards,
Holloway

On Thursday, March 10, 2022 at 2:53:05 PM UTC+8 kortschak wrote:

> On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> > This morning someone asked about dereferincing a pointer to a pointer
> > to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer,
> > but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := &a
> > c := &b
> > UltimatePointOne(&c)
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum
> > * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
>
> I think aspects of this thread are sad. None of us know the background
> of the OP and this kind of thinking illustrates a joyful level of
> curiosity that could have been answered in a way that helps the
> questioner and build a positive community (for Shane, Rob did answer it
> and in way that is really quite deep, and thinking about how he
> answered it will teach you something that is worth learning).
>
> Calling a question "silly" demeans the questioner without understanding
> where they are coming from.
>
> Dan
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50570864-f5f2-4835-b22b-6852bfb49949n%40googlegroups.com.