/tech/ - Technology★

>>895727 (OP)

But anon, null terminated strings take up less space and are the same format regardless of CPU architecture.

>>895728

they don't.

3 bytes difference is irrelevant for long strings.

if you want to make short strings small, then there is such a thing as variable length coding for integers, but this would be so little gain, it's not worth it.

CPU architecture is irrelevant, the pointer size would change in both cases. and the internal represenation of the length doesn't mean jack shit anyway.

also zero terminated strings are less efficient because calculating length is O(n).

>>895732

>they don't.

Ah so that 8 byte size prefix is not a waste of space then?

>there is such a thing as variable length coding for integers

Yeah we will just do a big num hack to size our strings! Good idea.

What if my string is more than 4,294,967,295 characters!

>>895735

No one would ever need to store a file more than 4 gigabytes. We don't need to design our system to handle that.

>>895727 (OP)

You know windows internally uses sized strings. Look how well that turned out.

>>895734

4 bytes are enough for strings for all practical purposes. if you have more, obviously it's time to use specialized data structures anyway.

it's not a waste of space, it's only 3 bytes more than the terminating null byte. which is about 1-2 characters on average if you use UTF-8, and less than 1 character if you use fixed size Unicode.

unless you store single characters in strings, this doesn't fucking matter, and it's a lot better than to turn all code dealing with strings into a potential minefield + sacrificing run time where you can't reuse length information for some reason.

>>895734

>Yeah we will just do a big num hack to size our strings! Good idea.

it's only big if your brain is small. it's not gonna be used in the most of application level code.

anyway, in the same sentence I also said that the gain is minimal so it is not worth it. learn to read. still, that would be still better than zero terminated strings.

>>895737

which exactly of windows problems are a consequence of this?

>>895738

>unless you store single characters in strings a lot of times

a few words escaped, fixed

With any kind of input you usually don't even know the string length beforehand, so some kind of string termination is necessary.

and you don't always need to know the string length either

>>895738

>4 bytes are enough for strings for all practical purposes

I agree, no one could possibly need a hard drive more than 16 megabytes. A 200Mhz CPU is blazing fast.

>it's not a waste of space, it's only 3 bytes more than the terminating null byte

For 32bit max length strings. For small strings especially its a waste of space.

>if you use fixed size Unicode.

Well good thing no one uses that for the same reason no one uses size prefixed strings. Because it has a different representation on different machines. Byte order and what not.

>you can't reuse length information

Well thats one particular operation

> it's not gonna be used in the most of application level code

Do you not know what bignum is? You are saying that everyone is going to be using a bignum implementation for basic fucking strings.

>>895739

>windows problems are a consequence of this?

Idk its proprietary they only let us know so much

>>895736

if you read a file that's as big, and need to keep all of the content in RAM for some reason, you aren't using a fucking string type for it. it will be almost useless

in this form anyway.

>>895735

a legit use case, please.

also keep in mind that scanning 4 GiB for the zero byte would take really a lot of time.

>>895744

>you aren't using a fucking string type for it.

So no one reads files into char* then? lol

>>895743

>>895743

>Do you not know what bignum is? You are saying that everyone is going to be using a bignum implementation for basic fucking strings.

I'm saying no one will re-implement it.

And using bignum already implemented in a library doesn't make shit any more complex.

>>895743

>Well thats one particular operation

when it is used somewhere and turns an O(n) algorithm into O(n^2) that would be a big deal and a PITA to fix.

>>895743

>Well good thing no one uses that for the same reason no one uses size prefixed strings. Because it has a different representation on different machines. Byte order and what not.

For most use cases it's a bullshit reason. Byte order only matters for data exchange --- files and network. Files do not need to store their size, their size is known. So prefixing size in files would be simply excessive, just as adding zero byte to the end. On network, size counts even more, so it's a normal practice to use variable length coding (protobuf, etc.).

But we are talking about in-memory representation. And you know, you don't swap a fucking CPU on a running machine while keeping RAM and CPU cache and registers, etc.

>+3 bytes is a waste of space for strings

Meanwhile people are happily making programs in javascript where every variable is some abominable super object.

>>895745

char* doesn't say anything about whether the referenced content is zero terminated.

it's just a fucking pointer.

>>895748

>And using bignum already implemented in a library doesn't make shit any more complex.

You think linking in foreign dependencies to use strings does not increase the complexity? HAHAHA

>Byte order only matters for data exchange

Like uhhhh text files, websites, spreadsheets, literally everything.

>are happily making programs in javascript where every variable is some abominable super object.

And this is a bad thing

>On network, size counts even more, so it's a normal practice to use variable length coding (protobuf, etc.).

Not for strings where the smallest representation is null terminated.

>>895750

>He does not have 10 gigabyte log files he wants to parse

>>895751

>>He does not have 10 gigabyte log files he wants to parse

you never wrote software which was able to do that, obviously.

>>895751

>Like uhhhh text files, websites, spreadsheets, literally everything.

and? they don't use zero terminated strings.

and we are talking about in-memory representation.

>>895751

>You think linking in foreign dependencies to use strings does not increase the complexity? HAHAHA

HAHAHA, go program some stuff without libc.

>>895751

>And this is a bad thing

Of course. My point was that 3 bytes on a string is nothing. It's the difference between "Hello world!" and "Hello world!gay". You're more likely to waste bytes on shit software design than a structured string.

>>895754

>go program some stuff without libc.

String copy is like 5 lines of code to write yourself, you want to add on a bunch of big num shit to make it 100.

>and we are talking about in-memory representation.

You think file formats don't use null termination literally everywhere?

>you never wrote software which was able to do that, obviously.

Its really fucking easy, you just mmap it into memory and start reading. The OS will load and unload the pages for you.

>You're more likely to waste bytes on shit software design than a structured string.

People wasting space at the high level is no excuse to waste shit at the low level. Even worse wasting space at the low level is going to make all that high level shit even shittier.

>>895757

>You think file formats don't use null termination literally everywhere?

Yes.

>>895757

>just mmap it into memory and start reading

Then you aren't using any null termination.

>>895757

>excuse to waste shit at the low level

You're free to null terminate your own esoteric string use cases if you really need to squeeze the fuck out of every byte of memory, but the chances that you do are probably 0. I don't think you understand how meaningless those 3 bytes really are in this case.

>>895761

>I don't think you understand how meaningless those 3 bytes really are in this case.

combining that with the other text, it's pretty much obvious that he doesn't.

>>895754

>Then you aren't using any null termination.

mmap is not dependent on the file type you dolt

>I don't think you understand how meaningless those 3 bytes really are in this case.

No reason to optimize! Not like computers process hundreds of billions of strings a day! That would not be beneficial at all!

>>895764

>mmap is not dependent on the file type you dolt

which retarded file format are you using which has zero termination at the end?

Null-terminated strings have the advantage of behaving extremely well with recursive function, as constructing a suffix substring is just a matter of incrementing a pointer.

Think about how Lisp handles list: they are chained cons cells, with the last cons having an empty (null) list as its CDR. This is how you work with recursivity in Lisp.

The fact that you think null-terminated strings are useless prove you have still much to learn, youngling.

>>895755

>3 bytes on a string is nothing

Wrong. First of all, a size_t variable in a 64 bits environment is 64 bits, so we're talking about 7 extra byes. Second of all, those bytes are nothing on a text, but when you have a plethora of max 10 characters strings (quite frequent), with 32 bits system it increases their size by a 30% factor, on 64 bits system, it's 70% of memory usage increase.

