Posts by nezachem

>> Sorry for annoyance. Is VC++ 2010 Express compliant?
Yes. What compiler are you using?

None.

>>I had an impression we're not talking pointers in general
That was referring to the printf() line, where the format specifer string uses %d yet only one of the 4 bytes of the integer is in the parameter list.

Huh? this one?

printf("The number is %d",*(char*)p1);

there is a pointer passed there.

try to compile it. VC++ 2010 Express gives warning

Sorry for annoyance. Is VC++ 2010 Express compliant?

Not really a pointer problem

I had an impression we're not talking pointers in general. Just pointers malloc returns.

PS:

don't know about gcc. its just a wierd compiler that doesn't complain about stuff that it should.

I have a strict policy to avoid smiley faces.

See the code snippet I posted for clarification of what I meant.

Now I am really confused. Which snippet?

But not when typecasting the return value of malloc.

Care to elaborate? (TM)

printf() will be expecting an integer but only getting a char

It will be getting int all right.The pointer is very well aligned. On a little-endian machine it would be a right int, surprisingly.

Index:2 Value:Test3 // <-- From here, the data continues exist. Why?

struct t_ddclist {
   int index;
   char value[256];
   struct t_ddclist *next;
};

ddclist *createDDCList() {
   ddclist *newList = NULL;
   newList = malloc(sizeof (ddclist));
   if (!newList) {
       return NULL;
   }

   newList->index = -1;
   newList->next = NULL;
   if (!newList->value) {
       return NULL;
   }

   return newList;
}

At every createDDCList, a single block of memory is allocated. At destroyDDCList, each of them is deallocated. Deallocation loosely speaking means that the system may reuse them at its leisure. It happens so that some parts of two first blocks did get reused. The rest happened to remain intact.
Make an experiment: just for fun, declare your structure as

struct t_ddclist {
   int index;
   struct t_ddclist *next;
   char value[256];
};

and rerun your program. Explain the difference.

Say what?

I said it int* can't be typecast to char*.

Care to elaborate?

the return value of malloc could not be typecast as char* because that it the wrong type.

Confused as always. malloc returns void * , which of course can be typecasted to anything.

As for the original question:
I run the code and the O/p is 10.

Try to run it on a big-endian machine.

> Can anyone explain me what I'm doing wrong?

Sure.

> If I call display after destroy, the display continues showing the data after the second node.

Question is, what do you expect?
After destroy, an access to the list invokes an undefined behaviour. That is, once the list is destroyed, Do Not Touch It. Otherwise, your code is quite correct.

From what I read, no, eggs must be unpacked.

Take a look at McMillan's installer; looks like archives is what you are looking for.
Disclaimer: I never used it myself.

You are calling pop() twice. Replace lines 182-185 with

temp = pop(s);
    if(temp == NULL)
        return;

Excel statistical functions: TREND

