Is this a ctfe bugs ? ref scope const(ubyte)[32]

[d007 via Digitalmars-d-learn]

```d
extern(C) int test(ref scope const(ubyte)[32] b);
```

This will automatic become this in ctfe relection

```d
extern(C) int test(ref scope const(ubyte[32]) b);
```

LDC2 1.34.0 DMD v2.104.2

Re: Is this a ctfe bugs ? ref scope const(ubyte)[32]

[d007 via Digitalmars-d-learn]

On Wednesday, 6 September 2023 at 12:15:02 UTC, Adam D Ruppe 
wrote:

On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote:

extern(C) int test(ref scope const(ubyte)[32] b);
extern(C) int test(ref scope const(ubyte[32]) b);


These are the same thing since the ref cannot be rebound 
anyway; a static array just is its contents.


thanks for explain

Need help with 128bit integer ucent boolfilter

[d007 via Digitalmars-d-learn]

I am search for a fast 128bit integer ucent boolfilter, used for 
server side duplicate request filter.



I can seed there is https://github.com/MartinNowak/bloom, only 
accept size_t as key.



Is there some library support 128bit integer boolfilter ? C or 
C++ or rust is ok for me.



Is 128bit boolfilter a doable thing? or it will not work or will 
be much more slow compare to 64 bit solution?

why remove octal literal support?

[d007 via Digitalmars-d-learn]

dlang is know for compile speed,  but in reality d project 
compile slow because so much ctfe and tempalte.



Why bring more ctfe call by remmove octal literal ?

Re: why remove octal literal support?

[d007 via Digitalmars-d-learn]

On Friday, 3 November 2023 at 15:34:37 UTC, Steven Schveighoffer 
wrote:

On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote:
dlang is know for compile speed,  but in reality d project 
compile slow because so much ctfe and tempalte.



Why bring more ctfe call by remmove octal literal ?


octal literals are extremely error prone, because people 
sometimes use leading zeroes for alignment, not realizing that 
it means the number is completely different.


Actual correct octal literal use is vanishingly small. Banning 
C-style octal literals just makes it so the compiler flags 
unintended errors like this.


-Steve


Thanks you all for explain.


In my opinion,  use some thing like 0o700 will be a better 
solution compare to template.

msghdr and cmsghdr mismatch for alpine musl

[d007 via Digitalmars-d-learn]

`import core.sys.posix.sys.socket : msghdr, cmsghdr, iovec;`


`msg_iovlen`, `msg_controllen`, `cmsg_len` is ulong for x86-64 in 
druntime.




in alpine musl, they are int,  socklen_t(uint), socklen_t(uint).



Is this mismatch can cause problems is I use related api ?

linux dynamic library __gshared var

[d007 via Digitalmars-d-learn]

I just notice the __gshared is cross process shared.   I want a 
var exits in one process, but shared for multi thread with atomic 
for __gshared library.  how can I do this with d ?

Re: linux dynamic library __gshared var

[d007 via Digitalmars-d-learn]

On Monday, 8 January 2024 at 06:12:16 UTC, d007 wrote:
I just notice the __gshared is cross process shared.   I want a 
var exits in one process, but shared for multi thread with 
atomic for __gshared library.  how can I do this with d ?


my bad, is is process only .