Imagine storing an associative array that uses, as keys, 5-char strings with 8 byte size variable. That's 13 bytes per key. With null-terminated strings, it's 6 bytes. That's some 118% more space used by the size+string solution.

>ITT: strings should be null terminated because some filetypes use null characters, also I don't stat my mmaps and EOF aren't a thing, and I prefer to waste cycles scanning for the null terminator rather than wasting an extra 1% of memory that would speed up most use cases and solve 95% of the silliest and most common types of bugs ever

The absolute state of C idiots in this board, everyone.

>>895777

Go back to your javascript bullshit. Clearly you don't care about efficiency and interchangeability.

>>895777

Do you know that EOF is an integer value, not an unsigned char, that most strings in a system are very small, that strlen() is rarely needed, and that you can still store a string's length in C, while not losing the advantages of the NULL termination?

>>895777

>C

You mean Unix.

the virgin FOReskin

void map(char *str, size_t str_len, char (func*)(char)) {
  for (size_t i = 0; i < str_len; ++i) {
    str[i] =  func(str[i]);
  }
}

The Chad Elegant Recursion

void map(char* str, char (func*)(char)) {
  if (str) {
    *str = func(*str);
      map(str, func);
  }
}

[/code]

>>895785

should be map(str++, func), LOL

>>895788

>stack overflow

This is why you don't use languages without proper tail recursion.

>>895785

>it took less to type therefore it's better as a program

Remove yourself from premises.

Null-terminated strings suck. C weenies defend it because that's what C uses. Common Lisp strings are arrays, and they can be adjustable (grow and shrink) and have a fill pointer (anything less than it is the currently used part). This covers all the uses of dynamically sized strings, length-prefixed strings, and fixed-length strings. Lisp strings are arrays, so all arrays can have these properties.

>>895742

Bullshit. You always need to know the length. If you really added up all the waste from C and UNIX "comparing characters to zero and adding one to pointers", it would be more efficient to have GC and dynamic typing and store files as arrays of strings. I'm not kidding. C malloc overhead is huge too, but on a Lisp machine, allocating a list only uses one word of memory per element. Allocating a 1D array only uses one header word to store the actual length of the array (which malloc has to do too, but it doesn't provide useful information to you) followed by the words for the array data. Lisp machine overhead is much smaller than C overhead, and the GC compacts to eliminate memory fragmentation.

>>895749

>>+3 bytes is a waste of space for strings

>Meanwhile people are happily making programs in javascript where every variable is some abominable super object.

That's because C sucks. malloc in C has more than 3 bytes of waste. JavaScript is a better language than C even though it sucks too.

>>895751

>>He does not have 10 gigabyte log files he wants to parse

You're going to read an entire 10 GB file into memory (not memory mapping) and stick a 0 byte on the end, but you think an 8 byte length is wasteful? I have no idea why anyone would do things like that.

> Subject: More On Compiler Jibberings... 
> 
> ...
> There's nothing wrong with C as it was originally 
> designed,
> ...

bullshite.

Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons?  Or do you have to do that if you mean
setf, not cadr?  Sigh.

Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and...  Sheesh.

I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else.  Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...

And what can you say about a language which is largely used
for processing strings (how much time does Unix spend
comparing characters to zero and adding one to pointers?)
but which has no string data type?  Can't decide if an array
is an aggregate or an address?  Doesn't know if strings are
constants or variables?  Allows them as initializers
sometimes but not others?

(I realize this does not really address the original topic,
but who really cares.  "There's nothing wrong with C as it
was originally designed" is a dangerously positive sweeping
statement to be found in a message posted to this list.)

>>895795

>Spams copy pasta

dropped

>>895776

>max 10 characters strings (quite frequent)

citation needed

>First of all, a size_t variable in a 64 bits environment is 64 bits

what about uint32_t?

>>895798

>4 gigabyte limit

>>895785

>char (func*)(char)

lol, what a retarded syntax

>>895801

I bet you are the type of larper that gets autistic about where parenthesis are placed or using spaces vs tabs wasting all our fucking time.

>>895800

>>895744

>>895727 (OP)

>misuse null-terminated strings

<FUCK NULL TERMINATED STRINGS, IT WASN'T MY OWN STUPIDITY

The code for the hash in your link is shit, and it's not because of the string. It's because the bcrypt writer played with fire and got burned. If you work directly with pointer logic, you need to be very careful. The language does offer you ways of solving the problem with safer, easier to use tools. The problem is, when you need to be efficient, you're going to have to write code closer to the hardware level. You might as well ban chainsaws because idiots get hurt by them.

>>895803

Who said anything about keeping it in RAM? You can process something without it being in RAM. Every heard of streams? Every heard of memory mapped files? Guess not lol.

>>895749

And there's absolutely nothing wrong with that. Having been in both worlds, its such a pleasure to write software in the more abstract languages.

>>895802

not.

it's a lot less clear than `char -> char` for example, or even `Function<char, char>`.

try to spell (in C) a type of a variable which is a function which takes a char and returns a function which returns a function which returns a function which returns a char, for example.

>>895805

if you read from file, you already know the size, because files have size. adding 1 useless byte is useless and stupid.

>>895806

Javascript is the C of high level languages

>>895779

>Do you know that EOF is an integer value

People ITT apparently don't know null terminated strings and reading from files have nothing to do with each other at all, that's my point.

>that most strings in a system are very small

Did you know SQL databases solved this ages ago with fixed size char fields, variable size char fields and text fields? Fuck, we could solve this the same way we solved numeric types of different sizes, with short strings, regular strings, long strings, etc.

<but that's not YOONIKS-y and simple!

It's about as obtuse as integer sizes. Read: not at all if you care the littlest bit about muh autistic efficiency. Not only that, but the compiler could infer the most adjusted type for literals, so you should only worry about user inputs and files, which should have a fixed length anyway.

<but muh length promotion would waste too much!

Go write assembly then, fag.

>that strlen() is rarely needed,

Rarely my ass, unless you use buffers and increase the complexity of your program by doing this.

>>895793

That alone is a reason to make it better, but it's also clearer, the function takes one less argument, and it doesn't need to push a new variable onto the stack.

>>895790

While it is true that ANSI C says nothing about tail call recursion, GCC does it.

>>895795

Mr. Common Lisp[1] here apparently does not understand the value of a null terminator in a linear collection of elements (like a string), even though it is the principle upon which cons cell lists are constructed.

[1] yuck!

>>895798

>citation needed

Look up any software, and see how long most string are.

>what about uint32_t?

Though there is no reason for it not to be used, is not recommended to hardcode your size_t. Also, uint32_t is not defined by ANSI standards older than C99.

>>895801

>return type (name) (arguments)

How would you do it, Mr. Smart Man?

>>895808

<Not

>Goes on to larp about syntax

>>895811

I bet you think a linked list is good too because it doesn't need an iterator variable to loop through.

>>895810

>People ITT apparently don't know null terminated strings and reading from files have nothing to do with each other at all, that's my point.

People ITT don't know that null terminated strings are used in file formats all the time.

>>895809

>Javascript is the crap of high level languages

ftfy

although C is crap too, so… not a big difference after all.

>>895810

>Go write assembly then, fag.

Go write in javascript faggot, its where you belong.

>>895815

Thats the point dingus

>>895811

>and it doesn't need to push a new variable onto the stack

who told you so?

>what is registers?

>>895814

>People ITT don't know that null terminated strings are used in file formats all the time.

and the most widely used example is … ?

>>895811

