Posts by TkTkorrovi

Write a simple makefile, as i said, then you can also make the ide to use that makefile :)

Well the easiest, if you have only one input file, is

gcc something.c -o something.exe

But better is

gcc -std=c89 -Wall something.c -o something.exe

This is for windows, in linux the executables usually have no extension, they can have, but exe in linux is kind of ugly. For that of course, you need to have gcc, in windows preferrably with msys or better cygwin, as these give you bash-like shell (all are free). And, from that you can make a nice makefile, too :)

all:
	gcc -std=c89 -Wall something.c -o something.exe

And then to compile, you only have to write "make".

I don't know such algorithms and don't think it's a simple problem. But if nothing helps, look at the gimp code and see how it's done there

Watch the '\n' in the end of your string, this appears among your ten characters, if you entered less than ten characters, well, and the rest of your characters would be garbage in that case, if you didn't define them as global, or init ether to space or zero...

Ohh yes, make sure to do this

char full_code_p [FILENAME_MAX]; /*>=11*/
full_code_p [0] = '\0';
/* or */
strcpy (full_code_p, "");

anywhere *before* you write your characters with sprintf.

Well, it's OK, in case of

char d1_p, d2_p, d3_p, d4_p,
    d5_p, d6_p, d7_p, d8_p, d9_p, d10_p;
sprintf (full_code_p,
    "%s%c%c%c%c%c%c%c%c%c%c",
    full_code_p,
    d1_p, d2_p, d3_p, d4_p,
    d5_p, d6_p, d7_p, d8_p, 
    d9_p, d10_p);

But your d1_p etc were not characters but pointers to character, as they appeared in your sscanf without &...

One more thing... If you write characters into string with sprintf, you don't need to add '\0' in the end of string, because sprintf does it.

Ohh i would say you get me a bit confused, with a strange code... But anyway, you don't need no functions from string.h to add characters to a string, but if you really like to do it with a function, then the only reasonable option is

sprintf (buffer, "%s%c", buffer, char);

but this function is in stdio.h, not string.h

What are you doing? Why do you need to have all these objects as function parameters when you input them in that same function, and where are all these objects defined? If all these "characters" are indeed defined as character arrays with the length of at least two characters, and the second character in all of these is '\0', well and everything else is correct, then your program could even work, otherwise it of course crashes. And of course you also have to consider, what if your dear user didn't enter ten characters, but less, then there would be '\n' and '\0' in your string, followed by some garbage characters, which you likely don't need in your string. But there is no need to add characters with strcpy, you can simply assign a character to a member of the character array, like buffer = c, where c is char c. But then of course you must always remember that the last character in a string must be '\0', which is the only way how it is possible to find the end of the string. What is good though, is that you input with fgets, not directly with scanf.

This works exactly as for int in 32 bit machine, but reverses longer numbers in 64 bit machine:

#include <stdlib.h>
#include <stdio.h>
#include <errno.h>

int main ()
{
        long int r = 0, n;
        char buf [FILENAME_MAX];

        printf ("Enter a number: ");
        fgets (buf, FILENAME_MAX, stdin);
        n = strtol (buf, NULL, 10);
        if (errno == ERANGE) n = 0;
        for (; n; n /= 10)
                r = 10 * r + n % 10;
        printf ("Reversed: %ld\n", r);
        return 0;
}

I don't quite understand what do you want to do, but maybe using tab (\t) somewhere in the printf format string would solve your problem.

I included stdlib.h, and my compiler doesn't give any warning, even with all warnings on. Without stdlib h it says "incompatible implicit declaration of built-in function 'malloc'" gcc 4.1.2, debian linux.

You still want to use scanf directly, instead of fgets and sscanf, atoi, or even better, strtol. This would cause you trouble at least because of all the input and newlines which scanf would discard, but which remain in the input stream. Much better and easier is to never use scanf. I would also trust more functions like atoi and strtol instead of sscanf, because at least it's described how they work, and what i can expect.

In the linux kernel codingstyle it's written that "It's a _mistake_ to use typedef for structures and pointers". Using typedef for structures is always unnecessary, even in case of structures which refer to each other, but would make the code unnecessarily less clear. Write instead:

