Apple writes bad co-

-de


fixed that for you

>>59266741
That's pretty clever

>>59266741

wheres that from

what does this do?

>>59266741
Elegant

>const pointer
What the fug

Im retarded can someone explain this to me like im 7 years old

>>59266766
That's why it's bad.
Any programmer worth their salt knows that clever code is bad code.

>>59266812

t. salty code monkey with 30k salary who does it 'close to the metal' aka programs 10 stack underflows a day into his precious C code and hates on 'liberal fags' who work for apple and develop clever code for 200k salaries and drive teslas around

>>59266741
>faggots impressed by this
Jesus, where are all the C hackers on /g/?

>>59266796
not sure if 7, but I'll try 17.
it creates a pointer and sets it to the address of str. it continues to increment the address until it can no longer be successfully dereferenced (the middle clause of the for-loop). That way you know that the pointer s is at the end of the string str. The length of the string then is simply the pointer difference between s and str.

>>59266821
>all that butthurt
You don't need to be upset if you don't know the basics of programming and it's principles, anon. It's not for everyone.

>>59266812
t. Pajeet

>>59266796

It's a mix of ancient C code (register, K&R arguments) with modern characteristics (const pointers).

Basically 's' is a pointer that starts at the beginning of the string and continues advancing until it points at a 0 (because in C everything different from 0 is "true", who the fucks needs actual booleans). Then returns the number of chars advanced, and that's the string length.

>>59266851
See >>59266849

>>59266841
>it continues to increment the address until it can no longer be successfully dereferenced (the middle clause of the for-loop).
No, the loop condition is simply the value that s points to, and it will only evaluate to false when the 0-terminator is reached.

>>59266741
>register
>>59266783
address_for_the_end_of the_string - address_for_the_start_of the_string

>>59266741
>declaring str again before the function body
How old is this code? I haven't seen code that does that since before C89

>>59266741
This is really basic stuff if you have experience with C and maybe know a bit of assembly to understand what "register" tells the C compiler.

>>59266987
Also, who the hell would use such strlen now that only supports ASCII when there are unicode characters everywhere?

>>59267017

Americans.

>>59267017

OSX, *nix and Linux uses UTF-8 and in that case there is no concern about the way strlen does because it still does what it intends to do (return number of bytes in string).

>>59266741
What the hell is that function syntax?

size_t strlen(str) const char *str;
{
}

Pointer minus pointer returns a diffptr_t, not a size_t.

Fucking apple n00bs.

>>59267088
Read K&R you pleb.

It's old-style parameter declaration.

>>59266812
Said like a real Pajeet.

>>59267088
Before the modern declaration syntax was created, functions with parameters were declared as follows:

return_type function_name(argname1, argname2, argname3)
type1 argname1;
type2 argname2, argname3;

Essentially, parameters were declared the same way variables would be.

>>59266812
This. Writing 'clever' or obfuscated code has literally no advantage. In fact it hurts you because other devs can't read it easily, and I'm sure the compiler has a harder time optimizing that shit. If you wanna write clever code, save it for your pet projects that no one else will touch.

>>59267154
>other devs can't read it
And neither can you a week later.

>>59267154
>>59266812
>>59266766
>standard implementation of strlen lifted straight out of K&R is considered "a clever hack" by /g/

God damn it, just go back to Java you fucking pajeets.

File: geenwtf.jpg (22KB, 718x717px)

22KB, 718x717px

>>59267154
>A function called millions of times a second should trade speed for readability
Any programmer with half a brain cell can figure out what that function is doing
Stop being retarded.

>>59267201
>calling strlen a million times a second in the first place

>>59267208

One piece of software isn't doing it. ALL of your software added up does it.

>>59267154
>but other devs..
i don't want anybody incapable on conceiving the genius of my code to be able to read it

>>59266812
>Optimizing is bad! Let's make inefficient code for those hardware makers to fulfill that programmed obsolescence quotas!
You meant this, right?

>>59267317
>you can only optimize shit if you write clever code
Please, refer to >>59266849

