A variation of constructor attribute
It's nice that GCC has included a constructor attribute, but it doesn't work in complex scenarios. I was considering tinkering with adding a 'initializer' and '?exiter' or maybe 'deinitializer'? (not sure what to name the other side) But on to the primary... __attribute((initializer(priority))) similar to constructor, but, and especially significant under windows, doesn't run until just before main() is dispatched. The initializers would be added to a list (or linked into a list) so they will all run in-order. It's not always proper to run lowest level initializers first (at dynamic library load time), and under windows the dll loader lock that blocks thread creation prevents creation of threads in constructor or DllMain level initializers. By waiting until all libraries have been loaded, and then dispatching their initializers the thread block is overcome. I implemented for my own library a method of doing this; but it requires additional code be added to each library/executable that uses this. Perhaps there is a way to overcome 2 of the source files I include, but the third (the scheduling part) would still have to be added, which makes adding new projects annoying. (I add a source at start with a known, unique name that indicates the first in a __attribute__((section( "deadstart_list" ))) and another that's the last in the section, the third source knows the section and can iterate through the objects defined there and schedule them. In the program I link a 4th source that has a __attribute__((constructor)) that calls all the registered startups.) So this new attribute would create a data structure similar to constructor, with a few extra fields to support adding it in-place into a list, and a flag for dispatched. it is possible that the list will change as the list is processed too, since a initializer could load another library which has it's own intializer attributed functions with various priorities (perhaps priorities that are lower than what has already been processed). I do assume that this is like most other projects I've run into that 'if I want something done, I'll have to do it myself'. Here's a rough flow of a process consisting of program lib1, plugin1 program loads, lib1 gets loaded; using constructor attributes, initializers in lib1 run (and cannot create threads in windows)... but if lib1 actually has a high priority constructor that loads plugin1 not all of the constructors have nessecarily run, but plugin1's constructors will all run at that time; It may rely on higher priority constructors from lib1 which run after the point it's dynamically loaded. after scheduling the routines, and returning to main initializers, intializer routines should start running, and new libraries loaded during initialization should get their initializers scheduled at that time (which may include initializers that are higher in priority than the current running initializer). But after all initializers have run, when a new library is loaded initializers should run immediately... hmm requires support in dlopen/LoadLibrary function too, because again, have to return to code outside of the loading process to create threads so maybe it's not practical to implement
C2X Proposal, merge '.' and '->' C operators
Here's the gist of what I would propose...
https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
In C, there are two operators . and -> used to access members of struct and
union types. These operators are specified such that they are always paired
in usage; for example, if the left hand expression is a pointer to a struct
or union, then the operator -> MUST be used. There is no occasion where .
and -> may be interchanged, given the existing specification.
It should be very evident to the compiler whether the token before '.' or
'->' is a pointer to a struct/union or a struct/union, and just build the
appropriate output.
The source modification for the compiler is very slight, even depending on
flag_c2x(that's not it's name). It ends up changing a lot of existing
lines, just to change their indentation; but that shouldn't really count
against 'changed lines'.
I'm sure, after 4 score and some years ('78-19) that it must surely have
come up before? Anyone able to point me to those existing proposals?
D
Re: C2X Proposal, merge '.' and '->' C operators
This is a view of the patch/diff... This is really just +6 lines... ` if(
!flag_iso2xc) `{` `}` `attribute fallthrough` `if(flag_iso2cx)` `return
ptr`
https://github.com/gcc-mirror/gcc/pull/41/commits/915bcffdea0aa4fead66c41830b66aa3db212307
While the compiler does compile itself, and a simple test case,
successfully
```
#include
struct s {
int a, b;
};
void f( void ){
struct s S;
struct s *P = &S;
P.a = 5; // 'wrong' operator
P.b = 13; // 'wrong' operator
printf( "Output: %d %d\n", S->a, S->b ); // 'wrong' operators...
}
int main( void ) {
f();
return 0;
}
```
I haven't built the testsuite...
On Mon, Dec 16, 2019 at 5:51 AM J Decker wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct
> and union types. These operators are specified such that they are always
> paired in usage; for example, if the left hand expression is a pointer to a
> struct or union, then the operator -> MUST be used. There is no occasion
> where . and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.
>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name). It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before? Anyone able to point me to those existing proposals?
>
> D
>
Re: C2X Proposal, merge '.' and '->' C operators
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > * J. Decker: > > > Here's the gist of what I would propose... > > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da > > > > In C, there are two operators . and -> used to access members of struct > and > > union types. These operators are specified such that they are always > paired > > in usage; for example, if the left hand expression is a pointer to a > struct > > or union, then the operator -> MUST be used. There is no occasion where . > > and -> may be interchanged, given the existing specification. > > This is incompatible with C++. I don't think it's worthwhile to change > C in this way. > ya, while I only just saw this, I thought shortly after posting that c++ compatibility might be an issue; and they have separate operators overrides for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` and `lo->Get()` are interchangeable. However, if not specifically overridden it could be possible to make a similar change there. (and conversely not having the operator support the C++ back port wouldn't be an issue). It's still an error in the native language context to use '.' on a pointer or '->' on a class/struct... and the modification is really a patch to that error to just do the other thing... > > Thanks, > Florian > >
Re: C2X Proposal, merge '.' and '->' C operators
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > > > On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote: > >> * J. Decker: >> >> > Here's the gist of what I would propose... >> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >> > >> > In C, there are two operators . and -> used to access members of struct >> and >> > union types. These operators are specified such that they are always >> paired >> > in usage; for example, if the left hand expression is a pointer to a >> struct >> > or union, then the operator -> MUST be used. There is no occasion where >> . >> > and -> may be interchanged, given the existing specification. >> >> This is incompatible with C++. I don't think it's worthwhile to change >> C in this way. >> > > ya, while I only just saw this, I thought shortly after posting that c++ > compatibility might be an issue; and they have separate operators overrides > for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` > and `lo->Get()` are interchangeable. > > However, if not specifically overridden it could be possible to make a > similar change there. (and conversely not having the operator support the > C++ back port wouldn't be an issue). It's still an error in the native > language context to use '.' on a pointer or '->' on a class/struct... and > the modification is really a patch to that error to just do the other > thing... > and add -> on references? > > > >> >> Thanks, >> Florian >> >>
Re: C2X Proposal, merge '.' and '->' C operators
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote: > > > On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote: > >> >> >> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer >> wrote: >> >>> * J. Decker: >>> >>> > Here's the gist of what I would propose... >>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da >>> > >>> > In C, there are two operators . and -> used to access members of >>> struct and >>> > union types. These operators are specified such that they are always >>> paired >>> > in usage; for example, if the left hand expression is a pointer to a >>> struct >>> > or union, then the operator -> MUST be used. There is no occasion >>> where . >>> > and -> may be interchanged, given the existing specification. >>> >>> This is incompatible with C++. I don't think it's worthwhile to change >>> C in this way. >>> >> >> ya, while I only just saw this, I thought shortly after posting that c++ >> compatibility might be an issue; and they have separate operators overrides >> for -> and . (which V8 uses such that `Local lo;` `lo.IsEmpty();` >> and `lo->Get()` are interchangeable. >> >> However, if not specifically overridden it could be possible to make a >> similar change there. (and conversely not having the operator support the >> C++ back port wouldn't be an issue). It's still an error in the native >> language context to use '.' on a pointer or '->' on a class/struct... and >> the modification is really a patch to that error to just do the other >> thing... >> > and add -> on references? > My first patch was to make the . and -> interchangeable; it could be more specifically to promote '.' to be either; with the intent to deprecate -> (in like 2119). This might simplify the scope of modification to C++; to just augment the default '.' to behave as -> on a native pointer to a struct/class/union ( I'm not sure how the new safe_ptr templated things end up reacting, I'd imagine they provide operator overloads, which would take precedence... ) > > >> >> >> >>> >>> Thanks, >>> Florian >>> >>>
Re: C2X Proposal, merge '.' and '->' C operators
On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen
wrote:
> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These operators are specified such that they are always
> paired
> > in usage; for example, if the left hand expression is a pointer to a
> struct
> > or union, then the operator -> MUST be used. There is no occasion where .
> > and -> may be interchanged, given the existing specification.
> >
> > It should be very evident to the compiler whether the token before '.' or
> > '->' is a pointer to a struct/union or a struct/union, and just build the
> > appropriate output.
> >
> > The source modification for the compiler is very slight, even depending
> on
> > flag_c2x(that's not it's name). It ends up changing a lot of existing
> > lines, just to change their indentation; but that shouldn't really count
> > against 'changed lines'.
> >
> > I'm sure, after 4 score and some years ('78-19) that it must surely have
> > come up before? Anyone able to point me to those existing proposals?
> >
> What if you operate on a pointer to a pointer to a struct? Should the same
> operator just magically dereference everything until it is a struct?
>
> how does pointer to a pointer to a struct work now? Does it somehow
involve ppStruct->->a ?
> I disagree with this proposal because separate a thing and a pointer to a
> thing is fundamental to C/C++, and providing short-cuts that confuse the
> two
> is doing a disservice to anyone that needs to learn it.
>
> It's not to the assembly though.
To me, it's not a matter of it being a shorthand, but to make JS code more
portable back to C (and C++ compiled C).
> Besides isn't this the wrong mailing list for this?
>
> Probably? I thought it a better starting point than the bug list? Where
would you suggest I go? It doesn't look like C standards, unlike
es-discuss for ecma script, I couldn't find a open forum to discuss such
things... or even a github group like... https://github.com/tc39/proposals
J
> 'Allan
>
>
>
Re: would you review the srcy programming language?
Somewhat like assembly meets c99 /javascript with maybe an extended
preprocessor macro system (#declr? )
pointers rarely contain a single value, they either reference an array, or
a group of values. In the case of the latter, the pointerVarName.FieldName
pair specifies to get the value, and then any manipulation of
pointerVarName is always updating the pointer... so there isn't really a
need to have two operators to do that
I'm not neutral; I have VESL on my mind. VESL is like
blockly/scratch/snap/... except also able to create objects (structures
with elements).
I've recently come to re-learn javascript from a 2017 perspective, and have
come to learn that really the type of data in a variable is always
determined by the value that's put into the variable. Have it be any other
type than that type would catch developer errors; but with proper habits I
don't have the tendency to put a integer value in a field that should be
holding a string.
Even before learning JS I knew JSON for websocket communication. JSON
defines 3 types ( okay there's actually like 7 but...).
{ "stringValue": "String",
"numValue" : 1234,
"object" : {
},
"realNumValue" : 1234.0e-3,
"nothing" : null
"yesNo" : true/false (keywords)
}
For specific microoptimizaitons of space (like you need a whole bunch of
values that are only 0-255, specifying a byte type can be useful).
int(float), void*, bool. and struct userTypes *, and [] are the only
types I've been using for the last 15 years developing in C.
That and decoding network protocols made up of bytes, shorts, etc, type
information can be useful.
Javascript (since ES5/6) has had TypedArray, which gives you optimal
uint8Array so you can have a string of packed bytes in memory, and the JIT
gets to generate fast code to access it without boxing it into integer
types always; This is required for things like Three.jS (Really WebGL ) to
work... sending vertex information from javascript in packed float arrays
to C++ Code to openGL driver eventually...
Not that everything can entirely be done in JS. I have a C++ addon that
provides many system abstractions that Node doesn't; but making an API for
javascript to utilize is almost eaiser than making an API for C/C++ to use,
because in JS you can just make one of the objects, and dump it to see what
fields/methods it has (right then and there).
so with JSON I get named variables and values, so I don't need 'var', and
there are no parenthesis in JSON (outside of quotes). So there are no
functions/expressions.
so simply saying { myFunction : (args... ) { ... } } means I don't need
the function keyword, and the definition of a function is always
a name (paren) (args) (closeparen) followed by a code block. If there is
no code block after it (it's a close statemtn like , or ; ... or it's an
operator, then it is a call, and the arguments are expressions instead of
name definitions for the function code block.
What I lose then... is without var or function, I can't really use let or
const.
https://github.com/d3x0r/VESL/blob/master/vesl.md
But then, as a VPL (visual programming language) I really want to use text
as little as possible. Typing in names to create lables for blocks then
allows me to have a visual representaiton of that for later use, so I only
need to type each name for each class once and then I don't have to
represent 'function' 'profcedure' 'this returns a value' 'this doesn't' ...
On Mon, Mar 19, 2018 at 8:36 PM, wce teky wrote:
> hi!
>
> i'm the dotre, and i am designing a programming language,
> you may be interested at, it is general purpose, structured,
> imperative, data-driven and autonomous; i have already its
> syntax and very brief introduction as documentation. it is
> documented with google docs, but it can be downloaded
> with a browser as plain text.
>
> see you!
>
> https://drive.google.com/drive/folders/1jf_iP9F_Iz_dGSYUzx9Xz-Od24qkchMH
>
GCC 4.5.0 Reports invalid warning
This is the code.
--
#define PointerA struct a *
void f( PointerA );
typedef struct a * PA;
struct a { int x; };
void f( PA a )
{
}
-
This is the output
warning: 'struct a' declared inside parameter list
warning: its scope is only this definition or declaration, which is
probably not what you want
error: conflicting types for 'f'
note: previous declaration of 'f' was here
This is valid C code by every other compiler.
If there is already a thread about this, or a bug about it, I didn't
find it searching this lsit or the bugs database.
If I move even the 'typedef struct a *PA' above the first function,
then 'struct a' is apparently defined, even if it is not.
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
> On 16/07/2010 00:59, J Decker wrote:
>
>> --
>>
>> #define PointerA struct a *
>>
>> void f( PointerA );
>>
>> typedef struct a * PA;
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
>>
>> -
>>
>> This is the output
>>
>> warning: 'struct a' declared inside parameter list
>> warning: its scope is only this definition or declaration, which is
>> probably not what you want
>> error: conflicting types for 'f'
>> note: previous declaration of 'f' was here
>>
>>
>>
>>
>> This is valid C code by every other compiler.
>
> Not so, as far as I can tell. Comeau online says:
>
>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>> MODE:strict errors C99
>>
>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>> function
>> void f( PointerA );
>> ^
>>
>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>> f(struct a *)"
>> (declared at line 3)
>> void f( PA a )
>> ^
>>
>> 1 error detected in the compilation of "ComeauTest.c".
>
> As long as "struct a" hasn't been (forward-)declared at the time the
> declaration of f() is found, it is a different one from the "struct a" in the
> global namespace that the formal parameter on the definition of f() then
> subsequently refers to.
>
Okay so if I just move the typedef up... (which isn't exactly feasible
in the actual project)
>>
>> #define PointerA struct a *
>>
>> typedef struct a * PA;
>> void f( PointerA );
>>
>> struct a { int x; };
>>
>> void f( PA a )
>> {
>> }
Now it's happy, why can't it just define 'struct a' as an appropriate
name as it used to, the strucutre still isn't defined.
(okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
before now)
> cheers,
> DaveK
>
>
Re: GCC 4.5.0 Reports invalid warning
Oh not so bad then, I can just add at the beginning...
typedef struct a *NeverUsedDefinition;
and now it's happy? And that makes good coding how? If I never
actually use 'NeverUsedDefinition'? Actually this 'feature' now
causes useless and unused declartions to be created.
On Thu, Jul 15, 2010 at 5:21 PM, J Decker wrote:
> On Thu, Jul 15, 2010 at 5:32 PM, Dave Korn wrote:
>> On 16/07/2010 00:59, J Decker wrote:
>>
>>> --
>>>
>>> #define PointerA struct a *
>>>
>>> void f( PointerA );
>>>
>>> typedef struct a * PA;
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>>>
>>> -
>>>
>>> This is the output
>>>
>>> warning: 'struct a' declared inside parameter list
>>> warning: its scope is only this definition or declaration, which is
>>> probably not what you want
>>> error: conflicting types for 'f'
>>> note: previous declaration of 'f' was here
>>>
>>>
>>>
>>>
>>> This is valid C code by every other compiler.
>>
>> Not so, as far as I can tell. Comeau online says:
>>
>>> Comeau C/C++ 4.3.10.1 (Oct 6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
>>> Copyright 1988-2008 Comeau Computing. All rights reserved.
>>> MODE:strict errors C99
>>>
>>> "ComeauTest.c", line 3: warning: declaration is not visible outside of
>>> function
>>> void f( PointerA );
>>> ^
>>>
>>> "ComeauTest.c", line 8: error: declaration is incompatible with "void
>>> f(struct a *)"
>>> (declared at line 3)
>>> void f( PA a )
>>> ^
>>>
>>> 1 error detected in the compilation of "ComeauTest.c".
>>
>> As long as "struct a" hasn't been (forward-)declared at the time the
>> declaration of f() is found, it is a different one from the "struct a" in the
>> global namespace that the formal parameter on the definition of f() then
>> subsequently refers to.
>>
>
> Okay so if I just move the typedef up... (which isn't exactly feasible
> in the actual project)
>
>
>>>
>>> #define PointerA struct a *
>>>
>>> typedef struct a * PA;
>>> void f( PointerA );
>>>
>>> struct a { int x; };
>>>
>>> void f( PA a )
>>> {
>>> }
>
> Now it's happy, why can't it just define 'struct a' as an appropriate
> name as it used to, the strucutre still isn't defined.
>
> (okay every other compiler I mention is MSVC, OpenWatcom, lcc, and gcc
> before now)
>
>> cheers,
>> DaveK
>>
>>
>
Re: GCC 4.5.0 Reports invalid warning
On Thu, Jul 15, 2010 at 6:08 PM, Dave Korn wrote: > On 16/07/2010 01:31, J Decker wrote: >> Oh not so bad then, I can just add at the beginning... >> >> typedef struct a *NeverUsedDefinition; >> >> and now it's happy? And that makes good coding how? > > No, that would be bad coding. Just forward-declare the tag: > > struct a; > > before you try and use it in a function's formal parameter list. > > The declarations in a function's formal parameter list are in a more inner > scope than file scope, so if there isn't a tag declaration at file scope yet, > you're talking about a new tag declaration limited only to the scope in which > it is declared - the function declaration (argument list and body, if present; > just argument list in the case of a prototype). > > When you later do declare a "struct a" tag at file scope, the later > definition of f() "inherits" that one from the more global scope, just like it > would "inherit" the name of a global variable from the enclosing scope. In > the C language spec: > > 6.7.2.3#4: "All declarations of structure, union, or enumerated types that > have the same scope and use the same tag declare the same type." > Then how does this result in the warnings even that type 'struct a' does not match target 'struct a'? (or some paraphrase of that, this sample code did not generate exactly the same warnings as the full project. How could two definitions of struct a be defined? > 6.7.2.3#5: "Two declarations of structure, union, or enumerated types which > are in different scopes or use different tags declare distinct types." > Okay, and how is this out of scope? it's a global prototype, and the struct must without question also be defined in said global scope. When would it ever be something other than this? Although I did go back and read the error more appropriately. Okay I'm leaving this list. > > cheers, > DaveK > >
Re: Guidance needed: hi-level steps to track an object until its destruction
Just out of curiosity - isn't this what C# does with objects? would it perhaps be something like that in how mcs (mono) builds objects and tracks their lifespan? On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker wrote: > >> I am not sure that is easily feasible. I would believe it is impossible. >> >> Within the compiler (or inside a GCC plugin, or inside a GCC extension >> coded in MELT), you probably are able change/inspect C++ classes& every >> other declaration any compiler is tracking. You are also able to find >> every occurrence of variables containing a pointer to such classes. > >> >> However, you are apparently willing to track a single *instance* of such >> a class, and this instance is in the execution of the compiled program >> [not inside the compiler]. This means that you are able to deal with all > > > To put it in other words: Here the issue is seeking runtime information at > compile time. An object is a run time entity. At compile time, we only see > the class. However, we also see the statements that create an object and > manipulate it. Although it is not possible to track each object distinctly, > a compile time approximation is certainly possible. And that is where > creativity > in compiler research lies. The better the approximations, the better the > gains. > For example, all objects that get created by a given statement can be > treated > alike. There is no way of distinguishing between them at compile time, but > perhaps > there is no need to do so because all of them are likely to be treated alike > at run time. if an object O1 and O2 are created by the same statement, > asking > the question whether a method m1 is invoked for O1 does not need us to > distinguish > between O1 and O2. > > To summarize, a good approximation is indeed possible at compile time. > > >> the aliasing& pointer equivalence issues (a task known to be >> impossible). How can the compiler surely know that pointer p in [a >> particular instruction of] method YourClass::foo() is never (or >> sometimes, or always) pointing to the same instance -in the running >> process of the compiled program- as pointer q in method yourclass::bar() > > Basile, you keep mentioning that English is not your first language and I > appreciate your politeness for reminding the reader for that (English is not > the first language for me too). It is in that light that I would like to > point > out that your use of word "impossible" is a little too strong. Perhaps you > mean > difficult. It is impossible if you want exact information. However, if > imprecisions can be tolerated for some gains, excellent approximations are > possible _within_ a procedure body which is what Jeff asked for, to begin > with. > > We have been working on this problem (pointer analysis) for a while but > are quite far from production implementation. Our ideas now seem to mature > a bit and whenever we have a conference paper, I will be happy to share it > with the gcc folks. > >> Or maybe you want to instrument your compiler so that for every code >> emitted for method yourclass::gee() you add a first block which checks >> that the this reciever is not a given pointer. >> >> In other words& C++ parlance, you could (this is doable, but not >> trivial) hack the compiler so that at the start of every method (i.e. >> member function in C++) the equivalent of the following C++ code has >> been magically added >> >> extern "C" YourClass* hunted_yourclass_pointer; >> extern "C" void some_error_routine(void); >> >> if (this == hunted_yourclass_pointer) >> some_error_routine(); > > This is a very good way of paraphrasing the "ideal" requirement. > > Regards, > > Uday. >
Re: array of pointer to function support in GNU C
On Wed, Sep 15, 2010 at 11:15 PM, ir_idjit wrote:
>
> i've been writing bits of codes where it requires to have an array or
> "pointers to functions", so the decision of which function to execute is
> indexed... (i know, a lot of you will say "well, that's a VERY specific of a
> solution, there's always the problem of binary compatibility when passing
> arguments for different argument-taking functions, blah, blah, blah... just
> rely on good old fashioned function calls with conditional statements..."
> but, pls, forget about that sort of incompatibility...)
>
> even if i hadn't tried it in C++, i know it should work as i've seen some
> examples posted on the net. but i'm trying to write my code in GNU C, so it
> could be compiled by GCC -- god knows i would never try to compile it in GNU
> C++; that gargantuan thing
>
> but whatever i do it i just can't get it to work
> code:
>
> some_header.h:
> static void *(*oper_table)(void **);
>
>
>
> main.c:
> int main(void)
> {
> oper_table[0]; /* just a test. data is not used or modified*/
oper_table[0](NULL); // you decoared it to receive a parameter... and
even if it didn't you'd need ().
> return 1;
> }
>
> error: subscripted value is pointer to function
>
>
>
>
> whereas:
> int main(void)
> {
> void *(*func)(void **);
> func;
strange that this does anything... since it also requires a pointer to
a pointer...
> return 1;
> }
>
> compiles just fine
>
> i do realize that i'm depending on dialect-specific features, so i don't
> even know if this is supported on my gcc as of version 4.3.3. if it's not a
> dialect problem, then this stumps me even more.
> --
> View this message in context:
> http://old.nabble.com/array-of-pointer-to-function-support-in-GNU-C-tp29725303p29725303.html
> Sent from the gcc - Dev mailing list archive at Nabble.com.
>
>
signed/unsigned comparison warning level
Can the severity of signed/unsigned comparisons be raised, since GCC
does not properly handle the comparisons.
Every example below is false compiled with gcc 4.5.0
int main()
{
int s = -2;
unsigned int u = 0xFFFDU;
if( s < u )
printf( "okay\n" );
else
printf( "incorrect handling\n" ); // gets here
{
int i = -2;
unsigned u = 2;
if (i < u) {
// Does GCC get here? no, it doesn't
printf( "Ya, of course\n" );
}
else
printf( "gcc puked\n" ); // gets here
}
{
unsigned int i = -3;
if( i < 0 )
printf( "this can't happen, it's unsigned.\n" );
else
printf( "this is actually a correct result here\n" ); // does
get this
}
{
int i = -3;
// visual studio does not warn on this one either... just the first
two comparisons
if( i < (unsigned)0 )
printf( "-3 is < 0 \n" );
else
printf( "-3 is more than 0?\n" ); // gets here
}
return 0;
}
---
I said a lot of words on
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/d0ec33f0-2534-48f8-9673-538d68d8ef86
to describe how this might be handled and even if 5% of the cases
were fixed, it would be 250% better overall.
I don't know why standards left this open, other than there isn't a
single-instruction translation from code to CPU for the comparison;
But if it's not fixed, this warning should definatly be issued at
default warning level. This should be more like 'if this comparison
can be wrong, it will be wrong'.
Re: signed/unsigned comparison warning level
> The standards did not leave this open. They define precisely what is > supposed to happen. > Really? I'll have to drop this whole lobbying effort then. That makes me sad that they didn't define it to be comparing of the numbers where there are overlaps in signed and unsigned instead of causing all negative signed values to be wrong. > >> But if it's not fixed, this warning should definatly be issued at >> default warning level. This should be more like 'if this comparison >> can be wrong, it will be wrong'. > > There is no problem comparing values of signed type with values of > unsigned type if the signed values are known to be nonnegative. Of > course it is sometimes hard to know that; hence the warning. But > enabling the warning by default does not make sense. > It's exactly the fact that 'of course it is sometimes' that makes the warning make more sense to be on by default. I don't always know that I've added an unsigned value to an expression, causing one side of a comparison to become unsigned, resulting in 100% failure on negative signed result comparison. > Ian >
Re: signed/unsigned comparison warning level
unless x is an integer larger than 1/2 UINT_MAX... then it's still a bad test. it's safer to test if the signed is less than 0 otherwise cast that to unsigned. On Sun, Sep 26, 2010 at 10:06 PM, foxmuldrs...@yahoo.com wrote: > Use the explicit override if you need signed comparison. > > unsigned int x; > int y; > if ((int)x < y) > > -Rick > > -Original message- > > From: J Decker > To: Ian Lance Taylor > Cc: gcc@gcc.gnu.org > Sent: Mon, Sep 27, 2010 05:51:56 GMT+00:00 > Subject: Re: signed/unsigned comparison warning level > >> The standards did not leave this open. They define precisely what is >> supposed to happen. >> > Really? I'll have to drop this whole lobbying effort then. That > makes me sad that they didn't define it to be comparing of the numbers > where there are overlaps in signed and unsigned instead of causing all > negative signed values to be wrong. > >> >>> But if it's not fixed, this warning should definatly be issued at >>> default warning level. This should be more like 'if this comparison >>> can be wrong, it will be wrong'. >> >> There is no problem comparing values of signed type with values of >> unsigned type if the signed values are known to be nonnegative. Of >> course it is sometimes hard to know that; hence the warning. But >> enabling the warning by default does not make sense. >> > > It's exactly the fact that 'of course it is sometimes' that makes > the warning make more sense to be on by default. I don't always know > that I've added an unsigned value to an expression, causing one side > of a comparison to become unsigned, resulting in 100% failure on > negative signed result comparison. > > >> Ian >> >