#define MAXSIZE 64
struct BulkData {
        char data [MAXSIZE];
        struct BulkData *next;
};

struct BulkData *bdWaitingToBeCopied;

It's OK to use the reference to the structure itself in the structure definition there.

Indeed, in my limits.h, short int is two bytes, int is four bytes and long int is eight bytes, thanks. And i have always thought that int is two bytes!!! There is information about limits.h, in standard, and there INT_MAX is defined as 32767, and INT_MIN as -32767, and i kind of believed it.

Yes indeed, i run the test again, and it works correctly, if this can be called to be correct, i'm still not quite sure that it doesn't write over the allowed memory. What it does is that when i enter a number greater than the limit, then it prints exactly the int upper limit as defined in my limits.h.

But still, it's better to consider that int is two bytes, to write portable programs, because in some platforms or compilers the int can still be two bytes. Or then, maybe it's better to use short int instead of int, because that at least seems to have remained the same, it's two bytes both in standard and in my limits.h, though of course even that is not guaranteed. It's really very bad that the int has been made bigger, this may cause completely unnecessary incompatability, and very bad potential bugs.

I had no time to look at your data very thoroughly, so all i can say is that all that compiler has to do is to guarantee that your program works as it is written, ie all references refer to the right objects, the memory can be reallocated if this would not make the pointers and references incorrect. Where this may cause problems is in accessing the memory by another process, which again means that using shared memory is not always the right way for the interprocess communication, it may be better to use a simple server to manage shared information.

No, never use scanf. Use fgets or even fread or read, and sscanf maybe. But then, the numbers conversion by sscanf is not specified in standard anyhow. And using %d, the sscanf does some strange things. %d must read int, but when we read into int and then print that number, it prints correctly even numbers which are greater than 65536. This should mean that it would write into memory larger than int allows, which is overflow. The easiest solution is to always use long int, and %ld, when reading with sscanf, but this would not much help when the aim is to enter very big numbers.

Wrong, order of evaluation is not specified except precedence and operator rules.

Please see http://www.iso-9899.info/wiki/Web_resources including the link to a draft standard. Yes everything which is not written in the standard must be considered unspecified.

Yes vim has these features as well, it is indeed better to use programmers editor instead of ide. If you have makefile, why do you then need all these additional files which IDE makes, like project file, and that's often even not the only one. And all these additional features potentially restrict you, especially in more complicated projects, or at least make things unnecessarily complicated. Vim is good in that it is the most widespread, and you can expect that it is always available, at least in linux, and it is a good editor as well. As much as i know, editplus is a commercial editor. A graphical version of vim really is almost not any different in use as any other text editor, but if really some special features of vim seem to be too unusual for someone, then better use some other open source programmers editor, like scite, why to use a commercial one. But to say honestly, i even don't see a need for the editor's IDE feautures, as in linux i can keep two terminals open, i compile in one, and edit in another, mostly though with vim. When first testing the program, often even the makefile is not necessary, though later it may be convenient for more complicated things, and to have a record of the way how you compiled, it may even not provide much more than the compiler command line.

Indeed it seems that the only thing which standard says concerning the unary ++ and -- operators, is that the value of the operand would be obtained for use in expression, either before (postfix) or after (prefix) applying the operator. What remains unspecified is the order of evaluation of the operands (except precedence) and when the postfix operator would be applied.

Using the gcc compiler, the value was indeed 125, which means that gcc compiler does it the most determined way, ie applies the postfix operators only after evaluating the whole expression.

But using tcc compiler, the result was 144, which means that the postfix operators were applied immediately after obtaining the value of their operand.

Therefore using ++ or -- operators in an expression when their operand would be used later in that same expression, is something which can cause unspecified behaviour, and should therefore be avoided. What is unspecified is when the operator would be applied after obtaining the value of the operand.

Please add shutdown (sv [0], SHUT_RDWR) and shutdown (sv [1], SHUT_RDWR) respectively in the end of both threads in my example. If we look at the unix domain sockets with lsof -U, two sockets remain otherwise hanging, which is not exactly what we should expect by standard, ie closing all open files on program exit. There are some compiler flags which force that behavior also for sockets, but this again depends on compiler.

