[llvm-commits] [PATCH] fix illegal impicit cast from const void* to void*

John Spencer maillist-llvm at barfooze.de
Sat Mar 3 15:34:57 PST 2012


On 03/04/2012 12:05 AM, Stephen Canon wrote:
> On Mar 3, 2012, at 5:56 PM, Joerg Sonnenberger<joerg at britannica.bec.de>  wrote:
>> On Sat, Mar 03, 2012 at 11:14:33PM +0100, John Spencer wrote:
>>> more context:
>>> void* DynamicLibrary::SearchForAddressOfSymbol(const char
>>> *symbolName) calls the macro
>>>
>>> EXPLICIT_SYMBOL
>>>
>>> to return a (void*) pointer to a FILE* from a named argument which
>>> is either stderr, stdin, or stdout.
>>>
>>> the musl libc defines these symbols as const FILE* (which is
>>> perfectly legal), so the implicit cast to void* fails.
>> Is it really legal? stdin and friends are supposed to be passed to
>> functions taking FILE * as argument, so it would force const violations
>> all the time.
> C11, 7.21.1 says:
>
>>           stderr
>>           stdin
>>           stdout
>>
>> which are expressions of type ‘‘pointer to FILE’’ that point to the FILE objects associated, respectively, with the standard error, input, and output streams.
> so that would not seem to be allowed by the standard.

the standard does not say that they're lvalues, so the idea of taking a 
pointer to it is bogus per se.

per the standard it's a macro that expands to an expression (not an 
lvalue) of type FILE *



the misbehaving piece of code has a comment about the matter which reads:

// On linux we have a weird situation. The stderr/out/in symbols are both
// macros and global variables because of standards requirements. So, we
// boldly use the EXPLICIT_SYMBOL macro without checking for a #define 
first.

you can s/linux/glibc/ here.



> - steve
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list