July 28, 2022

On Thursday, 28 July 2022 at 15:55:04 UTC, kdevel wrote:

>

On Thursday, 28 July 2022 at 14:57:36 UTC, pascal111 wrote:

> >

[...]
Sure. What effect do YOU hope to causes or prevent by writing

/******************************************/

between all of your functions?

I'm normal programmer, by mean that I'm not so expert in C matters to know really if there are particular patterns that have specific meanings for the compiler or not.

I was asking why /you/ put

I'm trying to answer you; remember that your question isn't simple as it seemed, so it needs rich explaining.

>
/******************************************/

between function definitions. You cannot or do not want to answer that question. I think that this pattern or habit is not your invention. You borrowed that style from someone else and did not ask him or her for its purpose. Right?

Really I want to answer you, but yes, maybe you are right that I saw this pattern before, but I don't remember where? really I don't remember where I saw it. I thought it's useless pattern.

July 28, 2022

On Thursday, 28 July 2022 at 14:57:36 UTC, pascal111 wrote:

>

well between US and some other countries like "Russia", and they are using US products like C compilers, so with some way we have a doubt that US developed compilers with a way to accept kind of messages or something like that, so my comment has no meaning to the compiler except if I knew the secret patterns or I do it accidentally.

Wait. You mean asterisks in comments may trigger some secret backdoor function in C-compilers? Come on :D

July 28, 2022

On Thursday, 28 July 2022 at 16:13:17 UTC, frame wrote:

>

On Thursday, 28 July 2022 at 14:57:36 UTC, pascal111 wrote:

>

well between US and some other countries like "Russia", and they are using US products like C compilers, so with some way we have a doubt that US developed compilers with a way to accept kind of messages or something like that, so my comment has no meaning to the compiler except if I knew the secret patterns or I do it accidentally.

Wait. You mean asterisks in comments may trigger some secret backdoor function in C-compilers? Come on :D

My friend, there is a wide deep secret world for hackers. We have no any idea about that world. Look, there is nothing called a 100% fact in our world. Believe me, what we see in software is just what "THEY" want us to see.

July 28, 2022

On Thursday, 28 July 2022 at 16:17:16 UTC, pascal111 wrote:

>

My friend, there is a wide deep secret world for hackers. We have no any idea about that world. Look, there is nothing called a 100% fact in our world. Believe me, what we see in software is just what "THEY" want us to see.

I think you have no idea how some processes work.

We have cryptographic digest methods to verify source code and final builds. In theory, someone could inject bad code if nobody would review it properly of course. But especially for compilers such code would be detected soon and no insane person in such projects would just merge code without reviewing it.

That applies for open source - not if you just download a compiled binary from a ftp server in the open web of course :D

July 28, 2022

On Thursday, 28 July 2022 at 16:37:35 UTC, frame wrote:

>

On Thursday, 28 July 2022 at 16:17:16 UTC, pascal111 wrote:

>

My friend, there is a wide deep secret world for hackers. We have no any idea about that world. Look, there is nothing called a 100% fact in our world. Believe me, what we see in software is just what "THEY" want us to see.

I think you have no idea how some processes work.

We have cryptographic digest methods to verify source code and final builds. In theory, someone could inject bad code if nobody would review it properly of course. But especially for compilers such code would be detected soon and no insane person in such projects would just merge code without reviewing it.

That applies for open source - not if you just download a compiled binary from a ftp server in the open web of course :D

Aha! "In theory, someone could inject bad code", you admit my theory.

July 28, 2022
On Thu, Jul 28, 2022 at 04:45:55PM +0000, pascal111 via Digitalmars-d-learn wrote:
> On Thursday, 28 July 2022 at 16:37:35 UTC, frame wrote:
> > On Thursday, 28 July 2022 at 16:17:16 UTC, pascal111 wrote:
> > 
> > > My friend, there is a wide deep secret world for hackers. We have no any idea about that world. Look, there is nothing called a 100% fact in our world. Believe me, what we see in software is just what "THEY" want us to see.
> > 
> > I think you have no idea how some processes work.
> > 
> > We have cryptographic digest methods to verify source code and final builds. In theory, someone could inject bad code if nobody would review it properly of course. But especially for compilers such code would be detected soon and no insane person in such projects would just merge code without reviewing it.
> > 
> > That applies for open source - not if you just download a compiled binary from a ftp server in the open web of course :D
> 
> Aha! "In theory, someone could inject bad code", you admit my theory.

In theory, Ken Thompson's compromised compiler hack could be at work[1].

