strange error "void not ignored as ought to be"

[earlz]

This is a strange error considering that i have tried casting and eveyrthing but nothing works
this is my code in a nutshell

Code: Select all

extern char **names;
extern void *cptr;
HANDLE tmp1;
tmp1=CreateFile(*names[*cptr],GENERIC_READ,0,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,0);

and this code under gcc says "void value not ignored as it ought to be"

[ark]

As far as I can tell, it means that you tried to dereference a void pointer, which is not legal in C.

Assuming that cptr actually points to an int, for example, then to dereference it you'd have to do something like:

*((int*) cptr)

But unless there's a really good reason for cptr to be a void pointer in the first place, I'd say redesigning your code is probably a better solution than casting.

In case you're curious, I was able to duplicate that error message with the following program:

Code: Select all

int main()
{
    int x = 5;
    void* pVoid = &x;
    int y = *pVoid;

    return 0;
}

This produced the following output:

test.c: In function `main':
test.c:5: warning: dereferencing `void *' pointer
test.c:5: error: void value not ignored as it ought to be

The following code compiled without errors or warnings:

Code: Select all

int main()
{
    int x = 5;
    void* pVoid = &x;
    int y = *((int*) pVoid);

    return 0;
}

[Pype.Clicker]

note that, when seen alone, that message can also inform you that you're assigning the result of a void-returning function to a variable.

[goldenaura3]

Howdy!

Something caught my attention int the CreateFile call. The first argument you pass is a single char. What you've got is a list of char *'s(char **name) and *names[*cptr] to grab one of em'.

Code: Select all

names -> char **
names[x] -> char *
*names[x] -> char

All ya' need to do is drop the * in front of names.

About the error you're getting, I've recieved that when trying to treat a void value as a non-void. Here's how I got the error:

Code: Select all

void rant() {
  puts("Blah blah blah...");
  puts("Blah blah blah...");
  puts("Blah blah blah...");
  puts("Blah blah blah...");
  puts("Blah blah blah...");
}

int main(int argc, char **argv) {

  int val;

  // Here's the problem! Since rant doesn't
  // return anything, I can't compare it...
  if (rant() < 0) {
    return 1;
  }

  // C won't let this happen either...
  val = rant();

}

I've got a few questions for ya'. Did you isolate this block of code as the problem area? Also, are the two extern values ever set? Finally, is there a special reason cptr is a void * instead of an int or something similar?

Good luck!

[Cjmovie_guest]

CreateFile does not return a void, rather a handle to the file. The problem is in the indexing of your array via cptr. Although explained above, just to point out, you'll probably not want to define it as "extern void*" but rather as "extern int*". Otherwise, your code would look something like this:

Code: Select all

extern char **names;
extern void *cptr;
HANDLE tmp1;
tmp1=CreateFile(TEXT(names[*(int*)cptr]),GENERIC_READ,0,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,0);

(assuming cptr points to an INT) Also, as goldenaura said, you do indeed pass a single character.

Among that, I'd recommend the use of the TEXT() macro to do whatever needs to be done to the buffer in the first argument. I'm not totally sure what it does, but it's used in the Microsft MSDN example, so I guess it's a good thing to have it, if not just to be safe. However, if it gives you errors (for all I know, it could only be for static strings and precedes them with L in cases nescesary), of course, remove it .

[Joel (not logged in)]

The TEXT macro is used on string literals and does indeed precede them with L, if the macro UNICODE (or maybe it's _UNICODE -- I can't remember) is defined.

In the code we're looking at here, the TEXT macro will do nothing if there's no UNICODE symbol defined and will cause a compile error if it is defined. Since it won't be defined unless you explicitly define it, that's an error you won't discover for quite some time. Best not to recommend that someone do something if you don't understand it yourself

Further, to be Unicode-ready, you should be using (in addition to the TEXT macro for string literals) the TCHAR data type and not char explicitly. TCHAR defines to char when UNICODE is not defined and wchar_t when it is defined.