And if your programming language of choice requires you to write clever code to optimize your program, you might as well use another language.

/g/ is dead.

>>59266841
isnt that the normal way of doing it anyways?

>>59267343
You can write the function a million other ways, it doesn't matter how good your compiler is at optimizing the code, it's still going to be slower than the "clever" code.
The function OP posted is good because it exploits Boolean logic, the only optimization in newer compilers would be the removal of the register keyword.

>>59266741
Slow ass pajeet code

http://tsunanet.net/~tsuna/strlen.c.html

>>59267386

/g/ was always dead. Go find a private community or somewhere where they actually narrow their topics and moderate heavily (until inevitably it crumbles due to inactivity or drama, then find the next community).

I'm here for banter and Chinese shit threads.

>>59267428
>it doesn't matter how good your compiler is at optimizing the code, it's still going to be slower than the "clever" code.
That doesn't make any sense and you know it. Worse yet you're endorsing bad programming attitudes.

If you're only gonna pull false information from your ass, then you better go learn the basics of programming again.

File: the_neverending_dreamer_by_parablev-d303yfo1.jpg (418KB, 1600x900px) Image search: [Google]

418KB, 1600x900px

>>59267448
>mfw

>>59267448
>I program like THIS so he can program like THIS
(show images of that code and JS pajeet code)

File: 14577213343940.png (78KB, 694x801px) Image search: [Google]

78KB, 694x801px

>>59267448
>153 lines+comments for a strlen function

>>59266741
access violation if str is not null terminated

>inb4 this is by design in c
that doesn't make it good code

>>59267560
But it's faster and for a function as primitive as strlen, that really matters.

The only way to improve speed from here on is to drop C strings, like most other programming languages do.

>>59267448
GNUcucks will defend this

>>59267076
utf8 isnt a fixed bytes/char

>>59267601
anon didn't claim it was either

>>59267618
it makes him wrong though. i think unicode chars can have null bytes in them. havent checked but it should be possible

>>59266741
>>59267448
Meanwhile, musl combines both approaches into a small yet tricky implementation.
https://git.musl-libc.org/cgit/musl/tree/src/string/strlen.c

>>59267201
>implying that shit is fast
>implying a less obfuscated version wouldn't compile to the same exact asm anyways

>>59267649
this

you could at least write it less cryptically, making it more obvious you're just address-walking until null

>>59267633
>i think unicode chars can have null bytes in them. havent checked but it should be possible
No, you are so very wrong.
Unicode doesn't even have a definite concept of a character. It's not a very useful concept.


>it makes him wrong though
No, the number of bytes in a string is the length of it by definition. in c at least.

Looks like some of you little guys havent been reading your Computer Systems a programmers perspective books.

>>59267674
byte length sounds pretty useless when talking about strings, which should be treated as arrays of (multibyte) chars

>>59267674
fine, i meant utf8

>>59267692
>useless
Try writing some code to take a string from a user, store it in memory, write a copy, with each character incremented by one, to another location in memory and write it out.
All without knowing the length of any of the strings in bytes.
I'll wait.

>which should be treated as arrays of (multibyte) chars
Like UTF-8, or something else?


>>59267698
how does that make you right?

>>59266858
yea if anything this piece of code's greatest sin is just looking old.

I suppose I can ask it here instead of sqt

The register keyword just "suggests" the compiler to store a variable in a cpu register (which the compiler may or may not comply) right? What if I absolutely 100% want my variable to be allocated in a cpu register?

>>59266796
Oh my god where are your parents?

>>59266858
The pointer isnt const retard. How would it advance if it was? Be less retarded please

File: tonge-4A.png (120KB, 280x280px) Image search: [Google]

120KB, 280x280px

>his libc doesn't have an implementation of strlen_s
lmao enjoy your buffer overflows fgt

>>59266741
this isn't that impressive

>>59266786
Pointer to const char. Const pointer would be

char * const str;

http://cdecl.org/

>return(result);
>not return result;
Shit taste/10.

>>59267448
Won't this break on machines where a long long int is 128 bits or more?

