I'm assured that "this works on my machine" by the guy who wrote it, but my own copy of MySQL cries syntax error on the first semicolon. As you might expect, I have an entire folder of SQL that works on his machine.

It usually isn't Congress or the State that tries to abridge free expression or free speech, [...] actually, in the present situation, the main threat to expression comes from public opinion.~Christopher Hitchens

The greater mystery is that this code is allegedly one of the setup scripts for our database, which has actually already been setup and works fine. Is there some weird configuration setting that would make this code runnable as written?

the whole thing is a batch script (see the "@", which suppresses console echo), which only makes sense if sql files are associated with some executable which runs them. (on my system, they'd just open up in my editor)

I started using somebody else's library for a new feature. It was very convenient and helped me solve some important problems easily, so that's good. Unfortunately, I'm using it in an environment where security is paramount, so I had to audit it for security problems. The pain never ends:

1) It can recurse indefinitely on untrusted input2) In some other places, it very carefully tracks the current recursion level and *aborts* if it recurses too far.3) Every single non-mutating operation on its data structures allocate memory (and then frees it again). In some cases, if the allocation fails it returns a potentially incorrect result. In the rest of the cases, it very carefully checks for a failed allocation and then explicitly aborts if the memory allocation failed.4) It doesn't restrict the nesting level of recursive data structures. This interacts badly with #1 and #2, as an unwitting user of the library can legitimately create a data structure that nests too far and then blows up later on.

Oh, and not security related, but it also borrows the name of several symbols from a different library that provides similar functionality. I can't use this other library for licensing reasons, but there will be situations where my code links with code that uses the other library, causing symbol conflicts. Urge to kill rising...

Alright, so I am having a problem with something surprisingly simple...I can't figure out how to calculate a fibonacci sequence in C. I have the following code, but it either segfaults or returns random values. I feel like an absolute moron for not being able to get this to work.

NecklaceOfShadow wrote:It wouldn't compile for me because you're missing a semicolon in fib. Once I added the semicolon, it seemed to work correctly for me. Could you give a bit more detail about how it fails?

Well, I'll try again with the semicolon that was apprently missing. I would type in a number [n] and it would just return [n]. No modification or anything.

Jplus wrote:As an aside, that is not a loop function but a recursive function. Thought I should mention that.

Indeed.

0xD34D, please try to do this using a simple loop. If you need help, feel free to ask here for hints.

Recursion can be useful, but a plain loop is generally more efficient. There are situations when the compiler can "magically" convert a single recursive call into a plain loop automatically, but that's not so easy for it to do when there's two recursive calls. The rule of thumb in C is to avoid recursion unless you really do need it, or it makes the code a whole lot more readable. (OTOH, in some weird languages, recursion is actually encouraged! )

char ** is a pointer to a pointer, which is useful when you have an array of strings, like char **argv, but that's not what you want here.Actually, it'd be a Good Idea to make find_nth() return an error code if n is longer than the string length; you certainly don't want it to try to modify a char beyond the end of the array.

• Your main() function does weird things with ptr, but I guess that's a side-effect of your find_nth() taking a pointer to a pointer.

• The for loop in find_nth() increments both count and str, so (str + count + 1) doesn't point where you want it to.

The name of find_nth() is a bit misleading. I'd expect such a function to return an index or a pointer to the thing it found (or an error code if not found, or if called with a bad argument); I wouldn't expect it to modify the string I passed it. But that's a minor quibble.

Your code has several pointer-related problems. I'll give you a few hints that will hopefully help you to repair it.• Your main() function does weird things with ptr, but I guess that's a side-effect of your find_nth() taking a pointer to a pointer.If you need more hints, please ask.

I changed what I understood from your post, but am still a bit confused. What exactly is main doing with pointers that is weird? Also, the exact programming problem (followed by my updated attempt at coding it.)

Design and test a function that fetches the next n characters from input (including blanks, tabs, and newlines), storing the results in an array whose address is passed an argument.

Come to think of it, I think I might be going at this all wrong. Maybe a getchar() for count chars and then into an array would work better?

Does that even compile?find_nth takes parameters of type char* and int, but you're passing it char** and int.If that does compile, then find_nth is not going to end up doing what you expect, since the pointer you've received isn't meaningful in that context.

Fancy wrote:What exactly is main doing with pointers that is weird?

Your original "find_nth" took a parameter of type char** - a pointer to a pointer to a char.This wasn't what you really wanted.It had the knock-on effect that main had to pass a pointer to ptr, instead of ptr itself (hence you're calling it with "find_nth( &ptr )"), which is unusual for the task at hand.

I'd really like a way to write inline code segments...

Fancy wrote:Come to think of it, I think I might be going at this all wrong. Maybe a getchar() for count chars and then into an array would work better?

Xenomortis wrote:Does that even compile?find_nth takes parameters of type char* and int, but you're passing it char** and int.If that does compile, then find_nth is not going to end up doing what you expect, since the pointer you've received isn't meaningful in that context.