[Solar]

Nlote that UNICODE and TCHAR are non-standard extensions and depend on the environment.

[Joel (not logged in)]

Yes...the context here would be the Windows API (as indicated by the CreateFile call). TCHAR and its related entities (LPTSTR, LPCTSTR, _tcscpy, TEXT, etc.) should be defined when using the C Windows API. If they're not, then the API implementation is incomplete (possible when using tools like cygwin that provide their own versions of the Windows API header files).

[LongHorn]

Is my understanding correct about TCHAR?
When the UNICODE is defined then TCHAR is defined to be UNICODE(more precisely WCHAR 16bit) else normal ASCII code( precisely CHAR 8bit). Could we compare TCHAR with UNICODE? we could compare UNICODE with ASCII.

[ark]

I'm not sure exactly what you're asking. TCHAR in the Windows API exists primarily because the Windows 9x line uses 8-bit ANSI characters and the Windows NT line uses Unicode (though these systems will run programs that use 8-bit characters). The idea behind TCHAR is to have one source code be usable for either character type, to minimize the need for conditional compilation in application code.

Most functions in the Windows API that take strings actually have two versions, one ending in "A" (for either ANSI or ASCII, I'd guess) and the other ending in "W" (presumably meaning "wide"), but there's a #define that gives them a unified name.

For example, the MessageBox function would actually be either MessageBoxW or MessageBoxA, depending on whether UNICODE is defined, as in:

Code: Select all

#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

TCHAR itself is actually a typedef, and as far as it goes it sounds like your understanding is correct. IIRC, the definition looks something like:

Code: Select all

#ifdef UNICODE
typedef WCHAR TCHAR;
#else
typedef CHAR TCHAR;
#endif

where WCHAR is a typedef for wchar_t and CHAR is a typedef for, I believe, unsigned char.

The Windows API also defines a set of functions for manipulating TCHARs, and these typically begin with "_tcs" instead of "str" (so strcpy would be _tcscpy and strcat would be _tcscat).

[Kemp]

You mean

Code: Select all

#ifdef UNICODE
typedef TCHAR WCHAR;
#else
typedef TCHAR CHAR;
#endif

Right?

[guest]

You mean

Code: Select all

#ifdef UNICODE
typedef TCHAR WCHAR;
#else
typedef TCHAR CHAR;
#endif

Right?

eh? that's backwards, you're typedefing WCHAR/CHAR as being of the type TCHAR. According to MS:

Code: Select all

#ifdef UNICODE 
    typedef wchar_t TCHAR; 
#else 
    typedef unsigned char TCHAR; 
#endif

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_28c3.asp

[Kemp]

Gah, fool of a Kemp. Skim reading and not noticing the difference between typedef and define is not recommended.

[LongHorn]

More specifically

Code: Select all

#ifdef UNICODE
typedef WCHAR TCHAR,*PTCHAR;
typedef LPWSTR LPTCH,PTCH,PTSTR,LPTSTR;
typedef LPCWSTR LPCTSTR;
#else
typedef char TCHAR,*PTCHAR;
typedef LPSTR LPTCH,PTCH,PTSTR,LPTSTR;
typedef LPCSTR LPCTSTR;
#endif

WINNT.H defines TCHAR to be generic character type.

[ark]

Although it's useful to know those because they're all over the API documentation, personally I've never seen much need for all the extra typedefs. These three constructs do it pretty well for me:

TCHAR
TCHAR*
const TCHAR*

I'm not aware of any reason why you'd need anything but those* and they look a lot cleaner (and a lot more like C++) than anachronistic names like LPCTSTR (the LP has been a meaningless appendage for over 10 years now), although perhaps I'm writing code that will need modifications to compile on a future system. I doubt it, though.

* that is, in C...in C++ I would also recommend std::basic_string<TCHAR>