In practice, though, especially for open-source projects where you can take the code and compile it with any of number of 3rd party compilers (at least one of which would be unlikely to have been compiled by a compromised compiler, so would be "clean"), or, for that matter, you can freely *modify* the code to replace arbitrary parts of it with semantically-equivalent code that no longer matches the hack-triggering pattern, it would take an unreal amount of influence over the entire world to be able to pull off such a hack.

If somebody actually wielded that much influence over your software, you already have far bigger problems to worry about; whether or not your software is being compiled with hidden backdoors is already a moot question. :-D  (And your efforts to write only "purely" your own code would also be futile anyway, esp. in a Thompson's-hack scenario.)


[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf


T

-- 
The early bird gets the worm. Moral: ewww...
July 28, 2022
On Thursday, 28 July 2022 at 17:21:57 UTC, H. S. Teoh wrote:
> On Thu, Jul 28, 2022 at 04:45:55PM +0000, pascal111 via Digitalmars-d-learn wrote:
>> [...]
>
> In theory, Ken Thompson's compromised compiler hack could be at work[1].
>
> [...]

I think you say advanced technical information. My information is not at that level.
July 28, 2022

On Thursday, 28 July 2022 at 16:45:55 UTC, pascal111 wrote:

>

Aha! "In theory, someone could inject bad code", you admit my theory.

The code would need to work and pass merge tests too. The merge reason must match in review. If someone fixes a task and additionally adds 100 LOC some should, will ask what this is about.

It's a extrem unlikely scenario. You may heard of linux kernel source that contains code that no one exactly knows about. But this some kind of bait. It's old code, reviewed years ago, not needed anymore but not knowing to be harmful. Completely different.

Anyway, code old or new may be harmful if it allows UB (undefined behaviour) and that is what hackers primarily use, not secret backdoors. This is why it's important to write CORRECT software that doesn't allow and cannot fall in a state of UB.

July 28, 2022

On Thursday, 28 July 2022 at 17:46:49 UTC, frame wrote:

>

On Thursday, 28 July 2022 at 16:45:55 UTC, pascal111 wrote:

>

Aha! "In theory, someone could inject bad code", you admit my theory.

The code would need to work and pass merge tests too. The merge reason must match in review. If someone fixes a task and additionally adds 100 LOC some should, will ask what this is about.

It's a extrem unlikely scenario. You may heard of linux kernel source that contains code that no one exactly knows about. But this some kind of bait. It's old code, reviewed years ago, not needed anymore but not knowing to be harmful. Completely different.

Anyway, code old or new may be harmful if it allows UB (undefined behaviour) and that is what hackers primarily use, not secret backdoors. This is why it's important to write CORRECT software that doesn't allow and cannot fall in a state of UB.

I agree with you in some points.

I retyped again some function of C library I made before, but with D code:

module dcollect;

import std.stdio;
import std.conv;
import std.ascii;

/****************************************/

string strleft(const string ch, int n)
{

    string ch_sub;

    ch_sub=ch[0..n];

    return ch_sub;

}

/************************************/

string strreverse(const string ch)
{

    string ch_rev;

    for(int i=to!int(ch.length-1); i>=0; i--)
        ch_rev~=ch[i];


    return ch_rev;

}

/*********************************************/

string strright(const string ch, int n)
{

    string ch_sub1,
    ch_sub2;

    ch_sub1=strreverse(ch);

    ch_sub2=strleft(ch_sub1, n);

    ch_sub1=strreverse(ch_sub2);

    return ch_sub1;

}

/*********************************************/

string strmid(const string ch, int x, int l)
{

    string ch_sub;

    ch_sub=ch[x..(x+l)];

    return ch_sub;

}

/*********************************************/

string strtolower(const string ch)
{

    string ch_cpy;

    for(int i=0; i<ch.length; i++)
        ch_cpy~=toLower(ch[i]);

    return ch_cpy;

}

/*********************************************/

string strtoupper(const string ch)
{

    string ch_cpy;

    for(int i=0; i<ch.length; i++)
        ch_cpy~=toUpper(ch[i]);

    return ch_cpy;

}

July 28, 2022

On Thursday, 28 July 2022 at 20:20:27 UTC, pascal111 wrote:

>

I retyped again some function of C library I made before, but with D code:

It's a start but you need to learn.

  • these functions can run into UB if you compile it without bound checking enabled

  • when working with arrays or ranges it's better to use unsigned integers or just use size_t which represents unsigned integer for 32 or 64 bit. This avoids negative values and enables the maxmium value which can be provided on the plattform to access the highest element in the array.

  • It's sure advanced topic but you should start to check your input from the beginning. Try what happens if you apply negative numbers or invalid offsets ;-)

I don't know which client you are using but please have an eye on proper format of your posts - see the "Markdown formatting" or disable the Markdown option below your input.

https://forum.dlang.org/help#about