>Though there is no reason for it not to be used, is not recommended to hardcode your size_t. Also, uint32_t is not defined by ANSI standards older than C99.

Older standards than C99 belong to the garbage bin.

>>895816

Your beloved C does size promotion all the time. Fuck, getchar(), which is used to read a single character from a file, which is about as wasteful of a function as it gets, performs promotions with every single call. And it's negligible.

Really, fuck off. You don't even want assembly, your autism should only allow you to use ASICs that waste zero cycles at all.

>>895823

I hate C, I just like null termination.

>>895810

SQL databases are much different than C storage. For starters, the length of VARCHAR is stored only once, in the column definition. When the length is dynamic, we're talking about text, which will indeed make the extra 8 bytes literally nothing.

><but that's not YOONIKS-y and simple!

I don't like Unix, please do not put words in my mouth.

>some rambling on stuff I haven't mentioned

ok

>Rarely my ass

Rarely indeed. For hard-coded strings, the length is simply sizeof(myString) (which counts the null terminator). For strings that you receive as input, the size is calculated while receiving it, or is pre-given.

Null-terminated dynamic-size strings are good for manipulation, sized dynamic-size strings are good for interchange (databases, network, file formats, etc.)

You should use fixed-length strings as much as possible anyway.

>>895819

If it is not pushed onto the stack, it's a compiler optimization, that you shouldn't rely on, or you need to specify the variable as volatile.

>>895813

Linked lists are excellent as lists. If you try to use them when you should use fixed-size arrays or vectors, maybe you should take an IQ test, and based on that, decide if you should kill yourself or retake Data Structures 101.

>>895822

If you're not a LARPer, surely you have heard of legacy codebases.

>>895824

Same. C sucks, but most of its detractors just don't understand the real reasons why.

>>895824

Well tough shit then…

>>895828

Tough shit for you, attacking a strawman this whole time.

>>895831

>I don't understand why you would possibly want a linked list.

How many years of programming do you have on your CV, again?

>>895827

>Linked lists are excellent as lists.

Linked lists waste all that space on pointers though, terrible cache properties, jumping around to different pages all the time. Big O time complexity has little to do with the real world when we are dominated by the size of N.

>>895833 (checked)

Is an array of pointers that get reallocated all the time a better solution when the list is not changing often?

>>895832

Well I've never heard of a situation where a linked list is the best solution, so here's your chance to educate me.

>>895834

If that array of pointers fits within a few pages then its absolutely faster compared to chasing down pages wherever they get allocated.

>>895836

>The furry c programmer knows all

>>895837

Thx. Is this the best solution for small lists? Is there a special list type you'd recommend?

>>895834

Have you ever benchmarked this shit on a relatively modern computers?

>>895833

You and I must have different definitions of "real world". When you need to constantly resize (queues, lists, stack), using vectors is extremely expensive. When the size of your vector remains constant, or is changed very little, using a vector is better.

You wouldn't cut a steak with a wood saw, or cut a plank with a steak knife. Two different tools serve two different purposes, and so do two different data structures.

>>895836

Not an argument

>>895727 (OP) (OP)

That vulnerability mentioned in that blog post is developer error. The function takes in a string, but you pass in a byte array. Why would you expect it to work? If you pass in the wrong type of variable then of course it might not work right.

>>895844

>You and I must have different definitions of "real world". When you need to constantly resize (queues, lists, stack), using vectors is extremely expensive

Any evidence?

>>895844

> using vectors is extremely expensive

Thats just it, its not extremely expensive. It have a expensive big O cost, but almost every benchmark will show that vectors are faster. This is because cache pages exist. The cache changes how all of this works.

>>895844

Look your CS 101 data structures class using big O notation is not an accurate description of how caches work.

>>895846

in C, char* is also used for byte arrays.

this is a programmer error, but it could be prevented if the design of the language and the stdlib was less shit.

programmers will always make some errors, but some of them can be prevented entirely as a class.

>>895843

No. But performance always takes priority.

And I think we should listen to

>>895837

's practical advice and not some stupid theory developed by java shitcoders at some university.

>>895849

>It have a expensive big O cost

it doesn't.

amortized cost of adding an item is still O(1).

>>895853

Adding an item to the middle of a vector is not amortized to O(1).

>>895844

You can change how often a vector reallocates itself, but really, the default behavior is sufficient for most implementations.

>>895854

neither in the linked list if you need first to find a place where to insert --- you'll need O(n) traversal first.

>>895845

Yours neither, loser. You literally made a bold statement without backing it, or providing proof. Your nodev ass can't even write a reverse polish calculator, LOL.

>>895856

Again you keep using all these fucking big O notation when talking about the speed of these datastructures. The real world does not follow big O. Iterating over a vector thats all in one page is thousands of times faster than jumping between pages where linked list nodes are allocated despite the same time complexity.

>>895842

Yup. This is why compiler warnings exist when you try to do implicit conversion, and this is why Apps Hungarian Notation is useful.

>>895848

>evidence

>of a math problem

1st year CS theory that you ought to know if you want to be taken seriously here.

>>895849

>benchmarks

That use cases where vectors are indeed better.

>>895850

>cache

Do you think data structures stop existing outside of RAM?

>>895835

Filesystems make extensive use of linked data structures.

>>895854

In the middle, or anywhere besides the end. Dynamic vectors can be used somewhat effectively as stacks because of that, but that's about it.

>>895859

>The real world does not follow big O

L M A O

M M

A A

O O

>>895858

>Your nodev ass can't even write a reverse polish calculator, LOL

I can write even infix calculator without any problem.

I actually wrote a compiler for a simple language and a lot of other shit too. Fix your detector.

>>895862

You're still claiming shit you've never done, and don't provide proof.

>>>/reddit/

>>895861

Look here retard. Iterating over a list and vector have the same big O cost. In the case of an actual list though you will be chasing down pointers in different pages. big O does not at all model this cast. If you knew more about CS theory than an undergrad simpleton you would understand this.

oh shit watch out there's a troll in here.

>>895864

>muh iterations

Insert a new value at the head of a 10 million records vector.

Now do it at the head of a 10 million records linked list.

Come back and tell everyone how it went.

>>895861

>1st year CS theory that you ought to know if you want to be taken seriously here.

When you make claims based on your invalid mental model of the modern computing hardware, of course you need to prove your bullshit to be taken seriously.

>>895859

Lol, are you a brainlet or what?

>>895861

>Filesystems make extensive use of linked data structures.

For different reasons altogether.

We are talking about in-memory data structures.

>>895867

>Lol, are you a brainlet or what?

<standard Big O notation always correctly models hardware

what the fuck are you on about

>>895866

>Insert a new value at the head of a 10 million records vector.

if you need to insert at head, you use deque and not vector.

for deque, this is not a problem at all and it will be faster than linked list (amortized)

>>895865

don't worry I got him right here: >>895868

>>895867

>We are talking about in-memory data structures.

Who says so? I defended that linked lists had very valid use cases, and everyone and their nodev asses have come to shit on what is basic knowledge.

>invalid mental model of the modern computing hardware

I know how cache works, thank you.

>>895869

>deque

Not always.

>>895872

>not always

I see you don't know what amortized means then

>>895872

TFW your linked list is slower for the one thing it should be better at because of how hardware actually works

https://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html

>>895873

If you need to frequently mutate the order of your data, deques can still prove too slow, or their head be too big.

>>895874

>muh benchmarks

Filesystems, do you understand them?

>>895874

See that the only case where the list is actually faster is where they happen to store very large values at each node instead of a pointer to them which is a retarded contrived use case.

>>895875