The TREND(known_y's, known_x's, new_x's, constant) function is used to perform Linear Regression. A least squares criterion is used and TREND tries to find the best fit under that criterion.

Is that what you are looking for?

> Some compilers, such as GCC, automatically initialize integers to 0

Correction. No compiler initialize an auto variable to anything. Every compiler initialize static variables to 0 (this is mandated by the Standard).

> issue a warning
At a proper warning level GCC will issue a warning as well.

In your second script the N command does join a current pattern space with the next line; however the s command causes the (updated) pattern space to be printed out. Essentially, you join pairs of lines.

My recommendation would be to use a hold buffer, and careful addressing like this:

/PowerOnHours/ !{
    # Notice the negation. Any line not matching is appended to the hold buffer
    H
}
/PowerOnHours/ {
    # Got the end of record. Append it to the hold buffer...
    H
    # ...copy the hold buffer into the pattern space...
    g
    # ...replace newlines with tabs...
    s/\n/^I/g
    # ...print out the desired result
    p
    # Finally, clear the pattern space and place an empty line in the hold buffer
    # for the next iteration.
    s/.*//
    h
}

First, the formal answer. Quoting the Standard,
output shall not be directly followed by input without an
intervening call to the fflush function or to a file positioning
function (fseek, fsetpos, or rewind), and input shall not be directly
followed by output without an intervening call to a file positioning
function

Your program satisfy the first requirement - you have fsetpos() between fgets() and fwrite(), but violates the second one - there's nothing between fprintf() and the next fgets() (note that fgetpos() is not a file positioning function).

Such a violation causes an undefined behaviour, which means that the program may occasionally work as expected, but not required to. The exact reason why did it work is unclear; I may only speculate that it has something to do with the underlying buffer sizes: your home system and the university server are configured differently.

The guts of the problem are with the IO buffering. I am afraid I can't explain "in depth" and stay in the format of a forum post.

Add fflush() right after fprintf(). Quoting man fsetpos:
The fsetpos() function shall fail if, either the stream is
unbuffered or the stream's buffer needed to be flushed, and the call to
fsetpos() causes an underlying lseek() or write() to be invoked

> Am I doing it wrong?
Yes.
Initialize vg once for the m you need.
To get a random number, instead of rand()%m just call vg().

Umm... they are tokens.

> are outside the definition of tokens
No. The Standard defines token as either of:
keyword
identifier
constant
string-literal
punctuator
and punctuator in turn is either of
[ ] ( ) { } . ->
++ -- & * + - ~ !
/ % << >> < > <= >= == != ^ | && ||
? : ; ...
= *= /= %= += -= <<= >>= &= ^= |=
, # ##
<: :> <% %> %: %:%:

os.walk returns the filenames without the path prefix. That is, you are trying to open them in the current directory, where they do not exist. change line 7 to

f = open(os.path.join(subdir, file), 'r')

PS: your variable names are misleading.

> All of the 32bit tutorials

Looks like you missed this, which accidentally comes first on a protected mode screen access google search.

// this appears to be causing the trouble

No. It is line 9. The error message points to line 17. There you call read with no arguments, while the definition of ReadIn.read requires one.

int input(worker_t *);
...
worker_t foo;
input(&foo);
...
worker_t employee[10];
input(&employee[5]);
input(employee + 5);

> So I'm porting a bunch of C functions that manipulate packets

Now that's a completely different story. Did you consider JNI? From the validation and maintenance standpoint I'd prefer to have a few interface entries to the existing C code, rather than porting everything.

> Why did they make Integer non-mutable?

Hard to say; my wild guess is to make it possible to use Integer as a key in a hashtable, etc.

My question is why do we even need AtomicInteger.

It is not about mutability. An Atomic prefix suggests that its methods are sefe in the multithreaded environment without additional synchronization.

> gives error that undefined reference "exp"

Including math.h is not enough. You need to link with the actual math library. How exactly do that depends on your compiler. Check the documentation.

First of all, both arrays must have the same size - they represent the same tree, so they have exactly as many elements as there are nodes in the tree. No need to test both sizes.
Second, in the terminating situation you should return NULL, not the root.

Third, there are way too many problems with the implementation.

You determine the array size with strlen(). This is wrong in general, because it restricts you to zero terminating strings (it also kills the asymptotics, but for now it's a least of the worries). This is wrong in particular, because the copies you made are not zero terminated.
The simplest way around - which also happens to be a correct solution - is to pass the size as a third parameter to plantBTree.

The copies themselves are also made incorrectly. For example,the RSTp loop fills up the right part of the array - leaving the left one with garbage. That garbage is then passed down to the recursive call. You need to pass RSTi + PreorderIndex + 1, RSTp + PreorderIndex + 1 instead, or copy to the beginning of the RST arrays.
Now, with the size being passed separately, copying doesn't buy you anything, and just stands in the way. You shall work directly from the original arrays. Hint: the whole function fits into 10 lines or so.

A final note: get rid of the global variables. They are bad in general, and extremely …

> Ok, so what does the video memory get placed in the pallet memory?

Please please please read the VGA spec.

> Shouldn't this display a red pixel at position 4

No. It sets the Red component of a fourth palette entry to 255. It does not display anything. To display something you need to move some data to the video memory. How to do it exactly depends on the selected mode. In some modes the value written to the video memory is an index to a palette: the pixel containing X is of color described by the palette entry number X.

Consider the following:

mov al, 4        ; Select entry 4
    mov dx, 0x3c8
    out dx, al

    mov dx, 0x3c9    ; Prepare to write components
    mov al, 255      ; Red
    out dx, al
    mov al, 0        ; Green
    out dx, al
    mov al, 0        ; Blue
    out dx, al

This sets the entry 4 to a pure red. Whenever you write 4 into a video memory, the corresponding pixel would have that color.

First and foremost: 0x3c8 has nothing to do with the video memory. It sets a pointer into a palette memory.
The value you put there is a palette entry number. A value 10 would make it point to 10'th entry. You may say is a 30'th byte; however the palette is not byte addressable, so counting bytes there makes little sense.
Yet again, it does not point to any pixel.

Now that you got rid of errors, it's time to read more on VGA. Writing 4 to the port 3c8 sets the internal pointer to the 4th palette entry. Successive write of 4 to the port 0x3c9 sets the Red value of that entry to 4. You probably want two more writes to the same port to complete the entry with Green and Blue values.

If you want to see something on the screen, read here for example. And again, read the documentation carefully. VGA is a very unfriendly piece of silicon.

Read the documentation carefully. You manage to violate practically all restrictions for the out instruction:

out	Output (write) to port
  Syntax:	out	op, AL
  		out	op, AX
  op: 8-bit immediate or DX
  Action: If source is AL, write byte in AL to 8-bit port op.
          If source is AX, write word in AX to 16-bit port op.
  Flags Affected: None

1. You may not output ah. Only ax and al are valid
2. You may not have a 16-bit immediate as the port number.

So,

mov dx, 0x3c8
    mov al, 4
    out dx, al

> Your suggestion is no different than Narue's.

No. Consider a scenario:

1. Open file for read - open succeeds; presume that the file didn't exist
2. Open file for write to do an actual job
So far so good, until another process creates the file right between step 1 and step 2. This is what is bad when test and use are separate.

CreateFile does it atomically, thus avoiding the race.

> Try to open it for reading. If it opens, it exists.

This approach suffers an inherent race condition. Moreover, in most cases (including this) such test is redundant. Both windows and posix systems provide an atomic solution to the OP problem.
For windows it is CreateFile with the disposition CREATE_NEW. For posix, it is open with flags O_CREAT | O_EXCL .

The semicolon at line 15 means that the code actually is

while (( n = fread(buffer,1,sizeof buffer, original_pointer)) > 0)
    /* Do nothing */
    ; /* End of loop */
		{
		fwrite(buffer,1, n , copy_pointer)

and fwrite is called once, after the loop finished, with n equal to -1.

Also, line 1 doesn't do what you want to.

Here's a fairly crazy proposal:
Pipe your files through sed -e 's/^#include/INCLUDE' prior to gcc -E, and then back through sed -e 's/^INCLUDE/#include/' (all that assuming that you don't want to expand any of your includes, and no line in your code begins with INCLUDE; in any case, the sed command could be tailored according to your needs). This is very much ad hoc, but I doubt there is a clean solution..

Few problems here.
1. Design problems.
1.1 You declare the function as void, yet in some cases return a value. Make up your mind (should I write a function like this, I'd declare it int and return the file descriptor).
1.2 The function opens just one file; therefore it needs just one argument. Yet you pass it the whole (counted) array of them.
That is, the proper declaration should be

int outputFile(char * filename)

2. Implementation problems.
2.1 A stat/open combination is a race condition (imagine another process creating the file right in between of a (successful) call to stat and a call to open). Don't do that.
Besides, it is redundant, because O_CREAT | O_EXCL flags do force open to fail if the file exists.
2.2 Error message at line 17 is not informative.

3. Too many unnecessary (and even undeclared) variables. What is inode, what is i?

All that said, the function becomes

int outputFile(char * filename)
{
    int file_desc_out = open(filename, O_CREAT | O_WRONLY | O_EXCL , S_IRUSR|S_IWUSR);
    if (file_desc_out == -1) {
        perror(filename);
    }
    return file_desc_out;
}

It links in the librt.so, the library which provides (among other things) implementation of the sem_* functions. Ask me not why this library is called rt; however, see the Linking section of a sem_overview manpage.
PS: it is important to realize that sem family is not related to pthread family whatsoever. The fact that posix semaphores, pthreads (as well as System V primitives) coexist peacefully in the same system is one of the marvels of unix.

> gcc filename.c -lpthread
is not enough. You also need -lrt

Always test the return values of the system calls. In this case, is ShmID valid? What is errno after shmget? What is errno after shmat?

This could be helpful.

I agree that the code is not polished. I disagree though with the proposed "encapsulation of ifs". Your approach requires 25 comparisons for each non-accented letter - just to leave it alone. Really wasteful, isn't it?

Consider a redesign based on a lookup table. Such table indexed by the original character, with the value being a the substitution one. For example, translate[0x83] is 'a', translate[0xc6] is also 'a', etc. This way the code collapses to a short simple loop:

for(x = 0; x < strlen(texto); x++)
        text[x] = translate[texto[x]];

Of course, you need to put some extra effort to populate the translation table.

You did it backwards. msgctl copies data from the buf to the kernel space. So, you need to modify BUF with the desired values, and then call msgctl.

Keep in mind that BUF as it is contains garbage. Before any other operations fill it up with the correct values via IPC_STAT.

In the circular queue you may not rely on relative head and tail positions. You must keep track of the number of elements manually. Extend the struct queue with an int count initialized to 0. Increment it on every enqueue and decrement on every dequeue operations. Rewrite is_empty and is_full to inspect the count and act accordingly.

Of course, upon reaching the end of array, head and tail shall go back to 0.

PS: I'd recommend to test the queue state inside enqueue and dequeue.

What does mkNode return? Or, to put it other way around, why mkNode returns nothing?

firstnode never changes. AddToList is passed the _value_ of firstnode (which is NULL), and operates on the local variable. Upon return, firstnode remains NULL.

You have to either pass an address of firstnode,

void AddToList(LankadLista ** listaptr, char name[])
{
    ...
    *listaptr = newnode;
    ...
}

main()
{
    ...
    AddToList(&firstnode, ...);
    ...
}

or return the modified local:

LankadLista * AddToList(LankadLista * lista, char name[])
{
    ...
    return lista;
}

main()
{
    ...
    firstnode = AddToList(firsnode, ...);
    ...
}

> a print statement did not execute means practically nothing. Load it in gdb, set a breakpoint at the moveFile, and run. This is the only way to know for sure what is going on.
I would do it, but I am away from my linux box.

> a print statement did not execute means practically nothing. Load it in gdb, set a breakpoint at the moveFile, and run. This is the only way to know for sure what is going on.
I would do it, but I am away from my linux box.

Most likely, it is dying at line 32. You have to allocate writable memory for the whole backup filename.

The entry returned by readdir is statically allocated. That is, you end up with only one instance of it, and all the pointers in the files array will have the same value.
You need to hold each d_name individually: replace line 41 with

files[count] = strdup(entry->d_name);

I think you've misinterpreted the situation. The {} is specific to the find utility, and has no special meaning for xargs (in fact I wonder how they are parsed at all in this context). The latter forms the command by appending the input string (as a last argument) to the given set of arguments. To summarize, a filename is mentioned in the lame command line just once.
I don't think there's a one-line solution which involves xargs; you may consider the find's -exec option. If I were you, I'd make a small wrapper script to invoke lame properly.