int mystrlen (char* s)
{
char* t = s;
while (s [7]) s += 8;
while (*(s++));
return s - t - 1;
}
Why does this work? I know that C deals with memory chunks of 8 bytes, but I don't understand why the last byte in the memory chunk always seems to be null. There's often garbage before that.
some tests-#include <stdio.h>
#include <stdlib.h>
int _strlen (char* s)
{
char* t = s;
while (s [7]) s += 8;
while (*(s++));
return s - t - 1;
}
int main (int argc, const char** argv)
{
char emp[] = "";
char ten[] = "0123456789";
char twn[] = "01234567890123456789";
char svn[] = "0123456";
char eig[] = "01234567";
char nin[] = "012345678";
char brk[] = "0\0\0\0\0\0\0\177";
// "0"
printf ("%d\n", _strlen (emp));
// "10"
printf ("%d\n", _strlen (ten));
// "20"
printf ("%d\n", _strlen (twn));
// "7"
printf ("%d\n", _strlen (svn));
// "8"
printf ("%d\n", _strlen (eig));
// "9"
printf ("%d\n", _strlen (nin));
// "8" (broken)
printf ("%d\n", _strlen (brk));
return 0;
}
This shows the only situation I've found that breaks it, which is manually putting a non-null byte at the end of the block. Also, I'm pretty sure that if it weren't putting a null byte after that this would cause a segmentation fault.
int mystrlen (char* s)
{
char* t = s;
while (s [7]) s += 8;
while (*(s++));
return s - t - 1;
}
int main(void){
char a[100];
strcpy(a, "Hello this is dog");
strcpy(a, "what");
printf("%d %s\n", mystrlen(a), a);
return 0;
}
>17 what
Maybe this is a troll, maybe it's just ignorance, but forget everything that you just wrote.
C strings* are 1 byte character wide and \0 terminated.
*Fixed size, non-wide characters. The simple kind.
>>51460911
Ah, thank you, this also breaks it. I didn't think of that one. Of course, if this was the defacto string counting implementation, strcpy would put a null byte at the end of the last block it worked on.
>>51460986
This has nothing to do with that. All dynamic memory options in C uses 8 byte chunks. If you make a struct that is 7 bytes long, C will pad it to 8 bytes. If you make a 14 character wide string, C will let you access the 16th byte.
char *b = malloc(19);
strcpy(b, "Hello, this is dog");
free(b);
b = malloc(4);
strcpy(b, "hey");
printf("%d %s\n", mystrlen(b), b);
free(b);
>18 hey
>>51461011
No it won't. That is simply not a factual statement.
>>51461024
On modern architectures it will.
https://en.wikipedia.org/wiki/Data_structure_alignment
>>51461042
Just stop will you? What you mean is that structures can be padded to fit the closest register by compilers that perform such optimizations. It is not a C thing. If you want to disable that behaviour there are pragmas for that for all the compilers.
Another mistake is you're confusing having a piece of data allocated in the stack and assuming that somehow the memory outside would be unnacessable. Naturally it would not.
>>51461082
Padding occurs, that's all I know. I started this thread to learn more about it. There's no reason to be a dick about it.
>>51461082
*I meant closest to the size of the register ofc
And to elaborate, accessing out of bounds memory or past the stack is undefined behavior, but that doesn't mean itt magically allocates things to fit register there. Read on how computers do segmentation and pagination in multiple processor systems.
>>51461120
There are books to learn more about it. The language has been out for +45 years now.
>>51461011
That is true in most cases but the thing is
Its still undefined behaviour and can aways suddenly break
Also on other architectures it may be completely different
>>51461276
Yes, I would never actually use tricks like this in a real program. I just assumed x86. I am very curious about that final byte at the end of the chunk being null though.
>>51461182
I've read my K&R. If anything about memory padding is in there, I don't remember it. Trust me, if I could spend all my time reading C books, I would.
int mystrlen (char* s)
{
char* t = s;
while (s [7]) s += 8;
while (*(s++));
return s - t - 1;
}
struct __attribute__ ((packed)) hellothere {
char c[5];
int s;
};
int main(void){
struct hellothere hi;
strcpy(hi.c, "meow");
hi.s = 0xffffffff;
printf("%d %s\n", mystrlen(hi.c), hi.c);
return 0;
}
>>51461455
>9 meow
>>51461455
I just read about __attribute__ ((packed)) from googling around because of the other posts. Neat stuff.
Just to clarify, I'm not actually positing that my strlen function is good in the real world, I'm just curious about that last byte in a chunk.
>C memory blocks
No such thing m8.
>>51461827
Memory blocks inside of C. Memory blocks as they apply to this C program. Memory blocks according to my C compiler on my architecture in this C program.
All terrible titles.
So no one knows why the last byte is null?
Your code is breaking at your while loop. It will hit the null character and the still increment the pointer
>>51463309while (*s) s++;
return s - t;
>>51460500
>{
#include<iostream>
using namespace std;
int main (void)
{
int i;
i=0;
while (i<9)
{
cout<<"go fuck yourself"<<endl;
i=i-1
}
return 0;
}
}
>posts picking apart the example program
5
>posts bitching about semantics
6
>posts even mentioning what OP was talking about other than OP's posts
0
>>51463309
This won't work on every system
http://stackoverflow.com/questions/4711449/what-does-the-0-symbol-mean-in-a-c-string
Who the fuck knew C was all fucked up.
>>51462655
probably "padding" for use in a linked list,
could be for the sake of making the process functorial without breaking scope aka to "break" the program process in the case that a pointer function finds itself attemtping to access info outside of your c programs memory where your function is used to automate an allocation process.
Can't tell if everyone is trolling or really this bad at c.
>>51465011
Then why don't you tell us why my C compiler puts a null byte at the end of a word?
Amazing how many genius level C experts here suddenly had to leave when asked to actually answer the question.
>>51465054
THe null byte indicates the end of the character array.
>>51465214
That's not the question. Memory is aligned to the system's word (block of bytes) size, which in my case is 8 bytes. The strlen example in the OP works by checking the end of a word for a null byte, NOT by looking for the end of the character array until it finds the final 8 byte word. I don't know why there is a null byte at the end of a word though.
>>51465214
>hurr
>>51465252
>. I don't know why there is a null byte at the end of a word though.
Why wouldn't there be?
>>51465320
There's garbage everywhere else that hasn't been populated or automatically filled. The end of the word must be explicitly set.
>>51460500
>Why does this work?
Pure chance.
Your code gives the impression that you think that each character in a string is aligned to an 8-byte boundary. It isn't. The compiler might place the next variable at the next 8-byte aligned address, though. Assuming your string buffer took up, say, 12 bytes, leaving this theoretical compiler four extra bytes to start address of the next variable, it might choose to initialize them to zero. I doubt that doing so is anywhere in the specification, though.
>>51465338
>The end of the word must be explicitly set.
Why? Obviously your compiler is choosing to zero those bytes out.
is this thread a joke on the pedants?
is that why the word success isn't finished?
>>51465351
I'm aware word size is not always 8.
>>51465363
Yes, I'd like to know why. There must be some purpose or it must be a side effect of something.
>>51465391
I feel like the pedants are playing a joke on me. I've never encountered such an overwhelming inability to extract meaning.
>>51460500
sizeof(char) is nowhere near 8 and it is sheer luck that this works some of the time
Stop hard-coding values for pointer arithmetic, this sort of thing is what sizeof is for
>>51465351
Sorry, I misread your post. I have examined many memory chunks in my debugger for this thread. I have not had it fail yet, but I have always had garbage at the bytes following the end of the string and before the end of the word.
>>51465482
8 bytes (1 char), not bits. I'm looking at words, not chars or character arrays.
The pointer arithmetic is to demonstrate that there are null bytes at the end of words. The example function is not intended to be used in practice.
Please read the thread.
>>51465519
*8 bytes (8 chars), not 8 bits (1 char)
>>51465430
>>51465430
perhaps it is to encourage automation?
consdering "computer scientists" come up with the language it would make sense to think that string length has something to with making the string process as seamless as possible. Providing the hooks and hinges as the standard to the model might help computer scientists make more "room" for the actual designs and engineering systems. Meaning, if you can reduce overhead costs then you can spend more on things like accessibility and optimizations between structures that lie/reside beyond the first order.
>>51465496
perhaps it is to allow for more unique values to aid in the optimization and retracing processes?
>>51465594
Words, not strings anon.
>>51465614
This seems likely.
>>51461453
Maybe the books you should focus on are the ones that talk about the compilers, rather than the language? If this is a compiler optimization, then it's not strictly part of the language, meaning K&R wouldn't have a reason to bring it up anyway as it's not how the language is defined.
>>51465628
Well considering it is C, you are right but I can't imagine they have a flag for 'word' in the assembly register. Maybe those aren't the right words but what I mean to say is that one of the unique values set to be acknowledged natively might not be 'word' but rather 'string'.
Maybe you might have more to say on the topic than I currently can say myself, though. A quick check of wikipedia shows they have a trap flag and a nested flag. Maybe that helps?
>>51465675
I think the next logical building block from there could be the keyword 'assert', if I can assume you are looking to understand the reasoning behind either the how or the why to those garbage values.
>>51460500
>I know that C deals with memory chunks of 8 bytes
That's determined by your hardware architecture, not the C programming language.
Now, if you're doing embedded systems programming with a hardware specification then it'd be valid to equate the two. Not so for general computing, though.
>>51461021
>>mystrlen(b)int mystrlen(char *s)
{
return 18;
}
