loves me some obscure error message

Ok, I've got this code (not exactly as seen here, it's much long and obviously uses real variable names etc. but I just provided the bare minimum so you can see what's going on):

void myfunc(const char *sarg)
{
        char *temp;

        temp = strtok(sarg, ".");

        /* etc.  doesn't matter what I have beyond this code */
}

I get this message:
[Warning] passing arg 1 of `strtok' discards qualifiers from pointer target type

What the hell does that mean?  I'm not too worried about it because it works fine if I just typecast sarg with (char*), but I'd like to know wtf this actually means instead of just assuming that everything will be ok as long as I typecast, since that could potentially lead to some unsafe behaviour that I can't foresee.

const char * is being passed as a char *.  You can cast to stop it.

Another reason not to use C++.

OT:
strtok is not threadsafe, just write your own tokenizer which passes around a tokenizer object/state. Another nice solution would be closures, but you can only greenspun those in C.

>>3

This is C

IHBT

gcc is seriously pissing me off.  It fucking always chokes on structs that use their own type in the structure (ie. a linked list).

Right now I've got a global at the top of this source file that is a pointer to this type of struct, and somewhere in a function I declare another pointer to this struct but this time it decides that _{mystruct_t} is UNDECLARED LOLOLOLOL.  How the fuck did it _{accept the previous global declaration} and then decide that this time the storage type was never declared?  NOBODY KNOWS!  Spooky Halloween mystery!

I have tried EVERY FUCKING COMBINATION THAT IS FUCKING IMAGINABLE of the following:

typedef struct name_t { name_t *nextName; };
typedef struct { name_t *nextName; } name_t;
struct name_t { name_t *nextName; };
struct { name_t *nextName; } name_t;
typedef struct name_t { struct name_t *nextName; };
typedef struct { struct name_t *nextName; } name_t;
struct name_t { struct name_t *nextName; };
struct { struct name_t *nextName; } name_t;

and probably some more before I ripped my scalp off.
And I try declaring with either

name_t *llNames;
struct name_t *llNames;


Still, it always gives me either:

fuck.h [Warning] useless keyword or type name in empty declaration <-- line number is last line of struct declaration, ie. "};"
or
fuck.h [Warning] no semicolon at end of struct or union <-- line number is the struct-ptr member
fuck.h [Warning] data definition has no type or storage class[/m] <-- line number is once again for "};"

I'm getting fucking tired of this and I might have no choice but to strip this bitch down until I have only the offending code and hope the problem is still reproduceable when I've gotten rid of everything else.  Does anyone have a fucking idea why this thing is being a jewish piece of crap?

>>6

typedef struct _linked_list
{
    void * data;
    struct _linked_list * next;
} LINKEDLIST;
doesn't work for you?

>>6
really?
i've never had this problem.
i do it this way:
struct whatever{
   struct whatever *whatever_ptr;
};

>>6
The really fucking weird thing is, this will occasionally compile without a hitch.  But I can touch something -- ANYTHING -- and suddenly it starts giving me that horse-shit again.  It just decides that the combination of crap I've fed it¹ is no longer valid.  So I start diddling with the structs again and when I think it's hopeless, suddenly the stars are just right again and the fucker compiles.

-
1. What I currently have is the following:

typedef struct name_t
{
        struct name_t *nextName;
} name_t;

/* this is what my global looks like */
struct name_t *listNames;

/* this is how the declaration looks inside the function */
void somefunc(void)
{
        name_t *name = malloc(sizeof(name_t));
}

I know that as soon as I touch anything, this crap will start all over again ;_;

maybe the name name_t is conflicting with something from one of your header files.
have you tried using a different name?

>>10
It would be weird if that was it.  I'm quite certain that the actual name that I am using for the struct is unused anywhere in the C standard, and I'm only using headers I wrote and a few standard headers like stdio and stdint.h.

Perhaps I suck at managing all the source files correctly... that's all I can think of in that area.  I have #define guards for every header but eh, I could be doing something wrong somewhere that I don't understand.

In any case it's been compiling ok since I tried including the struct name in BOTH places (fucking weird and stupid), so maybe the problem has been solved

passing a const char* to a function that modifies memory
posting random incomplete code and error messages
IHBT

>>6,9
You're doing it wrong. Anons >>7,8 have it right (though 8 is just because he isn't actually using typedef). Basically the typedef doesn't exist yet until the whole struct has been parsed, so until then you can't use the typedef; just use the struct name itself (by using the struct qualifier).

typedef struct my_struct_s {
  struct my_struct_s* next;
} my_struct;

AFTER this point you can use "my_struct*", but until the typedef is over, you have to use "struct my_struct_s*". Here I'm appending _s to differentiate the struct name from its typedef, but in most compilers you can actually use the same name (it's supposed to be allowed by ANSI C, but some compilers suck).

If it's still finicky, it's because you're fucking up your header files. Try to avoid including header files in other header files as much as possible. Where you would normally include the header file, just forward declare it instead:

typedef struct my_struct_s my_struct;

Only include the header file when you actually need the definition of the struct or its related functions (you don't need the definition for pointers).

Remember, you can always tell GCC to emit the preprocessed source (-E). Then you can look through it yourself to see where your declaration and typedefs are and where you're trying to use them.

>>1
The qualifier it's talking about is 'const'. The error message is not so obscure once you understand this.

DON'T EVER EVER EVER cast away the const modifier. If you would read the documentation, you would realize why it takes a non-const parameter:

str: C string to truncate. The contents of this string are modified and broken into smaller strings (tokens).

It replaces all the delimiters it finds with \0 to give you null-terminated tokens. If you try to use a const char* you get undefined behaviour. It might work on your computer, but on someone else's it will probably halt and catch fire. Don't do it.

Instead strdup() the string. This gives you a mutable copy. Don't forget to free it later.


Sane advice? On MY /prog/? It's more likely than you think

OP, don't listen to >>13, he's full of shit.

my hovercraft is full of feels

(error message i once saw from postfix)

>>14
I understand your desire to troll, but don't you think >>13-san might get a little sad after typing all that up?

>>16
That was the point, I was offended by the last line of his message and decided to punish him.

>>13
EXPERT C DEBUGGER

why do people use typedefs in structure definitions?
hell, why do people use typedefs at all?
never really appealed to me

>>19
NON-EXPERT C PROGRAMMER

>>19
so code isn't full of structs

>>13
Here I'm appending _s to differentiate the struct name from its typedef
I didn't really understand why I need to do that shit twice until I read this.  Thanks for the help.

>>19

I use typedefs for two things: enum types and function types.


typedef enum {
    TOKEN_NUM,
    TOKEN_IDENT,
    TOKEN_LPAREN,
    TOKEN_RPAREN
} tokentype_t;

typedef struct something *(*callback_t)(int x, int y, struct obj const *restrict p, void *cxt);

Typing out "enum tokentype" doesn't appeal to me, and writing out function types for parameters or fields gets old pretty quickly.

>>15
Because it's not programming if it doesn't have Monty Python references. I hate engineers.

>>23
Same here, except also for structs. Writing struct everywhere makes code hard to read.

Actually the only other time I use typedef is for defining a common int size for a module. Say I have a module in my program/library called 'blah' which uses numbers everywhere, and I decide they probably only need to be 16 bits. Instead of using short or int16_t, better to 'typedef int16_t blah_int' and use that. That way if someone decides they need 32 bits later on, they just change the typedef.

So my C apps will have a fair number of typedef'd ints.

strtok takes a const char* because it destroys the original string in the process of tokenizing it. nonetheless I cast away the const like you OP all the time as part of my ENTERPRISE-quality work

>>26
sorry, other way round. strtok takes a char* because...