The standard even allows empty subscript brackets in variable declarations outside function parameters, but there they must be followed by the initializer

But they must be interchangeable in gcc, i never use such construct, but the parameters of the function main are often written as int argc, char *argv [], and one can also write char **argv.

int space [] is in effect the same as int *space, you can use one instead of another.

I would gladly help him with signals, but only with some more reasonable example, the present one is too abhorrent.

Nothing wrong about exercise but using signals in that case is just senseless. The following code is tested, works correctly, and the transfer is not inconsistent. Look how much more simple and better organised it is using sockets, and i'm not dizzy after writing it :)

#include <stdio.h>
#include <sys/socket.h>

int sv [2];

int main ()
{
  socketpair (AF_UNIX,
    SOCK_STREAM, 0, sv);
  if (fork ()) { /* parent */
    char buf [MAX_INPUT]; 
    char sbuf [MAX_INPUT];
    FILE *f;

    f = fopen ("prodfile", "w");
    while (1) {
      if (!fgets (buf, MAX_INPUT, stdin))
        break;
      fputs (buf, f);
      fflush (f);
      send (sv [0], "read",
        MAX_INPUT, 0);
      while (recv (sv [0], sbuf, 
        MAX_INPUT, MSG_DONTWAIT) == -1)
        usleep (10000);
      if (strcmp (sbuf, "send")) break;
    }
  } else { /* child */
    char buf [MAX_INPUT];
    char sbuf [MAX_INPUT];
    FILE *f;

    f = fopen ("prodfile", "r");
    while (1) {
      while (recv (sv [1], sbuf, 
        MAX_INPUT, MSG_DONTWAIT) == -1)
        usleep (10000);
      if (strcmp (sbuf, "read")) break;
      if (!fgets (buf, MAX_INPUT, f))
        break;
      fputs (buf, stdout);
      send (sv [1], "send",
        MAX_INPUT, 0);
    }
  }
  return 0;
}

It is certainly possible, but likely not that simple. Read the gcc manual http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc You may try add to compiler options -b powerpc and -mcpu=powerpc, but most likely this would not be enough. Using gcc as a cross-compiler may iinvolve installing some additional files, and compiling gcc for being a cross-compiler for the target platform. Using cross-compiler is anyway not that simple, that you compile a binary and give it to a friend, you should most likely test it, in windows there is a powerpc emulator for that. So a realistic option, unless you have to do some serious cross-compiling, is still to compile it for your computer, and give the source code to a friend (a source distribution), maybe add the makefile, gcc is installed in every os x, and it is not difficult for your friend to compile your program.

Yes you can do that and source code is portable as well, gcc is Mac main compiler. And use GTK :) there is also GTK for Mac. Of course it would not work on Mac, when you use Windows API. Once dev-c++ had a package system, which enabled to easily install GTK, but i didn't use it now for so long time. Installing GTK in Windows is unfortunately a bit tricky, as it involves extracting several libraries into the same directory tree.

Yes also some may say, that GTK is slow for things like graphics, but the reason why GTK is slow, is exactly because it can do many other things, all the menus and dialog boxes. GTK is a wrapper around xlib, which is very fast, and therefore all the GTK graphics functions are very similar to these of xlib, porting to xlib is not difficult at all, the difference is mostly only in function name, and even this is often similar. The same is true about QT. Therefore SDL is not necessarily better, and quite unnecessary additional learning, unless you perhaps are not going to ever do anything else, than making games. If you really want 3d, then you certainly need opengl, but perhaps except a few fields, the 3d is necessary only for 3d games, and again it only makes sense to learn that, if making 3d games is what you are going to do in the future.

No it is something, in which the people never agree, and it concerns every little thing. If you use Linux, you use something more conservative and academic, where changes are made only if really necessary for practical reasons, and therefore what you learn once, you can mostly use for your lifetime. But otherwise you inevitably enter into commercial mincing machine, from where, once in, there is no way out, other than being ruined completely, and in the process of course spent all your money and other resources which might be in your disposal. Therefore these who are consumed by this mincing machine, cannot advise others anything outside it. And this dispute can never end, because the companies keep the fire burning, as they never agree to abandon their different solutions, which is more than clearly against their interests.