Are there any libs/compilers that do memoization of strlen?
If the compiler knows there's been no dereferences of that pointer, can't it use the same return value if it's called twice or more?

>>59267969
Now you know why GNU is shit.

>>59267838
>strlen_s
It's there, and it's called strnlen in the POSIX.1-2008 standard.

>>59266821
>30k

Where I live you are lucky if you get a 10k one

Not even sysadmins get 30

>>59268332
strnlen_s and strnlen are two different things.

Read the C11 standard. Inform yourself before you Shrek yourself.

>POSIX
lmao who gives a fuck about that shit?

>>59268408
>strnlen_s and strnlen
lmao they don't come much dumber than that

>>59268408
A collection of companies such as IBM, Fujitsu, HPE, friends

>>59267448
The fuck is this

File: rape_face.jpg (31KB, 324x196px) Image search: [Google]

31KB, 324x196px

>>59268446
>legacy shit
Oh ok. Carry on.

>>59266741
except it doesn't work properly with UTF-8 strings.

>>59267103
so K&R is only way to become patrician?

>>59268492
http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9?query=style

>>59268477
The fuck are you on about?

>>59266741

size_t mystrlen(const char *str){
    size_t i;
    for(i = 0; str[i] != '\0'; ++i);
    return i;
}

How much speed would be lost with this?

>>59268837
>have to extract each element for each element in the array
>have to check for equality
>probably have to convert between types thanks to that '\0'
A lot

>>59266812
Lol wut

>>59269000
>>have to extract each element for each element in the array
It's the exact same as accessing a pointer. compiler > you. This part I'm sure of.

The standard strlen function also checks if *s is true. Isn't that the same as checking equality?

And '\0' is a constant which will probably get optimized somehow, or am wrong here?

>>59267154
I figured that shit out quite quickly.

If anybody can't figure that out they have no business looking at the code.

>>59269070
It will produce the same binary as OP, but you version is more readable.

>>59268837
Both the original and your code compile to essentially the same assembly with gcc on Linux x86_64.

K&R strlen:

strlen:
.begin:
        /* %rdi is the first parameter to the function */
        cmpb    $0, (%rdi)
        je      .return_zero
        movq    %rdi, %rax
.loop:
        addq    $1, %rax
        cmpb    $0, (%rax)
        jne     .loop
        subq    %rdi, %rax
        ret
.return_zero:
        xorl    %eax, %eax
        ret

Your code:

strlen:
.begin:
        xorl    %eax, %eax
        cmpb    $0, (%rdi)
        je      .return_zero
.loop:
        addq    $1, %rax
        cmpb    $0, (%rdi,%rax)
        jne     .loop
        ret
.return_zero:
        ret

Your code just accesses memory with a constant offset of %rdi, while the OP's code does subtraction in the end.

>>59269070
>The standard strlen function also checks if *s is true. Isn't that the same as checking equality?
not really, it just executes the loop when *s is not zero.


>And '\0' is a constant which will probably get optimized somehow, or am wrong here?
In ascii, the '\0' is the null character. so, it's replaced with 0.

So, str[i] != 0; is just checking if str[i] is not 0, which is the same as str[i], so the compiler can replace that.


c is a _very_ simple language. The only way to really make code run faster is to make the computer do less stuff.

>>59269144
What do you use to get that ouput? gcc -S or objdump?

>>59269250
gcc -S. I just removed the function prolog/epilog macros for brevity, which just manipulate the stack frame and aren't actually needed in this case, and gave sensible names to the jump labels.

If you compile with -Os, it's mostly the same, but with "incq %rax" instead of "addq $1, %rax".

strlen:
    movq    %rdi, %rax
.loop:
    cmpb    $0, (%rax)
    je      .exit
    incq    %rax
    jmp     .loop
.exit:
    subq    %rdi, %rax
    ret

strlen:
    xorl    %eax, %eax
.loop:
    cmpb    $0, (%rdi,%rax)
    je      .return
    incq    %rax
    jmp     .loop
.return:
    ret