>amortized

>>895874

>The random position is found by linear search.

Gee!

>not just implementing a linked list with a lookup table for fast iteration

Kiss and make up, gentlemen. Try not to touch balls though, that's gay.

>>895875

Yeah no one is actually going to every have to do a linear search on their data to find what they need

>>895883

Lists are not intended for linear searches.

>>895877

>they will likely behind a pointer then, so even then it loses.

Only if you're a terrible programmer.

>>895827

>SQL databases are much different than C storage. For starters, the length of VARCHAR is stored only once, in the column definition. When the length is dynamic, we're talking about text, which will indeed make the extra 8 bytes literally nothing.

That really matters nothing at all. The compiler should be able to handle this, along with the promotion rules. My point is that fixed/limited size strings are nothing new and people know how to handle it. The reason most modern programming languages use the same type of strings for everything is because C hacked them in as simple pointers to chars, when that type actually has another property and it is that it is null terminated, so even though the following languages knew null terminated strings were bad because they caused all sorts of problems, they didn't think making a distinction wasn't worth it, so they just used size_t for every string, be it 2 or 20000 characters long.

Riddle me this: what would be so wrong about using structs for strings, where one of the members is a pointer and the other is an unsigned integer which number of bytes adjusts itself to the minimum number that can hold the number of characters in the string? This way, strings up to the max unsigned char value occupy the same as null terminated strings, and strings that take up to the maximum unsigned short int value would occupy a measly single extra byte. In addition, by manipulating pointer and length you could generate a view into a string, which is more or less what Rust already does, and save memory in the process.

>>895884

Okay so we can agree then that lists are useless for almost everything?

>>895887

How dare someone store and object bigger than the size of a page behind a pointer!

>>895890

lists DO have uses, though. Pretending that they don't is cargo cult programming

>>895890

>so we can agree then that lists are useless for almost everything?

They are not useless, they are slower. And sure, they're slower almost every time, but not every time, which is the point I'm making from the beginning.

>How dare someone store and object bigger than the size of a page behind a pointer!

>2048 bytes

>bigger than a page

nigguh

>>895882

this table will need to be updated each time you insert or remove something, defeating the purpose.

what you actually probably want is https://bitbucket.org/astrieanna/bitmapped-vector-trie.

>>895895

>>895894

Most things have uses, and the less useful should not be the default.

>>895895

>And sure, they're slower almost every time, but not every time, which is the point I'm making from the beginning

still useless for realtime, as memory allocation is unpredictable generally.

>>895899

I don't think I said they were or should be the default, have I?

>>895900

Man, I've mentioned filesystems three times already.

>>895901

They are the default in schema

>hurr durr lets LARP about irrelevant shit

/tech/ in a nutshell. I bet most of you fags haven't even programmed anything except fizzbuzz tier shit.

>>895903

*scheme

>>895904

>>>/g/

>>895901

>Man, I've mentioned filesystems three times already.

filesystems like the FAT? :^)

I've seen better filesystems use more clever data structures.

>>895906

not an argument XDDDDDDDDDDDDDDDDDDDDDDD

>>895910

>>>/molyneux/

>>895910

>>895904

>I-I bet you guyz hasnt even program! L O L

"well reasoned argument"

>n-not an argument

shhh. The grown NEETs are talking.

>>895913

>grown NEETs

LOL. Keep LARPing faggots.

>>895903

>>895905

They aren't.

>>895922

yes they are

>>895924

They aren't, that's a fact that's provable by knowing anything at all about Scheme. I don't see why that's even an argument.

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Vectors.html

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Strings.html#Strings

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Associations.html#Associations

Do these look like linked lists to you?

>>895925

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists

They are the default.

>>895926

>Ctrl+F

>"default"

>0 results

>>895903

what does it even mean for them to be "default"?

>>895930

It means "I know nothing about programming and I need to read my SICP".

>>895929

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces. The empty list is written (). For example, the following are equivalent notations for a list of symbols:

>(a b c d e)

>(a . (b . (c . (d . (e . ())))))

LOL. It is the default

>>895932

>this means they're the default DS

>>895932

you are confusing the abstract concept of lists, and the particular implementation of linked lists. Scheme uses lists heavily but that doesn't mean its based in linked lists

>>895933

They are. If you write (a b c) you have a linked list.

>>895935

>that doesn't mean its based in linked lists

proof?

Mine is here: https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists

>>895936

You don't, and you're retarded, and you don't understand the difference between an actual list structure, and the concept of list used in the representation of Scheme programs.

If you type (a b c), you are calling the function 'a' with the arguments 'b' and 'c'.

>>895937

proof of what? I'm just pointing out a distinction.

>Ctrl+F

>link

>0 results

>>895938

>>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces. The empty list is written (). For example, the following are equivalent notations for a list of symbols:

>>(a b c d e)

>>(a . (b . (c . (d . (e . ())))))

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists

>>895939

>7 Lists

>A pair (sometimes called a dotted pair) is a data structure with two fields called the car and cdr fields (for historical reasons). Pairs are created by the procedure cons. The car and cdr fields are accessed by the procedures car and cdr. The car and cdr fields are assigned by the procedures set-car! and set-cdr!.

>Pairs are used primarily to represent lists. A list can be defined recursively as either the empty list or a pair whose cdr is a list. More precisely, the set of lists is defined as the smallest set X such that

> The empty list is in X.

> If list is in X, then any pair whose cdr field contains list is also in X.

>>895940

>I still don't understand Scheme

You could have said "oh, ok, I thought so" when I told you they weren't the default, and you would have just appeared as someone who doesn't know Scheme, which is in itself not a bad thing. Now you're just making an ass out of yourself.

>>895943

>you don't know scheme

weal argument.

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists

>>895945

https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm

Are lists the default in C? It says "lists" right in its grammar.

>>895946

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

>A more streamlined notation can be used for lists: the elements of the list are simply enclosed in parentheses and separated by spaces.

>Pairs are used primarily to represent lists.

you don't understand english.

anyways have fun tripfagging.

>>895947

You haven't answered my question. Are lists the default data structure of C?

>>895949

there are no built-in data structures in C at all.

>>895950

There's arrays. Now not only you have to read your SICP, but you also have to read your 2nd edition of "The C Programming Language".

>>895955

Bullshit. There are no arrays.

>>895958

I mean, there's only a joke of an array which must fit into stack or constant pool and it can't be used for anything "big".

What you probably actually mean is just pointers + the ability to request some memory dynamically if your environment has it in the API.

>>895958

But everything is "just pointers". C has arrays, there's a syntax for array initialization, there's a syntax to specify arrays of types, and they are mentioned in the standard.

>>895960

Pro tip: if you can't query the size of the array, it's not an array.

>>895961

1) That's a definition you pulled out of your ass

2)

sizeof(myArray);

>>895962

the latter will not work for a pointer to dynamically allocated "array".

>>895837

I still don't understand why it's faster.

An entrypoint pointer and a bunch of structs would have the same performance with paging when cycling through in my brain.

Both have the distance of 1 pointer to the next struct and the contents are allocated dynamically.

>>895968

then go ahead and learn instead of making a clown out of yourself here

>>895963

Because dynamically allocated memory is not an array as per the C definition of array. Read your books.

>>895972

yeah that's what I said from the beginning.

arrays which are in C are almost useless, and there are no true arrays.

>>895973

My god, kiddo. Read your fucking book.

char *a;
char b[512];
sizeof(a);
sizeof(b);

Those yield different results, because arrays and pointers in C are, in fact, not the same thing.

