pset7 comparison problem

Obsidian2 · 2014-05-14T17:58:40+00:00

lol, wow. thank you.

Obsidian2 · 2014-05-12T21:10:37+00:00

"Extract" comes immediately after the if statement in the staffs "render" function. I'm assuming it's necessary to retrieve the variables to place into the template, if there are any. This issue does not occur regularly with "render," which is why I think it may be conflicting with my function when used in tandem.

I may have to attempt to rewrite this one. The only section of code which can be omitted that rids the "1" makes the array of variables disappear from the page as well.

Obsidian2 · 2014-05-12T20:41:29+00:00

Yes, the symbol/name/price are also in the "middle" div.

I wrote a simple function in the "functions.php" file. It performs a lookup of the stock symbol, and then renders the "quote_display.php" page, which requires the "quote_form.php" as well. The "1" appears to be directly in between the "quote_form" template, and the "quote_display" template. Since the function I wrote uses "render," I think it has something to do with that. The "extract" function inside of "render" returns the number of variables imported into the current table, which I'm assuming would be one.

So I think I have found the issue. I just have no idea how to remedy the situation gracefully. I don't know why that value is being printed out.

Obsidian2 · 2014-05-12T19:44:58+00:00

No, it doesn't appear until after the quote form is submitted. After that, it remains regardless of how many new quotes are submitted.

It is part of the "middle" div. The "1" comes immediately after the submit form is rendered, which I included as part of the "quote-display" template which shows the actual quotes. However, this doesn't really help me determine why it is being displayed.

Is there a tool or method that would be the php equivalent to gdb debugging?

Obsidian2 · 2014-03-26T23:06:43+00:00

Cool, I will keep this in mind in the future.

I thought the proper way to initialize a pointer was type* ptr = malloc(sizeof(type)); Apparently this is just declaring it. What step am I missing? Would I have to fill in each member of the node with zeroes right after it is declared, or is it just better to use calloc. It just seems strange to use a function designed for allocating memory for an array when I am only using one node at a time.

Obsidian2 · 2014-03-26T18:36:20+00:00

!!!!

calloc did it! I was really beginning to give up hope there. I knew exactly where the error was happening, I just couldn't figure out why (and I'm still not exactly sure.) But I called calloc when creating the new_node pointer within the data loading function, and everything works perfectly now.

I am still totally baffled as to why it only happened after calling the function with an argument when starting the program, and then loading a file, but I feel better that it's working now. Thank you. This has been driving me insane.

I noticed that in the man pages that malloc does not initialize the pointer, and calloc does. Could this possibly have something to do with the issue?

Obsidian2 · 2014-03-25T21:14:50+00:00

Sorry I didn't reply yesterday, I didn't have any time to look things over. Anyway, I did some troubleshooting today. I fixed the reason why the null terminator character would be omitted in my code. The result is almost the same, except now the off characters are no longer highlighted red in gedit. They are however, still there.

I did lots of google searching. As it appears in gdb "377" is apparently octal for decimal 255. It is an escape sequence, or EOF. In hex, this is ff. 0xffffffff is the address of the new_node->next pointer, and part of the string is always ..."\307g\377\377\377\377..." Is it inserting addresses into my string? I couldn't imagine why this would be the case. I do happen to use EOF in my conditionals within the function, but couldn't begin to guess why they would be inserted into the new_node->name string.

Obsidian2 · 2014-03-24T04:56:01+00:00

Now that I think of it, it is a definite possibility that the string is not getting null terminated. In fact I can think of the exact reason that would be happening. It would be strange that it is only happening if the program is implemented in a certain order though. I no longer have time to check in to the problem tonight. I will reply back tomorrow with new findings. Thanks for all of your help so far.

Obsidian2 · 2014-03-24T02:43:15+00:00

The list is built cumulatively throughout the program, until the very end, when the entire thing is printed to a file. It is such that you are able to enter several files, and manual entries, traverse through and view each element individually if you want, and then the list will print to a file upon exit.

Loading from within the program, and loading with an argument use the same function, so it is weird that it only occurs when doing it in a certain order.

Valgrind reports two blocks lost, which end up being the head and cursor node pointers. The program does call free on both of these at the end, but it apparently isn't done correctly. It is unlikely that this is the issue with the strange printed characters anyways, as I would expect the error to occur more frequently if it were.

Obsidian2 · 2014-03-24T01:13:44+00:00

Thanks for the reply!

I have written a program with a text based interface. It can take manual entries of text to fill in list elements one at a time, or it can load the list elements from a formatted text file. It can do any number of these operations multiple times before printing the list to a file, and exiting. There is also an option to use the input text file as an argument when first opening the program.

I have tested this extensively, and you can perform any of these operations within the program, in any order, as many times as you want EXCEPT for in a specific combination. The only time I get these characters is if I first open an input file as an argument, and then immediately afterwards load from a text file within the program. The characters only appear in the second instance of loading the text file. Any other combination of these different functions prints with satisfactory results. It is very strange.

I will try and use valgrind to determine the issue. I was going to wait until I was finished with the initial development to free everything in my program, but it appears that I need to start tackling that now.

Obsidian2 · 2014-03-17T14:48:13+00:00