File: 1466644344269.jpg (97KB, 1183x543px) Image search: [Google]

97KB, 1183x543px

>>59266741

>>59269474
why #if 0?

File: 10846808_kingsglaive-final-fantasy-xv-gets-new-release_a4c84be9_m.jpg (34KB, 630x329px) Image search: [Google]

34KB, 630x329px

>>59267448
>no CSS

>>59269536
Easier to manage than one huge /* … */, although you only should do that with actual code and not just a cheat sheet for gdb command line usage.

>>59267154
>other devs can't read it easily
the bigger problem is that not even I understand my own "clever" code after a couple weeks have passed.

>>59269596
about as easy to manage as one of these though.
/*/
...

//*/

That explains it though.

Why not use an identifier?

>>59266741
Isn't that function declaration old K&R C? Why are they using that?

>>59266812
>>59267154

How the fuck is that considered "clever"?

>>59270729
It's only clever to retarded pajeets who don't know anything beyond what stackoverflow says.

>>59266741
>"Clever code"
>Not a single commentary explaining anything in a code that will be used by hundreds of people.

>>59269305
> the year of our lord 0x07e1
> using AT&T asm syntax

For fuck sake, anon. Use -masm=intel.

christ
pointer arithmetic saved to size_t instead of uintptr_t which is then checked against SIZE_MAX and cast to size_t
not checking for overflow
const on the left size of type, fucking disgusting
not checking for null, though string.h strlen doesn't either
for without brackets, even if no body, it's better for readibility to have brackets and /* do nothing */
assuming '\0' is zero, assuming false is zero
return written like function, fucking disgusting

>>59270858
>2 lines
>needing comments for subtraction

>>59270858
>He needs comments to explain simple babby tier concepts in C

I hope you don't do any programming

>>59270934
actually i'm wrong. pointer arithmetic saved to fucking int, which is then cast to size_t. hello undefined behaviour!

>>59268401
>Not even sysadmins get 30
Sysadmins are well bellow programmers mate....

>>59270729
no idea. for some people pointer arithmetics seems like dark magic i guess.

>>59266741

>register
>const
What is the meaning of these?
How can s be constant if you're adding doing pointer arithmetic on it?

>>59271036
register is effectively fancy whitespace

>>59271036
Register is just s compiler hint

A const pointer doesn't mean the pointer itself is constsnt. It just means it points to a constant value.

>>59271036
what people want to say when they write register is to hold the value of a variable in cpu register instead of memory.
but since the compiler can disregard register type modifier for optimization purposes, it mostly means that you can't get the address of this variable

>for (s = str; *s; ++s);

wait what the fug? it's SEGFAULT if I dereference a null pointer, how the fuck does *s work?

>>59271036
It tells the compiler to keep the variable in a CPU register because it will be used a lot. The compiler doesn't have to actually do it and any decent one would do it anyway without the keyword.

>>59270966
>pointer arithmetic saved to fucking int,

Isn't it ptrdiff_t? A signed type.

> which is then cast to size_t. hello undefined behaviour!

Why? Signed -> Unsigned is a perfectly cromulent conversion.

>>59271096
stdlib's strlen doesn't check for that either.

>>59271096
It's stops when it hits value 0.
If you strlen a null pointer then it will segfault.

>>59271095

So you can't do &s I guess.

>>59271096

It takes the string pointer and increments it until it reaches the terminating null byte, which evaluates to true and ends the for loop.

>>59271096
>wait what the fug? it's SEGFAULT if I dereference a null pointer, how the fuck does *s work?

Calling it with a non NULL pointer is a precondition for the correct behavior of the function.

The compiler won't check it. You're on your own. Isn't C wonderful?

>>59271096
Check for your own null pointers scrub

>>59271116
but they are not using ptrdiff_t, they're using a type that can be smaller than the range of values returned from s - str.
what they should've written is at the very least

return ((uintptr_t) s) - ((uintptr_t) str);

which is still wrong, but less wrong.
unsigned types, so overflow is defined, explicitly cast to type which is sure to be big enough for pointers.