https://eli.thegreenplace.net/2009/10/21/are-pointers-and-arrays-equivalent-in-c

>>895975

>not the same thing.

<but they should be

one more piece of c bloat

>>895979

>I was wrong but I should be right

>>895981

Don't assume that anyone that responds is the same person

>>895955

>>895960

>>895972

>>895975

C does not have arrays. It has something called arrays, something called strings, and something called unions, but it does not have any of those things. If I built an array processor, languages with arrays would be faster, but C wouldn't be able to run on it.

>>895983

And I suppose you think lisp cannot exist on x86 because it does not have cons cells at the hardware level?

>>895851

>in C, char* is also used for byte arrays.

Byte arrays should be unsigned char*. When the char datatype is started without being signed or unsigned, it means that it represents characters (as in characters in a string).

This is a problem with PHP itself and has happened with other functions too.

>>895950

>there are no built-in data structures in C at all.

wew lad

>>895998

data structures? I think you mean bloat.

>>895984

It's harder to make a computer that can't run Lisp than it is to make a computer that can't run C because ISO C cannot run on certain hardware. There are requirements about the kind of hardware C can run on, like it must use binary integers in one of certain number of formats, and "strings" and "arrays" also have a lot of requirements, even though they're horrible. There's no way to use "arrays" and "strings" in C without pointer arithmetic, so C must specify how data appears in memory, which prevents a lot of optimizations and faster hardware designs.

>>896002

>It's harder to make a computer that can't run Lisp than it is to make a computer that can't run C because ISO C cannot run on certain hardware.

>Lisp is so shit, you can't build an emulator or compatibility layer with it.

LISPFAGS BTFO

>>896002

Are the existence of C and C++ one of the reasons why progress stopped and all computer architectures are so mediocre?

>>896005

you can emulate everything but running C with shit speed is pointless, as it's only ever used for speed gains.

if C becomes slower than Python for example, then it's fucking pointless to use, as it sucks donkey balls on everything else too.

>>896007

>C becomes slower than Python

That wouldn't happen because C is very specific about everything.

>>896008

it will only make matters worse, dude.

>>896009

No. Things can always be abstracted but reduction is impossible after some point which is why more specific languages are faster by default and that DOESN'T CHANGE.

>>895735

Then you really don't want to scan for that null terminator.

>>895790

Newer revisions of the ISO C standard require the compiler to implement tail recursion properly.

>>895836

you are a humongous faggot

>>895727 (OP)

It's easier to put a NUL byte at the end (just *one* byte) than calculate the new length everytime it's modified and put it into another variable (presumably at least an int, i.e. probably at least four bytes).

>>895979

>arrays and pointers should be the same thing

No. Their underlying concepts are very different. The fact that C arrays are implemented such that an array identifier represents a pointer to its first element in almost all contexts (using the array indentifier as a sizeof operand is a case when it does *not*, and for good reasons) is just because it's convenient that way, nothing else.

>>896072

What data structure could you possibly be using where you wouldn't already know the length?

>>895801

>>895802

>>895808

The syntax is retarded because it's invalid. "func being a pointer to function taking char argument and returning char is "char (*func)(char)".

>>896072

>calculate the new length every time it's modified

... which isn't how you're supposed to use this stuff.

>>896088

>asterisk is on the wrong side

>INVALID!!1!!!

Yeah this totally changes how it looks.

>>896088

Are you seriously complaining that he put the * on the other side?

>Hey kid, send me the word "hello". That'll be 2 megabytes long, by the way.

>>896095

This tbh.

>Store 50,000 5-char identifiers

>650kB

>>896096

>Storing 5 char identifiers

>Not mapping them to an enum

smh tbh famalamadingdong. I already told you how to handle that usecase with almost zero overhead, anyway.

>>896105

>want to store or delete identifier

>need to recompile entire application

>user-submitted identifier

>make script that modifies the sources and recompile

>giant enum {...} with 50 000 entries

>>896109

You could store them in a config file. Oh wait, that's bloat, amirite.

>>896110

>get user query based on identifier

>load up 640kB file everytime

>>896096

I was more so referring to the potential security problems with having an arbitrary length value, but yeah, that too.

>>896112

You could mmap that file and seek it on demand.

<ooh, but seeking these on demand is so expensive

>get user query based on identifier

>search a million entries

>compare a million 5 char long strings one by one

>not expensive

<but my program will only search for 5 entries tops!

Which is why you need 50k 5 char long strings, right. Two can play the "arbitrarily specific specifications" game, too.

>>896124

>What is a search tree

>>896122

>arbitrary length value,

Null terminated strings are a-okay tho.

>>896127

Did I stutter?

>>896126

Something you could apply to the file as well. Or something you could apply to enum-tagged entries for extra speed. I dunno, I'm not the one making up the stupid limitations.

>>896130

>calls it stupid limitations

>when he's the one calling for 8 extra bytes appended to EVERY string.

>>896127

<Null terminated

>A one-L NUL, it ends a string

>A two-L NULL points to no thing

>But I will bet a golden bull

>That there is no three-L NULLL

(char)'\0' != (void *)0

>>896142

You are complaining about such a minor irrelevant typo.

>>896145

>syntax error (proving him to be a larper who has actually not much of a clue of how function pointers are used correctly) preventing the code from even compiling

>"minor irrelevant typo"

dat desperate damage control of yours tho

>>896145

C isn't nignog transgender studies where nothing that is said actually ever matters. The compiler is autist extraordinaire and is merciless to syntax errors of any kind.

>>896146

I'm not the one that made the post. I'm calling you a faggot for sperging out about it.

>>896137

>when he's the one calling for 8 extra bytes appended to EVERY string.

Never said that, you just conveniently ignored my post on how to properly handle this, while also adding a feature that would simply save memory in the long run.

>>896151

The one where you advocated adding a complicated BigNum system to system that needs to process strings?

>>896150

