Return to Answer

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

Additional comments re check50 results

The first two errors look like you are not conforming to this (or any capitalization thereof), from the spec of lookup. The last two indicate a bug in indexes. That could include a memory leak which could explain the browser result of "broken image" when calling cat.html.

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

Additional comments re check50 results

The first two errors look like you are not conforming to this (or any capitalization thereof), from the spec of lookup. The last two indicate a bug in indexes. That could include a memory leak which could explain the browser result of "broken image" when calling cat.html.

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

Additional comments re check50 results

The first two errors look like you are not conforming to this (or any capitalization thereof), from the spec of lookup. The last two indicate a bug in indexes. That could include a memory leak which could explain the browser result of "broken image" when calling cat.html.

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

Additional comments re check50 results

The first two errors look like you are not conforming to this (or any capitalization thereof), from the spec of lookup. The last two indicate a bug in indexes. That could include a memory leak which could explain the browser result of "broken image" when calling cat.html.

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

"other load" first. From the spec:

Odds are you’re unfamiliar with popen. That function opens a "pipe" to a process (php-cgi in our case), which provides us with a FILE pointer via which we can read that process’s standard output (as though it were an actual file).

You cannot use fseek or ftell, or any of the other file-positioning functions, on a pipe. This post explains it far better than I can. There are innumerable articles on the internet that describe pipes, here's one such. This method will cause check50/server2 failures for php tests, so perhaps best to abandon that approach.

A problem common to both functions is sizeof. EG sizeof(bP). bP is a pointer, sizeof(a pointer) is usually 8 on 64bit architecture.

Think about a black pixel from pset4. It would be represented as 3 zero bytes. The null terminator of a string is a zero byte ('\0' notation is just for the humans, computer sees 0). So here strcpy(*content, buffer); and here (strlen(str) and other places, the computer will be "fooled"*. cat.html is text (character) data, so does not contain a 0 byte, so seems to load ok.

*I interpret this line The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0') from man strcpy this way: The strcpy() function copies the string pointed to by src, **up to and ** including the terminating null byte ('\0'). By "fooled" I mean that strcpy "stops" when it encounters a null byte. Perhaps you'll find the function memcpy of use.

IMO the addByte function is adding a level of complexity that will make success elusive. The first load function is on the right track. You know how big you want *content to be. You know you want to add the next byte to the "new end" of *content. Work with that.

debug50 and/or gdb can be valuable tools for troubleshooting server. You'll find some starter tips for using gdb to debug load at the end of this answer.

Additional comments re check50 results

The first two errors look like you are not conforming to this (or any capitalization thereof), from the spec of lookup. The last two indicate a bug in indexes. That could include a memory leak which could explain the browser result of "broken image" when calling cat.html.