>>59271144
>The compiler won't check it. You're on your own. Isn't C wonderful?

C btfo. what a pile of shit language, lel.

>>59266741
One line implementation:
size_t strlen(const char *str) {
return (*str ? 1 + strlen(++str) : 0);
}

>>59271243
your stack will end on long strings, because you can't into tail recursion

>>59271222
>but they are not using ptrdiff_t, they're using a type that can be smaller than the range of values returned from s - str.

Not according to this:

https://www.gnu.org/software/libc/manual/html_node/Important-Data-Types.html

Types classify expressions, not just variables.

>>59267806
You could use inline assembly or intrinsics to make sure a value gets stored in a register, but this is generally discouraged. The compiler is almost always better than you at juggling registers.

>>59271243
not sure if this would be better or not...

>>59270934
>assuming '\0' is zero, assuming false is zero
Aren't these "assumptions" the language's axioms?

>>59267017
>unicode characters
No such thing as a Unicode character, because the concept of a character does not apply to all writing systems.

Fortunately it turns out you don't need to count characters. The usefulness of strlen is counting bytes, not characters, and strlen still works fine for this. If you want to write Unicode capable code, you have to give up on the idea of counting characters, but it's not a big deal because you don't need to do this. Just treat strings as opaque blobs.

>>59267172
only sane post

>>59267172
This

>>59266812
unnecessary and obfuscated python lambdas to access an array within a list "elegantly" in 1 line instead of explicitly in 2 lines is dumb

this, however, is not

>>59267154
It literally says what it's doing in the function name, which is all you need for fucking string length.

You should go to quora and try to impress people with your broad statements without any understanding for when to apply them.

>>59271243
yeah it's one line, but recursion is more expensive than loops - OP's still is best

>>59271243
recursion is beautiful, but in this case it's also incredibly retarded. Hopefully your compiler will save you.

>>59266796
>Retards that cant into pointer arithmetic
killyourself fampai

>>59271243
tail recursive

size_t strlen(const char *str) {
    return muhstrlen(0, str);
}

size_t muhstrlen(int x, const char *str) {
    if (*str)
        return muhstrlen(x + 1, str++);
    else
        return x;
}

File: 1484174672113.jpg (44KB, 500x355px) Image search: [Google]

44KB, 500x355px

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv) {
    char* word = "hello /g/";

    printf("%s %i\n", word, strlen(word))

    return EXIT_SUCCESS;
}

int strlen(char* word)
return 9

>>59272603
>assuming int is the same size as size_t

>>59272603
>int

File: 1487969065005.png (42KB, 500x322px) Image search: [Google]

42KB, 500x322px

>>59272650

File: 1465833678038.jpg (195KB, 2016x1210px)

195KB, 2016x1210px

>>59266741

>>59266832
Yeah, this isn't remotely impressive.

File: but-why.gif (4MB, 581x327px)

4MB, 581x327px

>>59272884

>>59272650
>char* instead of char *

>>59273280

Yes, that's what type it is. It's not of type char, is it?

>>59273302
*word is of type char

>>59273294
How on earth can they be POSIX compliant with that sort of shit?
Or was that all a hoax?

>>59273350
It's not a hoax, every Intel version since 10.5 has been UNIX certified

>>59273350
POSIX doesn't specify how poll() should be implemented, only that it should be implemented.

>>59273345

Defining things according to what they return when you use this operator is a little silly when you can just define them according to what they are.

>>59266741
>const
>modifies it
Wtf man?

It's hardly clever. That shit is basic.

>>59273389

the value being pointed to is const, not the pointer.

>>59273389

const char *

means the contents are immutable

char *const

means the pointer itself is immutable

Null terminated strings are a cancer and a blight on this earth designed to shave 3 bytes off your string storage requirement. Functions like this are why we have decades of buffer overflow exploits in the wild.

The more sane way to do strings is to keep a reference to nemb items and even char byte-size at an offset to the beginning of the string, that way you don't have to rely on a null terminator for stuff to not explode. God forbid we use an int and a short and lose 5 or 7 bytes over a null terminator.