Those are fighting-words Mr. :)

No, these are the words of good advice, and only intended as such. I care about developers, and about the users, but i don't care about the companies. Please don't interpret it so that not caring about the companies is always fighting against them, this is the same as demanding a full compliance.

> You obviously have no clue what you are talking about. Win32 api in Vista is the same as previous versions of MS-Windows -- only enhanced and some additions.

I don't quite agree, but even *if* there are only some enhancements and additions, then they are quite substantial, and profoundly change the way the api is used. But "only some" is not a minutia in programming, as i still remember the "small changes" from windows 98 to 2000, like some small changes of default fonts and how the fonts were measured, this made my programs written for windows 98, look like a complete mess in windows 2000.

GDI is bad because it's not cross-platform. MFC is a horribly badly designed and unreliable library, never ever use this. And better don't rely on windows api, because microsoft tends to change its api, in windows vista it's not any more the same as in the descendants of windows nt, and this change is most likely not the last. For a commercial software, the changes may often be driven by commercial interests, one of which can often be the additional income from selling the information and support for any new solutions, which no one except them don't know completely enough. There they may not care about the developers and users. Therefore Linux and everything which comes from it always used to be much more reliable, of course they make changes as well, but in spite of all that, they care much more, as you can today use in Linux some programs which were written maybe in 1970-s, exactly as they worked then.

It is that in standard C, you can only print the results line by line (you can also overwrite the line, but not go back). Therefore using only standard C, the only option is to print the board every move, which sometimes can be even quite satisfactory option, because when you always print the board in the end of the console, it always appears in the same place, and even may cause some impression of moving. But in standard C, the terminal input is always line-buffered, so you must end every input, even a single character, with newline. For better interaction, the standard way is to use ANSI terminal escape sequences, and some POSIX input functions, but if you use windows, these are not supported, there is some way to do it in cygwin though. And if you want better than this, you should use some graphics interface, say, GTK, or even opengl if you really want 3d graphics. But someone could really try my nice GTK console http://www.daniweb.com/code/snippet737.html :)

QT is commercial, which means, owned by a company, and this may involve commercial interests, GTK is not commercial. Also, QT is only for C++, which means that it cannot be used in C program, while GTK is for C. Otherwise, QT and GTK are quite similar, having almost the same functions.

Concerning platforms, a good solution is to write only for Linux :) because Linux runs on many computer architectures. Otherwise, at least x86 and powerpc should be targeted, this also enables to use the software in some embedded devices. For that, the best compiler is gcc, which can compile for the biggest number of processors. gcc is certainly better than visual c, as it is more standard-compliant, and also more reliable, and at that it is free. In Windows, cygwin and mingw use gcc.

Use MinGW and GTK :)

Why do you do that with signals, signals supposed to be only for some system events, use pipes, or sockets. And if you anyway use files, nothing would become slower when you use files to signal.

Try to comment out the suspicious code, like that containing GTGetUniqueFileName, and see whether it works then. To comment out you may use something like #if 0 and #endif Or, try to temporarily substitude the suspicious code with something not suspicious.

Ancient Dragon is right what concerns scanf. I thus say that in the capacity of the right shouter, like in a meeting someone shouting "that's right", may significantly increase the credibility of the statement made by some other person. Additionally, scanf is a proper function only on condition that no one would enter more text than the variables into which we read, can take. :) :)

Debian, and some other linuces, have /proc directory, where is information about cpu, memory and devices.

getuserattr and putuserattr are some solaris functions or such, i found them nowhere in debian. The command usermod can be used to change these attributes. But to read these attributes, the only way seems to be to read the file /etc/shadow, which is not difficult, the format of this file is there: http://www.cyberciti.biz/faq/understanding-etcshadow-file