Desperately playing down a stupid mistake (yea no, it wasn't a "typo" because the larper consistently repeated it, go back to >>895785 and check if unsure) just because (you) yourself didn't notice it is far worse than pointing it out (which you cared to inaptly call "sperging out about it").

>>896151

>posts non-solutions

>how to properly handle this

Very simple use case, kid. You have a map of arbitrary-but-usually-small length strings to whatever (let's say 1 int), and you have 50,000 of those records. You have to attend numerous update and query requests.

You cannot

>use an enum (lm fucking ao)

>use a file (actually you can but it changes nothing)

>mmap enormous chunks of data

It's simple, you have a map of strings. Do you more than duplicate their size?

>>896156

It's an asterisk on the wrong side of the "func" identifier, no one cares about it actually, because it doesn't change the look of it overall. You're sperging over it because you absolutely can't stand losing an argument, or maybe just crave validation. Talk about LARPing.

>>896156

>just because (you) yourself didn't notice it is far worse than pointing it out

I guess if you don't autistically rant for multiple posts about a minor syntax error that means you did not know it was wrong. If you don't correct every little grammar error in a persons post you most have no concept of proper English usage. The only option is to be a massive faggot about everything.

>>896160

Why am I even coming back to this place choke-full of bitter and confused larpers

>>896166

>>>/g/

>>896155

Why the fuck would you need bignum when you couldn't hold strings bigger than size_t, anyway? And if you could, you would indeed need other access mechanisms. No, you just need unsigned chars, shorts, ints and longs. If this already included in C feature is too complicated for you, you should go back to scripting languages.

>>896158

>arbitrary-but-usually-small length strings

>arbitrary length

Oh sure, you never said that before but okay. If what you need is to hold SQL-like text fields you would indeed waste 7 bytes per entry using my method, but if you are short on resources (considering you are complaining about 650k being too much) you shouldn't be doing this anyway, at the very least use a varchar. You are also implying these keys are probably unique, non-system defined and dynamic, which weren't part of the original requirements, while I was assuming your dataset was larger and that these keys were not primary and non-unique, in which case they would benefit from compression if mapped to integers.

Your requirements are stupid anyway. About the only usecase in which NUL terminated strings would win, and that's making assumptions such as users submitting arbitrarily large keys and fucking over your limited resources, which could be solved by offloading your keys onto another table held in a file and organized using a radix tree.

>>896178

Not actual bignum you dumb fuck. Variable length encoding of the prefix size number. Its very similar.

>>896178

NULL-terminated string also win in ease of processing.

>>896179

Good solution for compact storage and transmission, not so good for processing, as it introduces more branching.

>>896182

Scheme uses actual bignum for all its calculations in its numeric tower, clearly you don't care about a little extra branching.

>>896183

Did I just hear a non-argument?

>>896191

>>>/molyneux/

>>896179

>variable length

Not variable at all, just like the size of a char, a short, an int or a long are not variable and they are simply different types. micro strings (minimum addressable size, equivalent to NUL terminated strings; could also be named short short string if you are into retarded modifier naming schemes), short strings, strings, long strings, macro strings (or long long strings) would be different types, and the language would just know how to promote them when appropriate, just like it already promotes these numeric types.

>>896196

Just what we need, c with even more type coercion, only this time with dynamically allocated values.

>>896198

>c with even more type coercion,

Okay, you can tell the fucking compiler you really want to cast that short to an int when passing them to functions accepting ints by explicitly stating it, Java pedantry style, but considering it makes no difference to you or the resource allocations required you may as well let the compiler do it for you.

If you don't want the compiler to automatize anything at all, why don't you fucking code it in assembly?

>with dynamically allocated values.

you wot m8

>>896200

>If you don't want the compiler to automatize anything at all,

I want the compiler to automate all kinds of things. I want it to automate ways to ensure my code is correct. I don't want it to just randomly fuck with the types of the numbers because I am using them. Its like javascript fuckery where ints get turned into strings based on the operation.

>>895728

That actually depends on the platform (i.e. what is a char actually stored as). Unarguably, though, they take up more processing, because to detect the end of the string, you have to check each and every character as you are parsing it.

>>896203

>they take up more processing

*for a single particular operation

copying a null terminated string takes less processing time

>>896205

No it doesn't. Consider this, how do you know when you are at the end of the source string? With a null-terminator, you must check every character.

With an integer counting up to the length of the string, you have the potential benefit of loop unrolling. i.e. compare the index to the string length every 16 elements or so instead of comparing each char to '\0'.

>>896207

>loop unrolling

If you want to blow your instruction cache and slow down your whole program

>>896202

>don't want it to just randomly fuck with the types of the numbers because I am using them

<int fug(long thing) { /* fug the long thing */ }

<unsigned short short benis = 255;

<int colonDDDDD = fug(benis);

<fug(benis) == fug(255)

<(int) benis == (int) 255

No data lost at all because you just told it to take 8 bytes rather than 1. 255 in 8 bytes is still 255, and since the function was already accepting a long long, unless you attempted to introduce some sort of generics into C that allowed you to make a function that worked with short shorts and another that worked with longs, but that's fucking bloat and would help you nothing at all.

Since you can not divide or multiply (possible float or double casting), sum or rest (possible int promotion) a string, all you could do would be concatting them, which would be implemented via functions that would return appropriately sized strings that would raise warnings if attempted to be assigned to smaller string types. No harmful type coercion at all, miles simpler than any other integer operations system ever devised in a mainstream language.

> Its like javascript fuckery where ints get turned into strings based on the operation.

For what's it for, JS more often than not does what you want it to do, considering it is meant for text processing. I agree JS's type system is retarded, but C can never be as retarded as JS since it is not dynamically typed, and type coercion is really one of your smallest problems, considering it is only a problem because the DOM is all retarded and doesn't define an universally enforced type for input values (ie: numeric fields generally return a Number in modern browsers if the field is supported, but IE returns a string even though it claims to support numeric fields even though it doesn't, so you have to cast it to Number anyway, but depending on locales you may not parse it correctly if they use commas instead of dots for decimal positions) and you can't really know which types you are working with.

>>896205

As long as you know the size of the string you are allocating to, which may be smaller or bigger than the string you are getting (in which case, you have to check for being inside your target string bounds and for your source string's NUL terminator). If it is bigger, your source string might get cut, which is undesirable, so you would want to have your target string be at least as big as your source string, which implies malloc and also seeking the last position of your source string. Or you could use buffers and do some retarded realloc-ing or an array of char * to grow your target string as you read your source string, but that's all sorts of retarded and would be more wasteful than if you just knew their lengths.

>>896219

Shouldn't do that since it should trigger tail call optimization, but using function pointers is wasteful if we are talking about autistically optimizing shit.

>>896208

The whole reason compilers insert loop unrolling is for the exact opposite reason; it increases I-cache hits.

>>896222

Neat, but I'm not finding any way to guarantee it and with small stacks it'll blow quick. I use function pointers all the time though

>>896222

>autistically optimizing shit

lmfao how about writing a function that actually works instead.

>>896230

>I use function pointers all the time though

It's not a bad thing and performance cost is negligible, but we are talking about people feeling the need to install Gentoo to cut 2 MB of total RAM usage here. If it's gonna save you several lines of code, or worse, a gigantic switch of death, by all means do it.

>>896236

Tell the tripfag. I personally wouldn't bother writing a single line of C (or C with syntax errors :^) )due to hipsterism.

>>896238

You wouldn't write it because you couldn't. You're just another retarded larper.

We won't ever be truly free of this moronic C string business until people stop using stdio.

>>895742

The read system call stops reading when input data is exhausted. It returns exactly how many bytes it has read, so at the end of the process you know exactly how long the data is.

NUL-terminated strings are, like errno, a C concept. Linux gives approximately zero fucks about your NUL, just like there is no actual errno global variable (the system call interface simply returns the error code like a sane implementation would). This is stdlib garbage.

>>895942

Is there a Lisp out there where the list data structure isn't actually a linked list? Can it be a dynamic array, for example?

>>896308

>list data structure

>but not an actual list

durr

>>896245

>>895778

>>895816

Feel like a hero yet, Reddit?

>>896308

Clojure kind of applies, they're not the default but they exist, and you can create a fork where they will be the default.

this "list" should be immutable, so it's relatively tough shit to implement if you want something better than the linked list, but in Clojure there are already a couple of persistent data structures, either you can use them, or study the algorithms and re-implement them in your language of choice.

>>895743

>200MHz CPU is blazing fast

but anon, a 200MHz CPU is blazing fast. You only need more if you plan to run the latest Macroshit Wangblows craperating cistern wid' Enpantsed Jewgle Crowd Pthtoorage Gapeability.

>>896348

>>>/g/

>>895736

t. FAT32

>>896516

thats the joke

>>896253

are there any viable alternatives to shill?

getting rid of stdio sounds like a good idea.

>>896253

>until people stop using stdio

aren't plain "string" literals in C also generating an extra zero byte at the end?

it seems people also need to eschew "string" literals in C and use something like a macro which expands to a constant array of bytes or something else.

I mean it's doable but not really ergonomic in plain C.

it's easier to get rid of this shit in C++ perhaps.

>>896522

>hurr durr just make the memory a linked list

literal brainlet

>>896526

can you even read plain English?

>>896253

>We won't ever be truly free of this moronic C string business until people stop using stdio.

Except null-terminated strings are embedded right in the language, with string literals being null-terminated.

>>896524

>use something like a macro which expands to a constant array of bytes or something else

Alas, I am afraid such a thing is not possible with the C preprocessor.

However, for all the LARPers out there, keep in mind GCC and Clang/LLVM are Free as In Freedom™ software, that anyone can modify. You're all such C expert senior engineers, writing a GNU extension for non-asciiz strings should be TRIVIAL.

>>896538

Cuck, with a cuck license. How's your wife's son?

>>896542

Whats cucked about it? I can go sell it to random fucks and no one can stop me. The developers are cucked. The users are the least cucked possible. This is in comparison to your GPL compiler. Under the GPL the developers are not as cucked as BSD developers, but they are still cucks compared to proprietary. The GPL users are more cucked than BSD users because they are bound by more terms.

>>896542

>Open Source

lol the cucks are fighting again

>>896535

>Except null-terminated strings are embedded right in the language

No. There is no string datatype at all in C. It's a convention to use NUL-terminated arrays of char, and that's what standard library functions expect. You're free to implement your own functions and libraries which handle whatever string datatype equivalent you come up with in whatever way you like.

>>896546

>It's a convention to use NUL-terminated arrays of char

So how do you explain the fact that this is null by the compiler?

const char* foo = "bar";

>>896547

*null terminated

>>896547

String literals are syntactic sugar.

>>896554

So no language has anything. Got it. Its all just syntactic sugar on top of machinecode.

>A character string literal has static storage duration and type ``array of char , and is initialized with the given characters. A wide string literal has static storage duration and type ``array of wchar_t, and is initialized with the wide characters corresponding to the given multibyte characters. Character string literals that are adjacent tokens are concatenated into a single character string literal. A null character is then appended.

>A string is a contiguous sequence of characters terminated by and including the first null character. It is represented by a pointer to its initial (lowest addressed) character and its length is the number of characters preceding the null character.

>A character string literal need not be a string (...), because a null character may be embedded in it by a \0 escape sequence.

https://port70.net/~nsz/c/c89/c89-draft.html

>null

>NULL

This is how fucktarded this guy actually is.

>>896543

>I can go sell it to random fucks and no one can stop me.

Can you please remind me of which part of the GNU Public License (version 2 or 3) forbids the user from selling a copy?

>>896592

>the user from selling a copy?

Look we both know thats bullshit. Its theoretically possible to have someone pay for GPL code but when they get the source you are gonna have a real hard time charging for it a second time.

>>896592

>one person buys

>can legally uploading to every other person

lmao

>>896594

>"NOT EVEN MERCHANTABILITY"

>>896546

>that's what standard library functions expect. You're free to implement your own functions and libraries which handle whatever string datatype equivalent you come up with in whatever way you like.

THIS is what I think we need. Quite frankly, C stdlib is pure garbage. I'm working on and off on a project of this type, a custom freestanding C library based on Limux. Once it has a reasonable set of features to make it useful, I will publish it under MIT.

>>896634

>cuck license

>>896638

Yes. I don't particularly care about improvements being sent back to me. I just want to stop using libc and start using Linux directly because frankly the Linux interfaces are a LOT better. If other people think my code is useful, I want them to please use it.

>>896638

>>896645

In fact, I'm personally rather wary of "improvements" that get sent since they can be a curse in disguise. Have you SEEN glibc source code? It's a mess. Even something as simple as an strlen implementation is huge and needs truckloads of comments to explain what the fuck is happening, all so it can scan lots of data at once to improve performance while looking for the NUL.

I want my code to be simple so that I, and maybe even other people, can immediately understand it when reading it. The license allows you to do whatever you want, so you can just supply your own highly optimized functions if it matters that much.

>>896535

>Except null-terminated strings are embedded right in the language, with string literals being null-terminated.

Just because string literals are NUL terminated doesn't mean that you can't keep count yourself. As far as I/O goes, only stdio requires NUL terminated strings; the kernel interfaces do not.

>>896315

What stops car from returning

array[0]

array[1..-1]

>>896124

>You could mmap that file and seek it on demand

How to recover from SIGSEGV properly?

>>896658

You just define a signal handler and keep on reading

>>896649

>Even something as simple as an strlen implementation is huge

size_t strlen(char *s)
{
    int i = 0;
    while (s[i++]);
    return (size_t)(i-1);
}

>huge

>>896554

It's not like "bar" is syntactic sugar for {'b', 'a', 'r', '\0'}, because

char *s = {'b', 'a', 'r', '\0'}

>>896547

>const char* foo = "bar";

>char* foo

In the following line

int* foo, bar, baz;

int *foo, bar, baz;

>>896706

What is the shortest possible strlen implementation that werks? Anything shorter than the one below (52 bytes)?

int strlen(char*s){int i=-1;while(s[++i]);return i;}

>>896711

Here are three alternatives, but all still same length:

int strlen(char*s){int i=0;while(*s++)++i;return i;}
int strlen(char*s){int i=-1;for(;s[++i];);return i;}
int strlen(char*s){int i=0;for(;*s++;++i);return i;}

>>896592

Have fun selling binaries right next to the readable source code.

>>896706

It's huge in glibc, yes. 78 lines not including the license comment at the top.

>>896716

Here's my attempt.

int strlen(char*s){return*s?strlen(s+1)+1:0;}

>>896674

Nope. Returning from the signal handler means returning to the point in the code that triggered the SEGV.

>>896706

>>896711

>>896716

Mine looks similar to that, but it uses pointer difference and checks for NULL.

Now check out the glibc strlen function. It's fucking huge.

>>896707

It's sugar for a const char array.

>Have advanced string object with separate size variable

>Check size and be ready to add data at the end

>The actual string is much shorter

>Either segfault or security fun

>>896779

When would that happen?

Is it a bigger danger than, for example, unterminated classical C strings?

Many languages before and after C have had counted strings.

>>896781

>When would that happen?

Even less chance than a classic buffer overflow.

Someone has to write exceptionally stupid code to produce invalid string object (that is, which has invalid length)

>>896779

>>The actual string is much shorter

This won't happen unless someone deliberately tries to change length value to some nonsense.

It's no different than producing any other kind of array with invalid length.

The string in this case is simply a special kind of an array.

Do you mean people should not use arrays as well and use some sentinel to terminate them? And what if there is no possible value to terminate, for example, if the array stores some bytes and all of them are valid encounters in the content?

Do you understand you just added more bullshit to this already drowning in bullshit thread?

>>896829

>Someone has to write exceptionally stupid code to produce invalid string object (that is, which has invalid length)

Given that C does not allow for private structure members, it is indeed perfectly possible to indicate a wrong length. A classic case of off-by-one when implementing some kind of concatenation function would do that.

>>896859

The solution is to not touch the struct directly. Just because you can doesn't mean you have to.

>>896859

>Given that C does not allow for private structure members, it is indeed perfectly possible to indicate a wrong length.

Come on, how hard is it not to screw up a size variable? You almost never touch them anyway. You get them as parameters. If your programmers can't stop themselves from accidentally overwriting a pointer + size pair, they should probably be writing Java. Lengths are explicit and really hard to screw up, completely unlike the "hurr I forgot a NUL terminator" bugs.

Strictly speaking, you could easily provide an opaque structure (incomplete, forward-declared type accessible only through pointers) with accessor functions.

/* string.h */

struct string;

size_t string_length(struct string *);
size_t string_data(struct string *);

/* string.c */

struct string { size_t s; char *p; };

size_t string_length(struct string *s) { return s->s; }
size_t string_data(struct string *s) { return s->p; }

But this would forbid stack allocation of the string structure and force people to use functions tonaccess member variables when it's just not necessary. In fact, this would be nearly undistinguishable from a generic dynamic array library. Indeed, most C stdlib str* functiond are pretty much equivalent to their mem* counterparts, save for the NUL terminator handling.

>>896859

>A classic case of off-by-one when implementing some kind of concatenation function would do that.

Yes, but that happens in virtually every other language as well. If didn't calculate an index or length incorrectly, it's a logical/mathematical error. If you failed to NUL-terminate the C string, it's a simple human forgetfulness error.

Using explicit lengths gets rid of the latter class of errors, while only Haskell might be truly immune to the former.

>>896896

>If you failed to NUL-terminate the C string, it's a simple human forgetfulness error

you know what?

it's also possible to accidentally include an extra NUL where it's now allowed to be, and that is harder to detect (no out of bounds access, no segfault) and can have even worse implications, actually the article in the OP is about exactly this.

>>896898

wow anon what about the implications of accidentally including NULL in the middle of a linked list. oh shit someone call blackhat.

>>896907

zero byte is a valid character in many encodings.

now go learn something about computing and programming, ffs.

>>896908

Yeah which encodings.

>>896907

Retard. A zero in a cadr doesnt terminate the list.

>>896898

True. That's why I don't like encoding data in-band. Arrays are simple, they are just a memory segment, a pointer to the start and the length, and they're a general data structure that can hold anything. C strings and other similar stuff constrain this simple concept. Suddenly, it can't hold arbitrary data anymore; it can hold anything except a zero byte, because the zero byte is now a special value that encodes the length of the array within the array itself, and if you accidentally put a zero value anywhere you end up cutting the string into pieces.

>>896907

NULL is a pointer. The data contained by the linked list is completely oblivious to the NULL pointer handling.

>>896910

lol

>>896911

hmm if only strings were more like arrays

>>895811

>but it's also clearer

So clear that you made an error while writing it.

>>896911

>C strings and other similar stuff constrain this simple concept

Like?

>Suddenly, it can't hold arbitrary data anymore

Well no shit, retard, it's a fucking string. Strings are supposed to encode human-readable text, not arbitrary data, unless that data is itself encoded in a human-readable (or at least printable like base64) format. Want arrays of arbitrary data? Use arrays instead of being a retard. I bet you're the kind of person who complains a stack interface doesn't have a function to access to an arbitrary element of it.

>>896921

Autist

>>896922

>Autist

Ouch.

>>896909

ASCII and UTF-8, for example.

C is unusual in having trouble with null bytes, and some parts of C and Unix do support them. Try this to see Python, C/Unix and UTF-8 work with a null byte:

python3 -c 'print("foo\0bar")' | cat -v

>>896925

thank you for freeing me from the burden of explaining this to him. really appreciate that.

>>896892

>Everyone is playing nice

>Nobody will try to put invalid data in something you will have to rely on

I can see CIA rubbing its hands

>>896892

>how hard is it not to screw up a size variable?

A single one? Not hard. However, consider the following game of statistics: say there is a 95% chance that you get a line of code right without needing to touch it. If you implement a complete, modern string library, the chances that you will not commit ANY error in 1,000 lines are 0,95^1000, which is to say, 0. On average, it means 50 bugs per 1,000 lines.

That's how easy it is to screw up. Even when writing trivial shit.

>>896896

it happens in every other language, yes, but those languages have bounds checking and hide the internals of the string implementation behind a structure.

Also, not NULL-terminating a string can easily be a logical or mathematical error as well (typical example of appending a string to another, but copying 1 byte less than its length, thus removing the null character).

If you want safe strings, hide them behind an interface that does bounds checking, but that's NOT going to be fast.

>>896988

>That's how easy it is to screw up.

those statistics would have to include pajeet and the soyfags.

>>896988

If you've got one string library that'll be used in thousands of programs it's reasonable to invest ten times the effort to make sure that it works the way it's supposed to. Making mistakes is easy, but when you use a library instead of C-style strings there's a lot less code using unsafe primitives when you add it all up.

Do you have some sort of benchmark or other source to support the claim that safe strings aren't fast? I'd expect slight performance loss in most (but not all) cases, but usually nothing significant. Safe strings aren't something modern they started using when computers became faster. BCPL had them.

>>896952

we are talking about in-memory data.

when you get the string from somewhere, you of course allocate the right amount of memory and the right length is stored. do you worry about someone overwriting the memory of your process? then you have bigger threats to worry about, and you probably want to look for techniques for radiation-safe software development, that is, software that is resilient to radiation-induced bit flips.

otherwise, it's obvious bullshit.

>>896996

Admittedly, it's number I pulled out of my ass, but if you've ever done any development beyond a fizzbuzz, you know that getting a program right from the start is impossible. Even if the actual statistics of errors was 1 error per 200 lines (99.5% correct lines), it still accumulates pretty fast.

>>896998

>Do you have some sort of benchmark or other source to support the claim that safe strings aren't fast?

Array bound checkings is slower than not checking, although admittedly usually not by much, as modern processors include branch prediction. And the larger the string, the lower the impact of branch prediction misses.

>>897010

>Array bound checkings is slower than not checking

for the most critical parts it can be optimized away, but it's not a reason to eschew checking everywhere, the golden rule of optimization is to optimize at the "bottle neck".

also, modern compilers can prove correctness of access in some places and optimize it away. I remember that Java's JIT does that in many cases.

>>897010

lines of code don't mean anything.

you can split and join lines arbitrarily without changing the meaning of code at all.

>>897015

And you could write a book with one fucking sentence. I bet thats meaningless too.

>>897015

Either you didn't read or don't know what you're talking about.

>>897019

>1 error per 200 lines

One really long line of code = no errors

>>896922

>Like?

Other sentinel-using data structures.

>>896916

They are. Just keep their length around in a variable.

>>897022

I think you just hacked programming.

>>896922

>Well no shit, retard, it's a fucking string. Strings are supposed to encode human-readable text

Kill yourself brainlet. C strings have absolutely no notion of an encoding, and even if it had, the encodings themselves usually attribute some meaning to code point zero. In ASCII it is a control code which functions as a no-op. It is absolutely valid for an ASCII- or UTF-8-encoded string to have a null byte in it. The fact including some 0 byte in a string will make software written in C truncate it is a bug.

>>896952

Most exploits happen in the input handling layer, actually. Unless the CIA can subvert the kernel's most fundamental I/O syscalls and make them return bogus values, I'd say you will always know the exact size of your data.

>>897038

>Most exploits happen in the input handling layer

this

>C strings have absolutely no notion of an encoding

not op but I like having a generic unicode type that is coding independent. Haskell does this for example where you have a type called Text and you have operations for it and can then encode / decode it to whatever you want, while the abstraction is independent of it.

>>896988

>those languages have bounds checking and hide the internals of the string implementation behind a structure.

These internals are essentially just a length and a pointer. Out of bounds access is still a bug, even with bounds-checking; the only difference is the runtime won't actually allow the access to take place, raising an exception instead.

>Also, not NULL-terminating a string can easily be a logical or mathematical error as well (typical example of appending a string to another, but copying 1 byte less than its length, thus removing the null character).