>>59273407

C syntax is fucking awful

>>59273425
How would you do it instead?

>>59273366
>>59273376
The article specifically mentions the behaviour it's not following.

>>59273436
It mentions that it blocks when it shouldn't. It's only an issue from a performance point of view.

>>59273436
I know what it specifies, all I'm saying is that OS X has been certified to be POSIX compliant with every release since 10.5 on Intel

>>59273425
The "const" modifies what comes after it. It's the logical way for this syntax to work.

>>59266812
Why? Name one aspect of code more important than its readability. Compiler optimisation is a thing you know, and if you argue that you don't need other people to understand it because you do, then you obviously don't have a very important job/project at all.

File: full_retard.jpg (19KB, 435x435px)

19KB, 435x435px

>>59272884

>>59273505
>Name one aspect of code more important than its readability
Test coverage.

Your code can be messy and """superoptimized""" as fuck as if it's easy to verify that any changes to it are correct or not.

>>59273407

It seems intuitively backwards. I don't really know C, I guess there's a certain way you have to think of it?

Here's what my initial impression is.

char* const foo

char pointer to constant

const char* bar

constant char pointer to bar

But you say it's backwards.

>>59272884
>confusing
what

>>59270729
The way they used a for loop is uncommon. A while loop would be easier to read.

>>59273505
Who cares if pajeet can't read my code. As long as anybody who actually understands C can read it then it's good.

The string length function in the OP fulfills that requirement.

>>59273540
const affects whatever's to the left of it (unless there's nothing to the left, in which case it goes to the right).

char* const foo

the const affects the *, meaning the pointer is constant

const char* bar

the const affects the char, meaning the actual content of the pointer is constant

>>59273540
>I guess there's a certain way you have to think of it?
Depends on if const appears before or after the asterics.

const char * ptr; // mutable pointer to immutable data

is the same as

char const * ptr; // mutable pointer to immutable data 

char * const ptr; // immutable pointer to mutable data

char const * const ptr; // immutable pointer to immutable data

>>59273555
A for loop is just shorthand for the while loop you're describing

>>59273524
That is a good point, but you still need readability for that to even be a benefit, seeing as it's highly likely you're going to be giving the code to someone else to test anyway.

>>59273590
I'm not saying the OP code is unreadable, I'm saying it's stupid to not treat readability as important. And while it may be infuriating to have to write code that pajeet can read, your boss is certainly going to care.

>>59273540
>>59273594

const char* bar

can also be written as

char const *foo

>>59273595
>>59273594
>>59273634

I suppose it's a style thing then. I feel more comfortable with

char const *ptr
char * const ptr

Because then there's a pattern of consistently modifying the thing to the left. Is that bad?

File: 1478121634229.jpg (38KB, 657x527px) Image search: [Google]

38KB, 657x527px

>>59273601
Explain bls

>>59273627
>seeing as it's highly likely you're going to be giving the code to someone else to test anyway.
Uh, what the actual fuck?

Tests are always a part of the software project and goes into the repo along with the code.

>>59273657
>Is that bad?
Not at all.

>>59273657
Most other programmers are going to expect

const char *ptr

and will be confused by

char const *ptr

>>59273601
This piece of code served as inspiration for -Wmisleading-indentation on GCC6 lel

>>59273627
Lol pajeets at my job are so incompetent that we have to spell everything out for them.

They wouldn't even be trusted with a language like C in the first place.

>>59267017

It's not about needing to know how many arbitrary Unicode code points are in the string. It's about knowing how big of a buffer is going to be needed to store the string.

>>59273664

google goto fail.

the second "goto fail" gets executed unconditionally because it's not in curly braces.

this had the unfortunate effect of breaking all SSL including HTTPS

>>59267172
I was wondering when people in this thread would get this meme -- took me 2 seconds til I saw how the function was declared.

this is 10/10 b8 OP, I might try this in the future.

>>59267874
>Calls Dennis Ritchie's original code conventions shit taste.