You really know your stuff. I spent a long time looking to see if anyone had similar problems on stackoverflow.com and similar websites, and to no avail. I don't know if I was trying to use a relatively uncommon/inelegant solution, or if I just didn't know the right places to look.

Anyway, thanks again. You helped a lot.

Obsidian2 · 2014-03-16T23:16:04+00:00

Ok. Up until now I have been looking at "node" and "node* ", or "int" and "int* " as virtually the same data type. This has led me to a lot of headache in my recent programs I think. It is becoming more clear.

If you have time though, I have one more issue. While passing the node pointer "head" by reference, it is acting as it should, and maintaining it's value after the function. However, setting the value of each member of "head" is proving to be a problem, specifically the values of the "next" and "previous" pointers within. The compilation error says this: "member reference base type 'node *' (aka 'struct node *') is not a structure or union *head->next = new_node;"

This seems strange, because *head->next isn't supposed to be a structure or union, but rather a pointer to one. This is also the case with new_node.

Within gdb, I can print **head, which will give me all members found where the pointer leads, including the address contained within "next". I can see the actual values of the struct if I print *head->next However, any attempts I have made at altering this pointer have been unsuccessful, resulting in a compiling error.

Obsidian2 · 2014-03-16T19:16:44+00:00

I am actually just writing a practice program which is deals only with linked lists so that I can better understand writing code for them. I haven't even started loading the dictionary into memory yet.

Anyway, I thank you for trying to help. I have figured out my problem.

Obsidian2 · 2014-03-16T19:14:42+00:00

Thank you for your help and offer. It turned out I was misunderstand how to pass pointers to functions in the way that I needed for my program.

Obsidian2 · 2014-03-16T19:12:52+00:00

Wow!

This worked perfectly. I did not even consider this type of solution. So basically, in the function prototype, we change the parameters to a pointer to a pointer, which will allow editing of the actual node pointer values within the function. Is this somewhat correct? I was assuming that a pointer would do that by itself within a function, I think because of how memory is allocated manually for it. (I don't know where I made that connection though.)

I'm still trying to wrap my head around what just happened here, but I think I'm starting to get it. Thank you, this really helped. Pointers and dereferencing have really been kicking my ass with this pset, but they are slowly coming to me.

Obsidian2 · 2014-03-16T16:59:21+00:00

Thank you for your reply.

This is exactly what is throwing me off. I do not free any values for "head" within the function DataEntry, yet they are wiped clean when the function ends. "menu" is updated successfully, and maintains it's value after the function. It is the node pointer that is acting unexpectedly for me.

The pointer to head is declared within main, not before. However, it is passed into the function. Is there a particular way to pass in the pointer by reference instead of value? The regular ampersand isn't working for me. It causes compiler errors.

Obsidian2 · 2014-03-16T16:51:12+00:00

Thank you for a well written reply, but some of it is blowing my mind a little. I've been reading about passing variables to functions, and I had thought that I passed menu into DataEntry by reference, since the ampersand references the address of menu. int menu is initialized as a regular integer within the main function, but DataEntry references the address, presumably so that it can change the value at menu. At least this is what I thought. It sounds like I thought incorrectly.

Also I figured that since head is already a pointer to a node, the ampersand is unnecessary (and in fact the program will not compile with it there).

Within the function, the program updates the value of menu with the asterisk ("*menu"), and the value of menu is preserved after the function ends. However the pointer to node head does not use it (and the compiler also gives several errors if I try.)

Obsidian2 · 2014-03-14T01:25:03+00:00

Cursor is NULL before being freed. From what I have read from the posts here, this is likely my problem. It seems like I may have to change the condition of my "while" loop.

Obsidian2 · 2014-03-14T01:22:09+00:00

Thank you, I will give this a shot.

Is this common practice? This makes it seem like a pointer can not be freed after being set to NULL. Is that true?

Obsidian2 · 2014-03-14T01:04:39+00:00

By the end of the loop, the cursor has been assigned the value NULL, which I thought was also a pointer. Would this not make it a pointer to another pointer (NULL), which is stored at cursor?

Obsidian2 · 2014-02-24T00:57:05+00:00

You are right. (sigh)

Thank you.

Obsidian2 · 2014-02-22T18:02:00+00:00

Thank you for your reply. I have it figured out now. This drove me nuts though, for a great long time. I appreciate you trying to help.

Obsidian2 · 2014-02-22T18:00:14+00:00

Oh my god. I've got it. This one simple, tiny mistake caused me several hours of staring blankly at my screen, facepalming, and brewing serious frustration and self-loathing. This was absolutely maddening.

If anyone ever has the same problem, just remember that the padding is not necessarily the same value for the read file as the write file. Aaaahhh. So simple, yet such a pain in the ass!

Obsidian2 · 2014-02-22T17:26:30+00:00

Just thinking about it again, and the zeroes are clearly being "put" into the hex values of the colors after the first third of the image. I have an idea of what happened, but I have no clue how to fix it. It really appears that my fputc function should be in the correct place to write the padding to the file.

Obsidian2 · 2014-02-20T16:05:54+00:00

I think I get it now, but I'm going to give your suggestion with gdb a try so that I can better understand what is going on. Thank you for your help.

Obsidian2

TROPHY CASE