Fancy wrote:What exactly is main doing with pointers that is weird?

Your original "find_nth" took a parameter of type char** - a pointer to a pointer to a char.This wasn't what you really wanted.It had the knock-on effect that main had to pass a pointer to ptr, instead of ptr itself (hence you're calling it with "find_nth( &ptr )"), which is unusual for the task at hand.

I'd really like a way to write inline code segments...

Fancy wrote:Come to think of it, I think I might be going at this all wrong. Maybe a getchar() for count chars and then into an array would work better?

Nah, this way is simpler.

It does compile, and I have it down to no warnings or anything, but it just prints the entire original string regardless.

EDITProbably because I'm an idiot. I made a second string to store the characters that are requested (probably not the best way, but whatever) and then forgot to change my printf to print the new string. Thanks for the help.

Point is, this code fails because find_nth is doing stuff with a meaningless pointer (it's not changing the string because you've not passed it a pointer to your string, but a pointer to somewhere "random" (although I can make a pretty good guess where that pointer is pointing to)).

Fancy wrote:Porbably because I'm an idiot. I made a second string to store the characters that are requested (probably not the best way, but whatever) and then forgot to change my printf to print the new string. Thanks for the help.

No.Your code stores precisely one string. You do not copy it anywhere.

Edit:As I've hinted at twice, there is a single character in your code that's causing it to fail.

Point is, this code fails because find_nth is doing stuff with a meaningless pointer (it's not changing the string because you've not passed it a pointer to your string, but a pointer to somewhere "random" (although I can make a pretty good guess where that pointer is pointing to)).

Fancy wrote:Porbably because I'm an idiot. I made a second string to store the characters that are requested (probably not the best way, but whatever) and then forgot to change my printf to print the new string. Thanks for the help.

No.Your code stores precisely one string. You do not copy it anywhere.

Edit:As I've hinted at twice, there is a single character in your code that's causing it to fail.

Design and test a function that fetches the next n characters from input (including blanks, tabs, and newlines), storing the results in an array whose address is passed an argument.

Doesn't this mean that the function should be doing the input, rather than working with input that the program has already read? It sounds to me like they want you to make a function that does the same thing fgets does.

Your code has several pointer-related problems. I'll give you a few hints that will hopefully help you to repair it.• Your main() function does weird things with ptr, but I guess that's a side-effect of your find_nth() taking a pointer to a pointer.If you need more hints, please ask.

Fancy wrote:I changed what I understood from your post, but am still a bit confused. What exactly is main doing with pointers that is weird?

I guess I should've been a bit more explicit. When I told you to "Change find_nth() to take a simple char pointer" I expected you to also change the call to find_nth() in main() to pass a plain pointer to char, not a double pointer. From the other thread, I assume you understand that in C the name of an array is a (constant) pointer to the first element of the array, so givenchar str[101];f(str) passes the address of the first char in str to f().

char *ptr = str;creates space on the stack for a pointer, and stores in it the address of the first char in str.To illustrate, let's say str[101] occupies bytes 1000 to 1100 in RAM and ptr occupies bytes 996 to 999 (it's a 32 bit system, I'm using decimal, and just making address numbers up).So after you say char *ptr = str;then bytes 996 to 999 ( considered as a 32 bit number) contain the value 1000.And if you say f(ptr) or f(str), then f receives 1000 as its argument.But if you say f(&ptr), then f receives the address of ptr itself, which is 996. A small but highly significant difference!

As others have said, your compiler should warn you if you try to call a function with the wrong type of pointer. It's a Good Idea to set your compiler's warning level up high; eg, on gcc that's -Wall . There are even more extreme settings, but -Wall is generally adequate, IMHO, (but if someone wants to disagree, please feel free).

Design and test a function that fetches the next n characters from input (including blanks, tabs, and newlines), storing the results in an array whose address is passed an argument.

Come to think of it, I think I might be going at this all wrong. Maybe a getchar() for count chars and then into an array would work better?

Yes, using getchar() is probably a good idea. fgets() is NOT really adequate for this task: it's for reading lines of text, so it stops reading chars when it sees a newline (or end of file). So you want a loop that reads chars using getchar() which exits when it gets the desired count number of chars or if EOF is reached. And don't forget to make sure that count isn't too big for your array.

Xenomortis wrote:Network cards are the new printers.My desktop has two of them and neither one is capable of maintaining a connection with a router 20 feet away.

Laptop's fine though; so now I'm in what feels like a perverse situation where my desktop is being fed internet by my laptop.

Routers are the new printers.

Buy a decent router, and many network cards will work. Stick with free-Verizon crap routers, and I've noticed that all Realtek Wi-Fi cards / dongles fail with them.

I have no idea why the free-Verizon crap router fails to work with Realtek chips, but its the truth. Realtek is an extremely common wifi chip however. I've fixed the problem by getting a decent router.

I'm working on making our code base at work compile with a newer version of gcc and a new version of the OS. Of course this means that I get to find all of the moronic things that people have done in our code. I've just wasted an hour trying to track down the source of this: