Posts by nezachem

I am not sure if this is related to your problem, but the receiving loop (lines 7 - 13) looks very suspicious. Is it a copy-paste or you typed it in?

> every byte in a dword gets a separate push mov call sequence, every letter in the text

I am afraid you misinterpret the disassembly. Can you post the disassembler output?

1. Error reporting. The message at line 32 is not informative. Failure to open file doesn't mean that the file doesn't exist. Use strerror(errno) to get a real cause. It is also a common courtesy to include the filename in the error message.

2. An unnecessary copy of a (fairly large) struct entry at line 43. You may scan data directly into contacts, and get rid of next_entry altogether.

3. Check the return value of sscanf.

4. The large argument list for scanf is better to be avoided. It becomes very hard to follow which conversion in a format string correcponds to which argument. You may want to consider scanning elements one by one.

You really need to check your spelling. It is glVewport, glClearColor, umsg, etc.

Basically, right. It is more idiomatic to use calloc here. Also, I prefer to set everything up as

struct __clause__ * build_clauses(const char * p_fname)
{
    struct __clause__ * clauses;
    ...
    clauses = calloc(..., ...);
    ....
    return clauses;
}

which removes one level of indirection and makes code more streamlined, but I can't see anything fundamentally wrong in your code.

Why you are not getting the desired output, I can't say. Time to run the proram in the debugger, step by step.

PS: the way you are filling up the array is very suspicious.

If you mean lines 79-82, the logic is as follows: p_clause is declared as struct __clause ** . *p_clause is struct __clause__ * , that is, a pointer. sizeof(*p_clause) yields the size of pointer (most likely, 4), regardless of how much memory you did allocate.
Do realize that (1) sizeof is calculated at compile time, and (2) there's now way to determine a size of object pointed to by inspecting the pointer.

Regarding a segfault, line 77 screws you up. The intention was to restore the *p_clause to its original value after it's been modified by the loop, right? But the loop doesn't modify it.

Something is wrong here.

I run your code (BTW it doesn't compile as is, and produces some warnings), and got the following results (also note that I changed the test loop count to 1E2):
time of the(hours : min : sec) testCPPFind : 0 : 0 : 18.03
loop 100 times
time of the(hours : min : sec) testCPPFind2 : 0 : 0 : 17.69
loop 100 times
time of the(hours : min : sec) testCFind : 0 : 0 : 22.21
loop 100 times

which is a very reasonable outcome (for a record, compiled with -g and -O0 gcc version 4.1.2 (Gentoo 4.1.2 p1.1) ).

However, the compiler warnings, namely converting to ‘size_t’ from ‘double’ and passing ‘double’ for argument 2 to ‘double timeCount(unaryOP, size_t, const char*) make me very suspicious. Get rid of them; rerun the test. If the problem persists, post the exact code you are running.

> These are all definitions.

Let's get legal. They are tentative definitions (6.9.2:2). All of them result in the behavior "exactly as if the translation unit contains a file scope declaration ... with an initializer equal to 0". That is, only one definition.

> All three foo declarations look like declarations, but one of them is a definition.

Funniest thing is, we don't know which one.

The argument is passed by the OS when the signal is delivered. The rationale is that you may install the same handler for different signals.

> So this is called a "script"?

No. This is called a makefile.

> Does that mean this is what the code looks like?

Can you clarify the question?

> Also, how does each line function?

deletes.obj: deletes.c  deldir.h 
  cl  /c  /Zid deletes.c

The first line tells the make utility when to rebuild the target. It says that deletes.obj depends on deletes.c and deletes.h. In other words, if any of the dependencies is newer than the target (say, you edited deletes.c), the target (deletes.obj) must be rebuilt. Otherwise, the target is intact, and should be left as is.
The second line (aka recipe) tells how to rebuild the target.

Other line pairs follow the same pattern.

A wild guess: you are running on Windows, right?
The png file begins with a signature
ID=89h,'PNG',13,10,26,10
which contains a byte with a decimal value 26, that is ascii Ctrl-Z, which is an end-of-file for a text mode. Open your file with "rb" instead of "r" and enjoy a garbage on your screen.

Sure.
If you insist on recursive approach, it is better to half the argument, rather than subtract a small decrement. For example, to calculate sin(0.5), your code goes down 50 levels of recursion, while halfing does only 6. Another speedup is achieved by sincos, which calculates both sin and cos simultaneously, and performs faster than any of them:

sincos(double x, double * sin, double * cos)
{
    if(fabs(x) < epsilon) {
        *sin = x;
        *cos = 1.0 - x*x/2.0;
        return;
    }
    double s, c;
    sincos(x/2, &s, &c);
    *sin = 2.0*s*c;
    *cos = c*c - s*s;
}

As a side note, in the base case for sin and tan you should return x instead of SIN/TANMIN (for cos it is 1 - x*x/2).

Try an experiment and remove the loop at lines 2-5.
After that, explain what was it trying to achieve.
PS: there will still be a bug, but you'll be able to figure it out yourself.

It is (2)

Just wonder what does it print at line 23... Do you realize that 10^100 takes 30+ bytes as an integer?

For the rest, read the math.

The tgets function has a timeout_secs argument, which you never use. You have to request a SIGALRM to be raised at that timeout. Read a man page for alarm().

The if/else in the signal handler is meaningless: the handler is installed specifically for SIGALRM, so the signum will never be anything else. It means BTW, that timerstatus, once set to 0, will stay 0 forever. You should set it to -1 in the mainline rignt before invoking alarm().

Lines 117 and 118 make no sense.

PS: don't forget to cancel an alarm when done, otherwise you'd get a funny race condition.

You created a buffer overflow, and corrupted the stack. Line 17: there's no such thing as s1[40]. The maximal index legal for s1 is 39.

If I understand correctly what you are after, pass relevant properties as command line arguments. For example, -Dsrc=Hello (details really depend on your ant file).

So now we agree that gdc works fine, and a problem is somewhere else.Correct me if I am wrong, but there's nothing in your code which would assign any value to firstRandomNumber (or secondRandomNumber). I am talking about the shared global variables, declared at lines 18 and 19.

PS: didn't your compiler warn you that a formal parameter shadows a global declaration?

I don't believe you:

nezachem@ ~/projects/dany $ cat gcd.c
#include <stdio.h>

int gcd (int firstRandomNumber, int secondRandomNumber)
{
    if (secondRandomNumber==0)
    {
        return firstRandomNumber;
    }
    else
    {
        return gcd (secondRandomNumber, firstRandomNumber % secondRandomNumber);
        
    }
}

int main()
{
    printf("%d\n", gcd(6, 9));
    return 0;
}
nezachem@ ~/projects/dany $ make gcd
cc     gcd.c   -o gcd
nezachem@ ~/projects/dany $ ./gcd 
3

Libraries are linked to the project, so they should go into a linkage recipe:

LIBS = -lmingw32 -lSDLmain -lSDL -lSDL_mixer
sdlTest.exe: sdlTest.o
    $(CC) sdlTest.o -o sdlTest.exe $(LIBS)

Notice that since they are 3rd-party, and not likely to change, they are not listed as dependencies.

it complains about the lines which include

*(list)

Change it to (*list), perhaps...

Take a look at how UltraStar and/or Perfomous (both are open source) do the scoring. Looks like almost what you are looking for.

> First of all, assuming your binary string is stored from most significant bit to least significant bit, you will have to traverse it in reverse

No no no. Direct traversal is much simpler. Two methods need to be implemented: double a decimal string and add a bit value (0 or 1) to a decimal string.

In a pseudocode,

initialize a resulting decimal string
for each "bit"
    double_decimal_string
    add bit value to a decimal string

double_decimal_string
    set carry to 0
    for each digit in a string
        double digit
        add carry
        if result > 10
            subtract 10
            set carry to 1
        else
            set carry to 0

> I'm sure there a sequences like that for other digits too!
I seriously doubt that.

Line 52: you do not return anything from the else clause.
Didn't the compiler warn you?

fread is fine. Look at a line 19. How much memory did you allocate?

> There was something wrong with my http request (changes are on line 75 and 76)

Yes. You shouldn't split those two lines. The correct request is
GET / HTTP/1.1\r\n
\r\n
At the 1.1 level this is not enough. You must send additional headers, such as Host (I don't recommend using 1.1 until you master 1.0 level).

When receiving a response, do not expect to get everything in a single recv call.
Finally, do not send all 100 bytes of aa . There's a lot of garbage there.

> What .depend files are I didn't really understand.

Usually they are hints to the compilation/build environment.
Obviously, an object file depends on a corresponding source file, in a sense that it should be recompiled once the source changed. Less obvious, the object file also depends on modifications of various header files the source includes directly or indirectly. There could be other even less obvious dependencies.
The .depend files keep this information.

> (2nd)at line 105..

The wait label is entered via a call instruction, so logically the control shall be relinquished by ret , shouldn't it?
In your case, the control is always getting back to state_1 , so no other state is possibly reachable. That is, listen is never called.
Besides, each call wait deposits a return address on the stack, and without ret it is never cleaned up, meaning the stack grows indefinitely.
So, make wait a proper subroutine, see what happens, and which new problems appear.

> Thanks for answering in the first place "nezachem"

Never mind. I solve problems

Few problems in your code.
First, your pops are in a wrong order. The last thing pushed shall be first to pop.
Second, can you explain line 105? The way it is written, you are (a) jailed to state_1 and (b) bound to a stack overflow.

> is this a valid approximation?

I don't think so.

> If not why?

Yielding CPU is not necessarily a context switch: control could be returned to the same context without remapping. I don't see anything forcing a switch.

The sample code gives a reliable lower bound of a system call/return though.

The behaviour you describe means that a -I option is silently passed to rm. Usually it is done by aliasing rm to rm -I somewhere in the startup scripts; some people think it is a good idea. The simplest way is to directly invoke /bin/rm instead. If you are writing a script, a full path to an external executable is a must anyway. If you are just annoyed at the command line, search your startup scripts for rm, and comment out the aliasing.

> don't use fgets, it's a security bug.

Care to explain?

What is m at line 7?

You can't send std.string to fscanf. It expects a C-style character array.

How name and pass are declared?

Line 46: How the memory for temp's data is allocated?

First of all, you must realize that on a 5081 architecture a true debugger is not possible. 8051 doesn't have a concept of exceptions, and even though a breakpoint (almost) may be emulated by a call, the resume from breakpoint seems practically impossible. It could be done with a support on a host side (very tricky); I don't know if the hyperterm allows that.

Open a new file in a good editor. Type some text, embedding backspaces in it. How to embed a backspace depends on the editor. In vim, type Ctrl-V Ctrl-H (in linux) or Ctrl-Q Ctrl-H (in windows). You will see ^H, this is a backspace. Save the file as foo. Then type your_program < foo .

> Is there some reasonable way of writing the internals of this function besides providing a giant switch statement?

Of course. Write a separate solver for each case, and keep them in a vector (or a map).

> it's the worthless checks for all possible words in the grid that are not dictionary words

Correct. That's why I suggest to let the dictionary drive the search.

The fact that the second function works at all is an unfortunate coincidence. It returns a pointer to a local variable. You must allocate Value dynamically.

Assuming that the dictionary is preprocessed into a tree, do something like this:

do_square(square, node):
    if node is null,
        return success, dictionary word found
    if letter in the square exist at the current node,
        select subtree corresponding to the letter
        for all neighbours
            do_square(neighbour, subtree)
    else
        return failure

I skipped a lot, especially bookkeeping, tracing the path, etc, etc, but you should get the basic idea.

They are shared because you can group many functions that could be useful to many different applications into one DLL and then different applications can share that DLL and its set of functions without the need for recompilation from source.

Correction. Sharability is a runtime property. A static library also requires no recompilation. The difference is that if you run two (or more) applications statically linked to the same library, you'd end up with two (or more) copies of the library code. If the library is shared, all applications share the same single image of its code.

It is (almost) beyond the programmatic control. The backspace character is processed by the console driver and not delivered to the program. You may prepare the file with embedded backspaces and redirect input from it; this way the driver is bypassed, and you will see the "\b".

The problem is in the Search function, specifically at lines 144 and 155. Can you explain the logic there?

Something is wrong here:

kputs:
	; get our first argument address into esi
	push ebp
	...
	jmp kputs

What state is the stack in when the end of string is reached?

It might be worth noting I have no debug tools that I know of available

gdb works fine in a sandbox (not to mention of a remote debug session).

Thank me when we reach some result.
Now, which directory liblapack resides in? Same for lapack and blas.
Just in case, are they valid libraries - what does nm liblapack_LINUX.a display?.
> this is driving me insane
Is this your first deadline? Relax, there are many more ahead. Insanity is not productive.

> find: /Lib: No such file or directory
OK, you have no /Lib, meaning that -L/Lib/ points to nowhere.

h2:~> dir

This is even better. You do have lapack library. What is the directory name ( pwd at the command prompt)? BTW, I am positive that you absolutely need blas; do you have it? find / -name "libblas*"

You have to check your installation. For starters, linux filenames are case sensitive. Do you have a /Lib directory with the capital L? If so, what is the output of find /Lib -name "libblas*" ? If not, try the same with /lib instead of Lib.