>>59269000
>convert between types
>from char to const char
>literally a java fag

>>59273595
>>59273540
>Literally just read the declaration from right to left
It just isn't that hard.

>>59270934
>implying that the author of the code was trying to code strnlen() instead of strlen()

>>59274444

/**
* strlen
* Returns the length of a string
* @param str The string we wish to measure
* @return The length of the string in question
*/
func strlen(str: String) {
    return str.count()
}

>>59266812
Even a fucking Starcraft 1, 2 and Warcraft 3 map maker will tell you to fuck off and organize your shit and use recycle code that can be reused for different things instead of hurr paa derp a durr let's make 3000 triggers for 3000 things instead of just 1 self-contained code which can do 3000 things by itself.

>>59273505
>>59274533
>I can't read: The posts

>>59266741
>undocumented
>slow
Yep, trash.
https://github.com/lattera/glibc/blob/master/string/strlen.c

>>59275055
How is this faster?

>>59275105
It's about 4 times faster because that's how many bytes it checks at once.

>>59275150
Even when you account for the bitshifts and ORs?

>>59275193
Should be balanced by less increments. The advantage lies in less memory accesses.

File: femiturd.gif (2MB, 269x299px) Image search: [Google]

2MB, 269x299px

>>59266812
this anon is right
micro optimization is the weapon of the clueless

File: 1463495186466.png (34KB, 809x808px) Image search: [Google]

34KB, 809x808px

>>59270970
tfw all the sysadmins on /g/ make 2x+ more than i do as a programmer

>>59266884
>and it will only evaluate to false when the 0-terminator is reached.
Wait, isn't this kind of dangerous if there is no null terminator?

>>59268492
>K&R
>2017
https://gustedt.wordpress.com/2016/11/25/modern-c-is-now-feature-complete/

>>59266821
C programmers aren't the ones who say ``clever code is bad code".

>>59267017
Unicode is code-word for bloat.

>>59267097
>I have no idea how C's type system works

>>59267448
That was GNU quality!

>>59267573
So how do you propose we find the length of a string that isn't null-terminated?

>>59276884
include the length of the string alongside the data <:)

>>59268408
>Inform yourself before you Shrek yourself.
Why don't you make like a tree and fuck off?

>>59271096
Start by assuming that s isn't a null pointer.

>>59267573
You should null terminate your strings

Scrub

>>59271223
Assembly (which C is just a readable version of) doesn't check your null pointers either. Use Java or Python if you want the compiler to hold your hand.

>>59276957
>java
>hold your hand
>NullPointerException

lmao

>>59266832
>>59273053
but it is extremely impressive how not impressed you are

>>59273431

const pointer<char[]>; //pointer to mutable array of char, pointer can't be changed to point at something else
pointer <const char[]>; //pointer to immutable array of char, pointer can be changed to point at something else
const pointer<const char[]>; //pointer to immutable array of char, pointer can't be changed to point at something else

The fact that it caught it is already holding your hand.

>>59274476
doesn't compile

>>59276987
>literally to retarded for designated shitting language

>>59273555
K&R, which is considered THE book for getting into C programming does for loops like that quite a lot in the example programs, and very near the beginning too.

>>59276637
>>59276637
>>59276637
>>59276637

>>59273605
yeah so just write the while loop, easier to read and if I'm not mistaken will have negligible performance difference.

>>59270934
>not checking for null, though string.h strlen doesn't either
that's up to the client to not give the function a null pointer, not the library

>assuming '\0' is zero, assuming false is zero
This is part of the standard.

>>59269144
What machine lang is this?

>>59267573
>expecting the library to filter your tripe

Keep walking east until you hit India

>>59277142
AT&T syntax for 64-bit x86

>>59273379
we have this argument every 2 days.

type *variable

is a mnemonic based on how it's used, not how it's declared.

char *foo,bar;

here foo is a pointer to char, bar is a char.

>>59266741
in haskell, this is just

strlen = lenght

>>59276991
It's unimpressive how impressed you are about this unimpressive code.