As much as i know, there are no system calls for doing all that in POSIX http://opengroup.org/onlinepubs/007908799 nothing about password expiry. All that can be done though with commands, again i'm not entirely sure whether all of these are POSIX. The shell script likely used commands, and it is not always possible to replace all commands with UNIX functions, there are no equivalent ones for every command. Some of the necessary data is likely in the file etc/shadow

It's tested now

#include <stdio.h>
#include <stdarg.h>

void stringstofile (FILE *fp, ...)
{
        char *p;
        va_list ap;

        va_start (ap, fp);
        while ((p = va_arg (ap, char *)))
                fprintf (fp, "%s\n", p);
        va_end (ap);
}

int main ()
{
        stringstofile (stdout, "one",
                "two", "three", NULL);
        return 0;
}

and the output is

one
two
three

For just making out the logic, you can simply print the board every move, you can do this in standard C. For any more complicated output, you need some console or graphics. For console, the most standard method is to use terminal escape sequences, but these don't work in Windows, except maybe if you have some special console. Using curses library is not a good solution, as it makes sense to use terminal escape sequences only for the most simple output, for anything more complicated it's better to use some graphical user interface, such as GTK, which is good because it's cross-platform. For 2d games also sdl can be used, the biggest advantage of which is that it is fast, if you really need so much speed, or opengl, if you need 3d, but you can use these two mostly only for games.

I also use FILENAME_MAX because it used to be somewhat smaller that BUFSIZ, in Linux, BUFSIZ used to be some 8000, and FILENAME_MAX some 4000, it's smaller, but quite enough so that it is quite difficult to type in so many characters. FILENAME_MAX is somewhat related to the size of the command line, as it has to allow a long file name which still has to be shorter than the maximum command line, while BUFSIZ is not exactly for such purpose, it's likely bigger in the systems with more resources.

> I prefer BUFSIZ, personally.

Yep, matter of taste, just because i must use FILENAME_MAX for file names, i prefer to use the same constant everywhere.

> That's a quality of implementation issue. You write your code so that it can intelligently handle excessively long lines.

Yes and this can only be done character by character, at least you have to consume pending characters that way. I talked about input which is not done character by character, using only fgets, which is not exactly a quality implementation, but just a somewhat satisfactory option.

> I'm not sure where you're going this.

??

Thanks Narue, discarding pending characters is indeed better than fflush (stdin). I never use fflush (stdin), and thus tend to forget what standard says about it. This discarding pending characters until newline or eof is good when using fgets as well, because fgets doesn't do that. fgets isn't perfect input method, but the only way not to do it character by character. And for not doing anything character by character, the only option is to have the number of input characters large enough, so that the user couldn't likely write too many characters by mistake. I usually use FILENAME_MAX as size, this is 256 or so, and a defined constant, so not a magic number. But, when the user still manages to write too many characters before newline, then the next input would consume it, and would most likely cause a wrong input. The standard doesn't guarantee either, that the input stream would be flushed when the program exits, though mostly it will be flushed.

Yes that's right, effect of fflush is undefined for stdin and it of course must not be used. But if they already do things insecurely, then they must use other uncertain things to compensate it, nothing to do, their choice. Then i say again that these who read would better remember, use only fgets for input. And if you use anything else for input, then delete all rubbish and use only fgets for input.

This was the most frequently asked question once in dev-c++ forum, and i'm the most sure this topic has already been discussed many times in this forum as well. Maybe the shortest answer, use only fgets for input, this is the only right function for input, as it restricts the number of input characters, and it would always input the newline as well. Then you can easily use getchar to prevent program from ending. But if you still want to use some weird input methods, like cin, then you have to put fflush (stdin); before getchar.

In fact I am firmly convinced that the vast majority of people are good (in the context of their own cultures and societies) only by the definitions of that culture and society and then only because they're afraid of the consequences of being anything else.

Nonsense, these are bad people.

I think you are good people, i indeed believe that you are good people, and therefore it's natural that you want to believe that world is good, with occasional few bad guys somewhere.

Likely the best advice, look at the SourceForge... 19073 projects written in C, many mature, some just ideas... http://sourceforge.net/softwaremap/trove_list.php?form_cat=164