>>59276599
welcome to C

len(string)

File: GATO pastero.jpg (43KB, 398x398px)

43KB, 398x398px

>>59273547
Just like python.

The concept is hard to understand, so changing the value of something and using it at the same time is not allowed.

and

var a = 0
a += 77; // expands to a = a + 77, but
a = 69; // doesn't have a value, so it can't be used for a function argument.
// a = b = c = 0 ; still works though ;)

>>59273686
Shame apple will never ship a version with that in it.

>>59273739
>this had the unfortunate effect of breaking all SSL including HTTPS
no.

It crashed the phone to black any time an access point with that obscure key exchange was detected.
A lot of people ran them just to fuck with iphone users.

>>59277122
It's not about performance difference, they'll both compile to the same thing anyway. The for loop is easier to understand quickly, it's a format you see all the time. Furthermore, easier to type and easier to change.

>>59277514
Yeah but it does compile to machine language at some point. I'm sure that machine language looks pretty similar to what these implementations compile to.

>>59266812
This. In production code, one that actually makes money, being simple and readable is more important then micro optimisations because "smart".

>>59267201
>millions

That function is horribly inefficient. If it was optimized for speed, then it would use duff's device or another unrolling method.

>>59266812
If you think this is anything other than standard C you're a fucking idiot, who I hope will never go near any code, let alone OS code.

>>59270858
I hear you brother. My company produces 20 lines of comments for every line of code. That's why we love coffeescript - size of documentation means ease of use.

Right on.

ptrdiff_t is bullshit and let me show you why.
suppose you have an array:

char s[SIZE_MAX];

this is allowed.
next suppose the array starts at address 0x0. this is also allowed since any interrupt vectors, etc can be somewhere else.
obviously ptrdiff_t works only on elements of the same array, otherwise it's UB.
on 64 bit systems size_t is 64 bit, so SIZE_MAX is 2^64 - 1. to hold the value of s[0] - s[SIZE_MAX - 1] ptrdiff_t would have to be able to hold the value of -(2^64 - 1), so it would have to be at least 65 bits long. unless sizeof(ptrdiff_t) is > 8, ptrdiff_t is bullshit.

>>59267448
Jesus Christ GNU, what are you doing?

>>59272603
You could make the tail recursion more explicit.

size_t muhstrlen(int x, const char *str) {
    if (!*str)
        return x;
    return muhstrlen(x + 1, str++);
}

>>59277288
>void *var
>*var is of type void

>>59276998
Enter C++ smart pointers

>>59279519
>Look mom! I can optimize fizzbuzz in so many ways you've never seen before!

File: gotolulz.png (8KB, 538x232px) Image search: [Google]

8KB, 538x232px

>>59266741
>>59267172
this, wtf?

>>59266858
>>59267832
the const is just there to say you're not going to alter the data referenced by the pointer

>>59280640
>T. Pajeet

>>59281651
no.
You're not going to alter the data through that pointer.


Not really though, it's just a pointer to a const type, so that type doesn't let you alter it unless it's cast to something else.

>>59266741
This assumes the string is stored in one continous block of data, this will fail horribly when the characters of the string are distributed over multiple fragments

>>59286210
This function measures the length of a null-terminated string, with the assumption that it is just one string. What you're talking about is multiple, independent strings.

>>59286412
>current year
>null-terminated strings

>>59286534
Welcome to C.

>>59270885
Sorry, I like to write Intel syntax too (and just compile with nasm, for example), but got used to it because it doesn't break as easy when including inline assembly where you don't directly control the compiler options.

Luckily objdump has -Mintel as well.

>>59276342
>>59270970
This. They get paid more than a lot of programmers still.
>>59268401
Where the the fuck do you live, son? Who would code for such degenerate pay?

>>59266741

size_t strlen(const char *str) {
     const char *s = str;
     while (*++s);
     return s - str;
}

>>59288431
Won't that break with
strlen("\0");?
You're incrementing then checking if it's null

>>59289878
Of course, it will.

>>59286534
how do *you* terminate your strings?